Cum urmăriți și rezolvați un cont Active Directory blocat? Aflați ce are loc, cum să găsiți evenimente specifice și cum să analizați evenimentele.
Active Directory (AD) este un serviciu minunat. Vă puteți conecta de oriunde din rețea folosind același nume de utilizator și aceeași parolă. Nu ar putea fi mai ușor de atât – asta până când uitați să închideți o sesiune de desktop la distanță, sau până când un vierme se răspândește în rețea, sau până când uitați că executați o sarcină programată ca fiind contul dvs. de utilizator, sau… Ei bine, ați prins ideea. AD este un produs extrem de util; acesta este motivul pentru care rata sa de adoptare este atât de ridicată. Problema este atunci când un cont începe să se blocheze fără niciun motiv. Sau cel puțin așa credeți.
Politici de blocare a conturilor AD
Multe organizații au (sau ar trebui să aibă) politici de blocare a conturilor. Această politică este o măsură de securitate pentru a împiedica părțile neautorizate să încerce să ghicească parola în mod continuu sau să forțeze brutal o parolă. Politicile de blocare a conturilor sunt obișnuite în Active Directory și constau într-o abordare simplă de combatere a unei probleme majore de securitate. Încercați să introduceți o parolă greșită de un anumit număr de ori, iar contul este inutilizabil până când un administrator îl reactivează din nou manual. Intenția este adevărată, dar, în unele cazuri, implementarea nu este.
În unele situații, în special atunci când o parolă este schimbată, un cont poate începe brusc să fie blocat în mod constant fără un motiv aparent. Un utilizator sună la biroul de asistență, biroul de asistență reactivează contul și, puțin mai târziu, contul este blocat din nou. Este o experiență frustrantă atât pentru utilizator, cât și pentru biroul de asistență. Uneori, problema este exacerbată de originea necunoscută a blocajelor. Undeva, cumva, există o persoană, un script sau un proces care încearcă continuu aceeași parolă greșită la nesfârșit, dar nimeni nu știe unde.
Atunci cum depistați aceste blocaje enervante? O modalitate este prin utilizarea unui script PowerShell. Dar mai întâi, haideți să trecem în revistă ce se întâmplă când un cont este blocat.
Resolvarea unui cont AD blocat
Într-un mediu Windows Server 2008 sau ulterior, există un scurt du-te-vino între sistemul client, controlerul de domeniu al sistemului client și controlerul de domeniu care deține rolul de emulator al Controlerului primar de domeniu (PDC). Acest lucru se întâmplă după cum urmează:
- De fiecare dată când se încearcă autentificarea unui cont de utilizator, acreditările sunt trimise până la controlerul de domeniu corespunzător pentru subrețeaua sistemului client.
- Dacă parola este greșită, controlerul de domeniu al sistemului client transmite cererea către controlerul de domeniu care deține rolul de emulator PDC. Acest lucru se datorează faptului că este posibil ca controlorul de domeniu al sistemului client să nu aibă cea mai recentă parolă și, ca o caracteristică de proiectare a Active Directory, controlorul de domeniu care deține rolul de emulator PDC o va avea întotdeauna.
- Emulatorul PDC încearcă din nou parola și, dacă se constată în continuare că este greșită, emulatorul PDC incrementează atributul badPwdCount pe contul de utilizator.
- Se generează un eveniment ID 4740 pe emulatorul PDC cu adresa IP a sistemului client care a inițiat cererea inițială și cu contul de utilizator.
- Emulatorul PDC informează apoi controlerul de domeniu al sistemului client că parola este, de fapt, greșită.
- Controlerul de domeniu al sistemului client notifică apoi sistemul client că parola a fost greșită.
Unde ar fi cel mai bun loc pentru a găsi sursa? Răspunsul este la emulatorul PDC. Motivul este acela că fiecare blocare de cont este înregistrată acolo în jurnalul evenimentelor de securitate. Emulatorul PDC este un loc central care poate fi interogat pentru toate evenimentele de blocare a conturilor.
Utilizarea PowerShell pentru a depista sursa blocărilor de conturi AD
Pentru a interoga emulatorul PDC, vom folosi cmdlet Get-WinEvent de la PowerShell. Acesta este un cmdlet extrem de util pentru analizarea rapidă a unuia sau mai multor jurnale de evenimente de pe un server. Căutăm un ID de eveniment de 4740. În primul rând, trebuie să găsim controlerul de domeniu care deține rolul de emulator PDC. O modalitate de a face acest lucru este utilizarea cmdletului Get-AdDomain.
După ce cunoaștem emulatorul PDC, atunci este doar o chestiune de interogare a jurnalului său de evenimente de securitate pentru ID-ul de eveniment 4740.
Am un cont numit abertram care este blocat. Să vedem cum să depistăm vinovatul.
Acum avem emulatorul PDC, așa că haideți să interogăm jurnalul său de securitate cu un script PowerShell.
## Definiți numele de utilizator care este blocat
$Username = ‘abertram’
## Găsiți rolul PDCe al controlorului de domeniu
$Pdce = (Get-AdDomain).PDCEmulator
## Construiți parametrii care se transmit la Get-WinEvent
$GweParams = @{
‘Computername’ = $Pdce
‘LogName’ = ‘Security’
‘FilterXPath’ = „* and EventData=’$Username’]]”
}
## Interoghează jurnalul evenimentelor de securitate
$Events = Get-WinEvent @GweParams
Aceasta ne oferă evenimentul de blocare.
Dar nu avem încă sistemul client de origine. Pentru a-l obține, va trebui să săpăm un pic mai adânc. Numele de utilizator real este îngropat în valoarea Properties a fiecărui eveniment. Pentru a găsi numele de utilizator în fiecare eveniment, putem folosi pur și simplu această linie.
$Events.Properties.Value
Aceasta găsește numele de utilizator în primul eveniment și în prima instanță a valorii Properties. Din fericire, sistemul client se află doar în a doua instanță a valorii Properties.
$Events.Properties.Value
După ce știți unde se află numele sistemului client, este doar o chestiune de inserare într-o buclă, și am găsit vinovatul.
Acum sunteți înarmat și gata de acțiune data viitoare când biroul de asistență vă sună cu acel cont de utilizator AD neîncetat care se tot blochează.
.