Impersonation and File Permission problems

I know your about 10 fold smarter than I am, but I think I disagree with
that. maybe you can clear it up for me.

as a reference I was looking at the IIS 6 arch in MSDN
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library...S/93ddb

based on that:
inetinfo *is* IIS
svchost contains the web service process (not sure what file it loads)
w3wp is the worker process (app pool) which executes the code. which by
default runs as Network Services.

I haven't been able to really find good info on this in MSDN but my gut is
telling me that the web service (svchost in this case) is what does the file
permission check (the web security stuff, in this case integrated security)
and once the user is allowed to execute the file (directory security of the
website) it is then tossed off to the w3wp process to be executed (the bit
about asp.net being an ISAPI makes sense)

now here is where I kind of get confused. I have tried to run things (like
powershell) in my application and tried the web.config identity stuff (that
seems to either work with, or override the setting in IIS) and I have also
tried to code an impersonate (that kb you listed, which works with
windows/console based apps but doesn't seem to work with IIS6) but no matter
what I do, the code always executes under the context of the app pool
(network services)

I think there might be some differences with how IIS5 handles that vs. IIS6
because from what I can tell IIS5 works more like how your describing.

also there is one other bit that has an effect on this, and that's Kerberos
delegation.. and I'll leave that alone for now because I don't understand
what part it plays in this, mostly because I don't fully understand the work
flow of security here...

more than willing to hear some more of your insight

Thanks
Justin


"David Wang" <w3.4you.RemoveThis@gmail.com> wrote in message
news:1193958187.092549.196150@e34g2000pro.googlegroups.com...
> On Nov 1, 2:48 pm, "Pablo Montilla" <mel....RemoveThis@odyssey.com.uy> wrote:
>> Thanks for your reply, I answer below...
>>
>> On Thu, 01 Nov 2007 19:13:57 -0200, David Wang <w3.4....RemoveThis@gmail.com> wrote:
>> > By default, Application Pools on IIS6 run as Network Service. So, your
>> > test server has non-default configuration which does not match
>> > production. That can cause behavior differences.
>>
>> That's strange, I won't say I didn't fiddle with the app pools, but they
>> all say they are running using the NetworkService account...
>>
>> > ASP.Net happens to make this configurable by the user via the
>> > <identity> section, and its inheritance level is defined within
>> > machine.config of the .Net Framework version the application uses. By
>> > default, ASP.Net uses the process identity, but you can configure it
>> > to behave in other ways and at different levels (webroot-wide, per-
>> > application, etc). See:
>>
>> I had the <identity> set to impersonate in the web.config for the app,
>> but
>> still it didn't work.
>>
>> >http://support.microsoft.com/kb/306158
>>
>> > I hope this explains what is going on so that you can ensure the
>> > appropriate configurations.
>>
>> What I *think* it's happening now is (given a request for an aspx file):
>> 1. IIS (NetworkService) checks permissions using client credentials.
>> 2. w3wp (NetworkService) reads aspx and web.config contents. Sees it
>> needs
>> to impersonate.
>> 3. w3wp (Client credentials) runs the aspx code.
>>
>> I'll have a go at the links you've sent, so I can get a better picture of
>> what is going on.
>>
>> Am I close to understand what's happening? I'm getting mad! ;o)
>>
>> Many thanks for your time,
>> Pablo
>>
>> --
>> Pablo Montillawww.odyssey.com.uy
>
>
> The permissions and entities you attribute to actions are not quite
> correct. You want to first read many of my blog entries (see the quick
> links bar on the left of my blog) to figure out the right entities and
> relationship within IIS and ASP.Net. You should then see what is awry
> with what you just said.
>
> Neither IIS nor w3wp.exe run ASPX code
> w3wp.exe *IS* IIS
> IIS runs with Process Identity until it runs ISAPI or does security
> checks
> IIS launches ISAPI with impersonated client credentials
> ISAPI decides what thread token to execute code
> ASP.Net is an ISAPI
> ASP.Net uses <identity> to allow user to decide what thread token it
> uses to execute ASPX page
>
>
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>
 >> Stay informed about: Impersonation and File Permission problems 

On Nov 2, 9:56 pm, "Pablo Montilla" <mel... DeleteThis @odyssey.com.uy> wrote:
> Aha! Stupid me, sorry. I think I get it now, but there's something I
> still don't understand.
>
> If as you say, IIS launches the ASPNET ISAPI impersonated with the client
> credentials, then why does ASPNET fail until I give NetworkService read
> access to the files I wish to protect? My web.config has the impersonate
> tag, and the aspx writes to the output the current thread identity, and it
> is what I provided in the browser, so in the end it is impersonating, but
> what happens in the middle?
>
> I've renamed one of the failing aspx files to html (so ASPNET's ISAPI was
> not involved), and they passed through fine, and access checks were done,
> giving access only to accounts in the group with read access, and denying
> it to accounts not in the group. When I renamed it back to aspx, it didn't
> work until I gave read access to NetworkService...
>
> Can you please explain what's going on?
>
> Many thanks for your patience and time,
> Pablo
>
> --
>
> The one function that TV news performs very well is that when there
> is no news we give it to you with the same emphasis as if there were.
> -- David Brinkley
>
> Pablo Montillawww.odyssey.com.uy


> If as you say, IIS launches the ASPNET ISAPI impersonated with the client
> credentials, then why does ASPNET fail until I give NetworkService read
> access to the files I wish to protect? My web.config has the impersonate



It's not if. IIS *does* launch all ISAPI Extensions, including ASP.Net
ISAPI, impersonated with the client credentials. What is non-obvious
is that ASP.Net ISAPI DLL strips OFF the impersonation token and run
with the process identity... until it reads the <identity> property
and go "oh, I need to put the impersonation back on again".

Furthermore, IIS has (I forget if it was fixed) a habit of touching
the script file itself when you have "Check if File Exists" checked
for an Application Mapping.

