| Groups | Blog | Home |
iis security : IIS 6 ASP: Which Process Identity Is It Using? App Pool or Anon?
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. // [quoted text, click to view] "C K" <blah@blah.com> wrote in message Hi,news:c0h85j$m3h$1@newstree.wise.edt.ericsson.se... 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.
Hi Bernard,
The only two ACLs I have is 1) Administrators Group (full control) 2) The TestService account. I have removed all inheritance for this folder so it is only those two ACLs in effect. I have also just tried using filemon to see what is causing the problem and I do see some ACCESS DENIED messages when the TestService account does not have write access. However, filemon does not show the user identity, it only shows the process name w3wp.exe. However, it must be the TestService account because when I give it write access to the folder, everything works ok. In my other response, I mentioned that the routines to retrieve the data from a remote server are in a statically linked dll (which I do not maintain). I believe it connects to the remote server via named pipe. But all this shouldn't matter right? Because it is getting the ACCESS DENIED on the file system due to insufficient NTFS permission. Any ideas? Thanks. [quoted text, click to view] "Bernard" <qbernard@hotmail.com.discuss> wrote in message news:#zjca2h8DHA.488@TK2MSFTNGP12.phx.gbl... > Wow, now you make me confuse :) > what other ACLs you have for the data folder ? > > AFAIK, your 'testservice' is process identity to execute the w3wp.exe > and the 'iusr' user identity for actual access. > > have you try filemon (sysinternals.com) and actually trace down the 'user' > that writting the content. > > -- > Regards, > Bernard Cheah > http://support.microsoft.com/ > Please respond to newsgroups only ... > > > "C K" <blah@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. > > > > > > > >
Wow, now you make me confuse :)
what other ACLs you have for the data folder ? AFAIK, your 'testservice' is process identity to execute the w3wp.exe and the 'iusr' user identity for actual access. have you try filemon (sysinternals.com) and actually trace down the 'user' that writting the content. -- Regards, Bernard Cheah http://support.microsoft.com/ Please respond to newsgroups only ... [quoted text, click to view] "C K" <blah@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. > > >
I don't see your other response in the thread.
now, as david pointed out do you change the security settings in your com object ? -- Regards, Bernard Cheah http://support.microsoft.com/ Please respond to newsgroups only ... [quoted text, click to view] "C K" <blah@blah.com> wrote in message news:c0j713$n0e$1@newstree.wise.edt.ericsson.se... > Hi Bernard, > > The only two ACLs I have is 1) Administrators Group (full control) 2) The > TestService account. I have removed all inheritance for this folder so it > is only those two ACLs in effect. > > I have also just tried using filemon to see what is causing the problem and > I do see some ACCESS DENIED messages when the TestService account does not > have write access. However, filemon does not show the user identity, it > only shows the process name w3wp.exe. However, it must be the TestService > account because when I give it write access to the folder, everything works > ok. > > In my other response, I mentioned that the routines to retrieve the data > from a remote server are in a statically linked dll (which I do not > maintain). I believe it connects to the remote server via named pipe. But > all this shouldn't matter right? Because it is getting the ACCESS DENIED on > the file system due to insufficient NTFS permission. > > Any ideas? > > Thanks. > > > > "Bernard" <qbernard@hotmail.com.discuss> wrote in message > news:#zjca2h8DHA.488@TK2MSFTNGP12.phx.gbl... > > Wow, now you make me confuse :) > > what other ACLs you have for the data folder ? > > > > AFAIK, your 'testservice' is process identity to execute the w3wp.exe > > and the 'iusr' user identity for actual access. > > > > have you try filemon (sysinternals.com) and actually trace down the 'user' > > that writting the content. > > > > -- > > Regards, > > Bernard Cheah > > http://support.microsoft.com/ > > Please respond to newsgroups only ... > > > > > > "C K" <blah@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. > > > > > > > > > > > > > > >
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |