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.

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

[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.

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

>
>

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

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

> >
> >

>
>
>

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

>>
>>
>>

[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)" 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?
> >> >
> >> >
> >>
> >>
> >>

>
>
>

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

>>
>>
>>

[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)" 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?
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>

>
>
>

[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" <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
> 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)" 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?
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>

>>
>>
>>

[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)" 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
> > 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)" 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?
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>

>
>
>

[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" <Matt@discussions.microsoft.com> wrote in message
news:6BE3BC16-D566-4BBF-9EF5-1C29A6B83E3F@microsoft.com...

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

>>
>>
>>

[Matt]

Joe, thanks for your help!

"Joe Kaplan (MVP - ADSI)" wrote:

> 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" <Matt@discussions.microsoft.com> wrote in message
> news:6BE3BC16-D566-4BBF-9EF5-1C29A6B83E3F@microsoft.com...

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

>
>
>