Remember, .Net is really flakey when it comes to Windows security
model. For example of that, see how impersonated user tokens just
disappear on .Net Async completions -- because the completion thread
has no idea what token the original thread used (it's not necessarily
the same thread -- this is Async IO).

I'm not saying that your expectations are improper. I'm just saying
that .Net is not so happy with the whole idea of Impersonation. And it
ends up showing up in situations like this.

In the end, the easiest thing to remember is to give IIS_WPG read
access to everything you ever want to serve over the web. If you want
to isolate, you may use the specific Application Pool Identity
(instead of IIS_WPG) to ACL.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//
 >> Stay informed about: Impersonation and File Permission problems 

Aha! Stupid me, sorry. I think I get it now, but there's something I
still don't understand.

If as you say, IIS launches the ASPNET ISAPI impersonated with the client
credentials, then why does ASPNET fail until I give NetworkService read
access to the files I wish to protect? My web.config has the impersonate
tag, and the aspx writes to the output the current thread identity, and it
is what I provided in the browser, so in the end it is impersonating, but
what happens in the middle?

I've renamed one of the failing aspx files to html (so ASPNET's ISAPI was
not involved), and they passed through fine, and access checks were done,
giving access only to accounts in the group with read access, and denying
it to accounts not in the group. When I renamed it back to aspx, it didn't
work until I gave read access to NetworkService...

Can you please explain what's going on?

Many thanks for your patience and time,
Pablo

--


The one function that TV news performs very well is that when there
is no news we give it to you with the same emphasis as if there were.
-- David Brinkley

Pablo Montilla
www.odyssey.com.uy
 >> Stay informed about: Impersonation and File Permission problems 

Let me clear up some confusions: That document only states at a high-
level the components, not how they interact.

My prior newsgroup post applies to all IIS versions past, present, and
future. It is how IIS Core Request Processing Pipeline, ISAPI, and
ASP.Net work, and I highly doubt these fundamental aspects will change
in the future. You may want to rethink what I have said, if you think
I described an IIS5-specific model.

What has changed through time is the organization of that code in
different processes -- for performance, scalability, security reasons.
Without getting into the nitty gritty details (let's get the concepts
straight first, then worry about the one-off details):

In IIS5, IIS5.1, and IIS6 running in IIS5 Compatibility Mode:
1. All requests funnel through to inetinfo.exe in user mode (For IIS6,
HTTP.SYS is configured to funnel all requests to inetinfo.exe -- you
can view IIS6 in IIS5 Compatibility Mode as HTTP.SYS being told there
is one worker process called "inetinfo.exe" that handles all user-mode
requests)
2. Request is parsed and processed inside of inetinfo.exe UNTIL it
comes time to execute the handler specified by an Application Mapping
to do the real work. AuthN/AuthZ checks are done at various stages of
this processing.
3. Depending on Application Isolation, that handler is either:
- Low: load and execute in inetinfo.exe
- Medium: load in one specific dllhost.exe
- High: load in its own dllhost.exe
4. Response is sent back out and logged by inetinfo.exe

In IIS6 running in Worker Process Isolation Mode and IIS7:
1. All requests are funneled through HTTP.SYS in kernel mode. Request
headers are completely parsed by HTTP.SYS to determine appropriate
Application Pool. WAS (Web Activation Service) in svchost.exe
configures HTTP.SYS to direct whether a new w3wp.exe needs to be
started or an existing w3wp.exe already exists to handle requests to
that Application Pool, and the request is routed to the correct
w3wp.exe by HTTP.SYS
2. Request processing continues in user-mode w3wp.exe, which actually
processes the request and executes the handler specified by an
Application Mapping inside the w3wp.exe process. AuthN/AuthZ checks
are done at various stages of this processing.
3. Response is sent back out and logged by HTTP.SYS

As you can see, depending on IIS version:
1. Request Parsing has changed location (inetinfo.exe vs HTTP.SYS)
2. Process Activation to handle request has changed dramatically
(inetinfo.exe/mtx.exe/dllhost.exe vs svchost.exe/w3wp.exe)
3. Request Execution of Handlers has changed (dllhost.exe vs w3wp.exe)
4. Logging handling has changed (inetinfo.exe vs HTTP.SYS)

It should be clear that inetinfo.exe is not exactly IIS even though it
shows up everywhere. The correct statement is that inetinfo.exe holds
the metabase, which is IIS configuration. Think about it this way --
Windows has the Registry to hold configuration, but you don't consider
the Registry "Windows", do you?

So, I would not get too hung up on what "process" constitutes IIS. I
would focus on the entire request processing sequence and how it is
broken up into various processes. For layman reference, I would say
that w3wp.exe is IIS; In IIS5.x modes, inetinfo.exe is IIS. Because
that's where most interesting things happen.

Now, when things get into managed code (like ASP.Net and Powershell),
the idea of "impersonation" within Windows that is used by IIS becomes
less reliable. I haven't really played with that technology yet, so I
can't say anything more about it.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//











