Hello, Linda Taylor here, I am an Escalation Engineer in the Directory Services support team in the UK. I do a lot of work with ADAM and ADLDS. One of frequent subjects for questions for ADAM/ADLDS is around auditing. We have lots of very good documents on TechNet about ADAM and ADLDS which briefly mention auditing, but there isn't one single document where you can find all auditing related information. So this should be helpful!
Note: information here applies to both ADAM and ADLDS unless otherwise stated. To be current with things I will use LDS to refer to ADAM and ADLDS.
First is first: Auditing is supported on WS03 (ADAM) and WS08 (ADLDS) but not in XP. Auditing is also improved in ADLDS with the new DS Access auditing categories
Q: So what do you need to configure directory service access auditing in LDS?
There are 3 things:
1. Enable auditing via GPO
2. Set the SACL on the object in LDS which you want to audit
3. The LDS service account must be granted 'generate security audit' right on the servers where LDS runs. Network Service or Local System have this by default so if you are running ADAM service under one of these then no need to do anything.
>>>See below for details of each of these steps.
Q. What can we audit using GPO?
Through GPO we have a number of options under Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit policy.
But not all of these can be used/apply to LDS / ADAM.
· There are 2 Audit settings here that are relevant to LDS:
1. Audit Directory Service Access.
As described this allows you to audit access to objects in LDS directory.
Note: in WS08 we added the new categories to DS Access auditing see Q&A section at the bottom.
2. Audit Account Logon Events
This allows you to get a security log audit on the LDS machine when a native LDS user connects/binds to an instance.
· Settings which do not make sense for ADLDS:
- Audit Account Management doesn't work for ADLDS. This one probably deserves an explanation as to why....This is because ADLDS user objects are viewed by Windows simply as objects stored in some directory which is independent of the operating system ( so they are not SAM account objects ).. Whose object class name happens to be "user". By Default ADLDS doesn't contain any user class so we are free to define anything and call it user class. Therefore the standard account management auditing doesn't apply.
-Audit Object access, Audit Policy change, Process Tracking and System Events also doesn't make sense for ADLDS since it applies to things like file objects, and policies which do not exist in the LDS database.
Q: How do I set up auditing for LDS?
So going back to the steps at the beginning of this doc:
1. Set up Group policy - enable DS Access auditing / account logon auditing (or both).
There are a few scenarios for this. Most people seem to be running LDS on domain joined machines so for this scenario either:
(a) The audit policy is usually set at the domain level in the Default Domain GPO. This then applied to all machines in the domain so your LDS server may be getting these settings in this way.
(b) You can put your LDS machines in an OU and create a specific GPO there to enable any audit settings if they are not enabled at domain level. This way any settings in the GPO will not affect the rest of the machines in your domain so it’s less of a risk.
The third option is for an LDS server in a workgroup. In this scenario you can simply configure auditing thought local Group Policy.
I won't go through the steps on how to configure Group Policy here as the main purpose of this article is to discuss auditing in LDS and ADAM. However you can find more information about Group Policy in TechNet by searching for "Group Policy". A good place to start could also be the "Windows Server Group Policy" home page here: http://technet.microsoft.com/en-us/windowsserver/grouppolicy/default.aspx
Note: don't forget to refresh group policy on the LDS machine after doing any modifying. (run gpupdate / force)
2. (a) For Directory Service Access Auditing - Set up the SACL in LDS.
For this you can use LDP.exe and its SACL Editor. (If you are on WS03 R2 or WS03 ADAM SP1 then you will need to make sure that you use the version of LDP.exe that comes with ADAM). Other ways of setting the SACL are thought dsacls.exe or scripting . Here I will give a simple LDP.exe example:
Steps:
1.Start LDP.exe and connect and bind to your ADLDS instance using an account which has permissions to edit SACL's. So for example the admin account of your LDS instance.
NOTE: In order to be able to see and edit ACE's in LDS you need to bind using a windows account (local or domain which has admin rights in LDS and the SESecurityPrivilege privilege on the LDS machine). If you bind with an LDS user account you will be unable to view, edit or add any ACE's . The windows will simply be blank and if you try to add an ACE you will get an "Error:Modify:Insufficient Rights <50>" when you try to update the SACL.
This is because Security administrators are users who have been assigned the Manage Auditing and Security Log (SeSecurityPrivilege) privilege. By default, this privilege is assigned to the built-in Administrators group in windows. ADAM users have no concept of privileges so it is not possible to assign an ADAM user this privilege.
2. From the "View" menu you can select <Tree> and leave the DN blank. This will enumerate all your partitions.
3. Navigate to the object which you want to audit access to and right click it. Then go to " advanced ->Security Descriptor " . A small Security Descriptor window will pop up with DN of your application partition. Select the SACL check box and click <OK>. Now you will see a dialog like this:
In the top you can see the owner of the object. In the middle pane there is the DACL section and right under there you can see the SACL box. For you it may be empty to start with. So you just need to click inside it to focus the tool on the SACL part.
4. Click in the SACL box or select a SACL to edit.
5. Click on <Add ACE> (or <Edit ACE>)and you will get a new pop up box where you can add the trustee (so the account/group you want to monitor) and choose which operations and attributes you want to audit. As well as choose if you want to audit success or failure and if you want to propagate this ACE to child objects.
6. When finished click OK and click update in the SD dialog. (Make sure SACL is checked - default)
Note: A WS03 ADAM instance will not generate SAM-style audits (636). It can only generate DS-style audits (566), which are controlled by SACLs on objects.
The 566 audit does not show the actual values being written, but it will say that user X updated attribute X on object X. In WS08 we added a capability to audit actual values being written. See Q3 below on how to enable this.
2. (b) Logon auditing.
No more configuration needed. LDS user bind auditing goes into the security log on the ADAM server. Look for event 680. This will tell you which ADAM user connected and to which instance as well as the source workstation IP and various other details.
Example event:
Event Type: Success Audit
Event Source: Security
Event Category: Account Logon
Event ID: 680
Date: 25/02/2009
Time: 11:14:37
User: S-1-340980651-3826302016-2572561877-1280810218-2114187174-3140415964
Computer: LINDAK-01
Description:
Logon attempt by: ADAM_adlds1
Logon account: CN=user1,OU=Users,DC=ADLDS
Source Workstation: 127.0.0.1
Error Code: 0x0
3. The LDS service account must be granted 'generate security audit' right on the servers where LDS runs. Network Service or Local System have this by default so if you are running ADAM service under one of these then no need to do anything. If you are running ADAM service as a local user account or a domain account you will need to give the user account this right. To do so you can use Local group policy and add the "Generate Security Audit" rights under Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignments.
Other audit Q&A:
Q1: How do I audit password changes for ADAM and ADLDS users?
Set up appropriate SACLs. You will want to audit the use of Change Password (and perhaps Reset Password) control access right on user objects.
Q2: How do I audit replication events in ADAM?
To enable replication auditing for an ADAM instance, you must modify the registry key:
HKLM\System\CurrentControlSet\Services\instance_name\Parameters
Where instance_name represents the name of the ADAM instance on which you want to audit replication. The following table describes the values in the registry key that control replication auditing. To enable replication auditing, set one or both of the values to 1.
|
Registry key value |
Data type |
Meaning |
|
Audit Access in Replication |
DWORD |
Provides a summary of the replication operations that are occurring. |
|
Audit Objects in Replication |
DWORD |
Audits the changes to individual objects and attributes. |
Once enabled Look for Events in the security log on the ADAM server under the category "Directory Service Access". (Note this also means you need to have DS Access auditing enabled via GPO as above). The event logged will show which object was modified, and which attribute. Including the new value.
Note note: this won't tell you who changed an object so if that is important I suggest you set a SACL on the desired object/container or choose WS08 ADLDS and the new auditing.
Q3. How I enable the new WS08 detailed object access auditing for ADLDS?
In Windows Server 2008 you can now set up AD DS auditing with a new audit subcategory to log old and new values when changes are made to objects and their attributes. For this to work on AD LDS you will need to use auditpol just like for DS.
The AD DS Auditing Step-by-Step Guide can be found here: http://technet.microsoft.com/en-us/library/cc731607.aspx and applies to AD LDS though the steps given are AD DS specific.
So here is how to make it work for AD LDS:
1. The GPO part is the same - use auditpol to enable the additional categories. Here is a link to auditpol commands - http://technet.microsoft.com/en-us/library/cc731451.aspx
Notes: There are a couple of different scenarios:
(a) If you have a WS08 ADLDS member server in WS03 domain , then if you enabled "Directory Access Auditing" via group policy (See above "How do I set up auditing in LDS?") then you don't need to do anything!! This turns on all 4 categories under DS Audit.
- run auditpol /get /category:* on the WS08 machine and it will show the following:
DS Access
Directory Service Changes Success and Failure
Directory Service Replication Success and Failure
Detailed Directory Service Replication Success and Failure
Directory Service Access Success and Failure
Note: ADLDS will take advantage and log all the new events in this scenario.
(b) if you have WS08 ADLDS server in a workgroup or a WS08 domain . In this case you will need to turn on the additional sub-categories of DS Access auditing. Only "Directory Service Access" is on by default. For example to turn on "Directory Service Changes" run the following command: auditpol /set /subcategory:"Directory Service Changes" /success:enable
2. The SACL part I have documented above in section 2(a)
3. The additional Schema controls (searchFlags) are the same for AD LDS Objects.
Example:
In ADLDS I used LDP to set a SACL on the NC head partition to audit "create child, delete child, write property, delete tree, delete". I also set the "inherit" flag. For trustee I added the CN=administrators group in that ADLDS partition. I then created a new user in this partition, and moved it into an OU. The following Events are logged in the security log:
· For the user creation (I cut out the relevant bits to save space):
<snip>
Event ID: 5137
...
Description:
A directory service object was created.
Subject:
Security ID: lindakup\Administrator
Account Name: Administrator
Account Domain: lindakup
Logon ID: 0xfcceb
Directory Service:
Name: ADAM_blogTest
Type: Active Directory Lightweight Directory Services
Object:
DN: CN=Linda,OU=europe,dc=adamblog
GUID: {23995da1-f623-414d-8a6e-a02376e8c666}
Class: user
</snip>
· A 5136 event for every attribute that I added to my user object.
<snip>
Event ID: 5136
...
Description:
A directory service object was modified.
Subject:
Security ID: lindakup\Administrator
Account Name: Administrator
Account Domain: lindakup
Logon ID: 0xfcceb
Directory Service:
Name: ADAM_blogTest
Type: Active Directory Lightweight Directory Services
Object:
DN: CN=Linda,OU=europe,dc=adamblog
GUID: {23995da1-f623-414d-8a6e-a02376e8c666}
Class: user
Attribute:
LDAP Display Name: objectClass
Syntax (OID): 2.5.5.2
Value: 1.2.840.113556.1.5.9
Operation:
Type: Value Added
</snip>
· Finally for the object move:
<snip>
Event ID: 5139
Task Category: Directory Service Changes
...
A directory service object was moved.
Subject:
Security ID: lindakup\Administrator
Account Name: Administrator
Account Domain: lindakup
Logon ID: 0xfcceb
Directory Service:
Name: ADAM_blogTest
Type: Active Directory Lightweight Directory Services
Object:
Old DN: OU=MiddleEast,DC=adamblog
New DN: OU=MiddleEast,OU=Countries,DC=adamblog
GUID: {d0385bd8-adea-4916-a656-dd49770848d0}
Class: organizationalUnit
</snip>
Q4. How do I enable auditing of object deletion in ADLDS?
Good news! The new DS Auditing category "Directory Service Changes" will report object deletions in WS08 ADLDS.
Look for Event 5145. This will tell you which object was deleted, when and by whom.
Finally Good Links:
· ADAM 2003 Technical Reference: http://technet.microsoft.com/en-us/library/cc736765.aspx
· ADLDS documentation includes step-by-step guide and operations guide here:http://technet.microsoft.com/en-us/library/cc731868.aspx
· More ADLDS resources: http://technet.microsoft.com/en-us/library/cc816744.aspx
- Linda Taylor