Local Security Policy resets

[Guest]

HI

I have an issue where the Local Security Policy\Local Policies\User Rights
Assignment\Access This Computer From the Network keeps losing its setting of
Everyone and becoming undefined which is a real pain in the ass when it comes
to authenticating my logon to the VMWare Management Website I have running on
IIS 6 and the ability for other machines to browse my shares.

After manually setting the policy to Everyone all works fine, then roughly
10 mins the policy resets to nothing so I have to RDP into my machine,
re-apply the policy and then log back into my website.

Things I have tried include Creating a new Security Configuration database
and importing the default "Setup Security.inf" template which has the correct
policy settings. But still the machine loses the policy setting after about
10mins.

If I choose to Analyze Computer Now in Security Configuration and Analysis
MMC snap-in it see's the correct configuration in the Database, but the
Computer Setting is missing.

I've also tried creating a new custom template but the same thing happens.

This is becoming a real pain in the ass and havn't found a similar issue on
the web.

The machine is running Windows XP x64 with all the latest Win Updates. It is
a stand alone machine on a Workgroup so its nothing to do with domain
policies that are resetting it.

Any info on this would be ace!

Cheers

 

[Steven L Umbach]

If you have not done so make sure you check the computer for malware. To try
and track down what is going on use Local Security Policy to enable
auditing of process tracking and policy change for success. Then check the
security log to see if an event is recorded that shows that the user right
was changed and by what user which it may show system. Then look for process
tracking event that happened at or just before the time the user right
changed and it may give you an idea what is going on. It sounds like a
Scheduled Task or script is running on a schedule to do the change possibly
using secedit. It might also be interesting to see what happens if you give
secedit.exe deny permissions for everyone temporarily. --- Steve

 

[Guest]

Thanks for the useful reply, I have now obtained these 2 eventlog messages at
the time it is removed:

Event Type: Success Audit
Event Source: Security
Event Category: Policy Change
Event ID: 622
Date: 11/04/2006
Time: 13:17:39
User: NT AUTHORITY\SYSTEM
Computer: DC187-X64
Description:
System Security Access Removed:
Access Removed: SeNetworkLogonRight
Account Modified: Everyone
Removed By:
User Name: DC187-X64$
Domain: WORKGROUP
Logon ID: (0x0,0x3E7)

and...

Event Type: Success Audit
Event Source: Security
Event Category: Policy Change
Event ID: 622
Date: 11/04/2006
Time: 13:17:39
User: NT AUTHORITY\SYSTEM
Computer: DC187-X64
Description:
System Security Access Removed:
Access Removed: SeNetworkLogonRight
Account Modified: DC187-X64\IUSR_DC187-X64
Removed By:
User Name: DC187-X64$
Domain: WORKGROUP
Logon ID: (0x0,0x3E7)


So it seems the SYSTEM is removing the policy. But why?

 

[Steven L Umbach]

Offhand I don't know but it could be a Scheduled Task so be sure to check
for that or a script using secedit that runs on a regular basis or is
triggered by some event both of which could be malware related. Like I said
it would be interesting to set deny permissions on secedit.exe to see if the
problem continues or not though that alone is not a solution. If you can not
track it down you may need to consider a clean install of the operating
system. If you do such make sure you decrypt any files encrypted via EFS
first. --- Steve

 

[Guest]

I beleive I have now fixed it. I noticed on a reboot at Windows Startup that
Windows Firewall caused alot of Policy Changes. Seeing as I had Windows
Firewall turned off anyway being behind a hardware firewall i disabled the
Windows Firewall/ICS service and since then the Policy resets have stopped.

Very strange.

Thanks for your help.

 

[Steven L Umbach]

Well I will never argue with success but that is very strange indeed as
there is no reason why the Windows Firewall service would do any security
policy changes. I would verify that the Windows Firewall service shows a
path to C:\WINDOWS\System32\svchost.exe -k netsvcs and run System File
Checker as in sfc /scannow to check the integrity of your system files and
then use sigcheck to check for unsigned executable files in the
\windows\system32 folder. Not all unsigned files are suspicious but ones
that are not associated with a publisher and description should be looked at
closely. -- Steve

http://www.sysinternals.com/Utilities/Sigcheck.html --- sigcheck. Use the
/u /e swithces.