none
Auditpol in Windows 7: doesn't update GUI RRS feed

  • Question

  • Using the auditpol command-line utility to configure various auditing settings. For example:

    ·         Auditpol /set /category:”Logon/Logoff” /success:enable

    ...then to verify the setting has been configured properly:

    ·         Auditpol /get /subcategory:*

    This works fine. However when checking the settings in the Audit policy user interface (secpol.msc), no settings have changed.
    Is this a bug???

    • Moved by Carey FrischMVP, Moderator Saturday, October 17, 2009 5:41 PM Moved to relevant category (From:Windows 7 Miscellaneous)
    Friday, October 16, 2009 11:01 PM

Answers

  • Hi,

    I tried the above steps as you mentioned, I found if you enable "the Audit: Force audit policy subcategory settings (Windows Vista or later) policy setting under Security Settings\Local Policies\Security Options", the Audit logon events reverts back to "Not Configured" after rebooting. While you disable the Audit: Force audit policy subcategory settings (Windows Vista or later) policy setting under Security Settings\Local Policies\Security Options, the setting remains "Success" after loging off and loging back on.  After further research, I found that documents says " Using both the basic audit policy settings under Security Settings\Local Policies\Audit Policy and the advanced settings under Advanced Audit Policy Configuration can cause unexpected results. Therefore, the two sets of audit policy settings should not be combined. If you use Advanced Audit Policy Configuration settings, you should enable the Audit: Force audit policy subcategory settings (Windows Vista or later) policy setting under Security Settings\Local Policies\Security Options. This setting will override audit policy settings under Security Settings\Local Policies\Audit Policy and prevent conflicts between similar settings by forcing basic security auditing to be ignored."

    Hope this helps.
    Thanks.
    Wednesday, October 21, 2009 2:37 AM
    Moderator