On Nov 2, 9:25 pm, "Justin Rich" <jrich....RemoveThis@yahoo.spam.com> wrote:
> I know your about 10 fold smarter than I am, but I think I disagree with
> that. maybe you can clear it up for me.
>
> as a reference I was looking at the IIS 6 arch in MSDNhttp://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Librar...
>
> based on that:
> inetinfo *is* IIS
> svchost contains the web service process (not sure what file it loads)
> w3wp is the worker process (app pool) which executes the code. which by
> default runs as Network Services.
>
> I haven't been able to really find good info on this in MSDN but my gut is
> telling me that the web service (svchost in this case) is what does the file
> permission check (the web security stuff, in this case integrated security)
> and once the user is allowed to execute the file (directory security of the
> website) it is then tossed off to the w3wp process to be executed (the bit
> about asp.net being an ISAPI makes sense)
>
> now here is where I kind of get confused. I have tried to run things (like
> powershell) in my application and tried the web.config identity stuff (that
> seems to either work with, or override the setting in IIS) and I have also
> tried to code an impersonate (that kb you listed, which works with
> windows/console based apps but doesn't seem to work with IIS6) but no matter
> what I do, the code always executes under the context of the app pool
> (network services)
>
> I think there might be some differences with how IIS5 handles that vs. IIS6
> because from what I can tell IIS5 works more like how your describing.
>
> also there is one other bit that has an effect on this, and that's Kerberos
> delegation.. and I'll leave that alone for now because I don't understand
> what part it plays in this, mostly because I don't fully understand the work
> flow of security here...
>
> more than willing to hear some more of your insight
>
> Thanks
> Justin
>
> "David Wang" <w3.4....RemoveThis@gmail.com> wrote in message
>
> news:1193958187.092549.196150@e34g2000pro.googlegroups.com...
>
>
>
> > On Nov 1, 2:48 pm, "Pablo Montilla" <mel....RemoveThis@odyssey.com.uy> wrote:
> >> Thanks for your reply, I answer below...
>
> >> On Thu, 01 Nov 2007 19:13:57 -0200, David Wang <w3.4....RemoveThis@gmail.com> wrote:
> >> > By default, Application Pools on IIS6 run as Network Service. So, your
> >> > test server has non-default configuration which does not match
> >> > production. That can cause behavior differences.
>
> >> That's strange, I won't say I didn't fiddle with the app pools, but they
> >> all say they are running using the NetworkService account...
>
> >> > ASP.Net happens to make this configurable by the user via the
> >> > <identity> section, and its inheritance level is defined within
> >> > machine.config of the .Net Framework version the application uses. By
> >> > default, ASP.Net uses the process identity, but you can configure it
> >> > to behave in other ways and at different levels (webroot-wide, per-
> >> > application, etc). See:
>
> >> I had the <identity> set to impersonate in the web.config for the app,
> >> but
> >> still it didn't work.
>
> >> >http://support.microsoft.com/kb/306158
>
> >> > I hope this explains what is going on so that you can ensure the
> >> > appropriate configurations.
>
> >> What I *think* it's happening now is (given a request for an aspx file):
> >> 1. IIS (NetworkService) checks permissions using client credentials.
> >> 2. w3wp (NetworkService) reads aspx and web.config contents. Sees it
> >> needs
> >> to impersonate.
> >> 3. w3wp (Client credentials) runs the aspx code.
>
> >> I'll have a go at the links you've sent, so I can get a better picture of
> >> what is going on.
>
> >> Am I close to understand what's happening? I'm getting mad! ;o)
>
> >> Many thanks for your time,
> >> Pablo
>
> >> --
> >> Pablo Montillawww.odyssey.com.uy
>
> > The permissions and entities you attribute to actions are not quite
> > correct. You want to first read many of my blog entries (see the quick
> > links bar on the left of my blog) to figure out the right entities and
> > relationship within IIS and ASP.Net. You should then see what is awry
> > with what you just said.
>
> > Neither IIS nor w3wp.exe run ASPX code
> > w3wp.exe *IS* IIS
> > IIS runs with Process Identity until it runs ISAPI or does security
> > checks
> > IIS launches ISAPI with impersonated client credentials
> > ISAPI decides what thread token to execute code
> > ASP.Net is an ISAPI
> > ASP.Net uses <identity> to allow user to decide what thread token it
> > uses to execute ASPX page
>
> > //David
> >http://w3-4u.blogspot.com
> >http://blogs.msdn.com/David.Wang
> > //- Hide quoted text -
>
> - Show quoted text -
 >> Stay informed about: Impersonation and File Permission problems 

On Fri, 02 Nov 2007 16:55:40 -0200, David Wang <w3.4you.TakeThisOut@gmail.com> wrote:

> It's not if. IIS *does* launch all ISAPI Extensions, including ASP.Net
> ISAPI, impersonated with the client credentials. What is non-obvious
> is that ASP.Net ISAPI DLL strips OFF the impersonation token and run
> with the process identity... until it reads the <identity> property
> and go "oh, I need to put the impersonation back on again".
>
> Remember, .Net is really flakey when it comes to Windows security
> model. For example of that, see how impersonated user tokens just
> disappear on .Net Async completions -- because the completion thread
> has no idea what token the original thread used (it's not necessarily
> the same thread -- this is Async IO).
>
> I'm not saying that your expectations are improper. I'm just saying
> that .Net is not so happy with the whole idea of Impersonation. And it
> ends up showing up in situations like this.
>

OK then, so the stupidity is within ASPNET itself. That's great to know! =)

Many, many thanks for your answers, at least I have a grip on what's
happening now.

Thanks,
Pablo

--


I knew the gun was loaded but I didn't think he'd kill.
-- Glen Frey

Pablo Montilla
www.odyssey.com.uy
 >> Stay informed about: Impersonation and File Permission problems 

Thanks, that makes good sense.

I appreciate you taking the time to lay that out for me.

as far as the one-off details is there a website or book that goes over the
flow of IIS request processing? Always looking to understand that aspect of
things better.

Thanks
Justin

