none
Urgent Group Policy Issue - not applying despite saying it does

    Question

  • Thank you for this urgent help. Auditors checking this out tomorrow morning.

    We have a GPO that sets the eventlog audit settings for success or failure security events. The scope is set to Authenticated Users.

    When I run the group policy wizard in GPMC it shows the settings applying to one of our servers in that OU.

    When I run gpresult/z from that server it shows the policy applying to that server.

    But when I go into gpedit.msc the security audit settings are all set to "not defined" and they are grayed out so I can't edit them manually.

    As a test I set the GPO to deny applying to that server. I ran gpudpate/force on the system and then gpresult and it shows the GPO now not applying. But the settings are still set to not defined and still not editable. they are not being set by any other GPO.

    In the event logs I only see three GPO errors but they are unrelated. A separate GPO is having issues creating user accounts. No other GPOs apply.

    Quick help would be fantastic.

    Server runs on Windows Server 2008 R2 (I can edit GPO but not the domain ones and I don't have access to the domain controllers).
    Thursday, January 15, 2015 9:24 PM

Answers

  • OK, After several hours I figured it out. Turns out there's bugs and odd functionality.

    If someone ever tested the 'advanced audit settings' (which I did in the same GPO at some point) then it sets a registry key to disable the use of the older basic audit settings. But when you stop using those advanced settings in your GPO it doesn't remove that registry bit. So I used the GPO to undo that setting. This was the first step. This is found Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > "Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings" to DISABLED.

    Even though this is done, sometimes the GPO files on the domain controllers don't remove the old audit settings. So in the comments of another thread I found out you may have to go to \\domain-fqdn\SYSVOL\domain-fqdn\Policies\{your-policy-id-where-this-setting-was-originally-set}\Machine\Microsoft\Windows NT\ and delete the Audit folder which is left behind due to some odd bug. If you don't do this even after doing the next step the next gpupdate will bring that security setting above back down.

    Next you have to reset your audit settings on your PC to the defaults. Unfortunately there is no way to do this. Auditpol /clear does not accomplish this. The only way to do this is to take the audit settings from another working system, export them and then 'restore' those same settings to the affected server. To do this:

    1. On 'working system' run cmd.exe as administrator and export the audit settings to a folder like this:
    auditpol /backup /file:c:\working-auditpol-settings.txt

    2. Copy that file to the broken system such as the C:\ drive and run this on the broken system:
    auditpol /restore /file:c:\working-auditpol-settings.txt

    Open GPEDIT.MSC and verify the audit settings are back to normal. Computer Configuration > Windows Settings > Security Settings > Local Policies > Audit Policy

    Then run gpupdate/force on the formerly broken system. Close gpedit.msc and reopen and verify the settings were not overwritten. If you skipped the sysvol audit folder deletion step they may come back.

    Hope this helps someone.

    • Marked as answer by ANDDITGUY Friday, January 16, 2015 1:19 PM
    Friday, January 16, 2015 1:19 PM

All replies

  • Hi,

    >>when I go into gpedit.msc the security audit settings are all set to "not defined" and they are grayed out so I can't edit them manually.

    Is it "Not Defined" or "No Auditing" in Gpedit.msc snap-in? If we enable an audit policy setting by ticking the checkbox of Define these policy settings in a domain GPO but not ticking the checkboxes of Success and Failure under Audit these attempts, then the setting is enabled but is set to no auditing. We can run the command: auditpol /get /category:* to check the audit settings on our computer.

    Besides, to generate a better view of group policy result report, we can run the command gpresult/h gpport.html with admin privileges.

    Regarding configuring audit policy, the following blog can be referred to for more information.

    Getting the Effective Audit Policy in Windows 7 and 2008 R2

    http://blogs.technet.com/b/askds/archive/2011/03/11/getting-the-effective-audit-policy-in-windows-7-and-2008-r2.aspx

    TechNet Subscriber Support
    If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here.

    Best regards,

    Frank Shen


    Friday, January 16, 2015 9:09 AM
    Moderator
  • did the gpo applied on the OU where all servers are present?

    Basically this audit log gpo is a computer based setting. No relation whether it's applied to all authenticated users. 

    Secondly as recommended by Frank we can refer MS article if you need to configure them via locally in the serves.


    Regards, Prabhu

    Friday, January 16, 2015 9:38 AM
  • GPedit is the Local Machines Group Policy Editor. It is not used to view your Resultant Set of Policy or applied settings.

    Run RSOP to get a GUI view of your applied Group Policys and GPREsult for a HTML Report


    Lee Bowman MCITP MCTS

    Friday, January 16, 2015 9:47 AM
  • OK, After several hours I figured it out. Turns out there's bugs and odd functionality.

    If someone ever tested the 'advanced audit settings' (which I did in the same GPO at some point) then it sets a registry key to disable the use of the older basic audit settings. But when you stop using those advanced settings in your GPO it doesn't remove that registry bit. So I used the GPO to undo that setting. This was the first step. This is found Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > "Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings" to DISABLED.

    Even though this is done, sometimes the GPO files on the domain controllers don't remove the old audit settings. So in the comments of another thread I found out you may have to go to \\domain-fqdn\SYSVOL\domain-fqdn\Policies\{your-policy-id-where-this-setting-was-originally-set}\Machine\Microsoft\Windows NT\ and delete the Audit folder which is left behind due to some odd bug. If you don't do this even after doing the next step the next gpupdate will bring that security setting above back down.

    Next you have to reset your audit settings on your PC to the defaults. Unfortunately there is no way to do this. Auditpol /clear does not accomplish this. The only way to do this is to take the audit settings from another working system, export them and then 'restore' those same settings to the affected server. To do this:

    1. On 'working system' run cmd.exe as administrator and export the audit settings to a folder like this:
    auditpol /backup /file:c:\working-auditpol-settings.txt

    2. Copy that file to the broken system such as the C:\ drive and run this on the broken system:
    auditpol /restore /file:c:\working-auditpol-settings.txt

    Open GPEDIT.MSC and verify the audit settings are back to normal. Computer Configuration > Windows Settings > Security Settings > Local Policies > Audit Policy

    Then run gpupdate/force on the formerly broken system. Close gpedit.msc and reopen and verify the settings were not overwritten. If you skipped the sysvol audit folder deletion step they may come back.

    Hope this helps someone.

    • Marked as answer by ANDDITGUY Friday, January 16, 2015 1:19 PM
    Friday, January 16, 2015 1:19 PM