| Groups | Blog | Home |
iis security : IUSR_myserver and deny write
permissions for IIS 6.0 , the relevant ones of which are USERS (Read & Excecute, List Folder.., and Read) and the Internet Guest Account server which has no "allows" and a "Deny Write". My question is: the deny write does not seem to do anything at all. I have a directory where an ASP script (not ASP.net, just classic ASP) writes a text file. On this directory I have anbled "WRITE" for Users. The intenet Guest Account is unchanged and inherits "Deny Write". In the IIS console for this directory "Write" is NOT ticked and anonymous access is enabled for the entire web site. The issue is that even though I put "deny write" on the internet guest account (which I'm doing as a test of my security) it does NOT stop the ASP script from writing to this directory. Why is this? I would have though that if you access the ASP script as an anonymous user and this ASP script writes to a second directory which has "Deny Write" for the Internet Guest Account this should prevent the ASP script from writing. But it doesn't. The IIS configuration is the default --- eg the application pool runs under the network identity (ie the default). Of course I can prevent writing to the directory if I remove write permissions from USERS. But I don't understand why the Internet guest account can write even when write permissions are explicitly denied and seconly why the Internet Guest Account seems to end up being treated as a "USER" even though it is not a member of the User group. Can anybody explain this behaviour?
[quoted text, click to view]
On Sep 22, 2:00 pm, "Brain Steward" <j...@junk.com> wrote: > I have IIS 6.0 Win 2003. Most directories in the web use MS default > permissions for IIS 6.0 , the relevant ones of which are USERS (Read & > Excecute, List Folder.., and Read) and the Internet Guest Account server > which has no "allows" and a "Deny Write". > > My question is: the deny write does not seem to do anything at all. I have > a directory where an ASP script (not ASP.net, just classic ASP) writes a > text file. On this directory I have anbled "WRITE" for Users. The intenet > Guest Account is unchanged and inherits "Deny Write". In the IIS console > for this directory "Write" is NOT ticked and anonymous access is enabled for > the entire web site. The issue is that even though I put "deny write" on > the internet guest account (which I'm doing as a test of my security) it > does NOT stop the ASP script from writing to this directory. > > Why is this? I would have though that if you access the ASP script as an > anonymous user and this ASP script writes to a second directory which has > "Deny Write" for the Internet Guest Account this should prevent the ASP > script from writing. But it doesn't. > > The IIS configuration is the default --- eg the application pool runs under > the network identity (ie the default). > > Of course I can prevent writing to the directory if I remove write > permissions from USERS. But I don't understand why the Internet guest > account can write even when write permissions are explicitly denied and > seconly why the Internet Guest Account seems to end up being treated as a > "USER" even though it is not a member of the User group. > > Can anybody explain this behaviour? Can you clarify the actual user account which performs the CreateFile/ WriteFile Win32 API call through all the layers of your ASP page and any components it may use. It is likely not what you think, which is what results in this seemingly insecure behavior. The best thing I can think of is to help you learn how to investigate and form correct interpretation of what is going on -- and not simply explain a mysterious behavior -- because simply explaining a mystery does not prevent another mystery from stymying you in the future. //David http://w3-4u.blogspot.com http://blogs.msdn.com/David.Wang //
David -- I have a simple ASP script which runs under IIS defaults. I
haven't set up any additional accounts -- administrator is the only user account on the server. I can't clarify which actual user account performs the writes -- I don't know how to do that. All I can say is that the server is stock standard, using defaults everywhere. Whatever user account ASP scripts run under is used I guess, but I though (unlike ASP.NET) that they would have the same permissions as the IUSR_myserver account. Is this not the case? The script creates and writes a text file to a directory (called "logs") within the web using the following components: <% set fs = CreateObject("Scripting.FileSystemObject") FileName="Logs\events.html" path=server.mappath(FileName) if fs.FileExists(path) = True then set f= fs.OpenTextFile(path,8) else set f = fs.CreateTextFile(path,True) end if temp = "information that I write to the file" f.write (left(temp,197) & "</b><br>") %> That's pretty much the whole script. The "logs" directory has write permissions for users. The permissions for the intenet guest account are "deny write". Access to the web is anonymous (ie users are not logged on as administrator or any othe user (as there aren't any anyway)). So in summary: anonymous visitors using a web browser execute this ASP script which writes information to the logs directory even though permissions on this directory for the internet guest account say "deny write". As I said below, the behaviour is consistent with the internet guest account being treated as a member of the users group, which it isn't. I haven't change any of the default groupings and the server is brand new with no third part software installed. If you need any more information to help you explain this please let me know exactly what I can provide and I'll let you have it. Thanks for you help. [quoted text, click to view] "David Wang" <w3.4you@gmail.com> wrote in message news:1190531527.150391.221770@57g2000hsv.googlegroups.com... > On Sep 22, 2:00 pm, "Brain Steward" <j...@junk.com> wrote: >> I have IIS 6.0 Win 2003. Most directories in the web use MS default >> permissions for IIS 6.0 , the relevant ones of which are USERS (Read & >> Excecute, List Folder.., and Read) and the Internet Guest Account server >> which has no "allows" and a "Deny Write". >> >> My question is: the deny write does not seem to do anything at all. I >> have >> a directory where an ASP script (not ASP.net, just classic ASP) writes a >> text file. On this directory I have anbled "WRITE" for Users. The >> intenet >> Guest Account is unchanged and inherits "Deny Write". In the IIS console >> for this directory "Write" is NOT ticked and anonymous access is enabled >> for >> the entire web site. The issue is that even though I put "deny write" on >> the internet guest account (which I'm doing as a test of my security) it >> does NOT stop the ASP script from writing to this directory. >> >> Why is this? I would have though that if you access the ASP script as an >> anonymous user and this ASP script writes to a second directory which has >> "Deny Write" for the Internet Guest Account this should prevent the ASP >> script from writing. But it doesn't. >> >> The IIS configuration is the default --- eg the application pool runs >> under >> the network identity (ie the default). >> >> Of course I can prevent writing to the directory if I remove write >> permissions from USERS. But I don't understand why the Internet guest >> account can write even when write permissions are explicitly denied and >> seconly why the Internet Guest Account seems to end up being treated as a >> "USER" even though it is not a member of the User group. >> >> Can anybody explain this behaviour? > > > Can you clarify the actual user account which performs the CreateFile/ > WriteFile Win32 API call through all the layers of your ASP page and > any components it may use. > > It is likely not what you think, which is what results in this > seemingly insecure behavior. > > The best thing I can think of is to help you learn how to investigate > and form correct interpretation of what is going on -- and not simply > explain a mysterious behavior -- because simply explaining a mystery > does not prevent another mystery from stymying you in the future. > > > //David > http://w3-4u.blogspot.com > http://blogs.msdn.com/David.Wang > // >
[quoted text, click to view]
> As I said below, the behaviour is consistent with the internet guest > account being treated as a member of the users group, which it isn't. I > haven't change any of the default groupings and the server is brand new > with no third part software installed. Any explicit "Deny" NTFS ACE overrides any "Allow" permissions. So whether or not IUSR account is part of the Users group, any explicit deny would nullify any grant of Write permissions. I suggest you either: a) download Filemon.exe from the Microsoft website, and see what user account is actually being used to write the file (it's probably not what you think) b) enable Object Access Auditing on your server (via the local security policy) and then enable auditing on that file (again, to see which account is being used. For this method, object access will be recorded in the Windows Security event log) Cheers Ken -- My IIS Blog: www.adOpenStatic.com/cs/blogs/ken [quoted text, click to view] "Brain Steward" <junk@junk.com> wrote in message
news:uSvuLZb$HHA.1188@TK2MSFTNGP04.phx.gbl... > David -- I have a simple ASP script which runs under IIS defaults. I > haven't set up any additional accounts -- administrator is the only user > account on the server. I can't clarify which actual user account performs > the writes -- I don't know how to do that. All I can say is that the > server is stock standard, using defaults everywhere. Whatever user account > ASP scripts run under is used I guess, but I though (unlike ASP.NET) that > they would have the same permissions as the IUSR_myserver account. Is > this not the case? > > The script creates and writes a text file to a directory (called "logs") > within the web using the following components: > <% > set fs = CreateObject("Scripting.FileSystemObject") > FileName="Logs\events.html" > path=server.mappath(FileName) > if fs.FileExists(path) = True then > set f= fs.OpenTextFile(path,8) > else > set f = fs.CreateTextFile(path,True) > end if > temp = "information that I write to the file" > f.write (left(temp,197) & "</b><br>") > %> > > That's pretty much the whole script. > > The "logs" directory has write permissions for users. The permissions for > the intenet guest account are "deny write". Access to the web is > anonymous (ie users are not logged on as administrator or any othe user > (as there aren't any anyway)). > > So in summary: anonymous visitors using a web browser execute this ASP > script which writes information to the logs directory even though > permissions on this directory for the internet guest account say "deny > write". As I said below, the behaviour is consistent with the internet > guest account being treated as a member of the users group, which it > isn't. I haven't change any of the default groupings and the server is > brand new with no third part software installed. > > If you need any more information to help you explain this please let me > know exactly what I can provide and I'll let you have it. > > Thanks for you help. > > "David Wang" <w3.4you@gmail.com> wrote in message > news:1190531527.150391.221770@57g2000hsv.googlegroups.com... >> On Sep 22, 2:00 pm, "Brain Steward" <j...@junk.com> wrote: >>> I have IIS 6.0 Win 2003. Most directories in the web use MS default >>> permissions for IIS 6.0 , the relevant ones of which are USERS (Read & >>> Excecute, List Folder.., and Read) and the Internet Guest Account server >>> which has no "allows" and a "Deny Write". >>> >>> My question is: the deny write does not seem to do anything at all. I >>> have >>> a directory where an ASP script (not ASP.net, just classic ASP) writes a >>> text file. On this directory I have anbled "WRITE" for Users. The >>> intenet >>> Guest Account is unchanged and inherits "Deny Write". In the IIS >>> console >>> for this directory "Write" is NOT ticked and anonymous access is enabled >>> for >>> the entire web site. The issue is that even though I put "deny write" >>> on >>> the internet guest account (which I'm doing as a test of my security) it >>> does NOT stop the ASP script from writing to this directory. >>> >>> Why is this? I would have though that if you access the ASP script as >>> an >>> anonymous user and this ASP script writes to a second directory which >>> has >>> "Deny Write" for the Internet Guest Account this should prevent the ASP >>> script from writing. But it doesn't. >>> >>> The IIS configuration is the default --- eg the application pool runs >>> under >>> the network identity (ie the default). >>> >>> Of course I can prevent writing to the directory if I remove write >>> permissions from USERS. But I don't understand why the Internet guest >>> account can write even when write permissions are explicitly denied and >>> seconly why the Internet Guest Account seems to end up being treated as >>> a >>> "USER" even though it is not a member of the User group. >>> >>> Can anybody explain this behaviour? >> >> >> Can you clarify the actual user account which performs the CreateFile/ >> WriteFile Win32 API call through all the layers of your ASP page and >> any components it may use. >> >> It is likely not what you think, which is what results in this >> seemingly insecure behavior. >> >> The best thing I can think of is to help you learn how to investigate >> and form correct interpretation of what is going on -- and not simply >> explain a mysterious behavior -- because simply explaining a mystery >> does not prevent another mystery from stymying you in the future. >> >> >> //David >> http://w3-4u.blogspot.com >> http://blogs.msdn.com/David.Wang >> // >> > >
I checked on the account used to write to the file. It's the NT
Authority\Network account. It's the same on all my Win 2003 servers -- I've checked a few. So it would appear that even though the web site was accessed by an anonymous user (ie the user was not authenticated as any other user) any permissions on a directory for anonymous users are effectively ignored by IIS as the ASP script runs under the NT Authority/Network account which has been granted write permissions, I presume, because it's a member of users or administrators. That's not a problem in iteslef, if we know for sure that this is the case, but it effectivly means including permissions for the IUSR_myserver user on the web directory achieves nothing. I can see it would prevent a webdav put from an anonymous user writing to the directory, but un-ticking 'write' in the IIS console for the directory achieves that (and it doesn't prevent ASP writing to the directory) so I can't even see the point of including the IUSR_mysever user at all as everything runs fine without it. The default IUSER_myserver user on Win 2003 doesn't even have read permissions. The only thing it has is deny write, so clearly it's not used by IIS. Is my understanding correct? [quoted text, click to view] "Ken Schaefer" <kenREMOVE@THISadOpenStatic.com> wrote in message
news:uzyjq7d$HHA.3548@TK2MSFTNGP06.phx.gbl... >> As I said below, the behaviour is consistent with the internet guest >> account being treated as a member of the users group, which it isn't. I >> haven't change any of the default groupings and the server is brand new >> with no third part software installed. > > Any explicit "Deny" NTFS ACE overrides any "Allow" permissions. So whether > or not IUSR account is part of the Users group, any explicit deny would > nullify any grant of Write permissions. > > I suggest you either: > a) download Filemon.exe from the Microsoft website, and see what user > account is actually being used to write the file (it's probably not what > you think) > > b) enable Object Access Auditing on your server (via the local security > policy) and then enable auditing on that file (again, to see which account > is being used. For this method, object access will be recorded in the > Windows Security event log) > > Cheers > Ken > > -- > My IIS Blog: www.adOpenStatic.com/cs/blogs/ken > > > "Brain Steward" <junk@junk.com> wrote in message > news:uSvuLZb$HHA.1188@TK2MSFTNGP04.phx.gbl... >> David -- I have a simple ASP script which runs under IIS defaults. I >> haven't set up any additional accounts -- administrator is the only user >> account on the server. I can't clarify which actual user account performs >> the writes -- I don't know how to do that. All I can say is that the >> server is stock standard, using defaults everywhere. Whatever user >> account ASP scripts run under is used I guess, but I though (unlike >> ASP.NET) that they would have the same permissions as the IUSR_myserver >> account. Is this not the case? >> >> The script creates and writes a text file to a directory (called "logs") >> within the web using the following components: >> <% >> set fs = CreateObject("Scripting.FileSystemObject") >> FileName="Logs\events.html" >> path=server.mappath(FileName) >> if fs.FileExists(path) = True then >> set f= fs.OpenTextFile(path,8) >> else >> set f = fs.CreateTextFile(path,True) >> end if >> temp = "information that I write to the file" >> f.write (left(temp,197) & "</b><br>") >> %> >> >> That's pretty much the whole script. >> >> The "logs" directory has write permissions for users. The permissions >> for the intenet guest account are "deny write". Access to the web is >> anonymous (ie users are not logged on as administrator or any othe user >> (as there aren't any anyway)). >> >> So in summary: anonymous visitors using a web browser execute this ASP >> script which writes information to the logs directory even though >> permissions on this directory for the internet guest account say "deny >> write". As I said below, the behaviour is consistent with the internet >> guest account being treated as a member of the users group, which it >> isn't. I haven't change any of the default groupings and the server is >> brand new with no third part software installed. >> >> If you need any more information to help you explain this please let me >> know exactly what I can provide and I'll let you have it. >> >> Thanks for you help. >> >> "David Wang" <w3.4you@gmail.com> wrote in message >> news:1190531527.150391.221770@57g2000hsv.googlegroups.com... >>> On Sep 22, 2:00 pm, "Brain Steward" <j...@junk.com> wrote: >>>> I have IIS 6.0 Win 2003. Most directories in the web use MS default >>>> permissions for IIS 6.0 , the relevant ones of which are USERS (Read & >>>> Excecute, List Folder.., and Read) and the Internet Guest Account >>>> server >>>> which has no "allows" and a "Deny Write". >>>> >>>> My question is: the deny write does not seem to do anything at all. I >>>> have >>>> a directory where an ASP script (not ASP.net, just classic ASP) writes >>>> a >>>> text file. On this directory I have anbled "WRITE" for Users. The >>>> intenet >>>> Guest Account is unchanged and inherits "Deny Write". In the IIS >>>> console >>>> for this directory "Write" is NOT ticked and anonymous access is >>>> enabled for >>>> the entire web site. The issue is that even though I put "deny write" >>>> on >>>> the internet guest account (which I'm doing as a test of my security) >>>> it >>>> does NOT stop the ASP script from writing to this directory. >>>> >>>> Why is this? I would have though that if you access the ASP script as >>>> an >>>> anonymous user and this ASP script writes to a second directory which >>>> has >>>> "Deny Write" for the Internet Guest Account this should prevent the ASP >>>> script from writing. But it doesn't. >>>> >>>> The IIS configuration is the default --- eg the application pool runs >>>> under >>>> the network identity (ie the default). >>>> >>>> Of course I can prevent writing to the directory if I remove write >>>> permissions from USERS. But I don't understand why the Internet guest >>>> account can write even when write permissions are explicitly denied and >>>> seconly why the Internet Guest Account seems to end up being treated as >>>> a >>>> "USER" even though it is not a member of the User group. >>>> >>>> Can anybody explain this behaviour? >>> >>> >>> Can you clarify the actual user account which performs the CreateFile/ >>> WriteFile Win32 API call through all the layers of your ASP page and >>> any components it may use. >>> >>> It is likely not what you think, which is what results in this >>> seemingly insecure behavior. >>> >>> The best thing I can think of is to help you learn how to investigate
OK - at least we have found the account being used.
However in a default configuration of IIS 6.0, the NT AUTHORITY\Network Sevice account is not the impersonated user for Classic ASP files. Network Service is used as the w3wp.exe process identity, but IIS should impersonate IUSR_<machinename> for anonymous access. So, something is up with your conifguration if Network Service is being used for Classic ASP files. Cheers Ken [quoted text, click to view] "Brain Steward" <junk@junk.com> wrote in message
news:eOy%23Oae$HHA.3716@TK2MSFTNGP03.phx.gbl... >I checked on the account used to write to the file. It's the NT >Authority\Network account. It's the same on all my Win 2003 servers -- I've >checked a few. > > So it would appear that even though the web site was accessed by an > anonymous user (ie the user was not authenticated as any other user) any > permissions on a directory for anonymous users are effectively ignored by > IIS as the ASP script runs under the NT Authority/Network account which > has been granted write permissions, I presume, because it's a member of > users or administrators. > > That's not a problem in iteslef, if we know for sure that this is the > case, but it effectivly means including permissions for the IUSR_myserver > user on the web directory achieves nothing. I can see it would prevent a > webdav put from an anonymous user writing to the directory, but un-ticking > 'write' in the IIS console for the directory achieves that (and it doesn't > prevent ASP writing to the directory) so I can't even see the point of > including the IUSR_mysever user at all as everything runs fine without it. > The default IUSER_myserver user on Win 2003 doesn't even have read > permissions. The only thing it has is deny write, so clearly it's not used > by IIS. > > Is my understanding correct? > > > > "Ken Schaefer" <kenREMOVE@THISadOpenStatic.com> wrote in message > news:uzyjq7d$HHA.3548@TK2MSFTNGP06.phx.gbl... >>> As I said below, the behaviour is consistent with the internet guest >>> account being treated as a member of the users group, which it isn't. I >>> haven't change any of the default groupings and the server is brand new >>> with no third part software installed. >> >> Any explicit "Deny" NTFS ACE overrides any "Allow" permissions. So >> whether or not IUSR account is part of the Users group, any explicit deny >> would nullify any grant of Write permissions. >> >> I suggest you either: >> a) download Filemon.exe from the Microsoft website, and see what user >> account is actually being used to write the file (it's probably not what >> you think) >> >> b) enable Object Access Auditing on your server (via the local security >> policy) and then enable auditing on that file (again, to see which >> account is being used. For this method, object access will be recorded in >> the Windows Security event log) >> >> Cheers >> Ken >> >> -- >> My IIS Blog: www.adOpenStatic.com/cs/blogs/ken >> >> >> "Brain Steward" <junk@junk.com> wrote in message >> news:uSvuLZb$HHA.1188@TK2MSFTNGP04.phx.gbl... >>> David -- I have a simple ASP script which runs under IIS defaults. I >>> haven't set up any additional accounts -- administrator is the only user >>> account on the server. I can't clarify which actual user account >>> performs the writes -- I don't know how to do that. All I can say is >>> that the server is stock standard, using defaults everywhere. Whatever >>> user account ASP scripts run under is used I guess, but I though (unlike >>> ASP.NET) that they would have the same permissions as the IUSR_myserver >>> account. Is this not the case? >>> >>> The script creates and writes a text file to a directory (called "logs") >>> within the web using the following components: >>> <% >>> set fs = CreateObject("Scripting.FileSystemObject") >>> FileName="Logs\events.html" >>> path=server.mappath(FileName) >>> if fs.FileExists(path) = True then >>> set f= fs.OpenTextFile(path,8) >>> else >>> set f = fs.CreateTextFile(path,True) >>> end if >>> temp = "information that I write to the file" >>> f.write (left(temp,197) & "</b><br>") >>> %> >>> >>> That's pretty much the whole script. >>> >>> The "logs" directory has write permissions for users. The permissions >>> for the intenet guest account are "deny write". Access to the web is >>> anonymous (ie users are not logged on as administrator or any othe user >>> (as there aren't any anyway)). >>> >>> So in summary: anonymous visitors using a web browser execute this ASP >>> script which writes information to the logs directory even though >>> permissions on this directory for the internet guest account say "deny >>> write". As I said below, the behaviour is consistent with the internet >>> guest account being treated as a member of the users group, which it >>> isn't. I haven't change any of the default groupings and the server is >>> brand new with no third part software installed. >>> >>> If you need any more information to help you explain this please let me >>> know exactly what I can provide and I'll let you have it. >>> >>> Thanks for you help. >>> >>> "David Wang" <w3.4you@gmail.com> wrote in message >>> news:1190531527.150391.221770@57g2000hsv.googlegroups.com... >>>> On Sep 22, 2:00 pm, "Brain Steward" <j...@junk.com> wrote: >>>>> I have IIS 6.0 Win 2003. Most directories in the web use MS default >>>>> permissions for IIS 6.0 , the relevant ones of which are USERS (Read & >>>>> Excecute, List Folder.., and Read) and the Internet Guest Account >>>>> server >>>>> which has no "allows" and a "Deny Write". >>>>> >>>>> My question is: the deny write does not seem to do anything at all. I >>>>> have >>>>> a directory where an ASP script (not ASP.net, just classic ASP) writes >>>>> a >>>>> text file. On this directory I have anbled "WRITE" for Users. The >>>>> intenet >>>>> Guest Account is unchanged and inherits "Deny Write". In the IIS >>>>> console >>>>> for this directory "Write" is NOT ticked and anonymous access is >>>>> enabled for >>>>> the entire web site. The issue is that even though I put "deny write" >>>>> on >>>>> the internet guest account (which I'm doing as a test of my security) >>>>> it >>>>> does NOT stop the ASP script from writing to this directory. >>>>> >>>>> Why is this? I would have though that if you access the ASP script as >>>>> an >>>>> anonymous user and this ASP script writes to a second directory which >>>>> has >>>>> "Deny Write" for the Internet Guest Account this should prevent the >>>>> ASP >>>>> script from writing. But it doesn't. >>>>> >>>>> The IIS configuration is the default --- eg the application pool runs >>>>> under >>>>> the network identity (ie the default). >>>>> >>>>> Of course I can prevent writing to the directory if I remove write
It's definitly the default configuration -- straight out of the box, brand
new Dell rack mounted server. It's the same as other servers I have going back to October 2005. All run IIS under the NT AUTHORITY\Network account. Furthermore as I noted below the default permissions for the IUSER_<machinename> on the wwwroot directory has no read permissions. It only has deny write. That is the same on every IIS 6.0 server that I have ever seen and it's been mentioned many times in this board and others. If there are no read permissions on the IUSR account then that would mean that if IIS impersonated the IUSR account it would not be able to read any files wouldn't it? I know you say IIS SHOULD impersonate the IUSR account -- but it would appear it doesn't in IIS 6.0. That really was the point of my original post as I thought (without ever checking prior to my doing this test) that it should as well. Saying something is up with my configuration unfortuantely just begs the original question. I don't believe anything is up with my coinfiguration, rather that's the way IIS 6.0 is configured by default. I'd be happy to be persuaded otherwise if you could point me to the change in my configuration that you think has caused non-standard behaviour. Thanks for your help to date. Brian. [quoted text, click to view] "Ken Schaefer" <kenREMOVE@THISadOpenStatic.com> wrote in message
news:%23nKBSnk$HHA.5164@TK2MSFTNGP05.phx.gbl... > OK - at least we have found the account being used. > > However in a default configuration of IIS 6.0, the NT AUTHORITY\Network > Sevice account is not the impersonated user for Classic ASP files. Network > Service is used as the w3wp.exe process identity, but IIS should > impersonate IUSR_<machinename> for anonymous access. > > So, something is up with your conifguration if Network Service is being > used for Classic ASP files. > > Cheers > Ken > > > "Brain Steward" <junk@junk.com> wrote in message > news:eOy%23Oae$HHA.3716@TK2MSFTNGP03.phx.gbl... >>I checked on the account used to write to the file. It's the NT >>Authority\Network account. It's the same on all my Win 2003 servers -- >>I've checked a few. >> >> So it would appear that even though the web site was accessed by an >> anonymous user (ie the user was not authenticated as any other user) any >> permissions on a directory for anonymous users are effectively ignored by >> IIS as the ASP script runs under the NT Authority/Network account which >> has been granted write permissions, I presume, because it's a member of >> users or administrators. >> >> That's not a problem in iteslef, if we know for sure that this is the >> case, but it effectivly means including permissions for the IUSR_myserver >> user on the web directory achieves nothing. I can see it would prevent a >> webdav put from an anonymous user writing to the directory, but >> un-ticking 'write' in the IIS console for the directory achieves that >> (and it doesn't prevent ASP writing to the directory) so I can't even see >> the point of including the IUSR_mysever user at all as everything runs >> fine without it. The default IUSER_myserver user on Win 2003 doesn't even >> have read permissions. The only thing it has is deny write, so clearly >> it's not used by IIS. >> >> Is my understanding correct? >> >> >> >> "Ken Schaefer" <kenREMOVE@THISadOpenStatic.com> wrote in message >> news:uzyjq7d$HHA.3548@TK2MSFTNGP06.phx.gbl... >>>> As I said below, the behaviour is consistent with the internet guest >>>> account being treated as a member of the users group, which it isn't. I >>>> haven't change any of the default groupings and the server is brand new >>>> with no third part software installed. >>> >>> Any explicit "Deny" NTFS ACE overrides any "Allow" permissions. So >>> whether or not IUSR account is part of the Users group, any explicit >>> deny would nullify any grant of Write permissions. >>> >>> I suggest you either: >>> a) download Filemon.exe from the Microsoft website, and see what user >>> account is actually being used to write the file (it's probably not what >>> you think) >>> >>> b) enable Object Access Auditing on your server (via the local security >>> policy) and then enable auditing on that file (again, to see which >>> account is being used. For this method, object access will be recorded >>> in the Windows Security event log) >>> >>> Cheers >>> Ken >>> >>> -- >>> My IIS Blog: www.adOpenStatic.com/cs/blogs/ken >>> >>> >>> "Brain Steward" <junk@junk.com> wrote in message >>> news:uSvuLZb$HHA.1188@TK2MSFTNGP04.phx.gbl... >>>> David -- I have a simple ASP script which runs under IIS defaults. I >>>> haven't set up any additional accounts -- administrator is the only >>>> user account on the server. I can't clarify which actual user account >>>> performs the writes -- I don't know how to do that. All I can say is >>>> that the server is stock standard, using defaults everywhere. Whatever >>>> user account ASP scripts run under is used I guess, but I though >>>> (unlike ASP.NET) that they would have the same permissions as the >>>> IUSR_myserver account. Is this not the case? >>>> >>>> The script creates and writes a text file to a directory (called >>>> "logs") within the web using the following components: >>>> <% >>>> set fs = CreateObject("Scripting.FileSystemObject") >>>> FileName="Logs\events.html" >>>> path=server.mappath(FileName) >>>> if fs.FileExists(path) = True then >>>> set f= fs.OpenTextFile(path,8) >>>> else >>>> set f = fs.CreateTextFile(path,True) >>>> end if >>>> temp = "information that I write to the file" >>>> f.write (left(temp,197) & "</b><br>") >>>> %> >>>> >>>> That's pretty much the whole script. >>>> >>>> The "logs" directory has write permissions for users. The permissions >>>> for the intenet guest account are "deny write". Access to the web is >>>> anonymous (ie users are not logged on as administrator or any othe user >>>> (as there aren't any anyway)). >>>> >>>> So in summary: anonymous visitors using a web browser execute this ASP >>>> script which writes information to the logs directory even though >>>> permissions on this directory for the internet guest account say "deny >>>> write". As I said below, the behaviour is consistent with the internet >>>> guest account being treated as a member of the users group, which it >>>> isn't. I haven't change any of the default groupings and the server is >>>> brand new with no third part software installed. >>>> >>>> If you need any more information to help you explain this please let me >>>> know exactly what I can provide and I'll let you have it. >>>> >>>> Thanks for you help. >>>> >>>> "David Wang" <w3.4you@gmail.com> wrote in message >>>> news:1190531527.150391.221770@57g2000hsv.googlegroups.com...
What you describe is not the default behavior, so I do not believe
your configuration is the default from Microsoft. It may be the default configuration that you get from Dell, but that is no guarantee that it is the same as Microsoft's. I can only talk in terms of Microsoft's defaults because that is a global constant. Server vendors may do their own customizations of the same Microsoft software. It is a "right" that they sued and obtained from Microsoft, so if you don't like how it's turning out, blame that lawsuit... Anyhow, I went over to my IIS6 server built from default Microsoft configuration, which has the same ACLs that you describe, and I copied/ ran your ASP page... and it fails with access denied under only anonymous authentication. All defaults... and behaving the way it should. So, I can say that I just provided counterpoint to your statement and that we are not looking at any bug in IIS6 but rather user- misconfiguration. Now, the user may be using defaults from server manufacturer and thinks they did nothing wrong -- so they think issue must be with IIS6 -- but the reality is that the problem is with the system's settings, not IIS, and we have to agree that the problem is with the setting. We all know that with improper settings, any system can appear insecure. Now that we are all on the same page that the problem is with user- configuration (let's not have violent reaction to it. I call it user configuration because it's not the defaults set by Microsoft/IIS -- maybe you want to think of it as "non-default configuration"), the fun will be to figure out what is non-default. Some of my thoughts -- perhaps .asp is scriptmapped to aspnet_isapi.dll, in which case your "ASP code" is actually run by ASP.Net under its default impersonation, which would be process identity -- which would be Network Service by default and match what you observe. //David http://w3-4u.blogspot.com http://blogs.msdn.com/David.Wang // [quoted text, click to view] On Sep 23, 8:06 pm, "BrianSteward" <j...@junk.com> wrote:
> It's definitly the default configuration -- straight out of the box, brand > new Dell rack mounted server. It's the same as other servers I have going > back to October 2005. All run IIS under the NT AUTHORITY\Network account. > > Furthermore as I noted below the default permissions for the > IUSER_<machinename> on the wwwroot directory has no read permissions. It > only has deny write. That is the same on every IIS 6.0 server that I have > ever seen and it's been mentioned many times in this board and others. If > there are no read permissions on the IUSR account then that would mean that > if IIS impersonated the IUSR account it would not be able to read any files > wouldn't it? > > I know you say IIS SHOULD impersonate the IUSR account -- but it would > appear it doesn't in IIS 6.0. That really was the point of my original post > as I thought (without ever checking prior to my doing this test) that it > should as well. > > Saying something is up with my configuration unfortuantely just begs the > original question. I don't believe anything is up with my coinfiguration, > rather that's the way IIS 6.0 is configured by default. I'd be happy to be > persuaded otherwise if you could point me to the change in my configuration > that you think has caused non-standard behaviour. > > Thanks for your help to date. > > Brian. > > "Ken Schaefer" <kenREM...@THISadOpenStatic.com> wrote in message > > news:%23nKBSnk$HHA.5164@TK2MSFTNGP05.phx.gbl... > > > > > OK - at least we have found the account being used. > > > However in a default configuration of IIS 6.0, the NT AUTHORITY\Network > > Sevice account is not the impersonated user for Classic ASP files. Network > > Service is used as the w3wp.exe process identity, but IIS should > > impersonate IUSR_<machinename> for anonymous access. > > > So, something is up with your conifguration if Network Service is being > > used for Classic ASP files. > > > Cheers > > Ken > > > "Brain Steward" <j...@junk.com> wrote in message > >news:eOy%23Oae$HHA.3716@TK2MSFTNGP03.phx.gbl... > >>I checked on the account used to write to the file. It's the NT > >>Authority\Network account. It's the same on all my Win 2003 servers -- > >>I've checked a few. > > >> So it would appear that even though the web site was accessed by an > >> anonymous user (ie the user was not authenticated as any other user) any > >> permissions on a directory for anonymous users are effectively ignored by > >> IIS as the ASP script runs under the NT Authority/Network account which > >> has been granted write permissions, I presume, because it's a member of > >> users or administrators. > > >> That's not a problem in iteslef, if we know for sure that this is the > >> case, but it effectivly means including permissions for the IUSR_myserver > >> user on the web directory achieves nothing. I can see it would prevent a > >> webdav put from an anonymous user writing to the directory, but > >> un-ticking 'write' in the IIS console for the directory achieves that > >> (and it doesn't prevent ASP writing to the directory) so I can't even see > >> the point of including the IUSR_mysever user at all as everything runs > >> fine without it. The default IUSER_myserver user on Win 2003 doesn't even > >> have read permissions. The only thing it has is deny write, so clearly > >> it's not used by IIS. > > >> Is my understanding correct? > > >> "Ken Schaefer" <kenREM...@THISadOpenStatic.com> wrote in message > >>news:uzyjq7d$HHA.3548@TK2MSFTNGP06.phx.gbl... > >>>> As I said below, the behaviour is consistent with the internet guest > >>>> account being treated as a member of the users group, which it isn't. I > >>>> haven't change any of the default groupings and the server is brand new > >>>> with no third part software installed. > > >>> Any explicit "Deny" NTFS ACE overrides any "Allow" permissions. So > >>> whether or not IUSR account is part of the Users group, any explicit > >>> deny would nullify any grant of Write permissions. > > >>> I suggest you either: > >>> a) download Filemon.exe from the Microsoft website, and see what user > >>> account is actually being used to write the file (it's probably not what > >>> you think) > > >>> b) enable Object Access Auditing on your server (via the local security > >>> policy) and then enable auditing on that file (again, to see which > >>> account is being used. For this method, object access will be recorded > >>> in the Windows Security event log) > > >>> Cheers > >>> Ken > > >>> -- > >>> My IIS Blog:www.adOpenStatic.com/cs/blogs/ken > > >>> "Brain Steward" <j...@junk.com> wrote in message > >>>news:uSvuLZb$HHA.1188@TK2MSFTNGP04.phx.gbl... > >>>> David -- I have a simple ASP script which runs under IIS defaults. I
David,
Where you at the ***** below, within repro'd the permissions by it did not repro the write success did you create the same dir level grant/deny precidence ? Roger [quoted text, click to view] "David Wang" <w3.4you@gmail.com> wrote in message news:1190707533.003742.83110@d55g2000hsg.googlegroups.com... > What you describe is not the default behavior, so I do not believe > your configuration is the default from Microsoft. > > It may be the default configuration that you get from Dell, but that > is no guarantee that it is the same as Microsoft's. > > I can only talk in terms of Microsoft's defaults because that is a > global constant. Server vendors may do their own customizations of the > same Microsoft software. It is a "right" that they sued and obtained > from Microsoft, so if you don't like how it's turning out, blame that > lawsuit... > > Anyhow, I went over to my IIS6 server built from default Microsoft > configuration, which has the same ACLs that you describe, and I copied/ ***** ***** [quoted text, click to view] > ran your ASP page... and it fails with access denied under only
> anonymous authentication. All defaults... and behaving the way it > should. > > So, I can say that I just provided counterpoint to your statement and > that we are not looking at any bug in IIS6 but rather user- > misconfiguration. Now, the user may be using defaults from server > manufacturer and thinks they did nothing wrong -- so they think issue > must be with IIS6 -- but the reality is that the problem is with the > system's settings, not IIS, and we have to agree that the problem is > with the setting. We all know that with improper settings, any system > can appear insecure. > > Now that we are all on the same page that the problem is with user- > configuration (let's not have violent reaction to it. I call it user > configuration because it's not the defaults set by Microsoft/IIS -- > maybe you want to think of it as "non-default configuration"), the fun > will be to figure out what is non-default. > > Some of my thoughts -- > perhaps .asp is scriptmapped to aspnet_isapi.dll, in which case your > "ASP code" is actually run by ASP.Net under its default impersonation, > which would be process identity -- which would be Network Service by > default and match what you observe. > > > //David > http://w3-4u.blogspot.com > http://blogs.msdn.com/David.Wang > // > > > > > > > > > On Sep 23, 8:06 pm, "BrianSteward" <j...@junk.com> wrote: >> It's definitly the default configuration -- straight out of the box, >> brand >> new Dell rack mounted server. It's the same as other servers I have going >> back to October 2005. All run IIS under the NT AUTHORITY\Network account. >> >> Furthermore as I noted below the default permissions for the >> IUSER_<machinename> on the wwwroot directory has no read permissions. It >> only has deny write. That is the same on every IIS 6.0 server that I >> have >> ever seen and it's been mentioned many times in this board and others. >> If >> there are no read permissions on the IUSR account then that would mean >> that >> if IIS impersonated the IUSR account it would not be able to read any >> files >> wouldn't it? >> >> I know you say IIS SHOULD impersonate the IUSR account -- but it would >> appear it doesn't in IIS 6.0. That really was the point of my original >> post >> as I thought (without ever checking prior to my doing this test) that it >> should as well. >> >> Saying something is up with my configuration unfortuantely just begs the >> original question. I don't believe anything is up with my coinfiguration, >> rather that's the way IIS 6.0 is configured by default. I'd be happy to >> be >> persuaded otherwise if you could point me to the change in my >> configuration >> that you think has caused non-standard behaviour. >> >> Thanks for your help to date. >> >> Brian. >> >> "Ken Schaefer" <kenREM...@THISadOpenStatic.com> wrote in message >> >> news:%23nKBSnk$HHA.5164@TK2MSFTNGP05.phx.gbl... >> >> >> >> > OK - at least we have found the account being used. >> >> > However in a default configuration of IIS 6.0, the NT AUTHORITY\Network >> > Sevice account is not the impersonated user for Classic ASP files. >> > Network >> > Service is used as the w3wp.exe process identity, but IIS should >> > impersonate IUSR_<machinename> for anonymous access. >> >> > So, something is up with your conifguration if Network Service is being >> > used for Classic ASP files. >> >> > Cheers >> > Ken >> >> > "Brain Steward" <j...@junk.com> wrote in message >> >news:eOy%23Oae$HHA.3716@TK2MSFTNGP03.phx.gbl... >> >>I checked on the account used to write to the file. It's the NT >> >>Authority\Network account. It's the same on all my Win 2003 servers -- >> >>I've checked a few. >> >> >> So it would appear that even though the web site was accessed by an >> >> anonymous user (ie the user was not authenticated as any other user) >> >> any >> >> permissions on a directory for anonymous users are effectively ignored >> >> by >> >> IIS as the ASP script runs under the NT Authority/Network account >> >> which >> >> has been granted write permissions, I presume, because it's a member >> >> of >> >> users or administrators. >> >> >> That's not a problem in iteslef, if we know for sure that this is the >> >> case, but it effectivly means including permissions for the >> >> IUSR_myserver >> >> user on the web directory achieves nothing. I can see it would >> >> prevent a >> >> webdav put from an anonymous user writing to the directory, but >> >> un-ticking 'write' in the IIS console for the directory achieves that >> >> (and it doesn't prevent ASP writing to the directory) so I can't even >> >> see >> >> the point of including the IUSR_mysever user at all as everything runs >> >> fine without it. The default IUSER_myserver user on Win 2003 doesn't >> >> even >> >> have read permissions. The only thing it has is deny write, so clearly >> >> it's not used by IIS. >> >> >> Is my understanding correct? >> >> >> "Ken Schaefer" <kenREM...@THISadOpenStatic.com> wrote in message >> >>news:uzyjq7d$HHA.3548@TK2MSFTNGP06.phx.gbl... >> >>>> As I said below, the behaviour is consistent with the internet guest >> >>>> account being treated as a member of the users group, which it >> >>>> isn't. I >> >>>> haven't change any of the default groupings and the server is brand >> >>>> new >> >>>> with no third part software installed. >> >> >>> Any explicit "Deny" NTFS ACE overrides any "Allow" permissions. So >> >>> whether or not IUSR account is part of the Users group, any explicit >> >>> deny would nullify any grant of Write permissions. >> >> >>> I suggest you either: >> >>> a) download Filemon.exe from the Microsoft website, and see what user >> >>> account is actually being used to write the file (it's probably not >> >>> what >> >>> you think)
[quoted text, click to view]
"Ken Schaefer" <kenREMOVE@THISadOpenStatic.com> wrote in message news:uzyjq7d$HHA.3548@TK2MSFTNGP06.phx.gbl... >> As I said below, the behaviour is consistent with the internet guest >> account being treated as a member of the users group, which it isn't. I >> haven't change any of the default groupings and the server is brand new >> with no third part software installed. > > Any explicit "Deny" NTFS ACE overrides any "Allow" permissions. So whether > or not IUSR account is part of the Users group, any explicit deny would > nullify any grant of Write permissions. > Hi Ken, This is not quite fully complete as ACLs now work. Inheritance of grants/denies have an order in how they overrule. An explict of either kind at some location overrules any inherited of the other and conflicting (same principal) kind. So, for example, and allow placed on a dir overrides an inherited deny. Roger [quoted text, click to view] > I suggest you either: > a) download Filemon.exe from the Microsoft website, and see what user > account is actually being used to write the file (it's probably not what > you think) > > b) enable Object Access Auditing on your server (via the local security > policy) and then enable auditing on that file (again, to see which account > is being used. For this method, object access will be recorded in the > Windows Security event log) > > Cheers > Ken > > -- > My IIS Blog: www.adOpenStatic.com/cs/blogs/ken > > > "Brain Steward" <junk@junk.com> wrote in message > news:uSvuLZb$HHA.1188@TK2MSFTNGP04.phx.gbl... >> David -- I have a simple ASP script which runs under IIS defaults. I >> haven't set up any additional accounts -- administrator is the only user >> account on the server. I can't clarify which actual user account performs >> the writes -- I don't know how to do that. All I can say is that the >> server is stock standard, using defaults everywhere. Whatever user >> account ASP scripts run under is used I guess, but I though (unlike >> ASP.NET) that they would have the same permissions as the IUSR_myserver >> account. Is this not the case? >> >> The script creates and writes a text file to a directory (called "logs") >> within the web using the following components: >> <% >> set fs = CreateObject("Scripting.FileSystemObject") >> FileName="Logs\events.html" >> path=server.mappath(FileName) >> if fs.FileExists(path) = True then >> set f= fs.OpenTextFile(path,8) >> else >> set f = fs.CreateTextFile(path,True) >> end if >> temp = "information that I write to the file" >> f.write (left(temp,197) & "</b><br>") >> %> >> >> That's pretty much the whole script. >> >> The "logs" directory has write permissions for users. The permissions >> for the intenet guest account are "deny write". Access to the web is >> anonymous (ie users are not logged on as administrator or any othe user >> (as there aren't any anyway)). >> >> So in summary: anonymous visitors using a web browser execute this ASP >> script which writes information to the logs directory even though >> permissions on this directory for the internet guest account say "deny >> write". As I said below, the behaviour is consistent with the internet >> guest account being treated as a member of the users group, which it >> isn't. I haven't change any of the default groupings and the server is >> brand new with no third part software installed. >> >> If you need any more information to help you explain this please let me >> know exactly what I can provide and I'll let you have it. >> >> Thanks for you help. >> >> "David Wang" <w3.4you@gmail.com> wrote in message >> news:1190531527.150391.221770@57g2000hsv.googlegroups.com... >>> On Sep 22, 2:00 pm, "Brain Steward" <j...@junk.com> wrote: >>>> I have IIS 6.0 Win 2003. Most directories in the web use MS default >>>> permissions for IIS 6.0 , the relevant ones of which are USERS (Read & >>>> Excecute, List Folder.., and Read) and the Internet Guest Account >>>> server >>>> which has no "allows" and a "Deny Write". >>>> >>>> My question is: the deny write does not seem to do anything at all. I >>>> have >>>> a directory where an ASP script (not ASP.net, just classic ASP) writes >>>> a >>>> text file. On this directory I have anbled "WRITE" for Users. The >>>> intenet >>>> Guest Account is unchanged and inherits "Deny Write". In the IIS >>>> console >>>> for this directory "Write" is NOT ticked and anonymous access is >>>> enabled for >>>> the entire web site. The issue is that even though I put "deny write" >>>> on >>>> the internet guest account (which I'm doing as a test of my security) >>>> it >>>> does NOT stop the ASP script from writing to this directory. >>>> >>>> Why is this? I would have though that if you access the ASP script as >>>> an >>>> anonymous user and this ASP script writes to a second directory which >>>> has >>>> "Deny Write" for the Internet Guest Account this should prevent the ASP >>>> script from writing. But it doesn't. >>>> >>>> The IIS configuration is the default --- eg the application pool runs >>>> under >>>> the network identity (ie the default). >>>> >>>> Of course I can prevent writing to the directory if I remove write >>>> permissions from USERS. But I don't understand why the Internet guest >>>> account can write even when write permissions are explicitly denied and >>>> seconly why the Internet Guest Account seems to end up being treated as >>>> a >>>> "USER" even though it is not a member of the User group. >>>> >>>> Can anybody explain this behaviour? >>> >>> >>> Can you clarify the actual user account which performs the CreateFile/ >>> WriteFile Win32 API call through all the layers of your ASP page and >>> any components it may use. >>> >>> It is likely not what you think, which is what results in this >>> seemingly insecure behavior. >>> >>> The best thing I can think of is to help you learn how to investigate >>> and form correct interpretation of what is going on -- and not simply >>> explain a mysterious behavior -- because simply explaining a mystery >>> does not prevent another mystery from stymying you in the future. >>> >>> >>> //David >>> http://w3-4u.blogspot.com >>> http://blogs.msdn.com/David.Wang >>> // >>> >> >> >
See within . . .
[quoted text, click to view] "Brain Steward" <junk@junk.com> wrote in message news:Oic0QuV$HHA.4460@TK2MSFTNGP02.phx.gbl... >I have IIS 6.0 Win 2003. Most directories in the web use MS default >permissions for IIS 6.0 , the relevant ones of which are USERS (Read & >Excecute, List Folder.., and Read) and the Internet Guest Account server >which has no "allows" and a "Deny Write". > > My question is: the deny write does not seem to do anything at all. I > have What you report is because of how NTFS is defined to work. Where conflicted, the most closely stated permission (allow or deny) for a principal rules, where "closely" is in levels going up the dir hierarchy from point of permissions evaluation. An explicit deny overrides an inherited allow; an explicit allow overrides an inherited deny. [quoted text, click to view] > a directory where an ASP script (not ASP.net, just classic ASP) writes a > text file. On this directory I have anbled "WRITE" for Users. The > intenet Guest Account is unchanged and inherits "Deny Write". In the IIS > console for this directory "Write" is NOT ticked and anonymous access is > enabled for the entire web site. The issue is that even though I put > "deny write" on the internet guest account (which I'm doing as a test of > my security) it does NOT stop the ASP script from writing to this > directory. > > Why is this? To explain we only need to assume your IUSR_ is a member of your Users, perhaps through Authenticated Users and/or Interactive. You have then defined an explict write grant the includes your IUSR_. If you want to see a deny of write effective for your IUSR_ do it at the same dir (or below) as where you grant Users write. Roger
[quoted text, click to view] "BrianSteward" <junk@junk.com> wrote in message news:ubQKWy3$HHA.484@TK2MSFTNGP06.phx.gbl... > Understood Ken. The fact is, it doesn't matter at all that ASP is running > under the same account as ASP.net -- it's certainly no less secure -- so > it's not something I'd want to spend too much more time on. I was just > interested as to why this is the case and has always been so since I > started using IIS 6.0 on several servers since October 2005. Perhaps > because .htm files are mapped to asp.net (see my note below) and thus run > under this network account, this has caused ASP to also run under this > account. Could this be the case? Given nobody can even suggest a > configuration change that I might have made to cause this, and given I > know I haven't made any, I From what I have seen of the thread, it is just that you are not reading correctly what should be allowed based on the NTFS permissioning. The site is anonymous, the Iusr_ account tries, and gets, write access. The ACL on the place written to says allow write to Users, and Iusr_ is a member of Users. All as it should be per the constraints. Roger [quoted text, click to view] > think that's probably where this discussion will end.
> > Thanks for your help to date. > > Brian. > > > "Ken Schaefer" <kenREMOVE@THISadOpenStatic.com> wrote in message > news:ejcqml3$HHA.4836@TK2MSFTNGP06.phx.gbl... >> Hi Brian, >> >> David works for Microsoft, and was with the IIS product group for many >> years. I've been an IIS MVP for about 5 years now, and I've looked at >> many, many IIS servers (and also written a book on IIS). I think, between >> the two of us, we know how a default configuration is supposed to work >> :-) >> >> There is something about the configuration of your server that is causing >> altered behaviour. But unless you wish to turn over your metabase (for >> starters) so that we can see every possible configuration item that you >> have, it's a bit difficult to say "this is the cause". >> >> Cheers >> Ken >> >> "BrianSteward" <junk@junk.com> wrote in message >> news:uto9OW3$HHA.536@TK2MSFTNGP06.phx.gbl... >>> David, >>> >>> Re ASP script mappings: they are the default. ie >>> C:\WINDOWS\system32\inetsrv\asp.dll >>> >>> Another point that may or may not be relevant: I have mapped all .htm >>> to asp.net 2.0 (ie >>> c:\windows\microsoft.net\framework\v2.0.50727\aspnet_isapi.dll). ie I >>> use ASP.net to process all htm pages as they all have some server side >>> script. The application pool for the site runs under the default >>> identity (Network Service). >>> >>> I can't see how the above could affect the account ASP scripts are run >>> under but I mention it anyway. >>> >>> As you believe it is not the default (although it would seem that it is >>> for Dell, one of Microsoft's largest server OEMs) could you please tell >>> me exactly what I could have changed to cause this "non standard" >>> behaviour? ie if you believe it is a user configuration issue then could >>> you let me know exactly what that user configuration could be? ie >>> unless somebody can identify what could cause that behaviour it's a bit >>> hard to argue that it is a user configuration issue. I agree Dell may >>> ship it's servers in this form, but I actually think it is very unlikely >>> they would change the account ASP scripts run under. >>> >>> Thanks! >>> >>> >>> >>> "David Wang" <w3.4you@gmail.com> wrote in message >>> news:1190707533.003742.83110@d55g2000hsg.googlegroups.com... >>>> What you describe is not the default behavior, so I do not believe >>>> your configuration is the default from Microsoft. >>>> >>>> It may be the default configuration that you get from Dell, but that >>>> is no guarantee that it is the same as Microsoft's. >>>> >>>> I can only talk in terms of Microsoft's defaults because that is a >>>> global constant. Server vendors may do their own customizations of the >>>> same Microsoft software. It is a "right" that they sued and obtained >>>> from Microsoft, so if you don't like how it's turning out, blame that >>>> lawsuit... >>>> >>>> Anyhow, I went over to my IIS6 server built from default Microsoft >>>> configuration, which has the same ACLs that you describe, and I copied/ >>>> ran your ASP page... and it fails with access denied under only >>>> anonymous authentication. All defaults... and behaving the way it >>>> should. >>>> >>>> So, I can say that I just provided counterpoint to your statement and >>>> that we are not looking at any bug in IIS6 but rather user- >>>> misconfiguration. Now, the user may be using defaults from server >>>> manufacturer and thinks they did nothing wrong -- so they think issue >>>> must be with IIS6 -- but the reality is that the problem is with the >>>> system's settings, not IIS, and we have to agree that the problem is >>>> with the setting. We all know that with improper settings, any system >>>> can appear insecure. >>>> >>>> Now that we are all on the same page that the problem is with user- >>>> configuration (let's not have violent reaction to it. I call it user >>>> configuration because it's not the defaults set by Microsoft/IIS -- >>>> maybe you want to think of it as "non-default configuration"), the fun >>>> will be to figure out what is non-default. >>>> >>>> Some of my thoughts -- >>>> perhaps .asp is scriptmapped to aspnet_isapi.dll, in which case your >>>> "ASP code" is actually run by ASP.Net under its default impersonation, >>>> which would be process identity -- which would be Network Service by >>>> default and match what you observe. >>>> >>>> >>>> //David >>>> http://w3-4u.blogspot.com >>>> http://blogs.msdn.com/David.Wang >>>> // >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Sep 23, 8:06 pm, "BrianSteward" <j...@junk.com> wrote: >>>>> It's definitly the default configuration -- straight out of the box, >>>>> brand >>>>> new Dell rack mounted server. It's the same as other servers I have >>>>> going >>>>> back to October 2005. All run IIS under the NT AUTHORITY\Network >>>>> account. >>>>> >>>>> Furthermore as I noted below the default permissions for the >>>>> IUSER_<machinename> on the wwwroot directory has no read permissions. >>>>> It >>>>> only has deny write. That is the same on every IIS 6.0 server that I >>>>> have >>>>> ever seen and it's been mentioned many times in this board and >>>>> others. If >>>>> there are no read permissions on the IUSR account then that would mean >>>>> that >>>>> if IIS impersonated the IUSR account it would not be able to read any >>>>> files >>>>> wouldn't it? >>>>> >>>>> I know you say IIS SHOULD impersonate the IUSR account -- but it would >>>>> appear it doesn't in IIS 6.0. That really was the point of my >>>>> original post >>>>> as I thought (without ever checking prior to my doing this test) that >>>>> it
David,
Re ASP script mappings: they are the default. ie C:\WINDOWS\system32\inetsrv\asp.dll Another point that may or may not be relevant: I have mapped all .htm to asp.net 2.0 (ie c:\windows\microsoft.net\framework\v2.0.50727\aspnet_isapi.dll). ie I use ASP.net to process all htm pages as they all have some server side script. The application pool for the site runs under the default identity (Network Service). I can't see how the above could affect the account ASP scripts are run under but I mention it anyway. As you believe it is not the default (although it would seem that it is for Dell, one of Microsoft's largest server OEMs) could you please tell me exactly what I could have changed to cause this "non standard" behaviour? ie if you believe it is a user configuration issue then could you let me know exactly what that user configuration could be? ie unless somebody can identify what could cause that behaviour it's a bit hard to argue that it is a user configuration issue. I agree Dell may ship it's servers in this form, but I actually think it is very unlikely they would change the account ASP scripts run under. Thanks! [quoted text, click to view] "David Wang" <w3.4you@gmail.com> wrote in message
news:1190707533.003742.83110@d55g2000hsg.googlegroups.com... > What you describe is not the default behavior, so I do not believe > your configuration is the default from Microsoft. > > It may be the default configuration that you get from Dell, but that > is no guarantee that it is the same as Microsoft's. > > I can only talk in terms of Microsoft's defaults because that is a > global constant. Server vendors may do their own customizations of the > same Microsoft software. It is a "right" that they sued and obtained > from Microsoft, so if you don't like how it's turning out, blame that > lawsuit... > > Anyhow, I went over to my IIS6 server built from default Microsoft > configuration, which has the same ACLs that you describe, and I copied/ > ran your ASP page... and it fails with access denied under only > anonymous authentication. All defaults... and behaving the way it > should. > > So, I can say that I just provided counterpoint to your statement and > that we are not looking at any bug in IIS6 but rather user- > misconfiguration. Now, the user may be using defaults from server > manufacturer and thinks they did nothing wrong -- so they think issue > must be with IIS6 -- but the reality is that the problem is with the > system's settings, not IIS, and we have to agree that the problem is > with the setting. We all know that with improper settings, any system > can appear insecure. > > Now that we are all on the same page that the problem is with user- > configuration (let's not have violent reaction to it. I call it user > configuration because it's not the defaults set by Microsoft/IIS -- > maybe you want to think of it as "non-default configuration"), the fun > will be to figure out what is non-default. > > Some of my thoughts -- > perhaps .asp is scriptmapped to aspnet_isapi.dll, in which case your > "ASP code" is actually run by ASP.Net under its default impersonation, > which would be process identity -- which would be Network Service by > default and match what you observe. > > > //David > http://w3-4u.blogspot.com > http://blogs.msdn.com/David.Wang > // > > > > > > > > > On Sep 23, 8:06 pm, "BrianSteward" <j...@junk.com> wrote: >> It's definitly the default configuration -- straight out of the box, >> brand >> new Dell rack mounted server. It's the same as other servers I have going >> back to October 2005. All run IIS under the NT AUTHORITY\Network account. >> >> Furthermore as I noted below the default permissions for the >> IUSER_<machinename> on the wwwroot directory has no read permissions. It >> only has deny write. That is the same on every IIS 6.0 server that I >> have >> ever seen and it's been mentioned many times in this board and others. >> If >> there are no read permissions on the IUSR account then that would mean >> that >> if IIS impersonated the IUSR account it would not be able to read any >> files >> wouldn't it? >> >> I know you say IIS SHOULD impersonate the IUSR account -- but it would >> appear it doesn't in IIS 6.0. That really was the point of my original >> post >> as I thought (without ever checking prior to my doing this test) that it >> should as well. >> >> Saying something is up with my configuration unfortuantely just begs the >> original question. I don't believe anything is up with my coinfiguration, >> rather that's the way IIS 6.0 is configured by default. I'd be happy to >> be >> persuaded otherwise if you could point me to the change in my >> configuration >> that you think has caused non-standard behaviour. >> >> Thanks for your help to date. >> >> Brian. >> >> "Ken Schaefer" <kenREM...@THISadOpenStatic.com> wrote in message >> >> news:%23nKBSnk$HHA.5164@TK2MSFTNGP05.phx.gbl... >> >> >> >> > OK - at least we have found the account being used. >> >> > However in a default configuration of IIS 6.0, the NT AUTHORITY\Network >> > Sevice account is not the impersonated user for Classic ASP files. >> > Network >> > Service is used as the w3wp.exe process identity, but IIS should >> > impersonate IUSR_<machinename> for anonymous access. >> >> > So, something is up with your conifguration if Network Service is being >> > used for Classic ASP files. >> >> > Cheers >> > Ken >> >> > "Brain Steward" <j...@junk.com> wrote in message >> >news:eOy%23Oae$HHA.3716@TK2MSFTNGP03.phx.gbl... >> >>I checked on the account used to write to the file. It's the NT >> >>Authority\Network account. It's the same on all my Win 2003 servers -- >> >>I've checked a few. >> >> >> So it would appear that even though the web site was accessed by an >> >> anonymous user (ie the user was not authenticated as any other user) >> >> any >> >> permissions on a directory for anonymous users are effectively ignored >> >> by >> >> IIS as the ASP script runs under the NT Authority/Network account >> >> which >> >> has been granted write permissions, I presume, because it's a member >> >> of >> >> users or administrators. >> >> >> That's not a problem in iteslef, if we know for sure that this is the >> >> case, but it effectivly means including permissions for the >> >> IUSR_myserver >> >> user on the web directory achieves nothing. I can see it would >> >> prevent a >> >> webdav put from an anonymous user writing to the directory, but >> >> un-ticking 'write' in the IIS console for the directory achieves that >> >> (and it doesn't prevent ASP writing to the directory) so I can't even >> >> see >> >> the point of including the IUSR_mysever user at all as everything runs >> >> fine without it. The default IUSER_myserver user on Win 2003 doesn't >> >> even
Hi Brian,
David works for Microsoft, and was with the IIS product group for many years. I've been an IIS MVP for about 5 years now, and I've looked at many, many IIS servers (and also written a book on IIS). I think, between the two of us, we know how a default configuration is supposed to work :-) There is something about the configuration of your server that is causing altered behaviour. But unless you wish to turn over your metabase (for starters) so that we can see every possible configuration item that you have, it's a bit difficult to say "this is the cause". Cheers Ken [quoted text, click to view] "BrianSteward" <junk@junk.com> wrote in message
news:uto9OW3$HHA.536@TK2MSFTNGP06.phx.gbl... > David, > > Re ASP script mappings: they are the default. ie > C:\WINDOWS\system32\inetsrv\asp.dll > > Another point that may or may not be relevant: I have mapped all .htm to > asp.net 2.0 (ie > c:\windows\microsoft.net\framework\v2.0.50727\aspnet_isapi.dll). ie I use > ASP.net to process all htm pages as they all have some server side script. > The application pool for the site runs under the default identity (Network > Service). > > I can't see how the above could affect the account ASP scripts are run > under but I mention it anyway. > > As you believe it is not the default (although it would seem that it is > for Dell, one of Microsoft's largest server OEMs) could you please tell me > exactly what I could have changed to cause this "non standard" behaviour? > ie if you believe it is a user configuration issue then could you let me > know exactly what that user configuration could be? ie unless somebody > can identify what could cause that behaviour it's a bit hard to argue that > it is a user configuration issue. I agree Dell may ship it's servers in > this form, but I actually think it is very unlikely they would change the > account ASP scripts run under. > > Thanks! > > > > "David Wang" <w3.4you@gmail.com> wrote in message > news:1190707533.003742.83110@d55g2000hsg.googlegroups.com... >> What you describe is not the default behavior, so I do not believe >> your configuration is the default from Microsoft. >> >> It may be the default configuration that you get from Dell, but that >> is no guarantee that it is the same as Microsoft's. >> >> I can only talk in terms of Microsoft's defaults because that is a >> global constant. Server vendors may do their own customizations of the >> same Microsoft software. It is a "right" that they sued and obtained >> from Microsoft, so if you don't like how it's turning out, blame that >> lawsuit... >> >> Anyhow, I went over to my IIS6 server built from default Microsoft >> configuration, which has the same ACLs that you describe, and I copied/ >> ran your ASP page... and it fails with access denied under only >> anonymous authentication. All defaults... and behaving the way it >> should. >> >> So, I can say that I just provided counterpoint to your statement and >> that we are not looking at any bug in IIS6 but rather user- >> misconfiguration. Now, the user may be using defaults from server >> manufacturer and thinks they did nothing wrong -- so they think issue >> must be with IIS6 -- but the reality is that the problem is with the >> system's settings, not IIS, and we have to agree that the problem is >> with the setting. We all know that with improper settings, any system >> can appear insecure. >> >> Now that we are all on the same page that the problem is with user- >> configuration (let's not have violent reaction to it. I call it user >> configuration because it's not the defaults set by Microsoft/IIS -- >> maybe you want to think of it as "non-default configuration"), the fun >> will be to figure out what is non-default. >> >> Some of my thoughts -- >> perhaps .asp is scriptmapped to aspnet_isapi.dll, in which case your >> "ASP code" is actually run by ASP.Net under its default impersonation, >> which would be process identity -- which would be Network Service by >> default and match what you observe. >> >> >> //David >> http://w3-4u.blogspot.com >> http://blogs.msdn.com/David.Wang >> // >> >> >> >> >> >> >> >> >> On Sep 23, 8:06 pm, "BrianSteward" <j...@junk.com> wrote: >>> It's definitly the default configuration -- straight out of the box, >>> brand >>> new Dell rack mounted server. It's the same as other servers I have >>> going >>> back to October 2005. All run IIS under the NT AUTHORITY\Network >>> account. >>> >>> Furthermore as I noted below the default permissions for the >>> IUSER_<machinename> on the wwwroot directory has no read permissions. It >>> only has deny write. That is the same on every IIS 6.0 server that I >>> have >>> ever seen and it's been mentioned many times in this board and others. >>> If >>> there are no read permissions on the IUSR account then that would mean >>> that >>> if IIS impersonated the IUSR account it would not be able to read any >>> files >>> wouldn't it? >>> >>> I know you say IIS SHOULD impersonate the IUSR account -- but it would >>> appear it doesn't in IIS 6.0. That really was the point of my original >>> post >>> as I thought (without ever checking prior to my doing this test) that it >>> should as well. >>> >>> Saying something is up with my configuration unfortuantely just begs the >>> original question. I don't believe anything is up with my >>> coinfiguration, >>> rather that's the way IIS 6.0 is configured by default. I'd be happy to >>> be >>> persuaded otherwise if you could point me to the change in my >>> configuration >>> that you think has caused non-standard behaviour. >>> >>> Thanks for your help to date. >>> >>> Brian. >>> >>> "Ken Schaefer" <kenREM...@THISadOpenStatic.com> wrote in message >>> >>> news:%23nKBSnk$HHA.5164@TK2MSFTNGP05.phx.gbl... >>> >>> >>> >>> > OK - at least we have found the account being used. >>> >>> > However in a default configuration of IIS 6.0, the NT >>> > AUTHORITY\Network >>> > Sevice account is not the impersonated user for Classic ASP files. >>> > Network >>> > Service is used as the w3wp.exe process identity, but IIS should >>> > impersonate IUSR_<machinename> for anonymous access. >>> >>> > So, something is up with your conifguration if Network Service is >>> > being >>> > used for Classic ASP files. >>> >>> > Cheers >>> > Ken >>> >>> > "Brain Steward" <j...@junk.com> wrote in message >>> >news:eOy%23Oae$HHA.3716@TK2MSFTNGP03.phx.gbl... >>> >>I checked on the account used to write to the file. It's the NT >>> >>Authority\Network account. It's the same on all my Win 2003 servers -- >>> >>I've checked a few. >>> >>> >> So it would appear that even though the web site was accessed by an >>> >> anonymous user (ie the user was not authenticated as any other user) >>> >> any
Roger, you say below "Iusr_ is a member of Users. It's not is it? That's
the point of the whole thread. If you believe IUSR is a member of users can you show me some docuementation that states that this is the case? IUSR is a member of GUESTS. It's not a member of users or authenticated users as far as I'm aware. Set me straight if this is not the case, but I've never seen anytying that suggests IUSR is a member of users. On IIS 6.0 it's not even a member of EVERYONE. [quoted text, click to view] "Roger Abell [MVP]" <mvpnospam@asu.edu> wrote in message
news:OzKPaR8$HHA.4568@TK2MSFTNGP02.phx.gbl... > > "BrianSteward" <junk@junk.com> wrote in message > news:ubQKWy3$HHA.484@TK2MSFTNGP06.phx.gbl... >> Understood Ken. The fact is, it doesn't matter at all that ASP is >> running under the same account as ASP.net -- it's certainly no less >> secure -- so it's not something I'd want to spend too much more time on. >> I was just interested as to why this is the case and has always been so >> since I started using IIS 6.0 on several servers since October 2005. >> Perhaps because .htm files are mapped to asp.net (see my note below) and >> thus run under this network account, this has caused ASP to also run >> under this account. Could this be the case? Given nobody can even >> suggest a configuration change that I might have made to cause this, and >> given I know I haven't made any, I > > From what I have seen of the thread, it is just that you are not reading > correctly what should be allowed based on the NTFS permissioning. > The site is anonymous, the Iusr_ account tries, and gets, write access. > The ACL on the place written to says allow write to Users, and Iusr_ > is a member of Users. All as it should be per the constraints. > > Roger > >> think that's probably where this discussion will end. >> >> Thanks for your help to date. >> >> Brian. >> >> >> "Ken Schaefer" <kenREMOVE@THISadOpenStatic.com> wrote in message >> news:ejcqml3$HHA.4836@TK2MSFTNGP06.phx.gbl... >>> Hi Brian, >>> >>> David works for Microsoft, and was with the IIS product group for many >>> years. I've been an IIS MVP for about 5 years now, and I've looked at >>> many, many IIS servers (and also written a book on IIS). I think, >>> between the two of us, we know how a default configuration is supposed >>> to work :-) >>> >>> There is something about the configuration of your server that is >>> causing altered behaviour. But unless you wish to turn over your >>> metabase (for starters) so that we can see every possible configuration >>> item that you have, it's a bit difficult to say "this is the cause". >>> >>> Cheers >>> Ken >>> >>> "BrianSteward" <junk@junk.com> wrote in message >>> news:uto9OW3$HHA.536@TK2MSFTNGP06.phx.gbl... >>>> David, >>>> >>>> Re ASP script mappings: they are the default. ie >>>> C:\WINDOWS\system32\inetsrv\asp.dll >>>> >>>> Another point that may or may not be relevant: I have mapped all .htm >>>> to asp.net 2.0 (ie >>>> c:\windows\microsoft.net\framework\v2.0.50727\aspnet_isapi.dll). ie I >>>> use ASP.net to process all htm pages as they all have some server side >>>> script. The application pool for the site runs under the default >>>> identity (Network Service). >>>> >>>> I can't see how the above could affect the account ASP scripts are run >>>> under but I mention it anyway. >>>> >>>> As you believe it is not the default (although it would seem that it is >>>> for Dell, one of Microsoft's largest server OEMs) could you please tell >>>> me exactly what I could have changed to cause this "non standard" >>>> behaviour? ie if you believe it is a user configuration issue then >>>> could you let me know exactly what that user configuration could be? >>>> ie unless somebody can identify what could cause that behaviour it's a >>>> bit hard to argue that it is a user configuration issue. I agree Dell >>>> may ship it's servers in this form, but I actually think it is very >>>> unlikely they would change the account ASP scripts run under. >>>> >>>> Thanks! >>>> >>>> >>>> >>>> "David Wang" <w3.4you@gmail.com> wrote in message >>>> news:1190707533.003742.83110@d55g2000hsg.googlegroups.com... >>>>> What you describe is not the default behavior, so I do not believe >>>>> your configuration is the default from Microsoft. >>>>> >>>>> It may be the default configuration that you get from Dell, but that >>>>> is no guarantee that it is the same as Microsoft's. >>>>> >>>>> I can only talk in terms of Microsoft's defaults because that is a >>>>> global constant. Server vendors may do their own customizations of the >>>>> same Microsoft software. It is a "right" that they sued and obtained >>>>> from Microsoft, so if you don't like how it's turning out, blame that >>>>> lawsuit... >>>>> >>>>> Anyhow, I went over to my IIS6 server built from default Microsoft >>>>> configuration, which has the same ACLs that you describe, and I >>>>> copied/ >>>>> ran your ASP page... and it fails with access denied under only >>>>> anonymous authentication. All defaults... and behaving the way it >>>>> should. >>>>> >>>>> So, I can say that I just provided counterpoint to your statement and >>>>> that we are not looking at any bug in IIS6 but rather user- >>>>> misconfiguration. Now, the user may be using defaults from server >>>>> manufacturer and thinks they did nothing wrong -- so they think issue >>>>> must be with IIS6 -- but the reality is that the problem is with the >>>>> system's settings, not IIS, and we have to agree that the problem is >>>>> with the setting. We all know that with improper settings, any system >>>>> can appear insecure. >>>>> >>>>> Now that we are all on the same page that the problem is with user- >>>>> configuration (let's not have violent reaction to it. I call it user >>>>> configuration because it's not the defaults set by Microsoft/IIS -- >>>>> maybe you want to think of it as "non-default configuration"), the fun >>>>> will be to figure out what is non-default. >>>>> >>>>> Some of my thoughts -- >>>>> perhaps .asp is scriptmapped to aspnet_isapi.dll, in which case your >>>>> "ASP code" is actually run by ASP.Net under its default impersonation, >>>>> which would be process identity -- which would be Network Service by >>>>> default and match what you observe. >>>>> >>>>> >>>>> //David >>>>> http://w3-4u.blogspot.com >>>>> http://blogs.msdn.com/David.Wang >>>>> // >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Sep 23, 8:06 pm, "BrianSteward" <j...@junk.com> wrote: >>>>>> It's definitly the default configuration -- straight out of the box, >>>>>> brand >>>>>> new Dell rack mounted server. It's the same as other servers I have >>>>>> going >>>>>> back to October 2005. All run IIS under the NT AUTHORITY\Network >>>>>> account. >>>>>>
Understood Ken. The fact is, it doesn't matter at all that ASP is running
under the same account as ASP.net -- it's certainly no less secure -- so it's not something I'd want to spend too much more time on. I was just interested as to why this is the case and has always been so since I started using IIS 6.0 on several servers since October 2005. Perhaps because .htm files are mapped to asp.net (see my note below) and thus run under this network account, this has caused ASP to also run under this account. Could this be the case? Given nobody can even suggest a configuration change that I might have made to cause this, and given I know I haven't made any, I think that's probably where this discussion will end. Thanks for your help to date. Brian. [quoted text, click to view] "Ken Schaefer" <kenREMOVE@THISadOpenStatic.com> wrote in message
news:ejcqml3$HHA.4836@TK2MSFTNGP06.phx.gbl... > Hi Brian, > > David works for Microsoft, and was with the IIS product group for many > years. I've been an IIS MVP for about 5 years now, and I've looked at > many, many IIS servers (and also written a book on IIS). I think, between > the two of us, we know how a default configuration is supposed to work :-) > > There is something about the configuration of your server that is causing > altered behaviour. But unless you wish to turn over your metabase (for > starters) so that we can see every possible configuration item that you > have, it's a bit difficult to say "this is the cause". > > Cheers > Ken > > "BrianSteward" <junk@junk.com> wrote in message > news:uto9OW3$HHA.536@TK2MSFTNGP06.phx.gbl... >> David, >> >> Re ASP script mappings: they are the default. ie >> C:\WINDOWS\system32\inetsrv\asp.dll >> >> Another point that may or may not be relevant: I have mapped all .htm to >> asp.net 2.0 (ie >> c:\windows\microsoft.net\framework\v2.0.50727\aspnet_isapi.dll). ie I >> use ASP.net to process all htm pages as they all have some server side >> script. The application pool for the site runs under the default identity >> (Network Service). >> >> I can't see how the above could affect the account ASP scripts are run >> under but I mention it anyway. >> >> As you believe it is not the default (although it would seem that it is >> for Dell, one of Microsoft's largest server OEMs) could you please tell >> me exactly what I could have changed to cause this "non standard" >> behaviour? ie if you believe it is a user configuration issue then could >> you let me know exactly what that user configuration could be? ie >> unless somebody can identify what could cause that behaviour it's a bit >> hard to argue that it is a user configuration issue. I agree Dell may >> ship it's servers in this form, but I actually think it is very unlikely >> they would change the account ASP scripts run under. >> >> Thanks! >> >> >> >> "David Wang" <w3.4you@gmail.com> wrote in message >> news:1190707533.003742.83110@d55g2000hsg.googlegroups.com... >>> What you describe is not the default behavior, so I do not believe >>> your configuration is the default from Microsoft. >>> >>> It may be the default configuration that you get from Dell, but that >>> is no guarantee that it is the same as Microsoft's. >>> >>> I can only talk in terms of Microsoft's defaults because that is a >>> global constant. Server vendors may do their own customizations of the >>> same Microsoft software. It is a "right" that they sued and obtained >>> from Microsoft, so if you don't like how it's turning out, blame that >>> lawsuit... >>> >>> Anyhow, I went over to my IIS6 server built from default Microsoft >>> configuration, which has the same ACLs that you describe, and I copied/ >>> ran your ASP page... and it fails with access denied under only >>> anonymous authentication. All defaults... and behaving the way it >>> should. >>> >>> So, I can say that I just provided counterpoint to your statement and >>> that we are not looking at any bug in IIS6 but rather user- >>> misconfiguration. Now, the user may be using defaults from server >>> manufacturer and thinks they did nothing wrong -- so they think issue >>> must be with IIS6 -- but the reality is that the problem is with the >>> system's settings, not IIS, and we have to agree that the problem is >>> with the setting. We all know that with improper settings, any system >>> can appear insecure. >>> >>> Now that we are all on the same page that the problem is with user- >>> configuration (let's not have violent reaction to it. I call it user >>> configuration because it's not the defaults set by Microsoft/IIS -- >>> maybe you want to think of it as "non-default configuration"), the fun >>> will be to figure out what is non-default. >>> >>> Some of my thoughts -- >>> perhaps .asp is scriptmapped to aspnet_isapi.dll, in which case your >>> "ASP code" is actually run by ASP.Net under its default impersonation, >>> which would be process identity -- which would be Network Service by >>> default and match what you observe. >>> >>> >>> //David >>> http://w3-4u.blogspot.com >>> http://blogs.msdn.com/David.Wang >>> // >>> >>> >>> >>> >>> >>> >>> >>> >>> On Sep 23, 8:06 pm, "BrianSteward" <j...@junk.com> wrote: >>>> It's definitly the default configuration -- straight out of the box, >>>> brand >>>> new Dell rack mounted server. It's the same as other servers I have >>>> going >>>> back to October 2005. All run IIS under the NT AUTHORITY\Network >>>> account. >>>> >>>> Furthermore as I noted below the default permissions for the >>>> IUSER_<machinename> on the wwwroot directory has no read permissions. >>>> It >>>> only has deny write. That is the same on every IIS 6.0 server that I >>>> have >>>> ever seen and it's been mentioned many times in this board and others. >>>> If >>>> there are no read permissions on the IUSR account then that would mean >>>> that >>>> if IIS impersonated the IUSR account it would not be able to read any >>>> files >>>> wouldn't it? >>>> >>>> I know you say IIS SHOULD impersonate the IUSR account -- but it would >>>> appear it doesn't in IIS 6.0. That really was the point of my original >>>> post >>>> as I thought (without ever checking prior to my doing this test) that >>>> it >>>> should as well. >>>> >>>> Saying something is up with my configuration unfortuantely just begs >>>> the >>>> original question. I don't believe anything is up with my >>>> coinfiguration, >>>> rather that's the way IIS 6.0 is configured by default. I'd be happy >>>> to be >>>> persuaded otherwise if you could point me to the change in my >>>> configuration >>>> that you think has caused non-standard behaviour. >>>> >>>> Thanks for your help to date. >>>> >>>> Brian. >>>> >>>> "Ken Schaefer" <kenREM...@THISadOpenStatic.com> wrote in message >>>> >>>> news:%23nKBSnk$HHA.5164@TK2MSFTNGP05.phx.gbl...
I don't think that's the cause. By default HTM is mapped to the IIS Static File Handler - you've just changed that to be the ASP.NET ISAPI extension (a |