Re: Configuration Differences

From: Joe Kaplan \(MVP - ADSI\) (joseph.e.kaplan_at_removethis.accenture.com)
Date: 11/23/04 

Date: Mon, 22 Nov 2004 23:16:29 -0600

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?
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>>
>>