IUSR and IWAM Permissions

S

Simon Watkins

Our server administrators recently changed the permissions of most of our
servers (you know how it is, the developers had, shock horror, got to know
the domain administrator password, and some decision was made on high to
clamp down on everything)

This consequently has had the effect of rendering our live ASP.NET 2 web
server useless with page requests for .NET sites returning ACL permission
errors.

I ran a few tools and found out that it seems to be the permissions of IUSR
and IWAN. As far as I can tell, they have the correct permissions (we are
running IIS 5 on Windows 2000 Server), but placing these users (temporarily)
inside the administrators group restores access. Obviously I can't leave
them in this group.

I'm 99% this has come about because of the permissions clamp down as we have
a development server that is experiencing identical behaviour. Is it
possible that the use of the Active Directory Manager from the domain
controller has screwed something up to cause this?
We also run Report Server on these servers and this had proved to be a bit
of a headache in the past, so it wouldn't surprise me if this had
contributed either.

Can anyone (hopefully there is an MVP about) give me any pointers as to what
I can do to restore the IWAM and IUSR permissions to their correct settings?

Thanks in advance
 
G

Guest

The most likely reason, if it is all directories, is the network admin turned
off anonymous access on the sites in IIS. If so, tell him to turn them back
on, unless your sites are using Windows Authentication only (ie, these are
Intranet applications that serve based on users domain credentials). As you
are getting errors on IUSR and IWAM, you probably have forms auth, which
locks things down.

He could have also whacked the IUSR and IWAM accounts by removing from
groups or resetting policy. If so, you really need the network admin to pull
his head out. Worst case is reinstalling IIS and then spanking an admin. :)
I would not think someobody would do this, but security changes are often
knee jerk reactions, so this is not impossible.

The other option is to check the ACLs (Access Control lists) on the web
folders (where your virtual directories are pointed to). Most likely he
increased access security on the web folders, or worse, on the entire drive
(which would cascade down). I would put it back on his plate, as he was the
one who did it, but say to him, "did you clamp down on the ACLs on web
directories?" He will either think you have gotten smarter (rare in most
network admins, who think developers are stupid, but worth a shot). :)

There may be some IWAM and IUSR perms that were whacked even beyond this,
but this is the norm.

If I think of something else, I will post.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************
 
J

Jamie

Cowboy,

Thanks for reply, any further information you have would be greatly
appreciated as we are banging our heads against a brick wall at the moment.
 
S

Simon Watkins

Cowboy (Gregory A. Beamer) - MVP said:
The most likely reason, if it is all directories, is the network admin
turned
off anonymous access on the sites in IIS. If so, tell him to turn them
back
on, unless your sites are using Windows Authentication only (ie, these are
Intranet applications that serve based on users domain credentials). As
you
are getting errors on IUSR and IWAM, you probably have forms auth, which
locks things down.

He could have also whacked the IUSR and IWAM accounts by removing from
groups or resetting policy. If so, you really need the network admin to
pull
his head out. Worst case is reinstalling IIS and then spanking an admin.
:)
I would not think someobody would do this, but security changes are often
knee jerk reactions, so this is not impossible.

The other option is to check the ACLs (Access Control lists) on the web
folders (where your virtual directories are pointed to). Most likely he
increased access security on the web folders, or worse, on the entire
drive
(which would cascade down). I would put it back on his plate, as he was
the
one who did it, but say to him, "did you clamp down on the ACLs on web
directories?" He will either think you have gotten smarter (rare in most
network admins, who think developers are stupid, but worth a shot). :)

There may be some IWAM and IUSR perms that were whacked even beyond this,
but this is the norm.

If I think of something else, I will post.

Hi Gregory,

Thank you for getting back to me.

As far as the IIS stuff goes, we administer that ourselves and all the
sites, except one, are set to anonymous access under IUSR_machine_name.
Being web servers, these have always been pretty much our department's
servers and we have a lot of autonomy in running them, at least as far as
the web and IIS is concerned. The problem is that they have to fit in the
greater organisation and ultimate control still lies with the domain admins.
Last week they were no longer to tolerate that many people were
administering the organisation's servers with passwords discovered by word
of mouth and that's when the big clamp down started. For our servers, most
of the developers remain listed as admininistrators, but an awful lot of
settings have been changed (users consolidated into groups, etc; the sort of
thing that would have probably be seen as sensible anyway). Just like you
alluded to, I am suspicious that somebody has made a change to one of the
..NET or IIS specific accounts somewhere along the line, and this has
cascaded down with the aforementioned result.
Of course, getting anyone to admit to this, is going to be impossible, as is
getting these people to lose any sleep over the problems of one web server,
or spend any time trying to fix it.

Suffice to say, I believe I have managed to fix the problem for most of the
sites by using filemon (sysinternals)- and for anyone else who goes down
this route in future, you need to give the LOCAL SERVICE and NETWORK SERVICE
read and execute access to the .net Framework version 2xx directory (just
called SERVICE and NETWORK in IIS 5).
I'm not very happy about it, since I can't be sure that something untoward
will not happen in the future.

Unfortunately this hasn't managed to fix SQL CE application for PDAs (we
make use of sscesa20.dll)
Again, it still only seems to work if IWAM and IUSR are in the
administrators group.

The application event log is throwing up the following COM+ errors for each
hit...

-------------------
COM+ Services was unable to initialize due to a failure in the system API
shown below. This is often caused by a shortage of system resources on the
local machine.

CryptAcquireContext

Process Name: dllhost.exe

The serious nature of this error has caused the process to terminate.

Error Code = 0x80090017 : Provider type not defined.

COM+ Services Internals Information:

File: .\security.cpp, Line: 643
---------------------

and ...

---------------------
The run-time environment has detected an inconsistency in its internal
state. Please contact Microsoft Product Support Services to report this
error. *** Error in __FILE__(926): Application image dump failed.
--------------------

Again, it still only seems to work if IWAM and IUSR are in the
administrators group. There is no "Acces Denied" entry in filemon, but
regmon captures the following ACCESS DENIED ocurrences for each hit

3.75126624 svchost.exe:484 OpenKey HKLM\Software\Microsoft\Windows
NT\CurrentVersion\ProfileList ACCESS DENIED Access: 0x20019
SERVERNAME\IWAM_SERVERNAME
3.75139499 svchost.exe:484 OpenKey HKLM\Software\Microsoft\Windows
NT\CurrentVersion\ProfileList ACCESS DENIED Access: 0x20019
SERVERNAME\IWAM_SERVERNAME
3.75170779 svchost.exe:484 OpenKey
HKLM\System\CurrentControlSet\Control\Session Manager\Environment ACCESS
DENIED Access: 0x1 SERVERNAME\IWAM_SERVERNAME
3.75210238 svchost.exe:484 OpenKey HKLM\Software\Microsoft\Windows
NT\CurrentVersion\ProfileList ACCESS DENIED Access: 0x20019
SERVERNAME\IWAM_SERVERNAME
3.75222063 svchost.exe:484 OpenKey HKLM\Software\Microsoft\Windows
NT\CurrentVersion\ProfileList ACCESS DENIED Access: 0x20019
SERVERNAME\IWAM_SERVERNAME
3.75247455 svchost.exe:484 OpenKey
HKLM\Software\Microsoft\Windows\CurrentVersion ACCESS DENIED Access: 0x20019
SERVERNAME\IWAM_SERVERNAME
3.75575757 DLLHOST.EXE:1384 OpenKey
HKLM\System\CurrentControlSet\Control\Session Manager ACCESS DENIED Access:
0x1 SERVERNAME\IWAM_SERVERNAME
3.75593042 DLLHOST.EXE:1384 OpenKey HKLM\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Winlogon ACCESS DENIED Access: 0x20019
SERVERNAME\IWAM_SERVERNAME
3.75694871 DLLHOST.EXE:1384 OpenKey HKLM\Software\Microsoft\Windows
NT\CurrentVersion\Windows ACCESS DENIED Access: 0x20019
SERVERNAME\IWAM_SERVERNAME
3.75745630 DLLHOST.EXE:1384 OpenKey
HKLM\System\CurrentControlSet\Control\Session Manager ACCESS DENIED Access:
0x1 SERVERNAME\IWAM_SERVERNAME
3.75759840 DLLHOST.EXE:1384 OpenKey HKLM\SOFTWARE\Microsoft\OLE ACCESS
DENIED Access: 0x20019 SERVERNAME\IWAM_SERVERNAME
3.75769639 DLLHOST.EXE:1384 OpenKey HKLM\SOFTWARE\Microsoft\OLE ACCESS
DENIED Access: 0x20019 SERVERNAME\IWAM_SERVERNAME
3.75792313 DLLHOST.EXE:1384 CreateKey
HKLM\SOFTWARE\Microsoft\Cryptography\RNG ACCESS DENIED Access: 0x1
SERVERNAME\IWAM_SERVERNAME
3.75809455 DLLHOST.EXE:1384 CreateKey HKLM\SOFTWARE\Microsoft\Cryptography
ACCESS DENIED Access: 0x2000000 SERVERNAME\IWAM_SERVERNAME
3.75818276 DLLHOST.EXE:1384 CreateKey HKLM\SOFTWARE\Microsoft\Cryptography
ACCESS DENIED Access: 0x1 SERVERNAME\IWAM_SERVERNAME
3.75857568 DLLHOST.EXE:1384 OpenKey
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager ACCESS DENIED Access:
0x20019 SERVERNAME\IWAM_SERVERNAME
3.76413941 DLLHOST.EXE:1384 OpenKey HKLM\Software\Microsoft\Rpc ACCESS
DENIED Access: 0x20019 SERVERNAME\IWAM_SERVERNAME
3.77733541 DLLHOST.EXE:1384 OpenKey HKLM\System\Setup ACCESS DENIED Access:
0x20019 SERVERNAME\IWAM_SERVERNAME
3.77782750 DLLHOST.EXE:1384 OpenKey
HKLM\System\CurrentControlSet\Services\DnsCache\Parameters ACCESS DENIED
Access: 0x1 SERVERNAME\IWAM_SERVERNAME
3.78018665 DLLHOST.EXE:1384 OpenKey HKU\.Default ACCESS DENIED Access:
0x20019 SERVERNAME\IWAM_SERVERNAME
3.78030825 DLLHOST.EXE:1384 OpenKey HKLM\Software\Microsoft\Windows
NT\CurrentVersion\winlogon ACCESS DENIED Access: 0x2000000
SERVERNAME\IWAM_SERVERNAME
3.78483319 DLLHOST.EXE:1384 OpenKey HKU\.Default ACCESS DENIED Access:
0x20019 SERVERNAME\IWAM_SERVERNAME
3.78494167 DLLHOST.EXE:1384 OpenKey
HKLM\SOFTWARE\Microsoft\Cryptography\Defaults\Provider Types\Type 001 ACCESS
DENIED Access: 0x20019 SERVERNAME\IWAM_SERVERNAME

I'm not really sure what any of that means, or how to go about fixing it.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,969
Messages
2,570,161
Members
46,710
Latest member
bernietqt

Latest Threads

Top