Re: Configuration Differences

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

Date: Tue, 23 Nov 2004 06:37:05 -0800

This style*** 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 style*** would run?

"Joe Kaplan (MVP - ADSI)" wrote:

> 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" <Matt@discussions.microsoft.com> wrote in message
> news:F1605619-6B14-4523-98F4-D00C17356511@microsoft.com...
> > 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?
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
>

Quantcast