Dove posso archiviare i dati sensibili in Active Directory?

Sto essenzialmente archiviando una chiave privata (hash) in uno degli attributi OctetString in Active Directory.

La mia domanda è: quale attributo è protetto per impostazione predefinita e ha senso mantenere lì i dati privati? Questo valore deve essere considerato simile a una password, in cui anche gli amministratori non dovrebbero avere accesso (se possibile), proprio come la password AD corrente.

Ecco un elenco di attributi abilitati per impostazione predefinita su un dominio Windows 2008 R2 + Exchange 2010.

Aggiornare:

Qualcuno è a conoscenza di un attributo Octet String che non espone le autorizzazioni di "lettura" per impostazione predefinita a tutti gli utenti nel dominio? Non voglio archiviare pubblicamente il mio hash e consentire a qualcuno di costruire una tabella arcobaleno basata sugli hash.

Il problema che molte persone affrontano quando si archiviano i dati in AD è

• Estensione dello schema (che spesso ha implicazioni politico-aziendali)

• Utilizzo di un attributo esistente e modifica delle autorizzazioni (che risulta in un gonfiamento AD / ACL che aumenta il DIT e le dimensioni della replica successiva)

C'è un'alternativa ... la scelta migliore nella mia mente è quella di utilizzare questa caratteristica meno conosciuta di AD per prendere un attributo esistente e contrassegnarlo come Riservato.

Ecco i dettagli sul processo

Le autorizzazioni predefinite in Active Directory sono tali che gli Utenti autenticati hanno un accesso in lettura a tutti gli attributi. Ciò rende difficile introdurre un nuovo attributo che dovrebbe essere protetto dalla lettura da parte di tutti.

Per mitigare ciò, Windows 2003 SP1 introduce un modo per contrassegnare un attributo come RISERVATO. Questa funzionalità è stata ottenuta modificando il valore searchFlags sull'attributo nello schema. SearchFlags contiene più bit che rappresentano varie proprietà di un attributo. Ad esempio, il bit 1 indica che l'attributo è indicizzato. Il nuovo bit 128 (7 ° bit) designa l'attributo come confidenziale.

Nota: non è possibile impostare questo flag sugli attributi dello schema di base (quelli derivati ​​da "top" come common-name). È possibile determinare se un oggetto è un oggetto schema di base utilizzando LDP per visualizzare l'oggetto e controllare l'attributo systemFlags dell'oggetto. Se è impostato il decimo bit, si tratta di un oggetto schema di base.

Quando il servizio di directory esegue un controllo di accesso in lettura, verifica la presenza di attributi riservati. Se ci sono, oltre all'accesso READ_PROPERTY, il servizio directory richiederà anche l'accesso CONTROL_ACCESS sull'attributo o sul suo set di proprietà.

Per impostazione predefinita, solo gli amministratori hanno accesso CONTROL_ACCESS a tutti gli oggetti. Pertanto, solo gli amministratori saranno in grado di leggere gli attributi riservati. Gli utenti sono liberi di delegare questo diritto a qualsiasi gruppo specifico che desiderano. Questo può essere fatto con lo strumento DSACL, gli script o la versione ADAM R2 di LDP. Al momento della stesura di questo documento non è possibile utilizzare ACL UI Editor per assegnare queste autorizzazioni.

Il processo di contrassegnare un attributo Riservato e aggiungere gli utenti che devono visualizzare l'attributo prevede 3 Passaggi

1. Determinazione dell'attributo da contrassegnare come riservato o aggiunta di un attributo da contrassegnare come riservato.

2. Contrassegnandolo come riservato

3. Concedere agli utenti corretti il ​​diritto Control_Access in modo che possano visualizzare l'attributo.

Per maggiori dettagli e istruzioni dettagliate, consultare il seguente articolo:

922836 Come contrassegnare un attributo come confidenziale in Windows Server 2003 Service Pack 1

http://support.microsoft.com/default.aspx?scid=kb;EN-US;922836

A questo scopo è sempre possibile estendere Active Directory con un nuovo campo.

Ecco un documento che include le istruzioni per aggiungere un nuovo attributo e limitare le autorizzazioni per l'attributo.

Questo valore deve essere considerato simile a una password, in cui anche gli amministratori non dovrebbero avere accesso (se possibile), proprio come la password AD corrente.

Questo non è corretto, non è nemmeno sbagliato. La password non è memorizzata L'hash viene archiviato e gli amministratori di dominio possono accedervi. In effetti, puoi anche configurare AD per archiviare la password in una crittografia reversibile se lo desideri.

Non c'è nulla da cui sia possibile tenere fuori gli amministratori di dominio in AD. Se si rimuovono i diritti o si nega, un amministratore di dominio può diventare proprietario e ricollegarsi. Questo è in contrasto con l'NDS di Novell, in cui un amministratore di un'unità organizzativa potrebbe bloccare irrevocabilmente amministratori di livello superiore.

Il meglio che puoi fare è utilizzare un attributo esistente o nuovo e limitare l'accesso. È possibile tenere fuori gli amministratori e abilitare il controllo sull'attributo in modo da registrare qualsiasi modifica di accesso o autorizzazioni.