Dumping Passwords From Microsoft Active Directory Lightweight Directory Services (AD LDS) 

In this article, we detail modifications we made to Impacket’s utility to support dumping password hashes from an AD LDS server.

By Bryan Halfpap | Application Security Lead

What Is Microsoft Active Directory Lightweight Directory Services? 

Microsoft Active Directory Lightweight Directory Services (AD LDS), formerly known as Active Directory Application Mode (ADAM), is a Lightweight Directory Access Protocol (LDAP) server constructed from a stripped-down version of Microsoft Active Directory. Its primary goal is to provide a standards-compliant LDAP service on Microsoft Windows servers without Active Directory’s overhead, hence the “lightweight” nature of the service. 

AD LDS does not require as many dependent services (such as the Microsoft DNS service) because it does not offer nor use services such as DNS or group policy management. This low overhead makes AD LDS more attractive for use as a user and/or object management solution for applications. Systems that use AD LDS get to leverage the flexible nature of LDAP to store properties and relationships while gaining “free” interoperability with applications that already speak LDAP.  A common use case of the server is to centralize user management and login services across varied systems or products. We have also seen the service used to manage customer accounts and data within customer-facing applications. 

Dumping AD LDS NTDS.dit Files 

AD LDS directory tree files are located in “C:\Program Files\Microsoft ADAM\[Instance Name]\data\adamntds.dit” where “[Instance Name]” is the name of the AD LDS server assigned by the administrator during its creation. It is not possible to copy the DIT file of a running AD LDS instance directly while the service is running, so more clever means of copying the file are required, just as with Active Directory proper. Unlike Active Directory, however, no further files are required to decrypt user password hashes.   

If you encounter an adamntds.dit file, you may notice that it is not easy to dump the contents of the AD LDS directory information tree (DIT) file even though it has much of the same format and data of the Active Directory ntds.dit file. In fact, no known tools support decrypting and dumping the user password hashes from an AD LDS adamntds.dit file. This is due to two significant changes in AD LDS, which cause Active Directory specific tooling to fail. 

#1: The “Bootkey” 

The directory information tree (DIT) file of an Active Directory installation uses a special value known as the bootkey to encrypt the Password Encryption Key (PEK). The PEK is, in turn, used to encrypt sensitive portions of Active Directory objects such as a user’s password hash. When dealing with the Active Directory DIT file (i.e., ntds.dit), this value is typically calculated using values from the SYSTEM registry hive. In AD LDS, however, the bootkey is contained within the adamntds.dit file itself. The bootkey is derived by combining the Password Encryption Key (PEK) list attribute of two specific LDAP records within file: “Root” (the record with a blank or null name attribute) and the record with the name “Schema”.  The schema and root entries are combined in a specific order (called permutation in to create the bootkey

When processing an AD LDS directory information tree file, decryption of encrypted record attributes proceeds using the bootkey and the PEK index of the record’s encrypted attribute to generate the attribute’s RC4 decryption key. No other encryption layers are used when processing encrypted attributes as opposed to Active Directory, which uses an additional layer of 3DES. 

To decrypt the PEK, the key is generated by adding the salt 1,000 times to the bootkey and taking the MD5 hash of that sequence of bytes. 

#2: Schema Differences 

In Active Directory, you are guaranteed to have several Microsoft-related user properties present in the user objects because the AD schema requires them. In plain implementations of LDAP, these properties are useless since LDAP doesn’t understand what a Microsoft Windows “sAMAccountType” is.  Icebreaker has modified Impacket’s so that it is able to process both Active Directory and Active Directory Lightweight Directory Services LDAP schemas while parsing DIT files to dump credentials. 


Download the Icebreaker team’s fork of Impacket and install it by browsing to the root of the Impacket directory and running  

`python3 -m pip install .` 

Then run Icebreaker’s modified utility with the following options: 

` -ntds [path-to-your-adamntds.dit] -adamlds LOCAL` 

A list of users and their corresponding password hashes will be displayed. 

We hope that these modifications prove useful to those encountering this LDAP service on security testing engagements, and we extend our gratitude to all those responsible for maintaining Impacket and in particular. These tools are excellent implementations of critical components of the Microsoft ecosystem and allow development of new capabilities to be performed quickly and easily. 

Give the Icebreaker team a shout to learn more.