Impersonation and File Permission problems

On Wed, 31 Oct 2007 13:03:19 -0200, Justin Rich <jrich523.DeleteThis@yahoo.spam.com>
wrote:

> from what i have learned, you cant really impersonate with web apps. the
> app
> pool overrides all of that... i worked with it for quiet some time with
> no
> luck.
>
> I basically saw the same thing you did... ran ok on my box but not in
> production. basically it ran ok because i run it from my machine which
> allowed the network service account access everything it needed to. to
> get
> around this i added the AD computer account of the server to the
> approprate
> groups that it needed for access to the resources.... not really the best
> options... and rather odd.. but the intigrated security is used to access
> the files, it has nothing to do with the running conext of the web app..
>

Thank you for replying, but I think I wasn't really clear with my problem
explanation. I want to use the client provided credentials, to give or
deny access to the aspx files on the server. The impersonation works
correctly in the ASP.NET context, I get the correct identity there, the
problem appears before.

I always thought that the credentials provided by the client where used to
check ACLs of the files in the server before sending them down the pipe.
Giving access to the network service account will make no difference in my
scenario, as I can access the aspx files simply by letting permissions
inherit from wwwroot...

What I want, is for IIS to honor the permissions set in the aspx files,
something IIS is doing in my test server, but is not doing in the
production server. The only important (I think) difference between these
servers, is that one is a standalone server working in a workgroup net,
and the other is a standalone server joined to an AD domain.

Do I need to check anything else?

Thanks,
Pablo
--


I'm just going into the card shop to look...
-- Famous Last Words

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

well if we are talking about file access then really the only thing you need
to do is turn off anonymous access withing IIS and make sure integrated is
turned on.. your not really doing any impersonating... impersonating is
running code under the context of the user. in asp.net the code is run under
the context of the app pool.

so if you just turn off the anonymous i think you should be all set. that
will use the NTFS permissions on the files to determin whether a user can
access the file or not..


"Pablo Montilla" <melkor.DeleteThis@odyssey.com.uy> wrote in message
news:op.t031oip3cj6shk@chimera.odyssey.com.uy...
> On Wed, 31 Oct 2007 13:03:19 -0200, Justin Rich <jrich523.DeleteThis@yahoo.spam.com>
> wrote:
>
>> from what i have learned, you cant really impersonate with web apps. the
>> app
>> pool overrides all of that... i worked with it for quiet some time with
>> no
>> luck.
>>
>> I basically saw the same thing you did... ran ok on my box but not in
>> production. basically it ran ok because i run it from my machine which
>> allowed the network service account access everything it needed to. to
>> get
>> around this i added the AD computer account of the server to the
>> approprate
>> groups that it needed for access to the resources.... not really the best
>> options... and rather odd.. but the intigrated security is used to access
>> the files, it has nothing to do with the running conext of the web app..
>>
>
> Thank you for replying, but I think I wasn't really clear with my problem
> explanation. I want to use the client provided credentials, to give or
> deny access to the aspx files on the server. The impersonation works
> correctly in the ASP.NET context, I get the correct identity there, the
> problem appears before.
>
> I always thought that the credentials provided by the client where used to
> check ACLs of the files in the server before sending them down the pipe.
> Giving access to the network service account will make no difference in my
> scenario, as I can access the aspx files simply by letting permissions
> inherit from wwwroot...
>
> What I want, is for IIS to honor the permissions set in the aspx files,
> something IIS is doing in my test server, but is not doing in the
> production server. The only important (I think) difference between these
> servers, is that one is a standalone server working in a workgroup net,
> and the other is a standalone server joined to an AD domain.
>
> Do I need to check anything else?
>
> Thanks,
> Pablo
> --
>
>
> I'm just going into the card shop to look...
> -- Famous Last Words
>
> Pablo Montilla
> www.odyssey.com.uy
 >> Stay informed about: Impersonation and File Permission problems 

Thanks for your reply I answer below:

On Thu, 01 Nov 2007 10:33:04 -0200, Justin Rich <jrich523.TakeThisOut@yahoo.spam.com>
wrote:

> well if we are talking about file access then really the only thing you
> need
> to do is turn off anonymous access withing IIS and make sure integrated
> is
> turned on..

That's exactly what I tried to do, but it didn't work on my production
server. The permissions are set identically (they are set via script,
actually), and the web site is configured identically too, but I can't get
it to honor the permissions. I've disabled anonymous access and enabled
integrated security in both servers, in one it works, in the other it
doesn't.

