• State Suggested Answer
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 20 subscribers
  • Views 5966 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

AD Advanced Audit Configuration

DJ
over 6 years ago

We're consolidating 2 Windows 2012 R2 forests into another 2012 R2 forest and the new audit settings for 2012 R2 are getting in the way. With the introduction of server 2008 we got the new Advanced Audit Configuration (Computer Configuration -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies) which can be configured to override the older category settings. It took a great deal of fine-tuning Advanced Audit Policy settings to get QMM to recognize that auditing was turned in the target. Now I'm struggling to get this to work for the source domains. The QMM documentation does not address the advanced audit policy config, which is something these domains need to have enabled. Despite all settings being enabled for success / fail for account management and DS access, the DSA log stills says auditing needs to be enabled on the source domains. But if we run audit pol or RSOP, the settings are clearly enabled. Has anyone else run into this issue?

  • 0 over 6 years ago
    Hi DJ - I have a few questions to get more background on your situation.

    1.) What exact error is specified in the DSA.log?
    2.) For the account synchronizing from the source domain in the DSA settings, does that account have DA rights, or more granular restrictive rights as outlined in the QMM access rights/setup doc?
    3.) Are you merging/replacing the security descriptor as a part of your DSA/Migration sessions?
  • 0 over 6 years ago

    Actually, we fixed. It's one of the most bizarre issues I've encountered and it affects both QMM and ADMT. In fact, I found the answer to the problem buried in a technet forum discussion. For some reason, these tools are finicky with the Advanced Audit settings and I had to disable and then re-enable the advanced audit settings. So the steps are (on the preferred DC):

    1. If it's enabled, disable the setting: Force audit policy subcategory settings... under Security Settings / Local Policies / Security Options.

    2. Run gpupdate /force on the preferred DC.

    3. Re-enable Force audit policy subcategory settings...

    4. Under Advanced Audit Configuration for the subcategories Account Management and Directory Access enable Success / Fail for each category.

    5. Run gpupdate /force on the preferred DC.

    Now when you attempt the migration again, it'll work just fine and migrate sidhistory. 

  • 0 over 6 years ago
    That's good to know! I haven't run into that before. Thanks for the follow up self-answer :)
  • 0 over 6 years ago
    In this case, DJ is using the Agentless Dis History option. So that means QMM will be using the same APIs are ADMT. If he was using the built in Sid history/Agent function this would not be an issue.