"David Wang" <w3.4you DeleteThis @gmail.com> wrote in message
news:1194032061.108470.266790@i38g2000prf.googlegroups.com...
> Let me clear up some confusions: That document only states at a high-
> level the components, not how they interact.
>
> My prior newsgroup post applies to all IIS versions past, present, and
> future. It is how IIS Core Request Processing Pipeline, ISAPI, and
> ASP.Net work, and I highly doubt these fundamental aspects will change
> in the future. You may want to rethink what I have said, if you think
> I described an IIS5-specific model.
>
> What has changed through time is the organization of that code in
> different processes -- for performance, scalability, security reasons.
> Without getting into the nitty gritty details (let's get the concepts
> straight first, then worry about the one-off details):
>
> In IIS5, IIS5.1, and IIS6 running in IIS5 Compatibility Mode:
> 1. All requests funnel through to inetinfo.exe in user mode (For IIS6,
> HTTP.SYS is configured to funnel all requests to inetinfo.exe -- you
> can view IIS6 in IIS5 Compatibility Mode as HTTP.SYS being told there
> is one worker process called "inetinfo.exe" that handles all user-mode
> requests)
> 2. Request is parsed and processed inside of inetinfo.exe UNTIL it
> comes time to execute the handler specified by an Application Mapping
> to do the real work. AuthN/AuthZ checks are done at various stages of
> this processing.
> 3. Depending on Application Isolation, that handler is either:
> - Low: load and execute in inetinfo.exe
> - Medium: load in one specific dllhost.exe
> - High: load in its own dllhost.exe
> 4. Response is sent back out and logged by inetinfo.exe
>
> In IIS6 running in Worker Process Isolation Mode and IIS7:
> 1. All requests are funneled through HTTP.SYS in kernel mode. Request
> headers are completely parsed by HTTP.SYS to determine appropriate
> Application Pool. WAS (Web Activation Service) in svchost.exe
> configures HTTP.SYS to direct whether a new w3wp.exe needs to be
> started or an existing w3wp.exe already exists to handle requests to
> that Application Pool, and the request is routed to the correct
> w3wp.exe by HTTP.SYS
> 2. Request processing continues in user-mode w3wp.exe, which actually
> processes the request and executes the handler specified by an
> Application Mapping inside the w3wp.exe process. AuthN/AuthZ checks
> are done at various stages of this processing.
> 3. Response is sent back out and logged by HTTP.SYS
>
> As you can see, depending on IIS version:
> 1. Request Parsing has changed location (inetinfo.exe vs HTTP.SYS)
> 2. Process Activation to handle request has changed dramatically
> (inetinfo.exe/mtx.exe/dllhost.exe vs svchost.exe/w3wp.exe)
> 3. Request Execution of Handlers has changed (dllhost.exe vs w3wp.exe)
> 4. Logging handling has changed (inetinfo.exe vs HTTP.SYS)
>
> It should be clear that inetinfo.exe is not exactly IIS even though it
> shows up everywhere. The correct statement is that inetinfo.exe holds
> the metabase, which is IIS configuration. Think about it this way --
> Windows has the Registry to hold configuration, but you don't consider
> the Registry "Windows", do you?
>
> So, I would not get too hung up on what "process" constitutes IIS. I
> would focus on the entire request processing sequence and how it is
> broken up into various processes. For layman reference, I would say
> that w3wp.exe is IIS; In IIS5.x modes, inetinfo.exe is IIS. Because
> that's where most interesting things happen.
>
> Now, when things get into managed code (like ASP.Net and Powershell),
> the idea of "impersonation" within Windows that is used by IIS becomes
> less reliable. I haven't really played with that technology yet, so I
> can't say anything more about it.
>
>
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>
>
>
>
>
>
>
>
>
>
>
> On Nov 2, 9:25 pm, "Justin Rich" <jrich... DeleteThis @yahoo.spam.com> wrote:
>> I know your about 10 fold smarter than I am, but I think I disagree with
>> that. maybe you can clear it up for me.
>>
>> as a reference I was looking at the IIS 6 arch in
>> MSDNhttp://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Librar...
>>
>> based on that:
>> inetinfo *is* IIS
>> svchost contains the web service process (not sure what file it loads)
>> w3wp is the worker process (app pool) which executes the code. which by
>> default runs as Network Services.
>>
>> I haven't been able to really find good info on this in MSDN but my gut
>> is
>> telling me that the web service (svchost in this case) is what does the
>> file
>> permission check (the web security stuff, in this case integrated
>> security)
>> and once the user is allowed to execute the file (directory security of
>> the
>> website) it is then tossed off to the w3wp process to be executed (the
>> bit
>> about asp.net being an ISAPI makes sense)
>>
>> now here is where I kind of get confused. I have tried to run things
>> (like
>> powershell) in my application and tried the web.config identity stuff
>> (that
>> seems to either work with, or override the setting in IIS) and I have
>> also
>> tried to code an impersonate (that kb you listed, which works with
>> windows/console based apps but doesn't seem to work with IIS6) but no
>> matter
>> what I do, the code always executes under the context of the app pool
>> (network services)
>>
>> I think there might be some differences with how IIS5 handles that vs.
>> IIS6
>> because from what I can tell IIS5 works more like how your describing.
>>
>> also there is one other bit that has an effect on this, and that's
>> Kerberos
>> delegation.. and I'll leave that alone for now because I don't understand
>> what part it plays in this, mostly because I don't fully understand the
>> work
>> flow of security here...
>>
>> more than willing to hear some more of your insight
>>
>> Thanks
>> Justin
>>
>> "David Wang" <w3.4... DeleteThis @gmail.com> wrote in message
>>
>> news:1193958187.092549.196150@e34g2000pro.googlegroups.com...
>>
>>
>>
>> > On Nov 1, 2:48 pm, "Pablo Montilla" <mel... DeleteThis @odyssey.com.uy> wrote:
>> >> Thanks for your reply, I answer below...
>>
>> >> On Thu, 01 Nov 2007 19:13:57 -0200, David Wang <w3.4... DeleteThis @gmail.com>
>> >> wrote:
>> >> > By default, Application Pools on IIS6 run as Network Service. So,
>> >> > your
>> >> > test server has non-default configuration which does not match
>> >> > production. That can cause behavior differences.
>>
>> >> That's strange, I won't say I didn't fiddle with the app pools, but
>> >> they
>> >> all say they are running using the NetworkService account...
>>
>> >> > ASP.Net happens to make this configurable by the user via the
>> >> > <identity> section, and its inheritance level is defined within
>> >> > machine.config of the .Net Framework version the application uses.
>> >> > By
>> >> > default, ASP.Net uses the process identity, but you can configure it
>> >> > to behave in other ways and at different levels (webroot-wide, per-
>> >> > application, etc). See:
>>
>> >> I had the <identity> set to impersonate in the web.config for the app,
>> >> but
>> >> still it didn't work.
>>
>> >> >http://support.microsoft.com/kb/306158
>>
>> >> > I hope this explains what is going on so that you can ensure the
>> >> > appropriate configurations.
>>
>> >> What I *think* it's happening now is (given a request for an aspx
>> >> file):
>> >> 1. IIS (NetworkService) checks permissions using client credentials.
>> >> 2. w3wp (NetworkService) reads aspx and web.config contents. Sees it
>> >> needs
>> >> to impersonate.
>> >> 3. w3wp (Client credentials) runs the aspx code.
>>
>> >> I'll have a go at the links you've sent, so I can get a better picture
>> >> of
>> >> what is going on.
>>
>> >> Am I close to understand what's happening? I'm getting mad! ;o)
>>
>> >> Many thanks for your time,
>> >> Pablo
>>
>> >> --
>> >> Pablo Montillawww.odyssey.com.uy
>>
>> > The permissions and entities you attribute to actions are not quite
>> > correct. You want to first read many of my blog entries (see the quick
>> > links bar on the left of my blog) to figure out the right entities and
>> > relationship within IIS and ASP.Net. You should then see what is awry
>> > with what you just said.
>>
>> > Neither IIS nor w3wp.exe run ASPX code
>> > w3wp.exe *IS* IIS
>> > IIS runs with Process Identity until it runs ISAPI or does security
>> > checks
>> > IIS launches ISAPI with impersonated client credentials
>> > ISAPI decides what thread token to execute code
>> > ASP.Net is an ISAPI
>> > ASP.Net uses <identity> to allow user to decide what thread token it
>> > uses to execute ASPX page
>>
>> > //David
>> >http://w3-4u.blogspot.com
>> >http://blogs.msdn.com/David.Wang
>> > //- Hide quoted text -
>>
>> - Show quoted text -
>
>
 >> Stay informed about: Impersonation and File Permission problems 

