Local admin restricted from IISRESET

[fg]

Hello - Any assistance on following pproblem will be greatly appreciated.

Our local admin group (and all users in the group - including domain admin
in the group) is restricted from performing certain admin functions such as
running IISRESET - an Access Denied error is thrown. Also, these users are
unable to run debug utilities such as NTREGMON or NTFILEMON (from
Sysinternals site).

I've pushed local admins - full down through C: - we're looking a reg
permissions, but all looks good so far. Any input will be appreciated.

Reply to (e-mail address removed) (remove "-nospam")

 

[Steven L Umbach]

Regmon and Filemon should run if they are installed into a directory where
administrators have at least read/list/execute permissions. Check the permissions on
the executables for those two files themselves to see if they have proper access and
are not a member of any group that has deny permissions which would include users and
the everyone group. Once you get them to run, then of course you can use them to
track your other problems. --- Steve

 

[freeguy]

Hello - Thanks for the reply. I just verified that the user I am using is a
member of the local administrator's group (only group listed in "member of"
tab). Also, I verified the local administrator group has full control of
these directories & files &, in desperation, I pushed everyone/full through
those dirs & files. I still get "Access Denied" - this is very
vexing.........

 

[Steven L Umbach]

That's interesting. I would try logging on as the built in local administrator on
that machine which would not be a member of the domain to see if that account can do
those things since a local account logon would bypass any user configuration Group
Policy from the domain/OU, but not local. I would also look in Event Viewer for any
errors that may help pinpoint the problem and run a virus scan since strange things
are happening. Software Restriction Policies can cause such behavior, but that can
not be applied to a W2K machine, only XP Pro or Windows 2003. Try placing Regmon and
Filemon in the users profile under documents and settings of a logged on local
administrator to see if that helps. If none of that pans out try booting into safe
mode as an administrator to see if anything works which if it does would indicate a
conflict with a startup program/service/driver/process. Also see the link below on
resetting security settings back to default defined levels, though domain/OU
container security settings could still override Local Security Policy and that would
be a last resort option. Running Security Configuration and Analysis mmc snapin
againsts the seupsecurity.inf template could also show where security settings differ
from a default setup. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;EN-US;313222
http://www.lokbox.net/SecureXP/secAnalysis.asp

 

[freeguy]

Again - thanks for your feedback.

This is a Win2000 Server SP3 on a large corp network running a prod app.
So - I'm somewhat limited in what I can try. I did try moving Filemon into
the local admin's profile & rec'd the "access denied. "

I'll look at the other 2 articles you sent & post the fix when I get it. If
you get any other thoughts, please don't hesitate to put them up. Thanks
again.

 

[Steven L Umbach]

OK. Possibly there is an application running on the server that monitors and only
allows certain programs to run maybe even md5 hash protected executables or Group
Policy has been configured to run only allowed Windows applications under user
configuration/administrative templates/system which could be at the local level via
gpedit.msc or if a domain machine may be configured at domain/Organizational Unit
level. Hope you figure it out. --- Steve

 

[freeguy]

THANKS! Your policy hunch was perfect. I've just fixed the inability to run
the diagnostics - there is a local policy/user rights assignment/debug
programs - I added administrators group to this and rebooted - and these
utils now work. Unfortunately, I can't try IISRESET yet.

 

[freeguy]

The policy change listed below fixed the IISRESET problem we had too. Thanks
again.