> your not really doing any impersonating.. impersonating is
> running code under the context of the user. in asp.net the code is run
> under
> the context of the app pool.
>

I don't know how the file access permissions are to be honored if the
server process doesn't change its security context when accessing files.

What I'm missing?

Pablo
--


An eccentric America is a Safe America...

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

from my understanding of this it basically goes like this...

a user requests a page from IIS and IIS checks to see if the user has access
to that page (a combo of layers here, IIS and NTFS security levels) once the
user has access to the page (the file itself) the page is then processed
(server side execution) which is where the app pool and stuff comes in.

provided you have turned off anonymous access in IIS and have the correct
permissions set for the NTFS levels you should be good. what is the error
you are getting? is it a stack trace or a standard HTTP error, like a 404?


"Pablo Montilla" <melkor.RemoveThis@odyssey.com.uy> wrote in message
news:op.t038b1t7cj6shk@chimera.odyssey.com.uy...
> Thanks for your reply I answer below:
>
> On Thu, 01 Nov 2007 10:33:04 -0200, Justin Rich <jrich523.RemoveThis@yahoo.spam.com>
> wrote:
>
>> well if we are talking about file access then really the only thing you
>> need
>> to do is turn off anonymous access withing IIS and make sure integrated
>> is
>> turned on..
>
> That's exactly what I tried to do, but it didn't work on my production
> server. The permissions are set identically (they are set via script,
> actually), and the web site is configured identically too, but I can't get
> it to honor the permissions. I've disabled anonymous access and enabled
> integrated security in both servers, in one it works, in the other it
> doesn't.
>
>> your not really doing any impersonating.. impersonating is
>> running code under the context of the user. in asp.net the code is run
>> under
>> the context of the app pool.
>>
>
> I don't know how the file access permissions are to be honored if the
> server process doesn't change its security context when accessing files.
>
> What I'm missing?
>
> Pablo
> --
>
>
> An eccentric America is a Safe America...
>
> Pablo Montilla
> www.odyssey.com.uy
 >> Stay informed about: Impersonation and File Permission problems 

I'm getting a 401. The problem is not with the ASP.NET app, as it runs
fine (and gets the correct credentials) when permissions to read is given
to the Users group (simply by inheriting the wwwroot default permissions).
I'm really baffled by this, as I don't see where's the problem. My
understanding was exactly as yours (save the part where the IIS check is
done without impersionation).

Is there any difference between the metabase configuration for an IIS in a
server in a workgroup and a server in a domain? I still see that as the
only meaningful difference between the servers. I've run this in two other
servers now, and the three of them work correctly, while the production
server won't.

Pablo

--


To do a lab really well, have your report done well in advance.

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

Using wget to get the page, I get this interaction:

HTTP request sent, awaiting response...
HTTP/1.1 401 Unauthorized
Content-Length: 1656
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
Date: Thu, 01 Nov 2007 17:05:23 GMT
Connection: keep-alive
Reusing existing connection to localhost:80.
HTTP request sent, awaiting response...
HTTP/1.1 401 Unauthorized
Content-Length: 1539
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: NTLM
TlRMTVNTUAACAAAAAAAAADgAAAACAgACQ4Fi/qaJ4GMAAAAAAAAAAAA
AAAA4AAAABQLODgAAAA8=
X-Powered-By: ASP.NET
Date: Thu, 01 Nov 2007 17:05:23 GMT
Connection: keep-alive
Reusing existing connection to localhost:80.
HTTP request sent, awaiting response...
HTTP/1.1 401 Unauthorized
Connection: keep-alive
Date: Thu, 01 Nov 2007 17:05:23 GMT
Server: Microsoft-IIS/6.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Length: 8620
Authorization failed.

The user that was used to get this is in a group wich has read access to
the aspx file. If I remove that group and add the Users group instead, I
get a 200 in the last part of the negotiation.

Checking the effective permissions for the user, I get the same
permissions when using the 'Users' or the 'O2 - Operator' group (the one
that should be ensuring access control).

I really don't get it. =(
--


We know what happens to people who stay in the middle of the road.
They get run over.
-- Aneurin Bevan

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

well, an AD server vs a standalone is slightly different and the difference
is that when you pass a username to a server in the AD it will always assume
the username is part of the domain so if you supply "justin" as your
usersname its going to assume "domain\justin" where as a standalone server
assumes "server\justin" but since you arent the one packaging or
manipulating the creds this shouldnt be the issue.

