IUSR_myserver and deny write

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?

Re: IUSR_myserver and deny write

On Sep 22, 2:00 pm, "Brain Steward" 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
//

Re: IUSR_myserver and deny write

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) & "
")
%>

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" wrote in message
news:1190531527.150391.221770@57g2000hsv.googlegroups.com...
> On Sep 22, 2:00 pm, "Brain Steward" 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
> //
>

Re: IUSR_myserver and 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.

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" 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) & "
")
> %>
>
> 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" wrote in message
> news:1190531527.150391.221770@57g2000hsv.googlegroups.com...
>> On Sep 22, 2:00 pm, "Brain Steward" 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
>> //
>>
>
>

Re: IUSR_myserver and deny write

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" 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" 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) & "
")
>> %>
>>
>> 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" wrote in message
>> news:1190531527.150391.221770@57g2000hsv.googlegroups.com...
>>> On Sep 22, 2:00 pm, "Brain Steward" 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
>>> //
>>>
>>
>>
>

Re: IUSR_myserver and deny write

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_ for anonymous access.

So, something is up with your conifguration if Network Service is being used
for Classic ASP files.

Cheers
Ken


"Brain Steward" 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" 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" 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) & "
")
>>> %>
>>>
>>> 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" wrote in message
>>> news:1190531527.150391.221770@57g2000hsv.googlegroups.com...
>>>> On Sep 22, 2:00 pm, "Brain Steward" 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
>>>> //
>>>>
>>>
>>>
>>
>
>

Re: IUSR_myserver and deny 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_ 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" 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_ for anonymous access.
>
> So, something is up with your conifguration if Network Service is being
> used for Classic ASP files.
>
> Cheers
> Ken
>
>
> "Brain Steward" 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" 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" 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) & "
")
>>>> %>
>>>>
>>>> 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" wrote in message
>>>> news:1190531527.150391.221770@57g2000hsv.googlegroups.com...
>>>>> On Sep 22, 2:00 pm, "Brain Steward" 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
>>>>> //
>>>>>
>>>>
>>>>
>>>
>>
>>
>

Re: IUSR_myserver and deny write

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" 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_ 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" 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_ for anonymous access.
>
> > So, something is up with your conifguration if Network Service is being
> > used for Classic ASP files.
>
> > Cheers
> > Ken
>
> > "Brain Steward" 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" 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" 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) & "
")
> >>>> %>
>
> >>>> 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" wrote in message
> >>>>news:1190531527.150391.221770@57g2000hsv.googlegroups.co m...
> >>>>> On Sep 22, 2:00 pm, "Brain Steward" 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
> >>>>> //- Hide quoted text -
>
> - Show quoted text -

Re: IUSR_myserver and deny write

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

"David Wang" 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" 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_ 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" 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_ for anonymous access.
>>
>> > So, something is up with your conifguration if Network Service is being
>> > used for Classic ASP files.
>>
>> > Cheers
>> > Ken
>>
>> > "Brain Steward" 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" 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" 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) & "
")
>> >>>> %>
>>
>> >>>> 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" wrote in message
>> >>>>news:1190531527.150391.221770@57g2000hsv.googlegroups.co m...
>> >>>>> On Sep 22, 2:00 pm, "Brain Steward" 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
>> >>>>> //- Hide quoted text -
>>
>> - Show quoted text -
>
>

Re: IUSR_myserver and deny write

"Ken Schaefer" 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

> 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" 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) & "
")
>> %>
>>
>> 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" wrote in message
>> news:1190531527.150391.221770@57g2000hsv.googlegroups.com...
>>> On Sep 22, 2:00 pm, "Brain Steward" 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
>>> //
>>>
>>
>>
>

Re: IUSR_myserver and deny write

See within . . .

"Brain Steward" 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.


> 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

Re: IUSR_myserver and deny write

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.d ll). 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" 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" 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_ 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" 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_ for anonymous access.
>>
>> > So, something is up with your conifguration if Network Service is being
>> > used for Classic ASP files.
>>
>> > Cheers
>> > Ken
>>
>> > "Brain Steward" 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" 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" 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) & "
")
>> >>>> %>
>>
>> >>>> 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" wrote in message
>> >>>>news:1190531527.150391.221770@57g2000hsv.googlegroups.co m...
>> >>>>> On Sep 22, 2:00 pm, "Brain Steward" 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
>> >>>>> //- Hide quoted text -
>>
>> - Show quoted text -
>
>

