No es necesario que procese el archivo DIT para adquirir hashes desde AD o AD LDS, también hay algún acceso de protocolo.
A pesar de que las lecturas LDAP regulares en el atributo "userpassword" (como puede hacer en otros productos de directorio) siempre estarán bloqueadas por completo en AD,
hay otra forma oficial de leer hashes de AD o AD LDS y está oficialmente allí desde al menos el Servidor 2003. Debe usar un permiso especial de acceso a AD (DS-Replication-Get-Changes-All) y un protocolo de Microsoft documentado oficialmente (El protocolo de replicación AD).
Esto no es un secreto interno de Microsoft, incluso existen implementaciones de terceros, por ejemplo: enlace (aunque este enlace lo exagera un poco, al afirmar que se trata de un hack): con esto no está pirateando el protocolo AD o LDAP, está otorgando un privilegio de AD de forma manual que no está allí por defecto.
Un uso legítimo de este privilegio DS-Replication-Get-Changes-All es, por ejemplo, la sincronización de contraseña de Microsoft Asure AD: sincroniza las contraseñas de AD de su empresa con las contraseñas de la nube de Azure mediante la transferencia de hashes.
necesita un privilegio especial de LDAP asignado a una cuenta de AD para esto, que se llama "DS-Replication-Get-Changes-All" enlace
Diferenciación: el control DIRSYNC también se puede usar con otro privilegio ligeramente diferente llamado "DS-Replication-Get-Changes" (sin el "-Todo" al final). El privilegio sin "-todos" al final no puede extraer datos de hash de contraseña confidenciales (hay productos comerciales de sincronización de datos de directorio, como Microsoft MIIS / ILM / FIM / MIM que dependen de ese privilegio. También controladores de dominio de tipo READONLY para uso de DMZ el privilegio sin el "-Todo")
Las instalaciones de DLL de filtro de contraseña o PCNS en los controladores de dominio no usan estos dos privilegios y tampoco otorgan acceso a los hashes de AD almacenados. Solo permiten reenviar una contraseña (en el momento en que el usuario la cambia) a un destino de procesamiento externo que luego establecerá la misma contraseña en sistemas de terceros dentro de su empresa.
Si bien una DLL / PCNS de filtro de contraseña solo podrá sincronizar las contraseñas que el usuario cambia después de que se haya implementado la solución de PCNS / filtro, la Reubicación junto con DS-Replication-Get-Changes-All también se puede sincronizar Hash de contraseñas de AD que han estado allí antes de que se implementara la solución de sincronización.
Ni los dos privilegios son malos.
Por supuesto, podría ser altamente problemático, si se usa descuidadamente. Pero lo mismo ocurre con los cambios de ACL descuidados en su AD, que le otorgan un acceso remoto extensivo a su AD, permitiendo a los administradores de dominios y esquemas a cualquier persona, etc.
Es una puerta abierta, si la abres. Si no lo necesitas, no abras esa puerta. Y si abre esa puerta, entonces endurezca adecuadamente, de modo que solo el huésped planificado pueda entrar por esa puerta para tocar sus preciosas piezas.
Por lo tanto, los casos comerciales habituales de este mecanismo de lectura-contraseña-hashes-from-AD son sincronizar los hashes AD con otros sistemas de autenticación legítimos o migrar los hashes AD de la empresa existentes a otro directorio de autenticación de terceros.
(En ambos casos, el otro sistema debe ser capaz de comprender los hashes para fines de autenticación)