and actually its rather odd your getting a 401. the 401 is for a specific
deny. what that means is most likely somewhere in NTFS you have a deny
access some place.

do you have the sub code? should be like a 401.1 or something.

here is a KB article that goes over how to troubleshoot this kind of
problem.
http://support.microsoft.com/kb/907273


"Pablo Montilla" <melkor DeleteThis @odyssey.com.uy> wrote in message
news:op.t04f1oyncj6shk@chimera.odyssey.com.uy...
> I'm getting a 401. The problem is not with the ASP.NET app, as it runs
> fine (and gets the correct credentials) when permissions to read is given
> to the Users group (simply by inheriting the wwwroot default permissions).
> I'm really baffled by this, as I don't see where's the problem. My
> understanding was exactly as yours (save the part where the IIS check is
> done without impersionation).
>
> Is there any difference between the metabase configuration for an IIS in a
> server in a workgroup and a server in a domain? I still see that as the
> only meaningful difference between the servers. I've run this in two other
> servers now, and the three of them work correctly, while the production
> server won't.
>
> Pablo
>
> --
>
>
> To do a lab really well, have your report done well in advance.
>
> Pablo Montilla
> www.odyssey.com.uy
 >> Stay informed about: Impersonation and File Permission problems 

On Nov 1, 1:12 pm, "Pablo Montilla" <mel....TakeThisOut@odyssey.com.uy> wrote:
> On Thu, 01 Nov 2007 16:40:34 -0200, Justin Rich <jrich....TakeThisOut@yahoo.spam.com>
> wrote:
>
> > well, its straight out a security issue so what i would suggest is some
> > basic testing. add a user account and test with a user account that has
> > admin access to the server and the slim it down from there until you find
> > where the deny access is set because i think thats what the problem is.
>
> > It sounds like your IIS security is set right so i would start digging
> > around with NTFS permissions..
>
> I hate it when this happens. I was checking file access with procmon, and
> figured what the problem was. I don't really know why, but in all my test
> servers, the w3wp.exe process is running under the SYSTEM account (at
> least when accessing aspx files), and in my production server it is
> correctly running in the NetworkService account. The app pools in my test
> servers and in the prod server say they run on the NetworkService account
> so there must be a configuration setting I missed in the machine.config,
> or something.
>
> Anyway, the case is that IIS is correctly doing the access check on the
> aspx files, probably is handling both the process token and the user token
> to the w3wp process, the process reads the aspx file while in the context
> of the process token, impersonates, and only then executes the page code.
>
> That explains it all, and sounds overly complex and nonsensical so it must
> be true..
>
> So my solution is to add read access to the network service and cross
> fingers.
>
> Many thanks for your time and your help,
> Pablo
> --
>
> It is easy to be tolerant of the principles of other people
> if you have none of your own.
> -- Herbert Samuel
>
> Pablo Montillawww.odyssey.com.uy



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.

Regarding permissions used to execute ASP.Net pages -- on IIS, the
answer always depends on the request handler, in this case ASP.Net.
http://blogs.msdn.com/david.wang/archive/2005/06/29/IIS_User_Identity_...Run_Cod

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:
http://support.microsoft.com/kb/306158

I hope this explains what is going on so that you can ensure the
appropriate configurations.


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

well, its straight out a security issue so what i would suggest is some
basic testing. add a user account and test with a user account that has
admin access to the server and the slim it down from there until you find
where the deny access is set because i think thats what the problem is.

It sounds like your IIS security is set right so i would start digging
around with NTFS permissions..


"Pablo Montilla" <melkor.TakeThisOut@odyssey.com.uy> wrote in message
news:op.t04h5qwbcj6shk@chimera.odyssey.com.uy...
Using wget to get the page, I get this interaction:

HTTP request sent, awaiting response...
HTTP/1.1 401 Unauthorized
Content-Length: 1656
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
Date: Thu, 01 Nov 2007 17:05:23 GMT
Connection: keep-alive
Reusing existing connection to localhost:80.
HTTP request sent, awaiting response...
HTTP/1.1 401 Unauthorized
Content-Length: 1539
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: NTLM
TlRMTVNTUAACAAAAAAAAADgAAAACAgACQ4Fi/qaJ4GMAAAAAAAAAAAA
AAAA4AAAABQLODgAAAA8=
X-Powered-By: ASP.NET
Date: Thu, 01 Nov 2007 17:05:23 GMT
Connection: keep-alive
Reusing existing connection to localhost:80.
HTTP request sent, awaiting response...
HTTP/1.1 401 Unauthorized
Connection: keep-alive
Date: Thu, 01 Nov 2007 17:05:23 GMT
Server: Microsoft-IIS/6.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Length: 8620
Authorization failed.