I don't really know of a website or book that goes over flow of IIS
request processing.

As far as I'm aware, this information is not officially documented nor
published anywhere. No write ever came and did a brain dump from any
of us. What I disclose on my MSDN blog of IIS request processing
basically comes from my discussions with the IIS6 developers
themselves, my personal experiences with ISAPI from IIS5 through IIS7,
and my involvement with the design, development, and testing of the
IIS7 request pipeline.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//





On Nov 5, 5:06 am, "Justin Rich" <jrich... RemoveThis @yahoo.spam.com> wrote:
> Thanks, that makes good sense.
>
> I appreciate you taking the time to lay that out for me.
>
> as far as the one-off details is there a website or book that goes over the
> flow of IIS request processing? Always looking to understand that aspect of
> things better.
>
> Thanks
> Justin
>
> "David Wang" <w3.4... RemoveThis @gmail.com> wrote in message
>
> news:1194032061.108470.266790@i38g2000prf.googlegroups.com...
>
>
>
> > Let me clear up some confusions: That document only states at a high-
> > level the components, not how they interact.
>
> > My prior newsgroup post applies to all IIS versions past, present, and
> > future. It is how IIS Core Request Processing Pipeline, ISAPI, and
> > ASP.Net work, and I highly doubt these fundamental aspects will change
> > in the future. You may want to rethink what I have said, if you think
> > I described an IIS5-specific model.
>
> > What has changed through time is the organization of that code in
> > different processes -- for performance, scalability, security reasons.
> > Without getting into the nitty gritty details (let's get the concepts
> > straight first, then worry about the one-off details):
>
> > In IIS5, IIS5.1, and IIS6 running in IIS5 Compatibility Mode:
> > 1. All requests funnel through to inetinfo.exe in user mode (For IIS6,
> > HTTP.SYS is configured to funnel all requests to inetinfo.exe -- you
> > can view IIS6 in IIS5 Compatibility Mode as HTTP.SYS being told there
> > is one worker process called "inetinfo.exe" that handles all user-mode
> > requests)
> > 2. Request is parsed and processed inside of inetinfo.exe UNTIL it
> > comes time to execute the handler specified by an Application Mapping
> > to do the real work. AuthN/AuthZ checks are done at various stages of
> > this processing.
> > 3. Depending on Application Isolation, that handler is either:
> > - Low: load and execute in inetinfo.exe
> > - Medium: load in one specific dllhost.exe
> > - High: load in its own dllhost.exe
> > 4. Response is sent back out and logged by inetinfo.exe
>
> > In IIS6 running in Worker Process Isolation Mode and IIS7:
> > 1. All requests are funneled through HTTP.SYS in kernel mode. Request
> > headers are completely parsed by HTTP.SYS to determine appropriate
> > Application Pool. WAS (Web Activation Service) in svchost.exe
> > configures HTTP.SYS to direct whether a new w3wp.exe needs to be
> > started or an existing w3wp.exe already exists to handle requests to
> > that Application Pool, and the request is routed to the correct
> > w3wp.exe by HTTP.SYS
> > 2. Request processing continues in user-mode w3wp.exe, which actually
> > processes the request and executes the handler specified by an
> > Application Mapping inside the w3wp.exe process. AuthN/AuthZ checks
> > are done at various stages of this processing.
> > 3. Response is sent back out and logged by HTTP.SYS
>
> > As you can see, depending on IIS version:
> > 1. Request Parsing has changed location (inetinfo.exe vs HTTP.SYS)
> > 2. Process Activation to handle request has changed dramatically
> > (inetinfo.exe/mtx.exe/dllhost.exe vs svchost.exe/w3wp.exe)
> > 3. Request Execution of Handlers has changed (dllhost.exe vs w3wp.exe)
> > 4. Logging handling has changed (inetinfo.exe vs HTTP.SYS)
>
> > It should be clear that inetinfo.exe is not exactly IIS even though it
> > shows up everywhere. The correct statement is that inetinfo.exe holds
> > the metabase, which is IIS configuration. Think about it this way --
> > Windows has the Registry to hold configuration, but you don't consider
> > the Registry "Windows", do you?
>
> > So, I would not get too hung up on what "process" constitutes IIS. I
> > would focus on the entire request processing sequence and how it is
> > broken up into various processes. For layman reference, I would say
> > that w3wp.exe is IIS; In IIS5.x modes, inetinfo.exe is IIS. Because
> > that's where most interesting things happen.
>
> > Now, when things get into managed code (like ASP.Net and Powershell),
> > the idea of "impersonation" within Windows that is used by IIS becomes
> > less reliable. I haven't really played with that technology yet, so I
> > can't say anything more about it.
>
> > //David
> >http://w3-4u.blogspot.com
> >http://blogs.msdn.com/David.Wang
> > //
>
> > On Nov 2, 9:25 pm, "Justin Rich" <jrich... RemoveThis @yahoo.spam.com> wrote:
> >> I know your about 10 fold smarter than I am, but I think I disagree with
> >> that. maybe you can clear it up for me.
>
> >> as a reference I was looking at the IIS 6 arch in
> >> MSDNhttp://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Librar...
>
> >> based on that:
> >> inetinfo *is* IIS
> >> svchost contains the web service process (not sure what file it loads)
> >> w3wp is the worker process (app pool) which executes the code. which by
> >> default runs as Network Services.
>
> >> I haven't been able to really find good info on this in MSDN but my gut
> >> is
> >> telling me that the web service (svchost in this case) is what does the
> >> file
> >> permission check (the web security stuff, in this case integrated
> >> security)
> >> and once the user is allowed to execute the file (directory security of
> >> the
> >> website) it is then tossed off to the w3wp process to be executed (the
> >> bit
> >> about asp.net being an ISAPI makes sense)
>
> >> now here is where I kind of get confused. I have tried to run things
> >> (like
> >> powershell) in my application and tried the web.config identity stuff
> >> (that
> >> seems to either work with, or override the setting in IIS) and I have
> >> also
> >> tried to code an impersonate (that kb you listed, which works with
> >> windows/console based apps but doesn't seem to work with IIS6) but no
> >> matter
> >> what I do, the code always executes under the context of the app pool
> >> (network services)
>
> >> I think there might be some differences with how IIS5 handles that vs.
> >> IIS6
> >> because from what I can tell IIS5 works more like how your describing.
>
> >> also there is one other bit that has an effect on this, and that's
> >> Kerberos
> >> delegation.. and I'll leave that alone for now because I don't understand
> >> what part it plays in this, mostly because I don't fully understand the
> >> work
> >> flow of security here...
>
> >> more than willing to hear some more of your insight
>
> >> Thanks
> >> Justin
>
> >> "David Wang" <w3.4... RemoveThis @gmail.com> wrote in message
>
> >>news:1193958187.092549.196150@e34g2000pro.googlegroups.com...
>
> >> > On Nov 1, 2:48 pm, "Pablo Montilla" <mel... RemoveThis @odyssey.com.uy> wrote:
> >> >> Thanks for your reply, I answer below...
>
> >> >> On Thu, 01 Nov 2007 19:13:57 -0200, David Wang <w3.4... RemoveThis @gmail.com>
> >> >> wrote:
> >> >> > By default, Application Pools on IIS6 run as Network Service. So,
> >> >> > your
> >> >> > test server has non-default configuration which does not match
> >> >> > production. That can cause behavior differences.
>
> >> >> That's strange, I won't say I didn't fiddle with the app pools, but
> >> >> they
> >> >> all say they are running using the NetworkService account...
>
> >> >> > ASP.Net happens to make this configurable by the user via the
> >> >> > <identity> section, and its inheritance level is defined within
> >> >> > machine.config of the .Net Framework version the application uses.
> >> >> > By
> >> >> > default, ASP.Net uses the process identity, but you can configure it
> >> >> > to behave in other ways and at different levels (webroot-wide, per-
> >> >> > application, etc). See:
>
> >> >> I had the <identity> set to impersonate in the web.config for the app,
> >> >> but
> >> >> still it didn't work.
>
> >> >> >http://support.microsoft.com/kb/306158
>
> >> >> > I hope this explains what is going on so that you can ensure the
> >> >> > appropriate configurations.
>
> >> >> What I *think* it's happening now is (given a request for an aspx
> >> >> file):
> >> >> 1. IIS (NetworkService) checks permissions using client credentials.
> >> >> 2. w3wp (NetworkService) reads aspx and web.config contents. Sees it
> >> >> needs
> >> >> to impersonate.
> >> >> 3. w3wp (Client credentials) runs the aspx code.
>
> >> >> I'll have a go at the links you've sent, so I can get a better picture
> >> >> of
> >> >> what is going on.
>
> >> >> Am I close to understand what's happening? I'm getting mad! ;o)
>
> >> >> Many thanks for your time,
> >> >> Pablo
>
> >> >> --
> >> >> Pablo Montillawww.odyssey.com.uy
>
> >> > The permissions and entities you attribute to actions are not quite
> >> > correct. You want to first read many of my blog entries (see the quick
> >> > links bar on the left of my blog) to figure out the right entities and
> >> > relationship within IIS and ASP.Net. You should then see what is awry
> >> > with what you just said.
>
> >> > Neither IIS nor w3wp.exe run ASPX code
> >> > w3wp.exe *IS* IIS
> >> > IIS runs with Process Identity until it runs ISAPI or does security
> >> > checks
> >> > IIS launches ISAPI with impersonated client credentials
> >> > ISAPI decides what thread token to execute code
> >> > ASP.Net is an ISAPI
> >> > ASP.Net uses <identity> to allow user to decide what thread token it
> >> > uses to execute ASPX page
>
> >> > //David
> >> >http://w3-4u.blogspot.com
> >> >http://blogs.msdn.com/David.Wang
> >> > //- Hide quoted text -
>
> >> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
 >> Stay informed about: Impersonation and File Permission problems 

