Come posso rilevare gli utenti che hanno richiesto ad amministratori AD di riutilizzare una password scaduta?

Esistono più modi per configurare il controllo in Criteri di gruppo, ma ritengo che il vecchio metodo primario (su Windows Server 2003) sia l'apertura di GPMC, la modifica del criterio di dominio predefinito (o qualsiasi criterio di dominio attivo nell'unità organizzativa e oggetti con cui si sta lavorando) e drill down dal nodo Politiche tramite Impostazioni di Windows a Impostazioni di sicurezza, per aprire il ramo Criterio di politica di controllo delle politiche locali. Esiste una sezione "Gestione account di controllo" che puoi definire.

Quanto sopra ti consente solo di controllare le modifiche all'account, ma devi renderlo praticabile riportandolo ai criteri di successo, come la password di un utente scaduta recentemente. Sfruttando OSSIM (o un altro motore di correlazione strong), è possibile combinare gli script ADSI che controllano tutti i messaggi di gestione degli account di verifica per vedere se si trattava di una modifica della password e per vedere se la password è scaduta di recente. Quindi, gli hash potrebbero essere abbinati, ecc. Anche OpenVAS potrebbe essere avviato per provare a bruteforce la password, anche se sarebbe probabilmente meglio eseguire questa attività con più dati.

Questo diventa un esercizio di personalizzazione per client / server e altri strumenti di protezione / monitoraggio dell'infrastruttura. Vorresti spostare la maturità dell'intera infrastruttura a un livello superiore, quindi presumo che tu abbia già svolto gran parte del lavoro prescritto dal Centro per la sicurezza di Internet (CIS) e / o NIST .

Se sei più greenfield e non hai implementato soluzioni personalizzate come questa in passato, sarebbe sicuramente meglio passare a una soluzione a prova di futuro come OpenIDM di ForgeRock. Questo sarebbe un progetto da diversi milioni di dollari, sei anni o giù di lì.

Se ti trovi in una grande installazione in aree dismesse, come ad esempio Fortune 500, sarebbe meglio identificare il tuo esistente IAM, IDM, Directory, ESB e altri componenti del backoffice al fine di analizzare correttamente dove inserire l'identità problemi di gestione del ciclo di vita come le reimpostazioni della password utente. È possibile che un fornitore di soluzioni esistente, come SAP, Oracle, TIBCO o Microsoft, abbia una risposta facile.

Se sei solo un negozio Microsoft (100%), allora probabilmente vorrai discutere dei loro ILM 2007 prodotto, FIM 2010 e relative soluzioni. Microsoft ha un brutto modo di cancellare queste linee di prodotti, o di cambiarle drasticamente - quindi è bello essere alla moda nella "traccia interna" e discutere direttamente con ILM / FIM e altri product manager (PM) invece di un semplice account manager (AM) o dei loro siti Web e informazioni commerciali.

Esistono altre soluzioni in più punti come ChangeAuditor for AD del software Quest, ma vorrei fai attenzione a risolvere solo un problema a breve termine, quando possono esistere chiaramente un processo aziendale e un enorme insieme di problemi di maturità commerciale / infrastrutturale.

forse la risposta qui non è solo la tecnologia ma anche il processo. Questa cortesia, non dovrebbe essere fatta, le azioni degli amministratori dovrebbero essere controllate e gli amministratori che lo fanno dovrebbero essere puniti. A meno che non sia conforme alla politica di sicurezza (se ne hai uno)

A livello tecnico, il problema fondamentale qui è che l'help desk può reimpostare la password e lasciare la casella di controllo "l'utente deve cambiare password" deselezionata.

Non conosco un modo per forzare lasciando selezionata questa casella. Ce ne potrebbe essere uno, ma non so come.

Un modo per aggirare questo potrebbe non essere quello di fornire al personale dell'help desk l'accesso delegato a utenti e computer AD, ma invece di creare uno script che utilizzi LDAP per reimpostare la password e imposta il flag "l'utente deve cambiare la password al successivo accesso" a lo stesso tempo. Puoi rendere questo script ancora più comodo (per l'help desk): generare automaticamente una password breve e semplice come password temporanea, quindi inviarlo via email (o consegnarlo) all'utente.

Detto questo: in definitiva, questo non è un problema tecnico. Con l'enorme numero di password anche se gli utenti non tecnici hanno a che fare con oggi, sento completamente il loro dolore. Alcuni addetti alla sicurezza hanno reso il caso più lungo, ma le password facili da memorizzare raramente o mai modificate potrebbero effettivamente essere migliori.

Spesso, anche senza gli "estensioni di cortesia" gli utenti sconfiggono il meccanismo di modifica della password usando sempre la stessa password semplice e breve con un contatore aggiunto e condividendo la stessa password tra sistemi vulnerabili e sistemi sensibili. Oppure lamentandoti con il top management e cambiando la politica in "non cambiare mai le password".

Quindi la tua strategia migliore è quella di affrontare questo problema al massimo livello di gestione. Se il top management non supporta la risoluzione di questo problema, i tuoi tentativi di affrontarlo a livello tecnico possono ritorcersi contro. E se il top management è favorevole a risolvere questo problema, potresti non aver bisogno di una soluzione tecnica; il personale dell'help desk otterrà semplicemente una nuova politica che proibisce specificamente tali azioni di cortesia.