Solución:
No es necesario procesar el archivo DIT para adquirir hashes de AD o AD LDS, también hay algunos protocolos de acceso.
Aunque una lectura LDAP regular en el atributo “userpassword” (como puede hacer en otros productos de directorio) siempre se bloqueará completamente en AD, hay otra forma oficial de leer hashes de AD o AD LDS y oficialmente ha estado allí desde en al menos Server 2003. Debe utilizar un permiso de acceso de AD especial (DS-Replication-Get-Changes-All) y un protocolo de Microsoft documentado oficialmente (el protocolo de replicación de AD). Esto no es un secreto interno de Microsoft, incluso existen implementaciones de terceros, por ejemplo: https://www.dsinternals.com/en/retrieving-active-directory-passwords-remotely/ (aunque este enlace lo exagera un poco, al afirmar esto para ser un truco): no está pirateando el protocolo AD o LDAP con esto, está otorgando manualmente un privilegio AD de antemano que no está allí de forma predeterminada.
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 transfiriendo los hash. necesita un privilegio LDAP especial asignado a una cuenta de AD para esto, que se llama “DS-Replication-Get-Changes-All” https://msdn.microsoft.com/en-us/library/windows/desktop/ms684355 ( v = frente a 85) .aspx
Diferenciación: El control DIRSYNC también se puede usar con otro privilegio ligeramente diferente llamado “DS-Replication-Get-Changes” (sin el “-All” al final). El privilegio sin “-All” al final no puede extraer datos confidenciales de hash de contraseñas (hay productos comerciales de sincronización de datos de directorios, 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 “-Todos”)
Las instalaciones de DLL de filtro de contraseña o PCNS en controladores de dominio no usan estos dos privilegios y tampoco otorgan acceso a hashes de AD almacenados. Solo permiten reenviar una contraseña (en el momento en que el usuario la cambia) a algún objetivo 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 cambie después de que se haya implementado la solución de filtro / PCNS, Relication junto con DS-Replication-Get-Changes-All también pueden sincronizar los hashes de contraseñas de AD. que han estado allí antes de que se implementara la solución de sincronización.
Ninguno de los dos privilegios es malo. Por supuesto, podría ser muy problemático si se usa de manera descuidada. Pero lo mismo ocurre con los cambios de ACL descuidados en su AD, otorgando un amplio acceso remoto a su AD, permitiendo administradores de dominios y esquemas a cualquiera y así sucesivamente … Es una puerta abierta, si la abre. Si no lo necesita, no abra esa puerta. Y si abre esa puerta, luego endurezca correctamente, de modo que solo el huésped planeado pueda entrar por esa puerta para tocar sus partes preciosas.
Por lo tanto, los casos comerciales habituales de este mecanismo de lectura-contraseña-hashes-de-AD es sincronizar los hashes de AD con otros sistemas de autenticación legítimos o migrar los hashes de AD existentes de la empresa a otro directorio de autenticación de terceros. (Sin embargo, en ambos casos, el otro sistema debe poder comprender los hash con fines de autenticación)
Necesitas conseguir el NTDS.DIT archivo binario de %SystemRoot%ntds.
Puedes usar ntdsutil para crear una instantánea de la base de datos de AD para que pueda copiar NTDS.DIT.
Luego, puede usar algo como la herramienta de recuperación de contraseña de Windows para extraer los hash.
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
Entonces, todo este razonamiento es una locura. Auditar la corrección de la contraseña después del hecho es una mala idea (porque necesita la contraseña original o un hash débil que pueda ser efectivamente una tabla de arco iris), y escribir servicios o herramientas para extraer los hash débiles es propenso a errores graves o peligros. Y lo que es menos importante, es una exageración y una pérdida de ciclos y recursos.
La mejor solución es simplemente usar un filtro de contraseña y verificar que los cambios de contraseña cumplan con los requisitos mínimos antes de permitir que el usuario realice el cambio. Luego, expire todas las contraseñas si realmente quiere garantizar la complejidad (aunque eso podría molestar a algunas personas).