Виявляємо джерело блокування облікового запису користувача в Active Directory

У цій статті ми опишемо, як відслідковувати події блокування облікових записів користувачів на Котроллер домену Active Directory, визначати з якого комп'ютера і із який конкретно програми виконується постійна блокування. Розглянемо використання для пошуку джерела блокування журналу безпеки Windows і скриптів PowerShell.

Політика безпеки облікових записів в більшості організацій вимагає обов'язкового блокування облікового запису користувача в домені Active Directory в разі n-кратного неправильного набору пароля користувачем. Зазвичай обліковий запис блокується контролером домену після декількох спроб ввести неправильний пароль на кілька хвилин (5-30), в перебігу яких вхід користувача в систему неможливий. Через визначення час, заданий політиками безпеки, обліковий запис домена автоматично розблокується. Тимчасове блокування облікового запису дозволяє знизити ризик підбору пароля (простим брутфорсом) облікових записів користувачів AD.

У тому випадку, якщо обліковий запис користувача в домені заблокована, при спробі авторизації в Windows з'являється попередження:

Обліковий запис користувача заблокована і не може бути використана для входу в мережу The referenced account is currently locked out and may not be logged on to ... .

зміст:

  • Політики блокування облікових записів в домені
  • Пошук комп'ютера, з якого була заблокована обліковий запис
  • Виявляємо програму, причину блокування облікового запису в AD

Політики блокування облікових записів в домені

Політики блокування облікових записів і паролів зазвичай задається відразу для всього домену політикою Default Domain Policy. Цікавлять нас політики знаходяться в розділі Computer Configuration -> Windows Settings -> Security Settings -> Account Policy -> Account Lockout Policy (Конфігурація Windows -> Параметри безпеки -> Політики облікових записів -> Політики блокування облікових записів). Це політика:

  • Account lockout threshold  (Граничне значення блокування) - через скільки невдалих спроб набору пароля обліковий запис повинен бути заблокована
  • Account lockout duration (Тривалість блокування облікового запису) - на який час буде заблокована обліковий запис (після закінчення цього часу блокування буде знято автоматично)
  • Reset account lockout counter after (Час до скидання лічильника блокування) - через якийсь час буде скинутий лічильник невдалих спроб авторизації

Порада. Вручну зняти блокування облікового запису, не чекаючи автоматичного розблокування, можна за допомогою консолі ADUC. Для цього у властивостях облікового запису користувача на вкладці Account, поставивши чекбокс на Unlock account. This account is currently locked out on this Active Directory Domain Controller.

Досить корисну інформацію про час блокування, завдання пароля, кількості спроб набору пароля та інше можна отримати у властивостях облікового запису в консоль ADSIEdit або на додатковій вкладці Additional Account Info у властивостях користувача (простіше).

Ситуації, коли користувач забув свій пароль і сам викликав блокування своєї учеткі трапляються досить часто. Але в деяких випадках блокування учеток відбувається несподівано, без будь-яких видимих ​​причин. Тобто користуватися "клянеться", що нічого особливого не робив, не разу не помилявся при введенні пароля, але його обліковий запис чомусь заблокувалася. Адміністратор на прохання користувача може вручну зняти блокування, але через деякий час ситуація повторюється.

Для того, щоб вирішити проблему користувача адміністратору потрібно розібратися з якого комп'ютера і якою програмою була заблокована обліковий запис користувача в Active Directory.

Пошук комп'ютера, з якого була заблокована обліковий запис

В першу чергу адміністратору потрібно розібратися з якого комп'ютера / сервера відбуваються спроби введення невірних паролів і йде подальша блокування облікового запису.

У тому випадку, якщо найближчий до користувача контролер домену визначив, що користувач намагається авторизуватися під невірним паролем, він перенаправляє запит аутентифікації на DC з FSMO роллю емулятора PDC (Саме він відповідає за обробку блокувань облікових записів). Якщо перевірка справжності не виконувалася і на PDC, він відповідає першому DC про неможливість аутентифікації.

При цьому в журналі обох контролерів домену фіксуються події 4740 із зазначенням DNS імені (IP адреси) комп'ютера, з якого прийшов початковий запит на авторизацію користувача. Логічно, що в першу чергу необхідно перевірити журнали безпеки на PDC контролері. Знайти PDC в домені можна так:

(Get-AdDomain) .PDCEmulator

Подія блокування облікового запису домену можна знайти в журналі Security на контролері домену. Фільтрувати журнал безпеки за подією з Event ID 4740. Повинен з'явиться список останніх подій блокувань облікових записів на контролері домену. Починаючи з самого верхнього переберіть всі події і знайдіть подія, в якому зазначено що обліковий запис потрібного користувача (ім'я облікового запису вказано в рядку Account Name) Заблокована (A user account was locked out).

