Re: Configuration Differences

From: Matt (Matt_at_discussions.microsoft.com)
Date: 11/22/04 

Date: Mon, 22 Nov 2004 14:49:06 -0800

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
style*** as a parameter and using its methods from inside the style***
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)" wrote:

> 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" <Matt@discussions.microsoft.com> wrote in message
> news:A7B2AE4D-16BC-4CDD-AEE9-A5D5ECB3C761@microsoft.com...
> > 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)" wrote:
> >
> >> 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" <Matt@discussions.microsoft.com> wrote in message
> >> news:03FCAD6B-DA13-42AB-962D-2450554CCBBA@microsoft.com...
> >> >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?
> >> >
> >> > "Paul Glavich [MVP - ASP.NET]" wrote:
> >> >
> >> >> I think Joe is spot on. The only thing to add is that impersonation is
> >> >> enabled in both web.config files as well.
> >> >>
> >> >> --
> >> >> - Paul Glavich
> >> >> Microsoft MVP - ASP.NET
> >> >>
> >> >>
> >> >> "Joe Kaplan (MVP - ADSI)" <joseph.e.kaplan@removethis.accenture.com>
> >> >> wrote
> >> >> in message news:ur$6x8pzEHA.2568@TK2MSFTNGP10.phx.gbl...
> >> >> > My guess is that anonymous access is enabled in IIS on server 1 and
> >> >> > is
> >> >> > not
> >> >> > on server 2.
> >> >> >
> >> >> > Joe K.
> >> >> >
> >> >> > "Matt" <Matt@discussions.microsoft.com> wrote in message
> >> >> > news:69AEF6B7-159E-4739-96E9-7E8A9F24C05A@microsoft.com...
> >> >> > >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?
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
>