Re: IUSR_myserver and deny write
- From: David Wang <w3.4you@xxxxxxxxx>
- Date: Tue, 25 Sep 2007 08:05:33 -0000
What you describe is not the default behavior, so I do not believe
your configuration is the default from Microsoft.
It may be the default configuration that you get from Dell, but that
is no guarantee that it is the same as Microsoft's.
I can only talk in terms of Microsoft's defaults because that is a
global constant. Server vendors may do their own customizations of the
same Microsoft software. It is a "right" that they sued and obtained
from Microsoft, so if you don't like how it's turning out, blame that
lawsuit...
Anyhow, I went over to my IIS6 server built from default Microsoft
configuration, which has the same ACLs that you describe, and I copied/
ran your ASP page... and it fails with access denied under only
anonymous authentication. All defaults... and behaving the way it
should.
So, I can say that I just provided counterpoint to your statement and
that we are not looking at any bug in IIS6 but rather user-
misconfiguration. Now, the user may be using defaults from server
manufacturer and thinks they did nothing wrong -- so they think issue
must be with IIS6 -- but the reality is that the problem is with the
system's settings, not IIS, and we have to agree that the problem is
with the setting. We all know that with improper settings, any system
can appear insecure.
Now that we are all on the same page that the problem is with user-
configuration (let's not have violent reaction to it. I call it user
configuration because it's not the defaults set by Microsoft/IIS --
maybe you want to think of it as "non-default configuration"), the fun
will be to figure out what is non-default.
Some of my thoughts --
perhaps .asp is scriptmapped to aspnet_isapi.dll, in which case your
"ASP code" is actually run by ASP.Net under its default impersonation,
which would be process identity -- which would be Network Service by
default and match what you observe.
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//
On Sep 23, 8:06 pm, "BrianSteward" <j...@xxxxxxxx> wrote:
It's definitly the default configuration -- straight out of the box, brand
new Dell rack mounted server. It's the same as other servers I have going
back to October 2005. All run IIS under the NT AUTHORITY\Network account.
Furthermore as I noted below the default permissions for the
IUSER_<machinename> on the wwwroot directory has no read permissions. It
only has deny write. That is the same on every IIS 6.0 server that I have
ever seen and it's been mentioned many times in this board and others. If
there are no read permissions on the IUSR account then that would mean that
if IIS impersonated the IUSR account it would not be able to read any files
wouldn't it?
I know you say IIS SHOULD impersonate the IUSR account -- but it would
appear it doesn't in IIS 6.0. That really was the point of my original post
as I thought (without ever checking prior to my doing this test) that it
should as well.
Saying something is up with my configuration unfortuantely just begs the
original question. I don't believe anything is up with my coinfiguration,
rather that's the way IIS 6.0 is configured by default. I'd be happy to be
persuaded otherwise if you could point me to the change in my configuration
that you think has caused non-standard behaviour.
Thanks for your help to date.
Brian.
"Ken Schaefer" <kenREM...@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:%23nKBSnk$HHA.5164@xxxxxxxxxxxxxxxxxxxxxxx
OK - at least we have found the account being used.
However in a default configuration of IIS 6.0, the NT AUTHORITY\Network
Sevice account is not the impersonated user for Classic ASP files. Network
Service is used as the w3wp.exe process identity, but IIS should
impersonate IUSR_<machinename> for anonymous access.
So, something is up with your conifguration if Network Service is being
used for Classic ASP files.
Cheers
Ken
"Brain Steward" <j...@xxxxxxxx> wrote in message
news:eOy%23Oae$HHA.3716@xxxxxxxxxxxxxxxxxxxxxxx
I checked on the account used to write to the file. It's the NT
Authority\Network account. It's the same on all my Win 2003 servers --
I've checked a few.
So it would appear that even though the web site was accessed by an
anonymous user (ie the user was not authenticated as any other user) any
permissions on a directory for anonymous users are effectively ignored by
IIS as the ASP script runs under the NT Authority/Network account which
has been granted write permissions, I presume, because it's a member of
users or administrators.
That's not a problem in iteslef, if we know for sure that this is the
case, but it effectivly means including permissions for the IUSR_myserver
user on the web directory achieves nothing. I can see it would prevent a
webdav put from an anonymous user writing to the directory, but
un-ticking 'write' in the IIS console for the directory achieves that
(and it doesn't prevent ASP writing to the directory) so I can't even see
the point of including the IUSR_mysever user at all as everything runs
fine without it. The default IUSER_myserver user on Win 2003 doesn't even
have read permissions. The only thing it has is deny write, so clearly
it's not used by IIS.
Is my understanding correct?
"Ken Schaefer" <kenREM...@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:uzyjq7d$HHA.3548@xxxxxxxxxxxxxxxxxxxxxxx
As I said below, the behaviour is consistent with the internet guest
account being treated as a member of the users group, which it isn't. I
haven't change any of the default groupings and the server is brand new
with no third part software installed.
Any explicit "Deny" NTFS ACE overrides any "Allow" permissions. So
whether or not IUSR account is part of the Users group, any explicit
deny would nullify any grant of Write permissions.
I suggest you either:
a) download Filemon.exe from the Microsoft website, and see what user
account is actually being used to write the file (it's probably not what
you think)
b) enable Object Access Auditing on your server (via the local security
policy) and then enable auditing on that file (again, to see which
account is being used. For this method, object access will be recorded
in the Windows Security event log)
Cheers
Ken
--
My IIS Blog:www.adOpenStatic.com/cs/blogs/ken
"Brain Steward" <j...@xxxxxxxx> wrote in message
news:uSvuLZb$HHA.1188@xxxxxxxxxxxxxxxxxxxxxxx
David -- I have a simple ASP script which runs under IIS defaults. I
haven't set up any additional accounts -- administrator is the only
user account on the server. I can't clarify which actual user account
performs the writes -- I don't know how to do that. All I can say is
that the server is stock standard, using defaults everywhere. Whatever
user account ASP scripts run under is used I guess, but I though
(unlike ASP.NET) that they would have the same permissions as the
IUSR_myserver account. Is this not the case?
The script creates and writes a text file to a directory (called
"logs") within the web using the following components:
<%
set fs = CreateObject("Scripting.FileSystemObject")
FileName="Logs\events.html"
path=server.mappath(FileName)
if fs.FileExists(path) = True then
set f= fs.OpenTextFile(path,8)
else
set f = fs.CreateTextFile(path,True)
end if
temp = "information that I write to the file"
f.write (left(temp,197) & "</b><br>")
%>
That's pretty much the whole script.
The "logs" directory has write permissions for users. The permissions
for the intenet guest account are "deny write". Access to the web is
anonymous (ie users are not logged on as administrator or any othe user
(as there aren't any anyway)).
So in summary: anonymous visitors using a web browser execute this ASP
script which writes information to the logs directory even though
permissions on this directory for the internet guest account say "deny
write". As I said below, the behaviour is consistent with the internet
guest account being treated as a member of the users group, which it
isn't. I haven't change any of the default groupings and the server is
brand new with no third part software installed.
If you need any more information to help you explain this please let me
know exactly what I can provide and I'll let you have it.
Thanks for you help.
"David Wang" <w3.4...@xxxxxxxxx> wrote in message
news:1190531527.150391.221770@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Sep 22, 2:00 pm, "Brain Steward" <j...@xxxxxxxx> 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 -
.
- References:
- IUSR_myserver and deny write
- From: Brain Steward
- Re: IUSR_myserver and deny write
- From: David Wang
- IUSR_myserver and deny write
- Prev by Date: Re: HTTP Trace
- Next by Date: Re: Client certificate beginners help!
- Previous by thread: Re: IUSR_myserver and deny write
- Next by thread: Re: IUSR_myserver and deny write
- Index(es):
Relevant Pages
|
