CAS newbie

[Supriya]

Hi,
I am facing a problem of failure to assert unrestricted permissions for a
resource from asp.net.
The scenario is like this:
I have a custom assembly which connects to windows active dicrectory using
..Net Directory Services. I plug this into reporting services and create a
code group to give full trust permissions to that dll. This works in our QA
environment but not in production.
I get an LDAP error, "An operations error occured" in production when I bind
the LDAP connection with the default identity that is running the report
manager.

DirectoryEntry _RootDSE = new DirectoryEntry("LDAP://RootDSE");

Now if I give a specific username and password with which to bind the
connection,

DirectoryEntry _RootDSE = new DirectoryEntry("LDAP://RootDSE", _username,
_password);

I get the following code access security exception at the point in code
where I assert unrestricted permissions to DirectoryServices:

"Request for the permission of type
System.Security.Permissions.EnvironmentPermission, mscorlib,
Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 failed."

Now I need to achieve one of two things. Either I get enough permissions for
the default context so that it can bind to Ldap or I give sufficient rights
to assembly such that the perm.Assert() command does not fail.
I'm swimming in new waters here. I'd appreciate any help.
Thanks a million,
Supriya

 

[Joe Kaplan]

I can address the S.DS issue. I'm not sure why exactly the CAS stuff is
causing you problems here. It appears that you may need to assert more than
the directory services permission in your code to do what you want, as the
permission demand that is failing is for EnvironmentPermission, which is not
what you said you asserted.

The issue with the credentials for the DirectoryServices call has to do with
the security context under which the current thread is executing. Depending
on how SSRS is configured, it is either running as the process identity or
an impersonated identity of the currently authenticated Windows users in the
application. You can determine this by looking at the value of
System.Security.Principal.WindowsIdentity.GetCurrent().Name before you
create the DirectoryEntry.

If you are impersonating, then you will likely need to implement Kerberos
delegation to get this to work, as users authenticated via Windows
Integrated Authentication in IIS cannot have their credentials used to
access a remote resource by an intermediate service unless that service has
rights to delegate.

If you aren't impersonating, then app pool identity will be used. This is
likely the Network Service account, which will use the machine account in
the domain to access the directory when using the network. It should have
rights to query the directory, so that should work, although you may need to
add a domain name to your binding string to get it to determine what domain
to use. That might look like LDAP://domain.com/RootDSE.

I'm guessing you are impersonating here, so I'd explore that option first.

Joe K.

 

[Supriya]

Thanks very much for your response, Joe.
The only thing that concerns me is that my assembly works on our integration
machine and fails only in production. The production web site is a two server
cluster. Would this affect security levels in any way?

Thanks again,
Supriya

 

[Joe Kaplan]

The cluster should not affect the CAS settings. Only the CAS policy would
do that. My guess is that something is different there.

The issue with System.DirectoryServices is also likely to be a configuration
or environmental difference, but I don't know if that has something to do
with the cluster or if it is just a difference in the server configurations.

The steps I suggested to determine the security context of the current
thread are the best way to diagnose what is going on.

Joe K.

 

[Supriya]

You are right, Joe. I guess the report server does use impersonation. Could
you point me to some article or resource on the web on Kerberos delegation?

Regards,
Supriya

 

[Joe Kaplan]

There is a bunch of stuff on this on TechNet. Here's one link:

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerberr.mspx

There have also been some good MSDN magazine articles on configuring
Kerberos delegation.

Give it a shot and post back if you get stuck. It can be a little painful
and difficult to troubleshoot.

Joe K.

 

[Supriya]

Thanks again, Joe. I'll go thru' this in the morning.
Have 2 last questions :
1. Does it help to set trust levels of an assembly to full trust using .Net
framework 1.1 wizard, and
2. Does it make a difference to sign the assembly. Are permissions for
signed assemblies less restrictive? My assembly in production wasn't signed.

Thanks
Supriya

 

[Joe Kaplan]

It really depends on what you are trying to do. First, CAS is not my
specialty, so take what I say with a grain of salt.

In general, it is hard to use S.DS without full trust. In .NET 1.1, the
assembly that calls S.DS at a minimum must have full trust because S.DS does
not allow partially trusted callers at all. In .NET 2.0, this restriction
is lifted. However, the other problem is that the DirectoryPermission is
not part of any of the default permission sets, so you always have to
customize something to use S.DS under partial trust.

Generally, the easiest way to delegate rights to a specific assembly is with
a URL membership condition pointing to the file system. However, strong
name membership conditions are easier to manage, so signing your assembly
with a strong name key an then building the permission set based on that is
probably the way to go from a CAS perspective. You'll also need to Assert
the DirectoryPermission and all of the other permissions that will be
demanded in order to prevent a stack walk back into the rest of the code.

All in all, it is pretty complicated. I try to stick with full trust for
Directory Services.

Joe K.