You may want to check SysVol replication. It’s amazing how sometimes how that can be failing without anyone noticing until a GPO is out of sync. I know it’s likely not the problem but it could be. If one DC had the GPO and another didn’t, you might see those kinds of symptoms.
Recently I discovered that in a couple of my test environments. The folders representing some GPOs were missing and others were present but contained files that had different time stamps than ones on other DCs. *From:* [email protected] [mailto: [email protected]] *On Behalf Of *Heaton, Joseph@Wildlife *Sent:* Friday, August 08, 2014 5:51 PM *To:* '[email protected]' *Subject:* RE: [NTSysADM] Setting auditing in local security policy So, I went back and created a GPO that applies only to the file servers I’m trying to work with. Set everything as I want it, applied the policy, did a gpupdate on the server, and no change. Legacy object access still configured with success/failure, which means all subcategories are going as well. I know everyone says modeling isn’t all that great, but I decided to run it anyway. On the Summary tab, under Component Status, I have a yellow warning symbol, and this warning: *Component Status **[image: Warning]hide <about:blank>* *Component Name* *Status* Group Policy Infrastructure Success 802.3 Group Policy Success Audit Policy Configuration Failed Audit Policy Configuration failed due to the error listed below and failed to log resultant set of policy information. The system cannot find the file specified. Additional information may have been logged. Review the application event log on the domain controller on which the simulation was run for events between 8/8/2014 2:31:44 PM and 8/8/2014 2:31:44 PM. Registry Success Security Success I’m not sure what file it is talking about, but if it can’t find whatever file, then I would guess that it couldn’t apply the settings I want. I’m going to try another new policy (this was an existing policy that I added to) just to see if it makes a difference, but does anyone have any idea what file is being referenced there? There was nothing in the application log, either. *From:* [email protected] [ mailto:[email protected] <[email protected]>] *On Behalf Of *Free, Bob *Sent:* Friday, August 08, 2014 10:57 AM *To:* [email protected] *Subject:* RE: [NTSysADM] Setting auditing in local security policy Modeling isn’t all it’s cracked up to be, actually, it’s really an epic fail IME. Only thing that is truly authoritative is auditpol. I’ve experienced situations where well-intentioned people messed around in 3 or 4 places not understanding all the subtleties and had the system so royally messed up that everything had to be cleared and started over. I’d recommend familiarizing yourself with the following: http://blogs.technet.com/b/askds/archive/2011/03/11/getting-the-effective-audit-policy-in-windows-7-and-2008-r2.aspx http://blogs.technet.com/b/askds/archive/2011/03/10/global-object-access-auditing-is-magic.aspx http://support.microsoft.com/kb/2573113 (basically echos what the askds blog says) http://www.ultimatewindowssecurity.com/blog/default.aspx?p=aa6c16dc-8bb8-40e3-aac9-d2c7eaa6c5f6 Summary from the last link is pretty succinct: Where does all of this leave us? Here are my Best Practices/Commandments for Win2008R2/Win7 Audit Policy Configuration: 1. Do not use Local Security Policy 2. Do not use auditpol /set 3. Use group policy objects in AD to configure audit policy 4. Always enable “Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings” and, for Win2008R2+ systems, ignore the 9 legacy audit categories. 5. Configure all of the advanced audit policy subcategories even if it is just to explicitly disable them 6. Do not use Local Security Policy, Group Policy Results Wizard, RSOP or gpresults to verify what your true audit policy is 7. Use only “auditpol /get /category:*” to verify what your true audit policy is on a given system 8. Monitor for 4719 where user is not the system itself. This indicates someone is temporarily overriding your official audit policy defined in AD GPOs. Terminate them! Seriously though, it is indicative of something bad. *From:* [email protected] [ mailto:[email protected] <[email protected]>] *On Behalf Of *Heaton, Joseph@Wildlife *Sent:* Friday, August 08, 2014 9:10 AM *To:* '[email protected]' *Subject:* RE: [NTSysADM] Setting auditing in local security policy No, I just did a modeling, with the account I’m logging into the server with, and there are no auditing settings at all being applied through GPO to that box for me. *From:* [email protected] [ mailto:[email protected] <[email protected]>] *On Behalf Of *Sean Martin *Sent:* Friday, August 08, 2014 7:55 AM *To:* [email protected] *Subject:* Re: [NTSysADM] Setting auditing in local security policy No chance that another gpo is being applied? - Sean On Aug 8, 2014, at 6:50 AM, "Heaton, Joseph@Wildlife" < [email protected]> wrote: Yes, pretty much what I’ve been trying to do. But it just doesn’t seem to want to hold the settings. We only need two sub-categories, so I left the basic auditing set to Success/Failure, and in the sub-categories, I set just the two that I need, leaving the rest at No Auditing. But, if I go to a command prompt and run auditpol.exe /get /category:*, it shows that all the subcategories are set to Success/Failure. And I’m still getting tons of the 5156 events in the security log. I even verified that I have the setting under Local Policies: Security Options: “Audit: Force audit policy subcategory settings to override audit policy category settings” set to Enabled. Even if I change the basic to No Auditing, if I close and reopen the Local Policy, it shows back up. I know I forgot to mention it before, but the servers in question are Server 2012 R2, in case there’s differences. *From:* [email protected] [ mailto:[email protected] <[email protected]>] *On Behalf Of *Sean Martin *Sent:* Thursday, August 07, 2014 9:36 PM *To:* [email protected] *Subject:* Re: [NTSysADM] Setting auditing in local security policy No idea if this is your answer, but I recently had to modify our audit policy to disable the filtering platform connection sub-category. Under Local Policy/Audit Policy, I left object access set to success/failure, and then under advanced audit policy settings/object access, I configured each option but left the success/failure option unchecked for filtering platform connection, which set it to no auditing. - Sean On Aug 7, 2014, at 8:13 PM, "Heaton, Joseph@Wildlife" < [email protected]> wrote: I’m having a horrible time trying to get the right items audited. Started out with a GP, setting the basic auditing setting of Object Access to Success, Failure. Unfortunately, this filled my security log with event id 5156 entries. Did some research, and found these entries were from auditing of Filtering Platform Connection, which I don’t need audited. Figured out exactly what I do need audited, which is File Share and Handle Manipulation. Now, I can’t get these settings to stick. I’ve disabled all settings in the GPO that set the basic auditing, and on the file servers themselves, I’ve made sure that the basic Object Access is set to No Auditing, and the advanced settings are set to Success, Failure. On one server, when these are set, I reboot, and the basic setting is back to Success, Failure, which then enables all the subcategories as well. On the other server, when I look at Local Security Policy, it looks like things are correct, but when I go to a command line and use: *auditpol.exe /get /category:*, **it shows Object Access set to No Auditing for everything.* *Anyone have any advice?* Joe Heaton Enterprise Server Support Information Technology Operations Branch Data and Technology Division CA Department of Fish and Wildlife 1807 13th Street, Suite 201 Sacramento, CA 95811 Desk: (916) 323-1284 ------------------------------ PG&E is committed to protecting our customers' privacy. To learn more, please visit http://www.pge.com/about/company/privacy/customer/ ------------------------------
