Blog - Title

April, 2009

  • “The LastLogonTimeStamp Attribute” – “What it was designed for and how it works”

    Warren here. In Windows Server 2003 we introduced the lastLogontimeStamp attribute. Administrators can use the lastLogontimeStamp attribute to determine if a user or computer account has recently logged onto the domain. Using this information administrators can then review the accounts identified and determine if they are still needed and take appropriate action.

    Intended Use

    It is important to note that the intended purpose of the lastLogontimeStamp attribute to help identify inactive computer and user accounts. The lastLogon attribute is not designed to provide real time logon information. With default settings in place the lastLogontimeStamp will be 9-14 days behind the current date.

    If you are looking for more “real-time” logon tracking you will need to query the Security Event log on your DC’s for the desired logon events i.e. 528 –Windows XP\2003 and earlier or 4624 Windows Vista\2008 . See this blog post by Eric Fitzgerald for more info. (I think he knows something about auditing)

    IMO your best bet for near real-time data is to use an event log collection service to gather all domain controller security event logs to a centralized database. You can then query a single database for the desired logon events. Microsoft’s solution for security event log collection is Audit Collection Services. There are many 3rd party solutions as well.

    How it worked in Windows 2000

    Prior to Windows Server 2003 administrators had to query the lastLogon attribute to determine the most recent logon of user or computer account. This process was time consuming as the lastLogon attribute is updated only on the DC that validates the logon request. The lastLogon attribute is not replicated. So in the past to determine the most recent logon of a user or computer account the lastLogon attribute had to be queried on all domain controllers (at least in concept) and then the most recent date for lastLogon had to be determined from all the results returned. In Windows 2003 and higher lastLogon is still has the same behavior. It is updated only on the validating DC and is not replicated.

    How it works in Windows Server 2003 and later

    In contrast the lastLogontimeStamp attribute is replicated so all DC's have the same value for the attribute (after replication convergence). Therefore you can query a single DC to find all the users or all the computers that have not logged in within a certain time.


    Your Windows domain must be at Windows 2003 Domain Functional Level for updates to the llastLogontimeStamp to occur.

    Logon types and that will trigger an update to the lastLogontimeStamp attribute.

    The lastLogontimeStamp attribute is not updated with all logon types or at every logon. The good news is that the logon types that admins usually care about will update the attribute and often enough to accomplish its task of identifying inactive accounts.

    Interactive, Network, and Service logons will update the lastLogontimeStamp. So if a user logs on interactively, browses a network share, access the email server, runs an LDAP query etc… the lastLogontimeStamp attribute will updated if the right condition is met. (The conditions are discussed below in the section Update and Replication of lastLogontimeStamp.

    As of Windows 2003 SP1 these logon types will NOT update lastLogontimeStamp

    • Certificate mapping through Microsoft Internet Information Services (IIS).
    • Microsoft .NET Passport mapping through IIS.

    [Update June 19, 2009 - removed one item from the list above that is under debate in a repro currently. Will update when we have more word] 


    Update and Replication of lastLogontimeStamp

    First become acquainted with the ms-DS-Logon-Time-Sync-Interval attribute. It is an attribute of the domain NC and controls the granularity (in days) with which the lastLogontimeStamp attribute is updated. The default value is 14 and is set in code. Meaning that if you look at this attribute in ADSIEDIT.MSC and you see it as "Not Set" don't be alarmed. This just means the system is using the default value of 14.

    The lastLogontimeStamp attribute is not updated every time a user or computer logs on to the domain. The decision to update the value is based on the current date minus the value of the (ms-DS-Logon-Time-Sync-Interval attribute minus a random percentage of 5). If the result is equal to or greater than lastLogontimeStamp the attribute is updated. There are no special considerations for replication of lastLogontimeStamp. If the attribute is updated it is replicated like any other attribute update. This is not urgent replication

    Walkthrough of a lastLogontimeStampUpdate update

    1. (Assuming the value of the ms-DS-Logon-Time-Sync-Interval is at the default of 14)

    2. User logs on to the domain

    3. The lastLogontimeStamp attribute value of the user is retrieved

    4. 14 - (Random percentage of 5) = X

    5. Current date - value of lastLogontimeStamp = Y

    6. X ≤ Y - update lastLognTimeStamp

    7. X > Y - do not update lastLogontimeStamp

    Why the Randomization?

    This randomization is done to prevent an update of the lastLogontimeStamp attribute from many accounts at the same time causing a high replication load on the DC's. Remember the purpose of the lastLogontimeStamp attribute is locate inactive accounts not provide real-time logon information.

    Controlling the update frequency of lastLogontimeStamp.

    It is possible to change the frequency of updates to the lastLogonTime stamp or turn it off completely if desired. If you need a different time interval you will need to adjust the value of the msDS-LogonTimeSyncInterval attribute to a value between 5-100,000. Yes that’s right: the max value is 100,000 days… Or if you prefer ~280 years... And the max value was set in code not in the schema. (I guess the dev was counting on medical science to solve that pesky aging problem.)

    In my experience the default settings can accommodate almost anyone and there is no need to change the update interval. Most customers I have talked to start considering accounts potentially inactive at the 30 day or higher mark of inactivity.

    Note: If the msDS-LogonTimeSyncInterval is less than 5 days, the randomization is not put into effect.

    How do I turn this thing off?

    If you want to disable the lastLogontimeStamp feature set the msDS-LogonTimeSyncInterval attribute to 0.

    I personally have never spoken with anyone that really had a business need to change how often lastLogontimeStamp needs to be updated. Once it was explained how the update process works and it was proven that the attribute is current and replicated to all DC’s that was all that was needed. If really think you need a more recent timestamp than 9-14 days for inactive account detection I suggest you make small changes and monitor DC workloads. This is especially true in large environments.


    Clearing up the confusion - Verifying that LastLogontimeStamp is in sync across all DCs in the domain.

    Many times customers will be concerned about what their tools are displaying to them (usually a very old date) as the lastLogontimeStamp of a user compared to what they know to be a more accurate date. This is almost always due to the admin using a tool that queries the lastLogon attribute instead of the lastLogontimeStamp attribute.

    For example acctinfo.dll that is included with the Account Lockout tools will display the lastLogon attribute data not the lastLogontimeStamp data. In some cases the date the tool reports may be months or years out of date or display nothing at all. This is because they are querying the lastLogon attribute and the user they are looking up has either never been authenticated by the reference DC (in the case of null) or has not been authenticated by the reference DC in a very long time.

    How to tell if lastLogontimeStamp is in sync

    To verify if the lastLogonTime stamp is being updated and replicated as expected you can use repadmin.exe with the showattr switch. Some examples are given below. These examples are intended to demonstrate that lastLogontimeStamp is being updated within the window of 9-14 days and replicated to all DC’s in the domain. They are not an example of how to manage stale accounts.

    1. Using repadmin to check the value of lastLogontimeStamp on all DC's in a domain for one user:

    repadmin /showattr * (DN of the target user) /attrs:lastLogontimeStamp >lastLogontimeStamp.txt


    repadmin /showattr * CN=user1,OU=accounting,DC=domain,dc=com /attrs:lastLogontimeStamp >lastLogontimeStamp.txt

    2. Using repadmin to dump the lastLogontimeStamp for all users in a domain including users that have no data in the lastLogontimeStamp attribute:

    repadmin /showattr * /subtree /filter:"(&(objectCategory=Person)(objectClass=user))" /attrs:lastLogontimeStamp >lastLogontimeStamp.txt

    3. Dump lastLogonTime stamp for users but only ones that have the attribute populated

    repadmin /showattr * dc=domain,dc=com /subtree /filter:"((&(lastLogontimeStamp=*)(objectCategory=Person)(objectClass=user)))" /attrs:lastLogontimeStamp > lastLogontimeStamp-2-22-2009.txt

    - Warren ‘For Once not DFSR’ Williams

  • DFSR Debug Log Series Wrapup and Downloadable Copies

    Ned again. As promised, here is the complete list of links for the recent 21-part DFSR Debug Log analysis series as well as downloadable versions of the series in Word 2007, Word 2003-97, XPS, and PDF formats. I have also included the debug logs I referenced as a separate ZIP file.

    Understanding DFSR debug logging

    Understanding DFSR debug logging (Part 1: Logging Levels, Log Format, GUID’s)
    Understanding DFSR debug logging (Part 2: Nested Fields, Module ID's)
    Understanding DFSR debug logging (Part 3: The Log Scenario Format, File Added to Replicated Folder on Windows Server 2008)
    Understanding DFSR debug logging (Part 4: A Very Small File Added to Replicated Folder on Windows Server 2008)
    Understanding DFSR debug logging (Part 5: File Modified on Windows Server 2003 R2)
    Understanding DFSR debug logging (Part 6: Microsoft Office Word 97-2003 File Modified on Windows Server 2008)
    Understanding DFSR debug logging (Part 7: Microsoft Office Word 2007 File Modified on Windows Server 2008)
    Understanding DFSR debug logging (Part 8: File Deleted from Windows Server 2003 R2)
    Understanding DFSR debug logging (Part 9: File is Renamed on Windows Server 2003 R2)
    Understanding DFSR debug logging (Part 10: File Conflicted between two Windows Server 2008)
    Understanding DFSR debug logging (Part 11: Directory created on Windows Server 2003 R2)
    Understanding DFSR debug logging (Part 12: Domain Controller Bind and Config Polling on Windows Server 2008)
    Understanding DFSR debug logging (part 13: A New Replication Group and Replicated Folder between two Windows Server 2008 members)
    Understanding DFSR debug logging (Part 14: A sharing violation due to a file locked upstream between two Windows Server 2008)
    Understanding DFSR debug logging (Part 15: Pre-Seeded Data Usage during Initial Sync)
    Understanding DFSR debug logging (Part 16: File modification with RDC in very granular detail (uses debug severity 5))
    Understanding DFSR debug logging (Part 17: Replication failing because of blocked RPC ports (uses debug severity 5))
    Understanding DFSR debug logging (Part 18: LDAP queries failing due to network (uses debug severity 5))
    Understanding DFSR debug logging (Part 19: File Blocked Inbound by a File Screen Filter Driver (uses debug severity 5))
    Understanding DFSR debug logging (Part 20: Skipped temporary and filtered files (uses debug severity 5))
    Understanding DFSR debug logging (Part 21: File replication performance from throttling (uses debug severity 5))

    Downloadable Versions (all 21-parts in one document)


    Download the sample log files


    - Ned Pyle

  • Tell us how we've been doing

    Ned here. Please take a moment to tell us how we've been doing over the past 18 months, and if you've found AskDS to be useful. The poll has been added to our sidebar on the left, just scroll down a little. It should take you less than 5 seconds to complete. :-)


    - Ned Pyle

  • Happy birthday Redmond domain :-)

    Ned here. From one of our MSIT bloggers-in-arms, Brian Puhl:

    10 years ago, Microsoft’s largest internal domain was upgraded to Windows 2000 becoming the first production Active Directory, and it’s still going strong…

    Dn: DC=redmond,DC=corp,DC=microsoft,DC=com
       whenCreated: 4/9/1999 7:49:12 PM Pacific Daylight Time;

    Happy birthday Redmond domain, here's to many more. In honor of the event, here's a rather creepy picture.


    - Ned ‘Party Hat’ Pyle

  • Conficker causes LSASS to consume CPU Time on Domain Controllers

    Hi Gautam here, I wanted to blog about a high-impact problem we have been seeing recently.

    The problem has to do with LSASS consuming a lot of CPU time on your Domain Controllers (DC's). The cause of this high CPU turns out to be Conficker infected computers throwing bad passwords against the DC's. The rate of bad passwords can be as high as 10,000 per minute from multiple clients.

    Technical information on Conficker can be found here.

    The problem could manifest itself in many ways, some being...

    1. Slow authentication and logons being reported by users,
    2. Slow mail flow
    3. Slow Resource access (resources could be Files shares, printers and more) or even complete failure in Resource access.

    Some of the above problems take time to be narrowed down. You typically will have to go through a few other pieces before you narrow down on the domain controllers being bogged down with high CPU time.


    CPU usage on domain controllers continues to be very high (I'm rating high = 70% and above as long as this is not normal for the DC). On looking closer, you find LSASS.EXE eating up all of this CPU. Perfmon reports show the CPU usage stays more or less consistent throughout the day. It doesn't climb down during off-peak hours.

    As you can imagine, this high CPU usage affects other workflows which are AD dependent – including Exchange/SharePoint/Authentication etc.

    If you temporarily pull the network cable from the DC and wait a few minutes, LSASS drops back down to ~1% or whatever value is normal in your setup. Ned Pyle has the logic of pulling out the network cable described in a previous post in detail.

    In this case as well, we saw that pulling out the network cable brings down the LSASS CPU usage to normal limits. Plugging it back in makes LSASS shoot up again to 80%-90% CPU.

    If you follow the steps which Ned has documented in the blog, network traces will show a HUGE number of authentication requests coming into the DCs. Now it's not always easy to differentiate between bad and good traffic when you are looking at 100MB worth of network traffic.

    In this case however, what you are bound to see if something like the below in the network traces – I highly recommend using Netmon 3* - the Conversations feature is ideal to work through a large trace which you are bound to get when collecting network traces from the DC.

    09:54:16.593    DC01.CONTOSO.COM    KerberosV5    KerberosV5:AS Request Cname: User1 Realm: CONTOSO.COM Sname: krbtgt/CONTOSO.COM

    09:54:16.625    DC01.CONTOSO.COM    KerberosV5    KerberosV5:KRB_ERROR - KDC_ERR_PREAUTH_FAILED (24)


    09:54:16.531    DC01.CONTOSO.COM    TCP    TCP:Flags=......S., SrcPort=4614, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=3314092510, Ack=0, Win=65535 ( ) = 65535

    09:54:16.531    DC01.CONTOSO.COM    TCP    TCP:Flags=...A..S., SrcPort=Microsoft-DS(445), DstPort=4614, PayloadLen=0, Seq=1831638666, Ack=3314092511, Win=17520 ( Scale factor not supported ) = 17520

    09:54:16.531    DC01.CONTOSO.COM    TCP    TCP:Flags=...A...., SrcPort=4614, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=3314092511, Ack=1831638667, Win=65535 (scale factor 0x0) = 65535

    09:54:16.531    DC01.CONTOSO.COM    SMB    SMB:C; Negotiate, Dialect = PC NETWORK PROGRAM 1.0, LANMAN1.0, Windows for Workgroups 3.1a, LM1.2X002, LANMAN2.1, NT LM 0.12

    09:54:16.531    DC01.CONTOSO.COM    SMB    SMB:R; Negotiate, Dialect is NT LM 0.12 (#5), SpnegoNegTokenInit

    09:54:16.578    DC01.CONTOSO.COM    SMB    SMB:C; Session Setup Andx, NTLM NEGOTIATE MESSAGE

    09:54:16.578    DC01.CONTOSO.COM    SMB    SMB:R; Session Setup Andx, NTLM CHALLENGE MESSAGE - NT Status: System - Error, Code = (22) STATUS_MORE_PROCESSING_REQUIRED

    09:54:16.593    DC01.CONTOSO.COM    TCP    TCP:Flags=...A...F, SrcPort=4614, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=3314092888, Ack=1831639470, Win=64732 (scale factor 0x0) = 64732

    09:54:16.593    DC01.CONTOSO.COM    TCP    TCP:Flags=...A...F, SrcPort=Microsoft-DS(445), DstPort=4614, PayloadLen=0, Seq=1831639470, Ack=3314092889, Win=17143 (scale factor 0x0) = 17143

    09:54:16.593    DC01.CONTOSO.COM    TCP    TCP:Flags=...A...., SrcPort=4614, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=3314092889, Ack=1831639471, Win=64732 (scale factor 0x0) = 64732

    Now, in the above three examples of network traffic, the first one with the Kerberos KDC_ERR_PREAUTH_FAILED is a sure shot bad password attempt. The other two traces aren't necessarily always bad authentication attempts, but is data connections to LSARPC which I saw on three of the four recent cases I had with this issue.

    SPA reports will show high number of calls to SAMSRV or LSARPC. Tim Springston, who runs his own excellent AD related blog, has discussed the using of SPA here.

    With TOP users attained from both SPA and from the Network traces, we explored 3 of the top client computers. We pulled MPSReports (an often used PSS Data collection tool) from these client computers. The first thing which stood out in the event logs was all the Audit Failures Logon/Logoff Event Id 529's in the Security Event logs.

    Note: by default, only Success for Logon/Logoff and Account Logon is enabled. And in this case, the Domain Controllers were running with the defaults. The client computers had Failure for Logon/Logoff enabled.


    This of course led us to...

    1. Checking this customer's account lockout policy –we saw they did not have account lockouts enabled
    2. We enabled Failure for Account Logon on a policy which applied to the Domain Controllers as well.

    No sooner had the failure-audit policy applied to the DC, the Security event logs were filled with Audit Failures Account Logon Event Id 675. Here is an example of a 675 event.

    Event Type:    Failure Audit
    Event Source:    Security
    Event Category:    Account Logon
    Event ID:    675
    Date:        3/23/2009
    Time:        3:03:57 AM
    User:        NT AUTHORITY\SYSTEM
    Computer:    DC01
    Pre-authentication failed:

        User Name:    User1
        User ID:        %{S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxx-xxxxx}
        Service Name:    krbtgt/CONTOSO.COM
        Pre-Authentication Type:    0x2
        Failure Code:    0x18
        Client Address: ß IP of the computer which is throwing the bad credentials

    Using EVENTCOMBMT to pull out the relevant event Ids from various DCs (namely 529, 644, 675, 676, and 681) and a little bit of Office Excel magic, I quickly had a list of ~100 computers sending bad passwords within a 30 minute time frame. The total number of failed logons were enough to drive up the LSASS.EXE CPU usage. LSASS ofcourse was only doing its job of keeping up with the load and failing the bad authentication attempts.

    Putting it all together:

    The kind of (multiple user logons from a single computer) and the rate (100's of attempts per minute per computer) at which they were throwing bad passwords, were a pretty sure sign of malware activity. A few more client computers, which we picked up from the SPA and Netmon reports, revealed traces of Conficker. With the Microsoft PSS Security team and the customers own Antivirus vendor involved, they were able to patch, scan, and clean their computers and this effort showed the LSASS CPU usage on the DCs drop down dramatically.

    So from high LSASS CPU – to network traces leading to TOP client computers – to security events – to DC security events – back to the client computers! As you can imagine, it took some time in nailing down the first time. The 2nd, 3rd and 4th cases were nailed down to unpatched computers infected by Conficker way quicker.

    I hope with this blog post out, someone will save themselves a LOT of time and effort when facing such an issue.

    • Gautam Anand
  • New Directory Services KB Articles 4/11-4/18

    New KB articles related to Directory Services for the week of 4/11-4/18.


    A DNS zone transfer between two Windows Server 2003-based DNS servers generates incomplete zone data when the DNS transfer process stops unexpectedly


    The Tcpipv6.sys driver stops responding to any TCP/IPv6 requests on a Windows Server 2003 SP2-based computer when the driver binds to many network adapters


    All network share access through the SMB protocol (client-side redirector) may fail on a Windows Server 2003-based computer


    Windows Server 2003 SP2-based domain controllers return incorrect error code to Kerberos requests during the shutdown process


    Windows 7 clients cannot locate the Active Directory Management Gateway service that is installed on Windows Server 2003-based domain controllers


    A Windows Server 2003-based file server may return file identifiers (Fids) that have the 0xffff value under heavy stress


    Some files are missing on a Windows Server 2003 R2-based computer after a DFSR replication


    Users cannot perform authentication through ADFS in a Windows Server 2003 R2 environment when the UPN suffixes contain a character that expands to a two-letter pair


    How do I enable User Account Control in Windows Vista?

  • Other Directory Services Blogs

    There are quite a few people out there blogging about AD-related stuff. Below are some I know about. There is an OPML file attached to this post if you just want to import them all into a feed reader (make sure you click through to this post specifically to see the attachment at the bottom).

    If you know about other blogs that talk about Directory Services, let us know in the comments section.



  • One stop Audit shop for ADAM and ADLDS

    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:

    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:


    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


    Logon attempt by:          ADAM_adlds1

     Logon account:                CN=user1,OU=Users,DC=ADLDS

     Source Workstation:

     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:


    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


    Audit Access in Replication


    Provides a summary of the replication operations that are occurring.

    Audit Objects in Replication


    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:  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 -

    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.




    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):


    Event ID:      5137



    A directory service object was created.


                    Security ID:                         lindakup\Administrator

                    Account Name:                 Administrator

                    Account Domain:                             lindakup

                    Logon ID:                             0xfcceb

    Directory Service:

                    Name:  ADAM_blogTest

                    Type:     Active Directory Lightweight Directory Services


                    DN:        CN=Linda,OU=europe,dc=adamblog

                    GUID:    {23995da1-f623-414d-8a6e-a02376e8c666}

                    Class:    user




    ·         A  5136 event for every attribute that I added to my user object.


    Event ID:      5136



    A directory service object was modified.


            Security ID:                         lindakup\Administrator

            Account Name:                 Administrator

            Account Domain:                             lindakup

            Logon ID:                             0xfcceb


    Directory Service:

            Name:  ADAM_blogTest

            Type:     Active Directory Lightweight Directory Services


            DN:        CN=Linda,OU=europe,dc=adamblog

            GUID:    {23995da1-f623-414d-8a6e-a02376e8c666}

            Class:     user


            LDAP Display Name:       objectClass

            Syntax (OID):

            Value:   1.2.840.113556.1.5.9      


            Type:     Value Added



    ·         Finally for the object move:



    Event ID:      5139

    Task Category: Directory Service Changes


    A directory service object was moved.



            Security ID:                         lindakup\Administrator

            Account Name:                 Administrator

            Account Domain:                             lindakup

            Logon ID:                             0xfcceb


    Directory Service:

            Name:                  ADAM_blogTest

            Type:                     Active Directory Lightweight Directory Services



            Old DN:                                OU=MiddleEast,DC=adamblog

            New DN:              OU=MiddleEast,OU=Countries,DC=adamblog

            GUID:                    {d0385bd8-adea-4916-a656-dd49770848d0}

            Class:                     organizationalUnit



    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:

    ·         ADLDS documentation includes step-by-step guide and operations guide here:

    ·         More ADLDS resources:

     - Linda Taylor