Currently we are working on a monthly internal security test which among other should contain a verification of the real password strength the users choose. For this reason I want to extract the password hashes of all users via LDAP. Everything I found was this technet discussion telling me I cant extract the hashes even not as an Administrator which I really can't (don't want) to believe.

Is there any way to extract the password hashes from an Active Directory Server?

What we want to do is extracting the hashes though we can run a syllable attack against them to verify if the passwords are really or just technically good.

  • Even if you got them out, how would you verify the passwords? The hashes are, by definition, not reversible. That is, you can't get a password from a hash. Commented Sep 14, 2015 at 18:06
  • 1
    Of cause they arent reversable. We are creating wordlists based on common words, technical terms,... and then run a syllable attack against the hashes to verify if they are really secure or just a common word with a number and a special char attached.
    – davidb
    Commented Sep 14, 2015 at 18:59
  • Alright. That makes sense. So you are asking us if the answer you pointed to that has an MS employee stating that you can't get the hashes is incorrect or can somehow be bypassed. I suspect not but I"m not an AD wiz. Commented Sep 14, 2015 at 19:21

4 Answers 4


You need to get the NTDS.DIT binary file out of %SystemRoot%\ntds.

You can use ntdsutil to create a snapshot of the AD database so that you can copy NTDS.DIT.

Then you can use something like the Windows Password Recovery tool to extract the hashes.





You do not need to process the .dit file to acquire hashes from AD or AD LDS; you can access the stored password hashes programmatically.

Normal attempts to read a user's userpassword attribute is blocked in AD. This is because you don't have the DS-Replication-Get-Changes-All permission - which is required to read secret domain data:

DS-Replication-Get-Changes-All extended right

Control access right that allows the replication of secret domain data.

  • CN:: DS-Replication-Get-Changes-All
  • Display-Name:: Replicating Directory Changes All
  • Rights-GUID:: 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2

This permission is used by domain controllers to replicate the AD database (including stored user password hashes). It is also used by Microsoft Azure AD password sync, as well as 3rd party implementations.

Differentiation: The DIRSYNC control can also be used with another slightly different privilege called DS-Replication-Get-Changes (without the "-All" at the end):

DS-Replication-Get-Changes extended right

Extended right needed to replicate changes from a given NC.

  • CN:: DS-Replication-Get-Changes
  • Display-Name: Replicating Directory Changes
  • Rights-GUID: 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2

This privilege (i.e., without -All) cannot extract sensitive password hash data. There are commercial directory data sync products, like Microsoft MIIS/ILM/FIM/MIM that rely on that privilege. Also domain controllers of type READONLY for DMZ usage use this privilege.

Password filter DLLs or PCNS installations on domain controllers do not use these two privileges and also do not grant access to stored AD hashes. They just allow forward a password (at the moment when it's gets changed by the user) to some external processing target that will then set the same password on 3rd party systems within your company.

While a password filter DLL/PCNS will only be able to synchronize passwords that get changed by the user after the filter/PCNS solution has been deployed, the Replication together with the DS-Replication-Get-Changes-All can also synchronize AD password hashes that have been there before the sync solution was deployed.

Neither the two privileges are evil.

It could of course be highly problematic, if used carelessly. But the same goes for careless ACL changes in your AD, granting extensive remote access to your AD, permitting domain and schema admins to anyone and so on......

It's an open door, if you open it. It you don't need it, don't open that door. And if you do open that door, then harden it properly, such that only planned guest can enter that door to touch your precious parts.

So the regular business cases of this read-password-hashes-from-AD mechanism is to synchronize AD hashes to other legitimate authentication systems or to migrate existing company AD hashes to an other 3rd party authentication directory.

(In both cases the other system must be able to understand the hashes for authentication purposes though)


So, this whole reasoning is kind of insane. Auditing password correctness after the fact is a bad idea (because you either need the original password, or a weak hash that can effectively be rainbow-tabled), and writing services or tools to extract the weak hashes is prone to serious error or danger. Less importantly, it's overkill, and a waste of cycles and resources.

The better solution is to just use a password filter and verify the password changes meet minimum requirements before allowing the user to actually make the change. Then, expire all the passwords if you're serious about guaranteeing complexity (though that might annoy some people).

  • You're right that it might annoy people. It might do much worse than that, for example when you are doing this for an enterprise of 100,000's of accounts, including potentially critical service accounts. There is nothing stopping you filtering passwords as they are set in addition to this approach, and I don't think there is anything insane about wanting to retroactively improve the security of your user accounts in a way that causes the minimum amount of disruption.
    – deed02392
    Commented Feb 26, 2020 at 21:11

To pull the passwords remotely, the best solution is to use DC SYNC (DRSUAPI) techniques. Domain controllers use this protocol to sync their information back and forth. If you have Domain Administrator credentials, you can use this protocol to grab all hashes from the domain controller. There are two easy tools to do this:

For Windows: Mimikatz (https://github.com/gentilkiwi/mimikatz)

Instructions for how to use it and more overview: https://adsecurity.org/?p=1729

For Linux: Impacket, specifically the secretsdump.py example script (https://github.com/CoreSecurity/impacket)

Instruction for how to use it: https://room362.com/post/2015/using-domain-controller-account-passwords-to-hashdump-domains/

In both cases, Anti-virus software will state that the tools are malicious, as they obviously have malicious potential, but both tools are not inherently malicious.

  • This is the best answer. Windows provides an API to extract user's stored passwords from a the domain controller. HIs "auditing domain controller" can then decrypt the passwords, decide if they like them, and can even push new passwords back into the domain.
    – Ian Boyd
    Commented Apr 29, 2020 at 14:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .