Audit Policy in Default Domain Controller Policy are reverted after gpupdate /force

Answered Audit Policy in Default Domain Controller Policy are reverted after gpupdate /force

  • Tuesday, January 12, 2010 4:47 AM
     
     
    Hi everyone,

    I have 3 Windows Server 2003 SP2 Domain Controllers.

    It seems that some computers are getting deleted from the AD, so I want to enable "Audit Account Management" setting under \Security Settings\Local Policies\Audit Policy in the Default Domain Controllers Policy, in order to figure out why.

    After select to enable the audit with "Success" events, I then run the command "gpupdate /force" on the DC, and the setting is reverted back to "No auditing". 

    Just FYI: All Audit Policies (except for the "Audit Policy Change") are in "No auditing" and cannot be changed.

    Any comments will be really appreciated.

    Thanks,
    Ivan



All Replies

  • Tuesday, January 12, 2010 10:27 AM
     
     
    Hi,

    It seems that Policy defined at some other Level is taking effect as soon as you are running Gpupdate /Force.

    Please tell us at what level are you trying to apply the Policy (Domain, Site, OU) ?  Also Audit Policy is a part of Computer Configuration and hould be applied on the Computers, so please make sure that all the Computers resides inside the OU on which you are applying the Policy.

    Also check the options like 'Block Inheritence' and 'No Override' on the OU in question. It's possible that you are applying the Audit Policy on Domain Level and while the Computers resides in the OU with 'Block Inheritence' Enabled. In such case only the Policy defined on that OU will take effect.

    You can also run Rsop.msc on the Client Machine and see where are the settings coming from.

    Check these things and revert back with the results.

    Cheers,
    Nitin
  • Tuesday, January 12, 2010 1:32 PM
     
     
    Hi Nitin, thanks for your response.

    The Policy was defined at the Domain Controllers built-in OU (since is the "Default Domain Controllers Policy" the one we are trying to change).  The only GPO linked here is Default Domain Controllers Policy.  The Inheritance is as follows:

    1. Default Domain Controllers Policy
    2. Default Domain Policy

    Neither "Block Inheritence" nor "Enforced/No Override" are active on the OU.

    Running Rsop.msc on the Domain Controller shows that all Audit Policies are coming from the "Default Domain Controllers Policy".

    Thanks,
    Ivan
  • Tuesday, January 12, 2010 4:07 PM
     
     
    Hi Ivan,

    Domain Controllers OU will only contain the Domain Controllers present in the Domain. I would rather suggest try and apply the Policy at Domain Level so that all the Domain Machines comes under the GPO Scope.

    Let me know if it helps.

    Cheers,
    Nitin
  • Tuesday, January 12, 2010 4:57 PM
     
     
    Hi Ivan,
     It sounds like there is some problem with the processing of your policies, does the behavior you're describing happen on all DCs? Are there any errors in the application event log of the DCs related to GPOs? Can you please run gpresult on one of the DCs and post the result?

    Thanks,
    Guy
  • Tuesday, January 12, 2010 7:20 PM
     
     

    Nitin,

    This article suggest to apply the Audit Policies at the Default Domain Controllers Policy.
    http://technet.microsoft.com/en-us/library/cc773388(WS.10).aspx

    Please advice if I'm doing it right.

    Thanks,
    Ivan

  • Tuesday, January 12, 2010 7:26 PM
     
     
    Guy,

    Yes, it happens on any of the DCs (remember we are trying to apply the audit policy at the "Default Domain Controllers Policy" which is a GPO shared by all the DCs.

    No errors in the application event related to GPOs.

    I will run the gpresult on one of the DCs and get back to you with the results (I'm not onsite right now).

    Thanks,
    Ivan

  • Tuesday, January 12, 2010 7:37 PM
     
     
    When you get onsite, can you also post the results of rsop.msc on one of the DCs - run rsop on the machine, save the report, upload it to skydrive (skydrive.live.com) and post the link so we can review it?

    Thanks,
    Guy
  • Wednesday, January 13, 2010 9:13 AM
     
     
    Hi Ivan,

    Yes the Policy is correct at it's place. You mentioned that when you run Rsop.msc, you see the Policy coming from Default Domain Controllers OU... I would like to know what is the Rsop Result once you have run Gpupdate /force. Does it change ? If it does what does it shows ?

    Revert back with the results.

    Cheers,
    Nitin
  • Wednesday, January 13, 2010 1:35 PM
     
     
  • Wednesday, January 13, 2010 1:40 PM
     
     
    Please review the gpresult and rsop file for our server on the following link: http://cid-05970566b5f3647f.skydrive.live.com/browse.aspx/TechNet%20Forum%20Upload%20Files

    As soon as I run gpupdate /force the settings under Audit Policy get reverted to its previous value, even though the rsop.msc shows Default Domain Controllers Policy as the GPO applied.

    Thanks,
    Ivan
  • Wednesday, January 13, 2010 4:20 PM
     
     
    Ivan, 
     When saving and uploading the RSOP report, please use GPMC to generate using Group Policy modeling. There you can save the report as HTML, that's the file we need uploaded.

    Thanks,
    Guy
  • Wednesday, January 13, 2010 4:59 PM
     
     

    Done.  Please try to access the file "RSOP report.htm" at the same link: http://cid-05970566b5f3647f.skydrive.live.com/browse.aspx/TechNet%20Forum%20Upload%20Files

    Thanks,
    Ivan

  • Wednesday, January 13, 2010 5:44 PM
     
     
    cool, thanks. One last thing, can you save an html report of the default domain controller policy and upload it the same way?

    Guy
  • Thursday, January 14, 2010 2:06 PM
     
     

    Hello again,

    There you go: http://cid-05970566b5f3647f.skydrive.live.com/browse.aspx/TechNet%20Forum%20Upload%20Files

    Note:
    You will find two files:
    1. Default Domain Controllers Policy before gpupdate.htm (with Audit Account Management set to "Success" under Security Settings\Local Policies\Audit Policy)
    2. Default Domain Controllers Policy after gpupdate.htm (with Audit Account Management reverted to "No auditing" just after we run gpupdate /force command)

    Hope this help.

    Thanks,
    Ivan 

  • Thursday, January 14, 2010 6:04 PM
     
     
    Ivan,
     To clarify, I was asking for an HTML report of the GPO itself, not the results on a computer. Or are you saying that the settings of the GPO change after you run gpupdate on a specific DC?

    Guy
  • Thursday, January 14, 2010 6:51 PM
     
     

    That's right.  The settings of the GPO changes after I run gpupdate /force on any of the DCs.

  • Thursday, January 14, 2010 7:27 PM
     
     
    Gotcha, that's a new one for me. Do they change after some time if you don't run gpupdate /force.

    Guy
  • Friday, January 15, 2010 1:33 PM
     
     
    Hi, everyone....
    Just a tip.... never use the "default domain policy" or "default domain controller policy" for anythig other than password or block....
    Then, I think if you create another policy, configure what you want, then link to the Domain Controllers OU, it will work just fine. To garantee, configure the new policy as "enforced".
    Hope this works for you just it works for me...
  • Friday, January 15, 2010 4:02 PM
     
     
    I haven't test that.  But gpupdate /force should work as expected, don't you think?
  • Friday, January 15, 2010 4:16 PM
     
     

    I create a new policy called "Audit Test", on this new policy I just change the value for "Audit Account Management" to Success. Then I linked it to the Domain Controllers OU and configure the policy as "enforced" (as you suggested).  Then I did:

    - gpupdate /force
    - the setting now maintain its new value "Success" (great!)
    - when run rsop.msc I can see that the "Audit Account Management" setting is now comming from "Audit Test" (great!)

    Now that is working as expected, for testing purpose: I created a new computer but nothing was showed in the Security Even Log.
    Remember that the whole purpose is to identify why some computers are getting deleted from the AD, so "Audit Account Management" setting in this policy can probably help me.

    What else am I missing here?

  • Friday, January 15, 2010 4:37 PM
     
     
    I do, but I want to see if we're working on the wrong cause. If AD replication is causing the settings to go away rather the gpupdate, that's important.

    I've never seen gpupdate (which is really just a download of the policy) modify policy settings.

    Guy
  • Friday, January 15, 2010 4:42 PM
     
     
    Now that the setting is active, do you see any of the related event at all? http://technet.microsoft.com/en-us/library/cc737542(WS.10).aspx

    If not, its starting to sound like there's a deeper issue here. Are there any errors in the directory services logs?

    Guy
  • Saturday, January 16, 2010 1:20 AM
     
     
    Hi, again....
    The problem was not the "gpupdate"... it was the default policy.... it simple ignores some configurations, i dont know exactly why.
    Well.... one question... When you create your computer accounts, do you use any kind of image software? I had the same errors in Event Viewer, in one client of mine, and the problem was that he used ghost to duplicate his installations, without use SYSPREP first.
    Is that your case??
  • Monday, January 18, 2010 12:18 PM
     
     
    Hi Guy,

    No related event regarding computer was created, changed or delete.
    There are no errors in Directory Services log.
  • Monday, January 18, 2010 12:27 PM
     
     

    No image software is used.  I'm just creating and deleting a computer object in the AD for testing purpose.  I want to test if event 647 (delete) get displayed on the Security Event Log.  That way, I will be able to audit any new occurrences of computers getting deleted from AD.

  • Wednesday, January 20, 2010 7:40 AM
    Moderator
     
     Answered

    Hi,

     

    From the Default Domain Controllers Policy reports, we  can find Deafult Domain Controllers Policy is being modified.

     

    Mdified

    1/14/2010 9:54:32 AM

    Computer Revisions

    351 (AD), 351 (sysvol)

     

    Local Policies/Audit Policyhide

    Policy

    Setting

    Audit account logon events

    No auditing

    Audit account management

    No auditing

    Audit directory service access

    No auditing

    Audit logon events

    No auditing

    Audit object access

    No auditing

    Audit policy change

    Success

    Audit privilege use

    No auditing

    Audit process tracking

    No auditing

    Audit system events

    No auditing

     

     

     

    Modified

    1/14/2010 9:53:22 AM

    Computer Revisions

    349 (AD), 349 (sysvol)

     

     

    Local Policies/Audit Policyhide

    Policy

    Setting

    Audit account logon events

    No auditing

    Audit account management

    Success

    Audit directory service access

    No auditing

    Audit logon events

    No auditing

    Audit object access

    No auditing

    Audit policy change

    Success

    Audit privilege use

    No auditing

    Audit process tracking

    No auditing

    Audit system events

    No auditing

     

    If it’s not you who is editing GPO, please try the following command to check GPO status:

     

    Gpotool /verbose /gpo:{6AC1786C-016F-11D2-945F-00C04FB984F9} >>gpo.txt

     

    Paste the gpo.txt here.

     

    Thanks.


    This posting is provided "AS IS" with no warranties, and confers no rights.
  • Monday, May 09, 2011 7:28 PM
     
     
    Domain level we need to configure the policies like if the user delete the exisitng GPO or changes the policies we need to trace the logs. That is the requirement.
    Thanks& Regards, SelPri | India | +91-9986655633 Future Looks Bright...