Примітка. В продуктивної середовищі у великій інфраструктурі AD, в журналі безпеки фіксується велика кількість подій, які поступово перезаписувати. Тому бажано збільшити максимальний розмір журналу на DC і приступати до пошуку джерела блокування якомога раніше.

Відкрийте цю подію. Ім'я комп'ютера (або сервера), з якого була зроблена блокування вказано в полі Caller Computer Name. В даному випадку ім'я комп'ютера - TS01.

Можна скористатися наступним PowerShell скриптом для пошуку джерела блокування конкретного користувача на PDC. Даний скрипт поверне дату блокування і комп'ютер, з якого вона сталася:

$ Username = 'username1'
$ Pdce = (Get-AdDomain) .PDCEmulator
$ GweParams = @
'Computername' = $ Pdce
'LogName' = 'Security'
'FilterXPath' = "* [System [EventID = 4740] and EventData [Data [@ Name = 'TargetUserName'] = '$ Username']]"

$ Events = Get-WinEvent @GweParams
$ Events | foreach $ _. Properties [1] .value + "+ $ _. TimeCreated

Аналогічним чином можна опитати з PowerShell все контролери домену в Active Directory:

$ Username = 'username1'
Get-ADDomainController -fi * | select -exp hostname | %
$ GweParams = @
'Computername' = $ _
'LogName' = 'Security'
'FilterXPath' = "* [System [EventID = 4740] and EventData [Data [@ Name = 'TargetUserName'] = '$ Username']]"

$ Events = Get-WinEvent @GweParams
$ Events | foreach $ _. Computer + "" + $ _. Properties [1] .value + "+ $ _. TimeCreated

Примітка. Якщо контролерів домену кілька, операцію пошуку події блокування доведеться шукати по журналам на кожному з них, також можна організувати передплату на події на інших DC. Полегшити це нелегке завдання можна за допомогою утиліти Microsoft Account Lockout and Management Tools (скачати її можна тут). За допомогою даної утиліти можна вказати відразу кілька контролерів домену, журнали подій яких потрібно моніторити, кількість невірних вводів паролів для конкретного користувача (атрибути badPwdCount і LastBadPasswordAttempt НЕ реплікуються між контролерами домену).

Виявляємо програму, причину блокування облікового запису в AD

Отже, ми визначили з якого комп'ютера або пристрою була заблокована обліковий запис. Тепер хотілося б зрозуміти, яка програма або процес виконує невдалі спроби входу і є джерелом блокування.

Часто користувачі починають скаржитися на блокування облікового запису в домені після планової зміни пароля для свого доменної облікового запису. Це наштовхує на думку, що старий (невірний) пароль збережений в якійсь програмі, скрипті або службі, яка буде робити періодичні спроби авторизуватися в домені із застарілим паролем. Розглянемо поширення місця, в яких користувач міг використовувати свій старий пароль:

  1. Монтування мережевого диска через net use (Map Drive)
  2. У завданнях планувальника Windows (Task Scheduler)
  3. У службах Windows, які налаштовані на запуск з-під доменної облікового запису
  4. Збережені паролі в менеджері паролів в панелі управління (Credential Manager)
  5. браузери
  6. Мобільні пристрої (наприклад, використовується для доступу до корпоративної пошти)
  7. Програми з Автологін
  8. Незавершені сесії користувача на інших комп'ютерах або термінальних серверах
  9. Та ін.
Порада. Існує ряд сторонніх утиліт (в основному комерційних) дозволяють адміністратору виконати перевірку віддаленої машини і детектувати джерело блокування облікових записів. Як досить популярного рішення відзначимо Account Lockout Examiner від Netwrix.

Для більш детального аудиту блокувань на знайденої машині необхідно включити ряд локальних політик аудиту Windows. Для цього на локальному комп'ютері, на якому потрібно відстежити джерело блокування, відкрийте редактор групових політик Gpedit.msc і в розділі Compute Configurations -> Windows Settings -> Security Settings -> Local Policies -> Audit Policy включите політики:

  • Audit process tracking: Success, Failure
  • Audit logon events: Success, Failure

Дочекайтеся черговий блокування облікового запису і знайдіть в журналі безпеки (Security) події з Event ID 4625. У нашому випадку ця подія виглядає так:

З опису події видно, що джерело блокування облікового запису - процес mssdmn.exe (Є компонентом Sharepoint). Залишилося повідомити користувачеві про те, що йому необхідно оновити свій пароль на веб-порталі Sharepoint.

Після закінчення аналізу, виявлення та покарання винуватця не забудьте відключити дію активованих групових політик аудиту.

У тому випадку, якщо ви так і не змогли з'ясувати причину блокування облікового запису на вашому комп'ютері, щоб уникнути постійної блокування учеткі, варто спробувати перейменувати ім'я облікового запису користувача в Active Directory. Це як правило найдієвіший метод захисту від раптових блокувань певного користувача.