В тази статия описваме как проследяване на събития за заключване потребителски акаунти в контролерите на домейни Active Directory, определете от кой компютър и от коя конкретна програма Извършва се постоянно блокиране. Помислете да използвате скриптове за сигурност на Windows и PowerShell, за да намерите източника на блокиране.
Политиките за сигурност на акаунта в повечето организации изискват потребителският акаунт в домейна на Active Directory да бъде заключен, ако потребителят зададе паролата неправилно n пъти. Обикновено акаунтът се блокира от контролера на домейна след няколко опита за въвеждане на грешна парола за няколко минути (5-30), по време на които потребителят няма право да влиза в системата. Чрез определяне на времето, посочено в политиките за сигурност, акаунтът в домейна автоматично се отключва. Временното блокиране на акаунта намалява риска от отгатване на паролата (с обикновена груба сила) на потребителските акаунти на AD.
В случай че потребителският акаунт в домейна е блокиран, се появява предупреждение, когато се опитвате да влезете в Windows:
Потребителският акаунт е заключен и не може да се използва за влизане. Реферираният акаунт в момента е заключен и може да не е влязъл в ... .
Съдържание:
- Правила за блокиране на домейн акаунта
- Потърсете компютъра, от който е заключен акаунта
- Разкриваме програмата, причината за блокирането на акаунта в AD
Правила за блокиране на домейн акаунта
Политиките за блокиране на акаунти и пароли обикновено се задават веднага за целия домейн чрез политика Политика по домейни по подразбиране. Политиките, които ни интересуват, са в раздела Конфигурация на компютъра -> Настройки на Windows -> Настройки за защита -> Политика на акаунта -> Политика за блокиране на акаунта (Конфигурация Windows -> Настройки за защита -> Политики за акаунти -> Политики за блокиране на акаунта). Това са правилата:
- Праг за блокиране на акаунта (Lock Threshold) - след колко неуспешни опита за парола, акаунтът трябва да бъде заключен
- сметка локаут продължителност (Продължителност на блокирането на акаунта) - за колко време ще бъде заключен акаунтът (след този период бравата ще се освободи автоматично)
- Reset сметка локаут брояч след (Време до нулиране на брояча за заключване) - след това време броячът на неуспешните опити за авторизация ще бъде нулиран
съвет. Можете ръчно да отключите акаунта си, без да чакате автоматично отключване, като използвате конзолата ADUC. За да направите това, в свойствата на потребителския акаунт в раздела Профил, поставяне на квадратчето за отметка Отключи акаунта Този акаунт в момента е заключен в този контролер на домейни на Active Directory.
Доста полезна информация за времето на блокиране, задаване на парола, броя на опитите за задаване на парола и др. Може да бъде получена в свойствата на акаунта в конзолата ADSIEdit или в допълнителния раздел Допълнителна информация за акаунта в потребителските свойства (по-лесно).
Ситуации, когато потребителят е забравил паролата си и сам е причинил блокирането на акаунта му, се случват доста често. Но в някои случаи блокирането на акаунта се случва неочаквано, без видима причина. Т.е. използва „кълне се“, че не е направил нещо специално, никога не е въвеждал погрешка парола, но по някаква причина акаунтът му е блокиран. Администраторът по искане на потребителя може ръчно да освободи ключалката, но след известно време ситуацията се повтаря.
За да разреши проблема с потребителя, администраторът трябва да разбере кой компютър и коя програма е блокиран потребителския акаунт в Active Directory.
Потърсете компютъра, от който е заключен акаунта
На първо място, администраторът трябва да разбере кой компютър / сървър се опитва да въведе неправилни пароли и акаунтът е допълнително блокиран.
В случай, че контролерът на домейна най-близо до потребителя определи, че потребителят се опитва да влезе с грешна парола, той пренасочва заявката за удостоверяване към DC с ролята на FSMO PDC емулатор (той отговаря за обработката на заключенията на акаунта). Ако удостоверяването не е извършено и на PDC, той отговаря на първия DC, че удостоверяването не е възможно.
В същото време събитията се записват в дневника на двата контролера на домейна 4740 с DNS име (IP адрес) на компютъра, от който идва първоначалната заявка за разрешение на потребителя. Логично е, че на първо място е необходимо да се проверят регистрационните файлове на защитата на PDC контролера. Можете да намерите PDC в домейн като този:
(Get-AdDomain) .PDCEмулатор
Събитието за блокиране на домейн акаунт може да се намери в дневника сигурност на контролера на домейна. Филтриране на журнала за сигурност по идентификационен номер на събитието 4740. Трябва да се появи списък на скорошни събития за блокиране на акаунта на контролера на домейна. Започвайки от самия връх, преминете през всички събития и намерете събитието, което показва, че акаунтът на желания потребител (името на акаунта е посочено в реда сметка име) заключен (Потребителски акаунт е заключен).
забележка. В продуктивна среда в голяма AD инфраструктура, в дневника за сигурност се записват голям брой събития, които постепенно се презаписват. Затова е препоръчително да увеличите максималния размер на лога на DC и да започнете да търсите източника на блокиране възможно най-рано.
Отворете това събитие В полето се посочва името на компютъра (или сървъра), от който е направено заключването посетител компютър име. В този случай името на компютъра е TS01.
Можете да използвате следния скрипт PowerShell, за да намерите източника на заключване на конкретен потребител в PDC. Този скрипт ще върне датата на заключване и компютъра, от който е възникнал:
$ Username = 'username1'
$ Pdce = (Get-AdDomain) .PDCEмулатор
$ GweParams = @
'Computername' = $ Pdce
'LogName' = 'Защита'
'FilterXPath' = "* [Система [EventID = 4740] и EventData [Данни [@ име = 'TargetUserName'] = '$ потребителско име']]"
$ Events = Get-WinEvent @GweParams
$ Събития | foreach $ _. Properties [1]. значение + "+ $ _. TimeCreate
По същия начин можете да питате всички контролери на домейни в Active Directory от PowerShell:
$ Username = 'username1'
Get-ADDomainController -fi * | изберете -exp име на хост | %
$ GweParams = @
'Име на компютъра' = $ _
'LogName' = 'Защита'
'FilterXPath' = "* [Система [EventID = 4740] и EventData [Данни [@ име = 'TargetUserName'] = '$ потребителско име']]"
$ Events = Get-WinEvent @GweParams
$ Събития | foreach $ _. Computer + "" + $ _. Properties [1] .value + "+ $ _. TimeCreate
Разкриваме програмата, причината за блокирането на акаунта в AD
И така, ние определихме от кой компютър или устройство е блокиран акаунтът. Сега бих искал да разбера коя програма или процес извършва неуспешни опити за влизане и е източник на блокиране.
Често потребителите започват да се оплакват от блокирането на акаунта си в домейна след планираната промяна на паролата на своя акаунт в домейна. Това предполага, че старата (неправилна) парола се съхранява в определена програма, скрипт или услуга, която периодично се опитва да влезе в домейна с остаряла парола. Помислете за най-често срещаните места, където потребителят може да използва старата си парола:
- Монтирайте мрежово устройство чрез мрежово използване (Map Drive)
- В Windows Scheduler Jobs
- В услуги на Windows, които са конфигурирани да се изпълняват от акаунт в домейн
- Запазени пароли в мениджъра на пароли в контролния панел (Credential Manager)
- браузъри
- Мобилни устройства (например, използвани за достъп до корпоративна поща)
- Програми с autologin
- Непълни потребителски сесии на други компютри или терминални сървъри
- И други.
За по-подробен одит на ключалки на намерена машина, трябва да активирате редица локални политики за одит на Windows. За целта отворете редактора на групови правила на локалния компютър, на който искате да проследите източника на заключването Gpedit.msc и в раздела Изчислете конфигурации -> Настройки на Windows -> Настройки за защита -> Локални политики -> Одитна политика активиране на правилата:
- Проследяване на процеса на одит: Успех, провал
- Одитиране на събития за влизане: Успех, провал
Изчакайте следващото блокиране на акаунта и погледнете в дневника за сигурност за събития с ID на събитието 4625. В нашия случай това събитие изглежда така:
От описанието на събитието става ясно, че източникът на заключването на акаунта е процес mssdmn.exe (е компонент на Sharepoint). Остава да информира потребителя, че трябва да актуализира паролата си в уеб портала Sharepoint.
След анализа, идентифицирането и наказанието на виновника, не забравяйте да деактивирате действието на активирани политики за групов одит.
В случай, че все още не можете да разберете причината за блокирането на акаунта на конкретен компютър, за да избегнете постоянно блокиране на акаунта, струва си да опитате да преименувате името на потребителския акаунт в Active Directory. Това обикновено е най-ефективният метод за защита срещу внезапни брави на конкретен потребител..
