AD auditing permissions

  • Last Post 05 July 2017
daemonr00t posted this 21 June 2017

Hi team,   So I got one of this “know it all” auditors that asking for some permissions in AD, create accounts, reset passwords, apply Windows updates, act as part of the operating systems… and more. I ain’t going further than Manage Security Logs, Event Log Reader and other permissions to just READ info… still I would love to have an article that I can use to back up my point. So far I found some articles about AD auditing tools and their requirements but… does anyone out there has any good articles in regards to AD auditing? Many thanks!     ~danny CS
Sent from Mail for Windows 10  

Order By: Standard | Newest | Votes
stevelane85 posted this 05 July 2017

The 'user' must have the DCOM & WMI permission only for the Windows Failover Cluster configuration.

DCOM Permission: Component Services | Computers | My Computer | Right Click and go to Properties | COM Security | Edit Limits of 'Launch and Activation Permissions | In Security Limits, Add the 'user' with Allow for all permissions. .

WMI Permission: Go to Start | Run 'wmimgmt.msc' | Security Tab | CIMV2 | Security | Add the 'user' with Allow for all permissions.

Member of Group Policy Creator Owners - Open Active Directory Users and Computers | Users Container | Add user as a member of 'Group Policy Creator Owners' group

Member of Local Administrators Group - Open Local Users and Groups | Groups | Add user as a member of 'Local Administrators' group.

Active Directory permission auditing solution:

kool posted this 21 June 2017

It occurs to me that requesting elevated access to AD may in itself be part of the auditing of your controls on AD. I’d say “no we can’t do that, it would require executive approval.”


Auditing is in a sense like pen testing. The auditor should be concerned about what people can do with ordinary levels of access, what information gets leaked and so on. And of course the audit has to look at

what technical and procedural controls are in place to limit exposure. Saying “no” to a request for elevated privs such as domain admin would certainly qualify as a good procedural control. As Brian suggests, you can show the auditor settings that are only

readable by DA without giving the auditor DA.


This feels recursive: auditing the auditor.



BTW, I’m not an auditor nor do I play one on TV.





BrianB posted this 21 June 2017

My 2 cents…


I would be more concerned about the request of an Auditor requesting that level of elevated access to AD. AD is a Tier 0 asset and should be treated as such. It has the keys to the kingdom and is not a playground

for people who should not have that level of access normally – Unless they are willing to take the responsibility and blame for compromise, misconfiguration, accidental deletions, information leakage, etc. There are people designated to perform the tasks in

AD and it should be minimal and they should be closely monitored and not done with alternate credentials and not normal user account.


I would also suggest that you need a signed statement from an executive level person after they have been made aware of the risks, in writing, associated before even granting.


The other option would be to assign someone to perform the tasks with the Auditor so they can report rather than the auditor doing so themselves.


Your hands may be tied, though and the only thing you can do is document the risks, communicate to executives, and get written authorizations. Even then get a list of requirements from the auditor and only grant

at an OU level, possibly even a test OU where they can do minimal damage.


Look at


Brian Britt