Re: IUSR_myserver and deny write

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" 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.d ll). 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" 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" 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_ 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" 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_ for anonymous access.
>>>
>>> > So, something is up with your conifguration if Network Service is
>>> > being
>>> > used for Classic ASP files.
>>>
>>> > Cheers
>>> > Ken
>>>
>>> > "Brain Steward" 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" 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" 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) & "
")
>>> >>>> %>
>>>
>>> >>>> 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" wrote in message
>>> >>>>news:1190531527.150391.221770@57g2000hsv.googlegroups.co m...
>>> >>>>> On Sep 22, 2:00 pm, "Brain Steward" 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
>>> >>>>> //- Hide quoted text -
>>>
>>> - Show quoted text -
>>
>>
>
>

Re: IUSR_myserver and deny write

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.


"Ken Schaefer" 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" 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.d ll). 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" 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" 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_ 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" 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_ for anonymous access.
>>>>
>>>> > So, something is up with your conifguration if Network Service is
>>>> > being
>>>> > used for Classic ASP files.
>>>>
>>>> > Cheers
>>>> > Ken
>>>>
>>>> > "Brain Steward" 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" 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" 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) & "
")
>>>> >>>> %>
>>>>
>>>> >>>> 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" wrote in message
>>>> >>>>news:1190531527.150391.221770@57g2000hsv.googlegroups.co m...
>>>> >>>>> On Sep 22, 2:00 pm, "Brain Steward" 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
>>>> >>>>> //- Hide quoted text -
>>>>
>>>> - Show quoted text -
>>>
>>>
>>
>>
>

Re: IUSR_myserver and deny write

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
(aspnet_isapi.dll), and ASP is mapped to the ASP ISAPI extension (asp.dll).
But again, that's the defaults, and not necessarily your configuration.

Cheers
Ken

"BrianSteward" 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 think that's probably where this discussion
> will end.
>
> Thanks for your help to date.
>
> Brian.
>
>
> "Ken Schaefer" 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" 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.d ll). 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" 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" 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_ 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" 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_ for anonymous access.
>>>>>
>>>>> > So, something is up with your conifguration if Network Service is
>>>>> > being
>>>>> > used for Classic ASP files.
>>>>>
>>>>> > Cheers
>>>>> > Ken
>>>>>
>>>>> > "Brain Steward" 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" 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" 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) & "
")
>>>>> >>>> %>
>>>>>
>>>>> >>>> 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" wrote in message
>>>>> >>>>news:1190531527.150391.221770@57g2000hsv.googlegroups.co m...
>>>>> >>>>> On Sep 22, 2:00 pm, "Brain Steward" 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
>>>>> >>>>> //- Hide quoted text -
>>>>>
>>>>> - Show quoted text -
>>>>
>>>>
>>>
>>>
>>
>
>

Re: IUSR_myserver and deny write

"BrianSteward" 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" 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" 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.d ll). 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" 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" 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_ 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" 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_ for anonymous access.
>>>>>
>>>>> > So, something is up with your conifguration if Network Service is
>>>>> > being
>>>>> > used for Classic ASP files.
>>>>>
>>>>> > Cheers
>>>>> > Ken
>>>>>
>>>>> > "Brain Steward" 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" 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" 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) & "
")
>>>>> >>>> %>
>>>>>
>>>>> >>>> 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" wrote in message
>>>>> >>>>news:1190531527.150391.221770@57g2000hsv.googlegroups.co m...
>>>>> >>>>> On Sep 22, 2:00 pm, "Brain Steward" 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
>>>>> >>>>> //- Hide quoted text -
>>>>>
>>>>> - Show quoted text -
>>>>
>>>>
>>>
>>>
>>
>
>

Re: IUSR_myserver and deny write

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.