The user that was used to get this is in a group wich has read access to
the aspx file. If I remove that group and add the Users group instead, I
get a 200 in the last part of the negotiation.

Checking the effective permissions for the user, I get the same
permissions when using the 'Users' or the 'O2 - Operator' group (the one
that should be ensuring access control).

I really don't get it. =(
--


We know what happens to people who stay in the middle of the road.
They get run over.
-- Aneurin Bevan

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

I'll continue digging then, thanks for your help!

Pablo
--


Kareen: "Are you a Romulan?"
Worf: [Growls] "Hardly."
-- "The Schizoid Man", Stardate unknown

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

On Nov 1, 2:48 pm, "Pablo Montilla" <mel....TakeThisOut@odyssey.com.uy> wrote:
> Thanks for your reply, I answer below...
>
> On Thu, 01 Nov 2007 19:13:57 -0200, David Wang <w3.4....TakeThisOut@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 Thu, 01 Nov 2007 16:40:34 -0200, Justin Rich <jrich523 DeleteThis @yahoo.spam.com>
wrote:

> well, its straight out a security issue so what i would suggest is some
> basic testing. add a user account and test with a user account that has
> admin access to the server and the slim it down from there until you find
> where the deny access is set because i think thats what the problem is.
>
> It sounds like your IIS security is set right so i would start digging
> around with NTFS permissions..
>

I hate it when this happens. I was checking file access with procmon, and
figured what the problem was. I don't really know why, but in all my test
servers, the w3wp.exe process is running under the SYSTEM account (at
least when accessing aspx files), and in my production server it is
correctly running in the NetworkService account. The app pools in my test
servers and in the prod server say they run on the NetworkService account
so there must be a configuration setting I missed in the machine.config,
or something.

Anyway, the case is that IIS is correctly doing the access check on the
aspx files, probably is handling both the process token and the user token
to the w3wp process, the process reads the aspx file while in the context
of the process token, impersonates, and only then executes the page code.

That explains it all, and sounds overly complex and nonsensical so it must
be true..

So my solution is to add read access to the network service and cross
fingers.

Many thanks for your time and your help,
Pablo
--


It is easy to be tolerant of the principles of other people
if you have none of your own.
-- Herbert Samuel

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

so what your saying is network services didnt have access to the files?


"Pablo Montilla" <melkor DeleteThis @odyssey.com.uy> wrote in message
news:op.t04qfdifcj6shk@chimera.odyssey.com.uy...
> On Thu, 01 Nov 2007 16:40:34 -0200, Justin Rich <jrich523 DeleteThis @yahoo.spam.com>
> wrote:
>
>> well, its straight out a security issue so what i would suggest is some
>> basic testing. add a user account and test with a user account that has
>> admin access to the server and the slim it down from there until you find
>> where the deny access is set because i think thats what the problem is.
>>
>> It sounds like your IIS security is set right so i would start digging
>> around with NTFS permissions..
>>
>
> I hate it when this happens. I was checking file access with procmon, and
> figured what the problem was. I don't really know why, but in all my test
> servers, the w3wp.exe process is running under the SYSTEM account (at
> least when accessing aspx files), and in my production server it is
> correctly running in the NetworkService account. The app pools in my test
> servers and in the prod server say they run on the NetworkService account
> so there must be a configuration setting I missed in the machine.config,
> or something.
>
> Anyway, the case is that IIS is correctly doing the access check on the
> aspx files, probably is handling both the process token and the user token
> to the w3wp process, the process reads the aspx file while in the context
> of the process token, impersonates, and only then executes the page code.
>
> That explains it all, and sounds overly complex and nonsensical so it must
> be true..
>
> So my solution is to add read access to the network service and cross
> fingers.
>
> Many thanks for your time and your help,
> Pablo
> --
>
>
> It is easy to be tolerant of the principles of other people
> if you have none of your own.
> -- Herbert Samuel
>
> Pablo Montilla
> www.odyssey.com.uy
 >> Stay informed about: Impersonation and File Permission problems