|
You might want to enable verbose security policy logging
and see if it is throwing any errors. Check out my GP logging ADM
(gpolog.adm) at www.gpoguy.com/tools.htm or just view
http://support.microsoft.com/default.aspx?scid=kb;en-us;245422 for
details.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Schmieder, Marc Sent: Wednesday, April 06, 2005 12:19 PM To: [email protected] Subject: RE: [ActiveDir] Audit Policies are not applying in windows 2000 Darren, Thank you very much for
the suggestions. Unfortunately everything checked out with the DB
integrity and deleting the files in the policies folder didn’t seem to get the
policies to apply correctly, although the files came back. What is
interesting is the gpt00002.ini file and the tmpgptfl.ini files both have the
correct audit settings as shown below, but the MMC still doesn’t show the
correct settings and the server is still auditing the wrong things. I
would appreciate any other suggestions you might
have. [Event
Audit] AuditSystemEvents =
3 AuditLogonEvents =
0 AuditObjectAccess =
0 AuditPrivilegeUse =
0 AuditPolicyChange =
0 AuditAccountManage =
3 AuditProcessTracking =
0 AuditDSAccess =
0 AuditAccountLogon =
3 [Registry
Values] From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Darren
Mar-Elia You could have a
corrupt local secedit.sdb database on these machines, which would prevent the
policy from being applied correctly. This file is typically stored on
c:\windows\security\database. You can run the following command on one of these
machines to check its integrity. esentutl /g c:\windows\security\database\secedit.sdb If it finds errors,
that utility has a command line repair option that you can
try. If that doesn't show
errors, another thing you can try is to delete the cached copies of the policy
files from the local machines and then force a GP refresh. Those files are
stored under
c:\windows\security\templates\policies Darren From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Schmieder,
Marc We have many servers that are not
getting the correct auditing policies applied, although all other policy
settings are working correctly. I’ve already checked for Blocked
Inheritance, enabled UserEnv.log and I cannot find anything that indicates any
problems. When I change the audit policies on the Domain, these
problematic servers don’t seem to see the change when they do a policy
refresh. It doesn’t seem to matter what OU the servers are in
either. Some machine work in the same OU as another machine that
doesn’t. Another thing is that the userenv.log entries for the security
extension seem to change. They are listed below from earliest to
oldest. Does anyone know why this would occur, or how to fix it?
USERENV(d0.358) 09:56:30:107
ProcessGPOs: Processing extension Security USERENV(d0.358) 09:56:30:107
CompareGPOLists: The lists are the same. USERENV(d0.358) 09:56:30:107
CheckGPOs: No GPO changes and no security group membership change and extension
Security has NoGPOChanges set. USERENV(d0.350) 10:00:00:515
ProcessGPOs: Processing extension Security USERENV(d0.350) 10:00:00:515
CompareGPOLists: The lists are the same. USERENV(d0.350) 10:00:00:515
CheckGPOs: No GPO changes but extension Security's MaxNoGPOListChangesInterval
has been exceeded. USERENV(d0.350) 10:00:00:515
ProcessGPOs: Processing extension Security USERENV(b7c.bb8) 10:20:51:039
ProcessGPOs: Extension Security skipped with flags
0x6. Thank
you, Marc
Schmieder |
- RE: [ActiveDir] Audit Policies are not applying in windows... Darren Mar-Elia
- RE: [ActiveDir] Audit Policies are not applying in wi... Roger Seielstad
