Local Security policy not persistent XP PRo

[sarasotab]

I have a client with a 5 node workgroup running mixed OS's but mostly windows XP. The Fileserver (also running XP Pro) is a P4 2.4 GHz machine runnning a Promise RAID 1 mirror.

We do not use simple file sharing since different permissions for different users are required. There is a common shared folder on the fileserver which everyone in the workgroup has access to. User names and passwords are identical on all machines including the fileserver.

Under Administrative Tools/Local Security Policy/User Rights there is a policy for "Users may access this machine over the network". Everything worked fine for about a month, then suddenly I get a call and no one can access the shared folder. I checked the user rights assignments and found the network access policy was blank. I inserted the Admin Staff group and Administrator into the policy and everything was once again cool. Two hours later I get another call from the client and once again no one has access, and the user rights assignment was again blank.

It seems to be related to system shut down which happens once a day when backup drives are swapped. Can't find any mention of this annoyance on Google or Technet.

Any thoughts?

Bob Barr
Bitdiddle's Inc.
Sarasota, FL :cool:

[Ghost_Hacker]

Hmmmmm.....I'm baffeled by this one.


Since you don't have a domain controller, or even a server really, it's not a case of it being "overruled" by another policy. At first I thought mabey it was an NTFS rights issue (a long shot) but I haven't been able to dublicate that on my box here. Frankly, I haven't been able to dublicate your problem at all and I'm trying to "break" it.

Have you run
Gpresults (http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/gpresult-o.asp) yet? ( use the /s switch for more info) The tool is really good at group policy troubleshooting when you have multiple group policies, it may not be very helpful here still its worth a shot as it may yield some clues ( you might run it after you change the policy and again when it changes back to the "wrong" one, noting the revision number. After all... It could turn out that your clients are changing something on the box and , for whatever reason, aren't aware of the damage their doing to them themselves).


Also there could be corruption in the local security policy (Windows 2000 had a security hole that would allow a person to corrupt the local security policy in a DOS attack. However, Windows XP shouldn't have this vulnerabilty).

Try making a backup of the secdit.sdb file found here: %systemroot%\security\Database and replace it with another from a different computer. (This is a dangerous move ,so your on your own if you decide to try it.) Also check that this file isn't being overwritten by an old copy during the "backup" process. (perhaps their restoring files they shouldn't)


EDIT Something else to try if the local security policy is corrupt:

Cause: Improperly shutting down the computer or a software error.

Solution: At a command prompt, run esentutl /g to check the integrity of the security database at %windir%\Security\Database\Secedit.sdb.

If the database is corrupt:

Attempt to recover it by typing esentutl /r at a command prompt on the %windir%\Security folder. If this fails, attempt to repair it by typing esentutl /p at a command prompt on %windir%\Security\Database\Secedit.sdb.
After that, delete the log files in %windir%\Security.




Good Luck :)

[sarasotab]

Thanks Ghost_Hacker

I will try these suggestions. I too am baffled. I posted this on the MS Security forum, and no one there has taken a shot at it yet.

The DOS attack seems like a possibility. We have a lot of people trying to hack in since we allow remote access and it appeared from the log that one of them got in and spent some time. I have since hardened passwords and changed the Adminstrator account user name.

I will let you know how I get along.

Bob

[sarasotab]

Well, I tried the suggestions for checking and repairing the security database. There was no corruption found. Also gpresults doesn't seem to recognize local policy as there were only NA's in the results areas.

Back to the drawing board. I set a success audit for policy change to see if I can track it down that way.

Bob