IIS 6 ASP: Which Process Identity Is It Using? App Pool or..

Hi,

I am currently test running an old ASP application on IIS 6.0 and I have a
question on what user identity is actually being used. I created a new
application pool with its own service identity account (let's call it
TestService, and added it to the IIS_WPG group) and assigned the web app to
use the app pool. I have also enabled anon access on the web app, using the
IUSR account. The web app, upon start up, a COM object connects to a
network server and d/ls files to a data directory. The data directory has
to have correct NTFS permissions for this to work.

Now... here are my tests.

1) I first set the NTFS permissions of the data directory to NOT allow
modify/write access to the TestService account and to allow modify/write
access to the IUSR account (I know I'm not supposed to, but this is just a
test). This did not work.

2) I then set the data directory to allow modify/write access to the
TestService account and the IUSR to only have read access. This worked.

etc...

What I basically found was that only the NTFS setting on the TestService
account mattered for this operation to succeed. But based on all I've read,
isn't it the authenticated user (in this case, the IUSR) that's supposed to
be impersonated, and all actions are performed as if it was the IUSR? In
this case, it doesn't even seem like the NTFS settings for IUSR matter at
all. I even removed IUSR from the NTFS permissions completely and it still
worked. Does anyone know why?

This is an excerpt from a Microsoft document:
For ASP applications, the type of authentication that is used by the user
automatically determines impersonation behavior. Because the impersonation
behavior is automatic, no configuration is required.

The impersonation behavior in an ASP application is as follows:

· If an anonymous user makes a request, the thread token is based on
the user account that is configured as the anonymous user identity (by
default, this is the IUSR_machinename user account).

· If an authenticated user makes a request, the thread token is
based on the authenticated account of the user.







Thanks if anyone can explain this to me.

ASP itself uses the impersonated identity - we verify that on IIS6. Custom
code that ASP runs, like your COM object, could be doing something else.
Actions done by the custom code, like connect to a network server and d/l
files, is completely subject to its behavior, not ASP's. It could cooperate
with ASP's behavior, but it doesn't have to.

Is the COM object configured to use the impersonated (IUSR) or process
(TestService) identity?

For example, a COM object could be calling RevertToSelf(), which in older
IIS gives it access to LocalSystem (in low isolation) or IWAM (in
medium/high isolation). It will now be using "TestService" identity.

--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"C K" <blah DeleteThis @blah.com> wrote in message
news:c0h85j$m3h$1@newstree.wise.edt.ericsson.se...
Hi,

I am currently test running an old ASP application on IIS 6.0 and I have a
question on what user identity is actually being used. I created a new
application pool with its own service identity account (let's call it
TestService, and added it to the IIS_WPG group) and assigned the web app to
use the app pool. I have also enabled anon access on the web app, using the
IUSR account. The web app, upon start up, a COM object connects to a
network server and d/ls files to a data directory. The data directory has
to have correct NTFS permissions for this to work.

Now... here are my tests.

1) I first set the NTFS permissions of the data directory to NOT allow
modify/write access to the TestService account and to allow modify/write
access to the IUSR account (I know I'm not supposed to, but this is just a
test). This did not work.

2) I then set the data directory to allow modify/write access to the
TestService account and the IUSR to only have read access. This worked.

etc...

What I basically found was that only the NTFS setting on the TestService
account mattered for this operation to succeed. But based on all I've read,
isn't it the authenticated user (in this case, the IUSR) that's supposed to
be impersonated, and all actions are performed as if it was the IUSR? In
this case, it doesn't even seem like the NTFS settings for IUSR matter at
all. I even removed IUSR from the NTFS permissions completely and it still
worked. Does anyone know why?

This is an excerpt from a Microsoft document:
For ASP applications, the type of authentication that is used by the user
automatically determines impersonation behavior. Because the impersonation
behavior is automatic, no configuration is required.

The impersonation behavior in an ASP application is as follows:

· If an anonymous user makes a request, the thread token is based on
the user account that is configured as the anonymous user identity (by
default, this is the IUSR_machinename user account).

· If an authenticated user makes a request, the thread token is
based on the authenticated account of the user.







Thanks if anyone can explain this to me.