Configuration Differences

[Matt]

I have two sites on separate servers configured. When I query a page that
returns information on security/user context, I get two different replies.

On Server 1:
HttpContext.Current.User.Identity
Name
IsAuthenticated False
AuthenticationType

WindowsIdentity.GetCurrent()
Name MACHINENAME\IUSR_MACHINENAME1
IsAuthenticated True
AuthenticationType NTLM

Thread.CurrentPrincipal.Identity
Name
IsAuthenticated False
AuthenticationType


On Server 2:
HttpContext.Current.User.Identity
Name DOMAIN\USER
IsAuthenticated True
AuthenticationType Negotiate

WindowsIdentity.GetCurrent()
Name DOMAIN\USER
IsAuthenticated True
AuthenticationType NTLM

Thread.CurrentPrincipal.Identity
Name DOMAIN\USER
IsAuthenticated True
AuthenticationType Negotiate

--

My question is what is the likely configuration that is created these
differing scenarios. I have not been able to locate the entries in
machine.config,web.config or system.config that would be causing this since
most of these files have the default configuration. Also, which of the above
could I expect to see as a default configuration on a web in IIS?

 

[Joe Kaplan \(MVP - ADSI\)]

My guess is that anonymous access is enabled in IIS on server 1 and is not
on server 2.

Joe K.

 

[Paul Glavich [MVP - ASP.NET]]

I think Joe is spot on. The only thing to add is that impersonation is
enabled in both web.config files as well.

 

[Matt]

I checked both sites. Both have Anon access enabled via IIS Mgr. Both sites
are using a domain-level account and the web.config on both is set to
impersonate. The behaviors on each are still different. Are there other
things I can check? Also, when the impersonation is enabled in web.config,
is it the user specified in the "Enable Anon Access" dialog that is
impersonated? Are there other settings in the machine.config and
security.config that may impact this?

 

[Joe Kaplan \(MVP - ADSI\)]

Are you certain the second site doesn't have Windows Integrated
Authentication enabled? The results you got indicate that someone was
authenticated by IIS (unless some special code ran that changed Context.User
to a Windows account).

When impersonation is enabled, ASP.NET will impersonate the account that was
authenticated by IIS. If anonymous access was enabled, then the anonymous
user account is impersonated. This is assuming that you haven't specified
the user and password attributes in that tag.

Joe K.

 

[Matt]

Thanks for your response. I am still trying to isolate the exact lines
responsible for this difference. However, copying one system's
security.config to the other and restarting IIS seems to have addressed the
problem I am having. I believe there was just a lower level difference in
permissions granted to the Intrenet_Zone code group.

Thanks again for your help.

 

[Joe Kaplan \(MVP - ADSI\)]

I don't see how that would make a difference unless the web sites are
running with partial trust. Do your web.config files use the securityPolicy
element in them?

Joe K.

 

[Matt]

The security.config is relevant since in the security.config that works, the
ALL_CODE branch was granted FullTrust. While this is a horrible
configuration to have, and not one I intend to allow, it has raised some
questions as to how this is working. When I set every other Zone to
FullTrust, one at a time, and run the web application, I receive the errors
while calling any W32 APIs. The moment I allow FullTrust on All_Code, the
application suddenly works without a hitch. The calls made range from
ReleaseHtc in gdi32.dll throwing SecurityExceptions to getting the hostname
throwing DnsPermission errors.

For background, my c# code is creating an Xsl document object and also an
instance of a referenced c# object. I am passing the c# object into the
stylesheet as a parameter and using its methods from inside the stylesheet
during transformation of data. It would appear that those calls are without
Zone context and only the All_Code section applies. FullTrust assigned at
any other level has no effect on it. This same methodology works just fine
when running as an executable. Very confused at this point....Ideas?

 

[Joe Kaplan \(MVP - ADSI\)]

I'm not really familiar with the CAS security model that is used with the
XslTransform class, but it appears that it needs a variety of permissions to
run. The evidence that will be associated with it depend on where the
tranform is loaded from, so if it is loaded from the local machine, it will
probably get Full Trust. If you want the tranform to run with partial
trust, I'm not sure what you need to do.

Personally, I'm not that big of a fan of running web applications in partial
trust because I use a lot of assemblies that don't allow partially trusted
callers and that makes the process very painful, but I can understand why it
is desirable. An option for you might be to do the XSLT under full trust
and run the rest of the web application under partial trust to help get
around these issues.

HTH,

Joe K.

 

[Matt]

This stylesheet is built dynamically, using information from a database using
user defined rules. Do you know how I can have an affect on the context in
which such a dynamically generated stylesheet would run?

 

[Joe Kaplan \(MVP - ADSI\)]

Unfortunately, I don't know much about them at all. This would probably be
a good question for one of the XML groups though. Someone else here might
know more about it too. You might try starting a new thread talking about
XslTransform class and CAS.

Joe K.

 

[Matt]

Joe, thanks for your help!

Unfortunately, I don't know much about them at all. This would probably be
a good question for one of the XML groups though. Someone else here might
know more about it too. You might try starting a new thread talking about
XslTransform class and CAS.

Joe K.