Extract Password Hashes from Active Directory LDAP

You do not need to process the DIT file to aquire hashes from AD or AD LDS, there is some protocol access as well.

Even though a regular LDAP-reads on "userpassword" Attribute (as you can do on other directory products) will always be blocked completely in AD, there is another official way to read hashes from AD or AD LDS and its officially been there since at least Server 2003. You need to use a special AD access permission (DS-Replication-Get-Changes-All) and an officially documented Microsoft protocol (the AD replication protocol). This is not a Microsoft internal secret, even 3rd party implementations exist, e.g.: https://www.dsinternals.com/en/retrieving-active-directory-passwords-remotely/ (although this link overdoes it a bit, by claiming this to be a hack) - You are not hacking AD or LDAP protocol with this, you are manually granting an AD privilege beforehand that is not there by default.

A legitimate use of this DS-Replication-Get-Changes-All privilege is e.g. the Microsoft Asure AD password sync - it syncs your company AD passwords with Azure cloud passwords by transfering the hashes. you need a special LDAP privilege assigned to an AD account for this, which called is "DS-Replication-Get-Changes-All" https://msdn.microsoft.com/en-us/library/windows/desktop/ms684355(v=vs.85).aspx

Differenciation: The DIRSYNC control can also be used with another slightly different privilege called "DS-Replication-Get-Changes" (whithout the "-All" at the end). The privilege without "-All" at the end 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 the privilege without the "-All")

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 Relication 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...... Its 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)

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.

https://technet.microsoft.com/en-us/library/cc753343.aspx

https://technet.microsoft.com/en-us/library/cc753609(WS.10).aspx

http://www.passcape.com/windows_password_recovery

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