AD Audit Pro reports on what your domain controllers record. It does not change Active Directory and it cannot recreate events that were never written, so if auditing is off, the matching report stays empty no matter how long you leave it running.
Audit policy is set once, in Group Policy, and applies to every domain controller.
What to turn on
All of these are under Advanced Audit Policy Configuration.
Required
Without these, the reports in the right-hand column stay empty.
| Category | Subcategory | Set to | Feeds |
|---|---|---|---|
| Account Management | User Account Management | Success and Failure | Created, deleted, enabled, disabled, renamed and modified users; password changes and resets; locked and unlocked users |
| Account Management | Security Group Management | Success and Failure | Created and deleted groups; members added and removed; modified and renamed groups |
| Account Management | Computer Account Management | Success and Failure | Created, deleted, enabled, disabled and modified computers |
| DS Access | Directory Service Changes | Success and Failure | Moved and restored objects, OU reports, GPO changes, and the attribute-level detail in the change reports |
| Logon/Logoff | Logon | Success and Failure | All logons, successful and failed logons, after hours logons, password spray, daily logon summary |
| Logon/Logoff | Account Lockout | Failure | Lockouts recorded at the point the sign-in is refused |
| Policy Change | Audit Policy Change | Success | Audit policy changed, which is how you see auditing being turned off |
Optional
Two more that add detail. Everything else works without them.
| Category | Subcategory | Set to | Feeds |
|---|---|---|---|
| Logon/Logoff | Logoff | Success | The User Logoff report, and session length in the logon reports |
| DS Access | Directory Service Access | Failure | Attempts to read or change directory objects that were refused |
Success and Failure, not just Success. Failures are the events worth having. A failed logon, a refused group change or a rejected password reset is what tells you something is wrong, and it is the half most often left off.
Set it in Group Policy
Do this on a computer with the Group Policy Management tools.
- Open Group Policy Management.
- Edit a GPO linked to the Domain Controllers OU. The Default Domain Controllers Policy is the usual choice, or create one of your own, for example "AD Audit Pro Auditing".
- Go to Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies.
- Open each subcategory from the tables above, tick Configure the following audit events, then tick Success, Failure, or both as listed.
- Close the editor.
Make sure advanced policy wins
If anything in your domain still sets the old basic audit policy, it can overwrite the advanced settings. Turn on the setting that stops that, in the same GPO:
Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings - set to Enabled.
Apply it
On a domain controller:
gpupdate /force
Then confirm what is actually in effect on that domain controller, which is the only answer that counts:
auditpol /get /category:"Account Management","DS Access","Logon/Logoff","Policy Change"
Each subcategory in the tables above should read Success and Failure, or the value listed for it.
New events start being recorded immediately. AD Audit Pro collects them within a minute or two, and the reports fill in from that point forward. Nothing from before auditing was turned on can be recovered.
Turn on auditing for directory changes
Directory Service Changes needs one more thing. The subcategory decides whether Windows is willing to record object changes; a SACL on the directory decides which objects it records them for. With the subcategory on and no SACL, no 5136, 5137, 5139 or 5141 events are written and the attribute-level detail in the change reports stays empty.
Active Directory ships with auditing entries on the domain, so most domains already have what is needed. To check or add it:
- Open Active Directory Users and Computers and turn on View > Advanced Features.
- Right-click the domain, select Properties > Security > Advanced > Auditing.
- There should be an entry for Everyone, applying to This object and all descendant objects, with Write all properties audited for Success. Add one if there isn't.
- Select OK.
Changes to the SACL replicate like any other directory change.
Turn on NTLM auditing
The NTLM Usage report reads the Microsoft-Windows-NTLM/Operational log, which is empty until NTLM auditing is turned on. In a GPO linked to the Domain Controllers OU:
Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Network security: Restrict NTLM: Audit NTLM authentication in this domain - set to Enable all.
This records NTLM use. It does not block anything.
Then enable the NTLM channel in AD Audit Pro under Settings > Event Filters.
The other logs
The health reports read logs that are on by default and need no audit policy:
| Report | Log |
|---|---|
| AD DS Errors and Warnings | Directory Service |
| DNS, DFS Replication and ADWS errors | DNS Server, DFS Replication, Active Directory Web Services |
| Server Restarts and Shutdowns, Service Failures, Time Sync | System |
Choose which of these AD Audit Pro collects under Settings > Event Filters.
The Audit Log Cleared report needs nothing turned on. Windows always records event 1102 when the Security log is cleared, and it cannot be suppressed.
Workstations and member servers
Collecting logons from workstations and member servers is the same exercise, applied to them rather than to domain controllers. In a GPO linked to the OUs containing those computers, turn on:
- Logon/Logoff > Logon - Success and Failure
- Logon/Logoff > Logoff - Success
Then add the computers under Settings > Connections, on the Computers tab.
A domain controller records the authentication, not the sign-in at the desk. Both are useful, and they are different events: collect from workstations when you need to know who used a particular machine.