All replies

  • Hi,

    Does your computer join to a domain? Generally, to update audit policy settings, we need to overwirte the earlier version of the Auditpolicy.txt file. Moveover, please make sure that there isn't any policy preventing from overwriting the audit policy. How about restarting your computer to check the setting in the Audit Policy? Basicly there should be some time to wait for replicating. If the GUI doesn't update for a long time, the security auditing settings may not match, try to examine the log files that are generated by the startup script in the %SystemRoot%\Temp folder. If no log files exist in the %SystemRoot%\Temp folder, examine the computer to determine why Group Policy was not applied.

    BTW, for more inforamtion about Audipol in Windows 7.

    Best Regards
    Dale
    Monday, October 19, 2009 10:09 AM
    Moderator
  • Hello Dale,

    Thanks for the reply.

    The computer does not join to a domain.

    Can't find auditpolicy.txt anywhere on the system (just as a test I created a read-only and hidden text file on the root of C, and the search did find it, so it's not an issue of the search engine filtering attributes).

    I did restart, no changes in the GUI.

    It's been several days and the GUI still doesn't match the command-line query output (/get /subcategory:*)

    There are some unreadable files (opened with Notepad: garbage characters) in the TEMP folder with tmp and sqm extensions.

    Can you please verify that when you follow the same steps that are in my original message, on Windows 7 RTM, that the settings due change in the GUI (secpol.msc)?

    The bottom line is that I need a command-line (or other automated) method for configuring the following settings that are shown in secpol.msc:

    Security Settings:
        Local Policies:
            Audit Policy:
                Audit logon events
            Security Policy:
                Audit: Audit the access of global system objects
        Advavced Audit Policy Configuration:
            System Audit Policies - Local Group Policy Object:
                Logon/Logoff:
                    Audit Logon
                    Audit Logoff
                Privilege Use:
                    Audit Non-Sensitive Privilege Use
                    Audit Other Privilege Use Events
                    Audit Sensitive Privilege Use
                System:
                    Audit System Integrity

    Thanks again,
    Bill
    Monday, October 19, 2009 9:55 PM
  • Hi,

    What is the edition of your Windows 7? Based on test on our test machines, Local Policy settings are updated while auditing with the command line. However, Advanced Audit Policy Configuration can't be accessed by Windows 7 computer that can't join a domain. BTW, I recommend you to run gpupdate /force command to update Group Policy after auditing to see if it works.

    Best Regards
    Dale
    Tuesday, October 20, 2009 9:01 AM
    Moderator
  • I'm using Windows 7 Enterprise (64-bit in this case). 6.1.7600.

    It's not that our systems can't join a domain, we just don't need to.

    However, I have another scenario I'd like you to try. This one really must be some kind of a bug:

    Windows 7:
        1. Run secpol.msc and manually set:
            Local Policies:
                Audit Policy:
                    Audit logon events: Check the Success box
        2. Save the setting and reboot the system.
        3. Once back in Windows 7, run secpol.msc and note that the setting has reverted back to "Not Configured".

    Vista:
        Do the same steps as with Windows 7. After the reboot, the setting remains "Success" in Vista


    BTW: gpupdate /force resets all settings back to Not Configured

    Thanks again,
    Bill

    Tuesday, October 20, 2009 11:04 PM
  • Hi,

    I tried the above steps as you mentioned, I found if you enable "the Audit: Force audit policy subcategory settings (Windows Vista or later) policy setting under Security Settings\Local Policies\Security Options", the Audit logon events reverts back to "Not Configured" after rebooting. While you disable the Audit: Force audit policy subcategory settings (Windows Vista or later) policy setting under Security Settings\Local Policies\Security Options, the setting remains "Success" after loging off and loging back on.  After further research, I found that documents says " Using both the basic audit policy settings under Security Settings\Local Policies\Audit Policy and the advanced settings under Advanced Audit Policy Configuration can cause unexpected results. Therefore, the two sets of audit policy settings should not be combined. If you use Advanced Audit Policy Configuration settings, you should enable the Audit: Force audit policy subcategory settings (Windows Vista or later) policy setting under Security Settings\Local Policies\Security Options. This setting will override audit policy settings under Security Settings\Local Policies\Audit Policy and prevent conflicts between similar settings by forcing basic security auditing to be ignored."

    Hope this helps.
    Thanks.
    Wednesday, October 21, 2009 2:37 AM
    Moderator
  • Hi Dale,

    By disabling the Audit: Force audit policy subcategory settings (Windows Vista or later) policy setting under Security Settings\Local Policies\Security Options, I can configure all other settings that I need to, except for one.

    The one setting that still won't stay after a reboot is Audit logon events under Security Settings\Local Policies\Audit Policies. I set it to Success, but after a reboot it goes back to "no auditing".

    I was able to configure several other settings, including some under the Advanced Audit policy configuration category, and they all remained after a reboot. It's just that one particular setting that doesn't stick for some reason.

    Oh, I see now. I just reset the setting to Success and logged-off instead of rebooting. That made it stick. I guess that's the way it's designed?

    Thanks again,
    Bill
    Friday, October 23, 2009 1:52 AM
  • Dale, one more question:

    I can't seem to figure out how to use Auditpol to set the Audit: Force audit policy subcategory settings (Windows Vista or later) policy setting under Security Settings\Local Policies\Security Options to disabled. Is there an Auditpol command for this?

    Running Auditpol /get /category:* doesn't show any possible settings that have the word "force" in them. The closest thing I found was Policy Change/Audit Policy Change but that didn't disable the setting even after a reboot.

    Thanks again,
    Bill
    Tuesday, October 27, 2009 12:35 AM
  • Based on my test, I can't set this policy using Audipol command neither. But for references, you can either configure it in Registry Editor to modify SCENoApplyLegacyAuditPolicy under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa or run the following command:

    REG ADD HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v SCENoApplyLegacyAuditPolicy /t REG_DWORD /d /0x1

    Value=0x1 Enable the policy.
    Value=0x0 Disable the policy.

    Best Regards
    Dale

    Tuesday, October 27, 2009 3:47 AM
    Moderator
  • Excellent! Thanks again for the help!
    Tuesday, October 27, 2009 5:31 PM
  • Hello Dale,

    Well I thought everything was working, but I'm still seeing what I consider to be a bug between the Auditpol command and the Local Security Policy user interface. Using auditpol, settings don't stick after a reboot. However if the Local Security Policy user interface is used to configure the same setting, then it sticks after a reboot.

    Here are the steps I've done to reproduce this issue. I'm using the System Integrity" option as an example.

    1. On initial Windows 7 startup (or a Windows 7 system that hasn't had any auditing settings configured through the Local Security Policy user interface, otherwise skip to step 2):
        a. Run "auditpol /get /category:*". Notice that the "System\System Integrity" option says "Success and Failure"
        b. Run secpol.msc. Notice that the "Advanced Audit Policy Configuration\System Audit Policies\System\System Integrity" option is set as "Not Installed", which does not match what the auditpol command is showing.
       
    2. Enable the "force" option through the registry (SCENoApplyLegacyAuditPolicy=0)
    3. Use secpol.msc to configure the "Advanced Audit Policy Configuration\System Audit Policies\System\System Integrity" option:
        a. First uncheck the "Success" box
        b. Then uncheck the "Configure" box
        c. Save the changes
    4. Reboot
    5. Verify through auditpol and secpol.msc that the "\System\System Integrity" option is disabled ("Not Installed" in secpol.msc, "No Auditing" with auditpol).
    6. Close secpol.msc
    7. Run "auditpol /set /subcategory:"System Integrity" /success:enable"
        a. Run "auditpol /get /category:*". Verify that the System\System Integrity option says "Success"
        b. Run secpol.msc. "Advanced Audit Policy Configuration\System Audit Policies\System\System Integrity" option is still set as "Not Installed"
    8. Reboot
    9. Note that the System Integrity option has been disabled (using auditpol or secpol.msc). Ok, so maybe this setting doesn't remian after a reboot.
    10. Run secpol.msc and navigate to "Advanced Audit Policy Configuration\System Audit Policies\System\System Integrity"
    11. Set check the "Configure" and "Success" boxes, and save the changes
    12. Reboot
    13. Now the setting stays after a reboot!

    Another thing I've noticed is that with a fresh install of Windows 7 (before making any changes using the Local Security Policy user interface), there are quite a few default policies set that are shown when running "auditpol /get /category:*" (one example is System\System Integrity is set to "Success and Failure"). However when the Local Security Policy user interface is run, all settings are "Not Configured".

    There is some disconnect between auditpol and the Local Security Policy user interface, or there is something I'm not understanding.

    Any ideas?

    Thanks once again,
    Bill
    Wednesday, October 28, 2009 6:21 PM
  • Wow, I spent a good 30 minutes writing that last reply, and I almost lost it because of an "Unexpected Error" when I clicked the Submit button. Fortunately I "always" copy the text before clicking anything.
    Wednesday, October 28, 2009 6:23 PM
  • Sorry to bump a 2 year old post, but has anyone ever found a workaround for this?  I am seeing the exact same behaviour on Windows 2008 R2 SP1 Standard.

     


    Brad
    Thursday, September 8, 2011 12:48 PM
  • Just to let you know that you are not alone. Me too! I'd like to have the problem solved! I am administering w2008 r2 servers for a big client. We have script to set auditpol in order not to fill security logs in half a day. But the GUI does not reflect what is set by audipol, except some server, randomly, I do not know why.

    Very bad, this problem, that inpacts eavily on security, has not been solved yet .

    I propose a workaround.

    I 've noticed that , setting in the GUI have higher priority: if you run audipol commands and modify setting, if after you run GPUPDATE /force ,  all settings revert as indicated in the GUI. This is ennoying if you have to set several servers. But if you export adv audit setting from the GUI and then copy the *.csv file to an other server you can import settings and make them working.


    gab


    • Edited by gabobbio Thursday, October 25, 2012 9:51 AM
    Thursday, October 25, 2012 8:52 AM
  • Same on Windows Server 2016
    Thursday, December 26, 2019 1:23 PM