Non è necessario elaborare il file DIT per acquisire gli hash da AD o AD LDS, esiste anche l'accesso al protocollo.
Anche se un normale LDAP-legge sull'attributo "userpassword" (come è possibile fare su altri prodotti di directory) sarà sempre bloccato completamente in AD,
c'è un altro modo ufficiale per leggere gli hash da AD o AD LDS ed è ufficialmente presente da almeno Server 2003. È necessario utilizzare una speciale autorizzazione di accesso AD (DS-Replication-Get-Changes-All) e un protocollo Microsoft documentato ufficialmente (il protocollo di replica AD).
Questo non è un segreto interno di Microsoft, esistono anche implementazioni di terze parti, ad esempio: link (anche se questo collegamento lo stravolge un po ', sostenendo che si tratta di un hack) - Non stai hackerando il protocollo AD o LDAP con questo, stai concedendo manualmente un privilegio AD in anticipo che non è lì per impostazione predefinita.
Un uso legittimo di questo privilegio DS-Replication-Get-Changes-All è ad es. la sincronizzazione delle password di Microsoft Asure AD: sincronizza le password di AD dell'azienda con le password del cloud di Azure trasferendo gli hash.
è necessario uno speciale privilegio LDAP assegnato a un account AD per questo, che viene chiamato "DS-Replication-Get-Changes-All" link
Differenciation: il controllo DIRSYNC può anche essere usato con un altro privilegio leggermente diverso chiamato "DS-Replication-Get-Changes" (senza "-All" alla fine). Il privilegio senza "-All" alla fine non può estrarre dati sensibili sull'hash della password (esistono prodotti di sincronizzazione dei dati di directory commerciali, come Microsoft MIIS / ILM / FIM / MIM che si basano su tale privilegio.) Anche i controller di dominio di tipo READONLY per l'utilizzo DMZ il privilegio senza "-All")
Le DLL del filtro password o le installazioni PCNS sui controller di dominio non utilizzano questi due privilegi e non concedono l'accesso agli hash AD memorizzati. Permettono solo di inoltrare una password (nel momento in cui viene modificata dall'utente) a un target di elaborazione esterno che imposterà la stessa password su sistemi di terze parti all'interno dell'azienda.
Mentre un filtro password DLL / PCNS sarà in grado di sincronizzare solo le password modificate dall'utente dopo che la soluzione filtro / PCNS è stata distribuita, la Relication insieme a DS-Replication-Get-Changes-All può anche essere sincronizzata Gli hash delle password AD che sono stati lì prima della distribuzione della soluzione di sincronizzazione.
Né i due privilegi sono malvagi.
Potrebbe naturalmente essere molto problematico, se usato con noncuranza. Ma lo stesso vale per le modifiche negligenti di ACL nel tuo annuncio, garantendo un accesso remoto completo al tuo annuncio pubblicitario, consentendo agli amministratori di domini e schemi a chiunque e così via ......
È una porta aperta, se la apri. Non ne hai bisogno, non aprire quella porta. E se apri quella porta, indurila correttamente, in modo che solo l'ospite pianificato possa entrare in quella porta per toccare le tue parti preziose.
Quindi, i normali casi aziendali di questo meccanismo read-password-hashes-from-AD consistono nel sincronizzare gli hash degli AD con altri sistemi di autenticazione legittimi o nella migrazione degli hash degli AD dell'azienda in un'altra directory di autenticazione di terze parti.
(In entrambi i casi, l'altro sistema deve essere in grado di comprendere gli hash a scopo di autenticazione)