well thank goodness you're here

ever consider writing a book?


Justin

"David Wang" <w3.4you DeleteThis @gmail.com> wrote in message
news:1194323123.912783.315680@i38g2000prf.googlegroups.com...
>I don't really know of a website or book that goes over flow of IIS
> request processing.
>
> As far as I'm aware, this information is not officially documented nor
> published anywhere. No write ever came and did a brain dump from any
> of us. What I disclose on my MSDN blog of IIS request processing
> basically comes from my discussions with the IIS6 developers
> themselves, my personal experiences with ISAPI from IIS5 through IIS7,
> and my involvement with the design, development, and testing of the
> IIS7 request pipeline.
>
>
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>
>
>
>
>
> On Nov 5, 5:06 am, "Justin Rich" <jrich... DeleteThis @yahoo.spam.com> wrote:
>> Thanks, that makes good sense.
>>
>> I appreciate you taking the time to lay that out for me.
>>
>> as far as the one-off details is there a website or book that goes over
>> the
>> flow of IIS request processing? Always looking to understand that aspect
>> of
>> things better.
>>
>> Thanks
>> Justin
>>
>> "David Wang" <w3.4... DeleteThis @gmail.com> wrote in message
>>
>> news:1194032061.108470.266790@i38g2000prf.googlegroups.com...
>>
>>
>>
>> > Let me clear up some confusions: That document only states at a high-
>> > level the components, not how they interact.
>>
>> > My prior newsgroup post applies to all IIS versions past, present, and
>> > future. It is how IIS Core Request Processing Pipeline, ISAPI, and
>> > ASP.Net work, and I highly doubt these fundamental aspects will change
>> > in the future. You may want to rethink what I have said, if you think
>> > I described an IIS5-specific model.
>>
>> > What has changed through time is the organization of that code in
>> > different processes -- for performance, scalability, security reasons.
>> > Without getting into the nitty gritty details (let's get the concepts
>> > straight first, then worry about the one-off details):
>>
>> > In IIS5, IIS5.1, and IIS6 running in IIS5 Compatibility Mode:
>> > 1. All requests funnel through to inetinfo.exe in user mode (For IIS6,
>> > HTTP.SYS is configured to funnel all requests to inetinfo.exe -- you
>> > can view IIS6 in IIS5 Compatibility Mode as HTTP.SYS being told there
>> > is one worker process called "inetinfo.exe" that handles all user-mode
>> > requests)
>> > 2. Request is parsed and processed inside of inetinfo.exe UNTIL it
>> > comes time to execute the handler specified by an Application Mapping
>> > to do the real work. AuthN/AuthZ checks are done at various stages of
>> > this processing.
>> > 3. Depending on Application Isolation, that handler is either:
>> > - Low: load and execute in inetinfo.exe
>> > - Medium: load in one specific dllhost.exe
>> > - High: load in its own dllhost.exe
>> > 4. Response is sent back out and logged by inetinfo.exe
>>
>> > In IIS6 running in Worker Process Isolation Mode and IIS7:
>> > 1. All requests are funneled through HTTP.SYS in kernel mode. Request
>> > headers are completely parsed by HTTP.SYS to determine appropriate
>> > Application Pool. WAS (Web Activation Service) in svchost.exe
>> > configures HTTP.SYS to direct whether a new w3wp.exe needs to be
>> > started or an existing w3wp.exe already exists to handle requests to
>> > that Application Pool, and the request is routed to the correct
>> > w3wp.exe by HTTP.SYS
>> > 2. Request processing continues in user-mode w3wp.exe, which actually
>> > processes the request and executes the handler specified by an
>> > Application Mapping inside the w3wp.exe process. AuthN/AuthZ checks
>> > are done at various stages of this processing.
>> > 3. Response is sent back out and logged by HTTP.SYS
>>
>> > As you can see, depending on IIS version:
>> > 1. Request Parsing has changed location (inetinfo.exe vs HTTP.SYS)
>> > 2. Process Activation to handle request has changed dramatically
>> > (inetinfo.exe/mtx.exe/dllhost.exe vs svchost.exe/w3wp.exe)
>> > 3. Request Execution of Handlers has changed (dllhost.exe vs w3wp.exe)
>> > 4. Logging handling has changed (inetinfo.exe vs HTTP.SYS)
>>
>> > It should be clear that inetinfo.exe is not exactly IIS even though it
>> > shows up everywhere. The correct statement is that inetinfo.exe holds
>> > the metabase, which is IIS configuration. Think about it this way --
>> > Windows has the Registry to hold configuration, but you don't consider
>> > the Registry "Windows", do you?
>>
>> > So, I would not get too hung up on what "process" constitutes IIS. I
>> > would focus on the entire request processing sequence and how it is
>> > broken up into various processes. For layman reference, I would say
>> > that w3wp.exe is IIS; In IIS5.x modes, inetinfo.exe is IIS. Because
>> > that's where most interesting things happen.
>>
>> > Now, when things get into managed code (like ASP.Net and Powershell),
>> > the idea of "impersonation" within Windows that is used by IIS becomes
>> > less reliable. I haven't really played with that technology yet, so I
>> > can't say anything more about it.
>>
>> > //David
>> >http://w3-4u.blogspot.com
>> >http://blogs.msdn.com/David.Wang
>> > //
>>
>> > On Nov 2, 9:25 pm, "Justin Rich" <jrich... DeleteThis @yahoo.spam.com> wrote:
>> >> I know your about 10 fold smarter than I am, but I think I disagree
>> >> with
>> >> that. maybe you can clear it up for me.
>>
>> >> as a reference I was looking at the IIS 6 arch in
>> >> MSDNhttp://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Librar...
>>
>> >> based on that:
>> >> inetinfo *is* IIS
>> >> svchost contains the web service process (not sure what file it loads)
>> >> w3wp is the worker process (app pool) which executes the code. which
>> >> by
>> >> default runs as Network Services.
>>
>> >> I haven't been able to really find good info on this in MSDN but my
>> >> gut
>> >> is
>> >> telling me that the web service (svchost in this case) is what does
>> >> the
>> >> file
>> >> permission check (the web security stuff, in this case integrated
>> >> security)
>> >> and once the user is allowed to execute the file (directory security
>> >> of
>> >> the
>> >> website) it is then tossed off to the w3wp process to be executed (the
>> >> bit
>> >> about asp.net being an ISAPI makes sense)
>>
>> >> now here is where I kind of get confused. I have tried to run things
>> >> (like
>> >> powershell) in my application and tried the web.config identity stuff
>> >> (that
>> >> seems to either work with, or override the setting in IIS) and I have
>> >> also
>> >> tried to code an impersonate (that kb you listed, which works with
>> >> windows/console based apps but doesn't seem to work with IIS6) but no
>> >> matter
>> >> what I do, the code always executes under the context of the app pool
>> >> (network services)
>>
>> >> I think there might be some differences with how IIS5 handles that vs.
>> >> IIS6
>> >> because from what I can tell IIS5 works more like how your describing.
>>
>> >> also there is one other bit that has an effect on this, and that's
>> >> Kerberos
>> >> delegation.. and I'll leave that alone for now because I don't
>> >> understand
>> >> what part it plays in this, mostly because I don't fully understand
>> >> the
>> >> work
>> >> flow of security here...
>>
>> >> more than willing to hear some more of your insight
>>
>> >> Thanks
>> >> Justin
>>
>> >> "David Wang" <w3.4... DeleteThis @gmail.com> wrote in message
>>
>> >>news:1193958187.092549.196150@e34g2000pro.googlegroups.com...
>>
>> >> > On Nov 1, 2:48 pm, "Pablo Montilla" <mel... DeleteThis @odyssey.com.uy> wrote:
>> >> >> Thanks for your reply, I answer below...
>>
>> >> >> On Thu, 01 Nov 2007 19:13:57 -0200, David Wang <w3.4... DeleteThis @gmail.com>
>> >> >> wrote:
>> >> >> > By default, Application Pools on IIS6 run as Network Service. So,
>> >> >> > your
>> >> >> > test server has non-default configuration which does not match
>> >> >> > production. That can cause behavior differences.
>>
>> >> >> That's strange, I won't say I didn't fiddle with the app pools, but
>> >> >> they
>> >> >> all say they are running using the NetworkService account...
>>
>> >> >> > ASP.Net happens to make this configurable by the user via the
>> >> >> > <identity> section, and its inheritance level is defined within
>> >> >> > machine.config of the .Net Framework version the application
>> >> >> > uses.
>> >> >> > By
>> >> >> > default, ASP.Net uses the process identity, but you can configure
>> >> >> > it
>> >> >> > to behave in other ways and at different levels (webroot-wide,
>> >> >> > per-
>> >> >> > application, etc). See:
>>
>> >> >> I had the <identity> set to impersonate in the web.config for the
>> >> >> app,
>> >> >> but
>> >> >> still it didn't work.
>>
>> >> >> >http://support.microsoft.com/kb/306158
>>
>> >> >> > I hope this explains what is going on so that you can ensure the
>> >> >> > appropriate configurations.
>>
>> >> >> What I *think* it's happening now is (given a request for an aspx
>> >> >> file):
>> >> >> 1. IIS (NetworkService) checks permissions using client
>> >> >> credentials.
>> >> >> 2. w3wp (NetworkService) reads aspx and web.config contents. Sees
>> >> >> it
>> >> >> needs
>> >> >> to impersonate.
>> >> >> 3. w3wp (Client credentials) runs the aspx code.
>>
>> >> >> I'll have a go at the links you've sent, so I can get a better
>> >> >> picture
>> >> >> of
>> >> >> what is going on.
>>
>> >> >> Am I close to understand what's happening? I'm getting mad! ;o)
>>
>> >> >> Many thanks for your time,
>> >> >> Pablo
>>
>> >> >> --
>> >> >> Pablo Montillawww.odyssey.com.uy
>>
>> >> > The permissions and entities you attribute to actions are not quite
>> >> > correct. You want to first read many of my blog entries (see the
>> >> > quick
>> >> > links bar on the left of my blog) to figure out the right entities
>> >> > and
>> >> > relationship within IIS and ASP.Net. You should then see what is
>> >> > awry
>> >> > with what you just said.
>>
>> >> > Neither IIS nor w3wp.exe run ASPX code
>> >> > w3wp.exe *IS* IIS
>> >> > IIS runs with Process Identity until it runs ISAPI or does security
>> >> > checks
>> >> > IIS launches ISAPI with impersonated client credentials
>> >> > ISAPI decides what thread token to execute code
>> >> > ASP.Net is an ISAPI
>> >> > ASP.Net uses <identity> to allow user to decide what thread token it
>> >> > uses to execute ASPX page
>>
>> >> > //David
>> >> >http://w3-4u.blogspot.com
>> >> >http://blogs.msdn.com/David.Wang
>> >> > //- Hide quoted text -
>>
>> >> - Show quoted text -- Hide quoted text -
>>
>> - Show quoted text -
>
>
 >> Stay informed about: Impersonation and File Permission problems