Jak śledzić i rozwiązać problem blokady konta Active Directory? Dowiedz się, co się dzieje, jak znaleźć konkretne zdarzenia i jak analizować zdarzenia.
Active Directory (AD) to wspaniała usługa. Możesz zalogować się z dowolnego miejsca w sieci, używając tej samej nazwy użytkownika i hasła. Nie mogłoby być łatwiej — to znaczy, dopóki nie zapomnisz zamknąć sesji zdalnego pulpitu, albo robak nie rozprzestrzeni się w sieci, albo nie zapomnisz, że uruchamiasz zaplanowane zadanie jako swoje konto użytkownika, albo… Cóż, rozumiecie o co chodzi. AD jest niezwykle użytecznym produktem; dlatego właśnie jego adopcja jest tak wysoka. Problem pojawia się, gdy konto zaczyna się blokować bez żadnego powodu. Albo tak Ci się wydaje.
Polityka blokowania kont AD
Wiele organizacji ma (lub powinno mieć) politykę blokowania kont. Polityka ta jest środkiem bezpieczeństwa zapobiegającym próbom odgadnięcia hasła przez osoby nieupoważnione lub wymuszenia hasła metodą brute force. Zasady blokowania kont są powszechnie stosowane w Active Directory i polegają na prostym podejściu do walki z poważnym problemem bezpieczeństwa. Po kilkukrotnej próbie podania błędnego hasła konto staje się bezużyteczne do czasu, aż administrator ręcznie je ponownie włączy. Intencja jest prawdziwa, ale w niektórych przypadkach, wdrożenie nie jest.
W niektórych sytuacjach, zwłaszcza gdy hasło jest zmienione, konto może nagle zacząć się coraz zablokowany konsekwentnie bez wyraźnego powodu. Użytkownik dzwoni do działu pomocy technicznej, dział pomocy technicznej ponownie włącza konto, a chwilę później, konto jest ponownie zablokowane. Jest to frustrujące doświadczenie zarówno dla użytkownika, jak i działu pomocy technicznej. Czasami problem pogłębia się z powodu nieznanego pochodzenia blokad. Gdzieś, w jakiś sposób jest osoba, skrypt, lub proces nieustannie próbuje tego samego błędnego hasła w kółko, ale nikt nie wie gdzie.
Jak więc wytropić te irytujące blokady? Jednym ze sposobów jest użycie skryptu PowerShell. Ale najpierw przejdźmy do tego, co się dzieje, gdy konto jest zablokowane.
Resolving A Locked AD Account
W środowisku Windows Server 2008 lub nowszym, istnieje krótkie tam i z powrotem pomiędzy systemem klienta, kontrolerem domeny systemu klienta, a kontrolerem domeny posiadającym rolę emulatora Primary Domain Controller (PDC). Odbywa się to w następujący sposób:
- Gdy uwierzytelnienie konta użytkownika jest próbowane, dane uwierzytelniające są wysyłane do odpowiedniego kontrolera domeny dla podsieci systemu klienckiego.
- Jeśli hasło jest nieprawidłowe, kontroler domeny systemu klienckiego przekazuje żądanie do kontrolera domeny pełniącego rolę emulatora PDC. Jest to spowodowane tym, że kontroler domeny systemu klienta może nie mieć najbardziej aktualnego hasła, a jako cecha projektowa Active Directory, kontroler domeny posiadający rolę emulatora PDC zawsze będzie.
- Emulator PDC próbuje ponownie hasło, a jeśli nadal jest ono błędne, emulator PDC zwiększa atrybut badPwdCount na koncie użytkownika.
- Na emulatorze PDC generowane jest zdarzenie o identyfikatorze 4740 z adresem IP systemu klienta, który zainicjował oryginalne żądanie, oraz z kontem użytkownika.
- Emulator PDC informuje następnie kontroler domeny systemu klienckiego, że hasło jest w rzeczywistości nieprawidłowe.
- Kontroler domeny systemu klienckiego powiadamia następnie system kliencki, że hasło było nieprawidłowe.
Gdzie najlepiej byłoby znaleźć źródło? Odpowiedź brzmi: w emulatorze PDC. Powodem tego jest fakt, że każda blokada konta jest tam rejestrowana w dzienniku zdarzeń bezpieczeństwa. Emulator PDC jest centralnym miejscem, które można odpytywać o wszystkie zdarzenia blokady konta.
Using PowerShell To Track Down The Source Of AD Account Lockouts
Aby odpytywać emulator PDC, użyjemy cmdleta Get-WinEvent programu PowerShell. Jest to bardzo przydatny cmdlet do szybkiego przeglądania jednego lub więcej dzienników zdarzeń na serwerze. Szukamy zdarzenia o numerze ID 4740. Po pierwsze, musimy znaleźć kontroler domeny, który posiada rolę emulatora PDC. Jednym ze sposobów jest użycie polecenia cmdlet Get-AdDomain.
Gdy znamy już emulator PDC, wystarczy zapytać jego dziennik zdarzeń zabezpieczeń o identyfikator zdarzenia 4740.
Mam konto o nazwie abertram, które jest zablokowane. Zobaczmy, jak namierzyć winowajcę.
Mamy teraz emulator PDC, więc przepytajmy jego dziennik zabezpieczeń za pomocą skryptu PowerShell.
## Zdefiniuj nazwę użytkownika, który jest zablokowany
$Username = 'abertram’
## Znajdź rolę PDCe kontrolera domeny
$Pdce = (Get-AdDomain).PDCEmulator
## Zbuduj parametry, które przekażesz do Get-WinEvent
$GweParams = @{
’Computername’ = $Pdce
’LogName’ = 'Security’
’FilterXPath’ = „* and EventData=’$Username’]]”
}
## Przepytaj dziennik zdarzeń bezpieczeństwa
$Events = Get-.WinEvent @GweParams
W ten sposób otrzymamy zdarzenie blokady.
Ale nie mamy jeszcze systemu klienta inicjującego. Aby to uzyskać, będziemy musieli kopać trochę głębiej. Rzeczywista nazwa użytkownika jest ukryta w wartości Properties każdego zdarzenia. Aby znaleźć nazwę użytkownika w każdym zdarzeniu, możemy po prostu użyć tej linii.
$Events.Properties.Value
To znajduje nazwę użytkownika w pierwszym zdarzeniu i w pierwszej instancji wartości Properties. Na szczęście system klienta znajduje się właśnie w drugiej instancji Properties.
$Events.Properties.Value
Gdy już wiesz, gdzie znajduje się nazwa systemu klienta, wystarczy wstawić ją do pętli i znaleźliśmy winowajcę.
Teraz jesteś uzbrojony i gotowy do działania, gdy następnym razem biuro pomocy technicznej zadzwoni do Ciebie z problemem konta użytkownika AD, które ciągle się blokuje.
.