"Roger Abell [MVP]" wrote in message
news:OzKPaR8$HHA.4568@TK2MSFTNGP02.phx.gbl...
>
> "BrianSteward" 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" 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" 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.d ll). 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" 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" 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_ 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" 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_ for anonymous access.
>>>>>>
>>>>>> > So, something is up with your conifguration if Network Service is
>>>>>> > being
>>>>>> > used for Classic ASP files.
>>>>>>
>>>>>> > Cheers
>>>>>> > Ken
>>>>>>
>>>>>> > "Brain Steward" 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" 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" 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) & "
")
>>>>>> >>>> %>
>>>>>>
>>>>>> >>>> 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" wrote in message
>>>>>> >>>>news:1190531527.150391.221770@57g2000hsv.googlegroups.co m...
>>>>>> >>>>> On Sep 22, 2:00 pm, "Brain Steward" 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
>>>>>> >>>>> //- Hide quoted text -
>>>>>>
>>>>>> - Show quoted text -
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
>

Re: IUSR_myserver and deny write

Brian

I do not know how your machine has been adjusted, but Authenticated Users
and Interactive are commonly members of Users, and first always includes
Iusr_ while the second one includes the the Iusr_ account when it is used,
as it is, for a local login.

In my initial post to you I said to check whether it is in Users, even if
only
indirectly, as then all that you are reporting would be expected behavior.

Roger

"BrianSteward" wrote in message
news:OWIsjsBAIHA.4656@TK2MSFTNGP04.phx.gbl...
> 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.
>
>
>
> "Roger Abell [MVP]" wrote in message
> news:OzKPaR8$HHA.4568@TK2MSFTNGP02.phx.gbl...
>>
>> "BrianSteward" 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" 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" 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.d ll). 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" 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" 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_ 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" 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_ for anonymous access.
>>>>>>>
>>>>>>> > So, something is up with your conifguration if Network Service is
>>>>>>> > being
>>>>>>> > used for Classic ASP files.
>>>>>>>
>>>>>>> > Cheers
>>>>>>> > Ken
>>>>>>>
>>>>>>> > "Brain Steward" 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" 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" 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) & "
")
>>>>>>> >>>> %>
>>>>>>>
>>>>>>> >>>> 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" wrote in message
>>>>>>> >>>>news:1190531527.150391.221770@57g2000hsv.googlegroups.co m...
>>>>>>> >>>>> On Sep 22, 2:00 pm, "Brain Steward" 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
>>>>>>> >>>>> //- Hide quoted text -
>>>>>>>
>>>>>>> - Show quoted text -
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
>

Re: IUSR_myserver and deny write

PS. I have not understood why you added the write grant for Users
in the first place, and rather have only posted based on fact that it
was added. As apparently the web is anonymous, the grant to Users
for write was intended to do what ?? as it would be the IUsr_ or the
AppPool identity used for the access.

Roger

"BrianSteward" wrote in message
news:OWIsjsBAIHA.4656@TK2MSFTNGP04.phx.gbl...
> 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.
>
>
>
> "Roger Abell [MVP]" wrote in message
> news:OzKPaR8$HHA.4568@TK2MSFTNGP02.phx.gbl...
>>
>> "BrianSteward" 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" 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" 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.d ll). 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" 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" 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_ 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" 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_ for anonymous access.
>>>>>>>
>>>>>>> > So, something is up with your conifguration if Network Service is
>>>>>>> > being
>>>>>>> > used for Classic ASP files.
>>>>>>>
>>>>>>> > Cheers
>>>>>>> > Ken
>>>>>>>
>>>>>>> > "Brain Steward" 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" 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" 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) & "
")
>>>>>>> >>>> %>
>>>>>>>
>>>>>>> >>>> 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" wrote in message
>>>>>>> >>>>news:1190531527.150391.221770@57g2000hsv.googlegroups.co m...
>>>>>>> >>>>> On Sep 22, 2:00 pm, "Brain Steward" 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
>>>>>>> >>>>> //- Hide quoted text -
>>>>>>>
>>>>>>> - Show quoted text -
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
>

Re: IUSR_myserver and deny write

"Brain Steward" skrev i en meddelelse
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 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?
>