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)