Some question were raised by few peoples about directory object auditing – mostly in a context of question "Who deleted the object?" – so I've decided to give this topic a little space.
Windows 2000\2003 provides us with auditing mechanism which can be used also to track changes for Active Directory objects. Probably this isn't exactly what one can look for when it comes to the question "who did this?" but it works and can be used if we need to gather some auditing data. This is also not a kind of mechanism You may look for if You need to comply with some regulations like SOX for example. There are third party products which are built for such kind of auditing.
So let's get to the point – directory object access auditing exists in Windows Server and has to be turned on if You want to collect some data. To turn on this mechanism You have to do two things:
- Turn on Object access auditing in Domain Controller Security Policy (there is no need to turn this option on servers others than DCs)
- Configure appropriate SACL on objects You want to audit.
SACL stands for System Access Control List and are used to identify users and groups for which auditing should be performed if they will attempt (with success or failure) to access specific directory object.
SACLs can be configured with Active Directory Users and Computers security tab or ldp.exe from ADAM SP1 (Windows 2003 R2). SACL contains ACEs (Access Control Entry) which determines what kind of access and for which user or group should be audited for particular object.
Below sample dialog box with auditing settings is presented:
To be sure that all required SACLs are in place it is good to check it with LDP.Exe or any other tool which is able to dump SACLs. Audit entry presented above in LDP.EXE dump looks like this:
Ace Type: 0x7 - SYSTEM_AUDIT_OBJECT_ACE_TYPE
Ace Size: 56 bytes
Ace Flags: 0xc6
Object Ace Mask: 0x00000002
Object Ace Flags: 0x1
Object Ace Type: user - bf967aba-0de6-11d0-a285-00aa003049e2
Object Ace Sid: W2K\Domain Admins S-1-5-21-1885536488-2434298766-162818185-512
So now, lets hunt the bug .. or rather answer the question – how to determine who deleted object in directory? Unfortunately in most cases auditing isn't enabled in directory and it is very hard to determine who performed this operation. If you are able to restore this object You can try to make some approximation. If You are in such case You can try to do "best effort" job and take a look at ACLs on the object and then at security log. Your goal is to narrow potential identities who were able to perform this operation (ACLs) and than analyses security log on a DC on which operation was performed to find out who was logged on at this time – than compare it with a list of identities who were able to do this regarding the ACLs. Not very sure, time consuming – but this is what You can do with those data.
In this case when auditing directory object access was enabled and You are lucky enough to set SACLs on this object to track successfully deletion everything what You have to do is to check where this operation took place (on which DC) and than check event log on this DC.
To check when and were operation took place we can use replication metadata of deleted object. What we are looking for is originating change to IsDeleted attribute. Repadmin.exe is Your friend here (but You can use other tool as well). For this we will have to know GUID of this object, and we will user repadmin's /showobjectmeta:
Now we know that this object was deleted on ROOTDC at 23:59. What we have to do is to check ROOTDC security log and look for 630 event id generated around this time.
Event Type: Success Audit
Event Source: Security
Event Category: Account Management
Event ID: 630
Time: 12:02:16 AM
User Account Deleted:
Target Account Name: jnowak
Target Domain: W2K
Target Account ID: Jan Nowak
Caller User Name: Administrator
Caller Domain: W2K
Caller Logon ID: (0x0,0x188D2)
Now we have it, as You can see this object was deleted by W2K\Administrator. Simple and easy.
One thing which has to be remembered – auditing can be very resources consuming and too many audit entries can affect Your DC performance. It should always be compromise between need of detailed auditing information and performance of your DC. You can try to stick to some rules which may make Your life with auditing easier:
- If You are interested in tracking particular actions, like object deletion etc. determine who has enough access rights to objects You are setting SACLs on and set SACLs only for those users\groups. In this way You will keep number of SACLs at minimum required level.
- Try to be very specific in Your SACLs, don't use "audit Everyone to everything" approach which will affect Your performance and will give You a lot of noise in security logs.
Next time auditing entry will be about LH. Stay tuned.