Come rintracciare e risolvere un account Active Directory bloccato? Scopri cosa succede, come trovare eventi specifici e come analizzare gli eventi.
Active Directory (AD) è un servizio meraviglioso. Puoi accedere da qualsiasi punto della rete usando lo stesso nome utente e la stessa password. Non potrebbe essere più facile — cioè, fino a quando non dimentichi di chiudere una sessione di desktop remoto, o un worm si diffonde nella rete, o dimentichi che stai eseguendo un’attività pianificata come tuo account utente, o… Beh, avete capito bene. AD è un prodotto estremamente utile; questo è il motivo per cui il suo tasso di adozione è così alto. Il problema è quando un account comincia a bloccarsi senza alcun motivo. O così si pensa.
Politiche di blocco degli account AD
Molte organizzazioni hanno (o dovrebbero avere) politiche di blocco degli account. Questa politica è una misura di sicurezza per evitare che parti non autorizzate provino a indovinare la password continuamente o a forzare una password. Le politiche di blocco degli account sono comuni in Active Directory e consistono in un approccio semplice per combattere un importante problema di sicurezza. Tenta la password sbagliata un certo numero di volte, e l’account è inutilizzabile fino a quando un amministratore non lo riabilita manualmente. L’intenzione è vera, ma in alcuni casi, l’implementazione non lo è.
In alcune situazioni, specialmente quando una password viene cambiata, un account può improvvisamente iniziare ad essere bloccato costantemente senza alcuna ragione apparente. Un utente chiama l’help desk, l’help desk riabilita l’account, e poco dopo, l’account viene nuovamente bloccato. È un’esperienza frustrante sia per l’utente che per l’help desk. A volte il problema è esacerbato dall’origine sconosciuta dei blocchi. Da qualche parte, in qualche modo c’è una persona, uno script o un processo che prova continuamente la stessa password sbagliata, ma nessuno sa dove.
Come si fa a rintracciare questi fastidiosi blocchi? Un modo è usare uno script PowerShell. Ma prima, vediamo cosa succede quando un account è bloccato.
Risolvere un account AD bloccato
In un ambiente Windows Server 2008 o successivo, c’è un breve avanti e indietro tra il sistema client, il controller di dominio del sistema client e il controller di dominio che detiene il ruolo di emulatore del Primary Domain Controller (PDC). Questo avviene come segue:
- Ogni volta che viene tentata l’autenticazione di un account utente, le credenziali vengono inviate al controller di dominio appropriato per la sottorete del sistema client.
- Se la password è sbagliata, il controller di dominio del sistema client inoltra la richiesta al controller di dominio con il ruolo di emulatore PDC. Questo perché il controller di dominio del sistema client potrebbe non avere la password più recente, e come caratteristica di progettazione di Active Directory, il controller di dominio con il ruolo di emulatore PDC lo avrà sempre.
- L’emulatore PDC prova di nuovo la password, e se è ancora trovata sbagliata, l’emulatore PDC incrementa l’attributo badPwdCount sull’account utente.
- Un evento ID 4740 è generato sull’emulatore PDC con l’indirizzo IP del sistema client che ha iniziato la richiesta originale e con l’account utente.
- L’emulatore PDC informa quindi il controller di dominio del sistema client che la password è, in effetti, sbagliata.
- Il controller di dominio del sistema client notifica quindi al sistema client che la password era sbagliata.
Dove sarebbe il posto migliore per trovare la fonte? La risposta è nell’emulatore PDC. La ragione è che ogni blocco dell’account è registrato lì nel registro degli eventi di sicurezza. L’emulatore PDC è un luogo centrale che può essere interrogato per tutti gli eventi di blocco dell’account.
Usare PowerShell per rintracciare la fonte dei blocchi degli account AD
Per interrogare l’emulatore PDC, useremo il cmdlet Get-WinEvent di PowerShell. Questo è un cmdlet estremamente utile per analizzare rapidamente uno o più registri di eventi su un server. Stiamo cercando un ID evento di 4740. Per prima cosa, dobbiamo trovare il controller di dominio che detiene il ruolo di emulatore PDC. Un modo per farlo è usare il cmdlet Get-AdDomain.
Una volta che conosciamo l’emulatore PDC, allora è solo una questione di interrogare il suo registro eventi di sicurezza per l’ID evento 4740.
Ho un account chiamato abertram che è bloccato fuori. Vediamo come rintracciare il colpevole.
Ora abbiamo l’emulatore PDC, quindi interroghiamo il suo log di sicurezza con uno script PowerShell.
### Definire il nome utente che è bloccato
$Username = ‘abertram’
## trovare il controller di dominio PDCe il ruolo
$Pdce = (Get-AdDomain).PDCEmulator
## Costruisci i parametri da passare a Get-WinEvent
$GweParams = @{
‘Computername’ = $Pdce
‘LogName’ = ‘Security’
‘FilterXPath’ = “* and EventData=’$Username’]]”}
## Interroga il registro eventi di sicurezza
$Events = Get-WinEvent @GweParams
Questo ci dà l’evento di blocco.
Ma non abbiamo ancora il sistema client di origine. Per ottenerlo, dovremo scavare un po’ più a fondo. Il nome utente effettivo è sepolto nel valore delle proprietà di ogni evento. Per trovare il nome utente in ogni evento, possiamo semplicemente usare questa linea.
$Events.Properties.Value
Questo trova il nome utente nel primo evento e nella prima istanza del valore Properties. Fortunatamente, il sistema client è solo nella seconda istanza di Properties.
$Events.Properties.Value
Una volta che sapete dove si trova il nome del sistema client, è solo questione di inserirlo in un ciclo, e abbiamo trovato il colpevole.
Ora sei armato e pronto a partire la prossima volta che l’help desk ti chiama per quell’incessante account utente AD che continua ad essere bloccato.