What rights are needed to view the SACL on an Active Directory object?
I'd also like to know what rights are needed to be able to view the SACL on an Active Directory object, you know, the one that specifies what access should be audited on the object?
We would like and delegate audit management to our in-house compliance team, but have been struggling to determine what rights they need to be able to modify the audit settings on objects in Active Directory?
Does it need some user right, or some privilege, or membership in some builtin group? If anyone know, would appreciate you letting me know. Thank you in advance for your help.
Do you wish to know what rights are needed to view an object's SACL or to modify the object's SACL?
In order to modify an Active Directory object's SACL, you need to have the Manage Auditing and Security Log user right granted to you in the Domain Controllers Security Policy.
By default, this right is assigned to the BuiltIn Admins security group.
In general, you should NOT delegate the ability to modify SACLs, unless you are delegating it to an highly and equally trusted individual or group of individuals.
This is because anyone who has this right, can permanently or temporarily disable the auditing of specific events on specific objects, and use the opportunity to engage in malicious activity for which there won't be any audit events generated.
It is best to work in collaboration with your in-house compliance team, let them know which administrative tasks they would like audited, then configure the corresponding SACLs yourself, instead of giving them the ability to do so.
This is merely my 2c, but this is very critical stuff, and thus I would highly advise against delegating this ability to anyone.
Thanks, and good luck with your project.
Ray.
__________________
One misconfigured 00299570-246d-11d0-a768-00aa006e0529 is all I need.
Thanks very much for providing this information. I really appreciate you pointing out that we should not be delegating the ability to control what is audited, and now it makes complete sense as to why this must not be done.
We have since gone ahead and delegated all common administrative tasks in our Active Directory as well as specified adequate auditing settings so as to be able to catch the occurence of these tasks by our delegated admins.
Nice work! By the way, don't forget to verify your delegations on a weekly basis.
This is very important because while auditing can certainly help you find out who did what, it is equally or more important to know who did what, because as they say, prevention is better than cure, and sometimes cure may not be possible.
For instance, if a smart hacker was to reset the password of an Enterprise / Domain Administrator, even though an event will get generated in the audit log, by the time you notice in and attempt to act upon it, the smart hacer, now loggged in as Domain Admin would already have disabled your account.
Just remember than weekly audits of who is delegated what access in your Active Directory are equally, if not more important than auditing the delegated tasks.
Ray.
__________________
One misconfigured 00299570-246d-11d0-a768-00aa006e0529 is all I need.
