Як знайти причину заблокованого облікового запису користувача в домені AD AD

Після недавнього інциденту з Outlook мені було цікаво, як я найбільш ефективно вирішуватимуть таку проблему:

Припустимо досить типову інфраструктуру AD для невеликих і середніх розмірів: кілька постійних серверів, кількість внутрішніх серверів і клієнтів Windows, кілька сервісів, що використовують AD і LDAP для автентифікації користувача зсередини DMZ (ретранслятор SMTP, VPN, Citrix тощо) та кілька внутрішніх послуги, які покладаються на AD для аутентифікації (Exchange, SQL сервер, сервери файлів і друку, сервери термінальних служб). Ви маєте повний доступ до всіх систем, але вони трохи надто численні (рахуючи клієнтів), щоб перевірити їх окремо.

Тепер припустимо, що з незрозумілої причини один (або більше) облікових записів користувачів закривається через політику блокування пароля кожні кілька хвилин.

• Який найкращий спосіб знайти службу / машину, відповідальну за це?
• Якщо припустити, що інфраструктура є чистою, стандартна Windows, без додаткового інструменту управління та мало змін за замовчуванням, чи є спосіб пошуку причин такого блокування заблокувати чи покращити?
• Що можна зробити, щоб підвищити стійкість системи проти такого блокування облікових записів DOS? Вимкнення блокування облікового запису є очевидною відповіддю, але тоді ви стикаєтеся з тим, що користувачі мають можливість легко користуватися паролями, навіть із застосуванням складності.

Додавши щось, чого я не бачу у наведених відповідях.

Який найкращий спосіб знайти службу / машину, відповідальну за це?

Ви не можете просто переглянути журнал безпеки PDCe, оскільки, хоча PDCe має найновішу інформацію про блокування облікових записів для всього домену, він не має інформації про те, від якого клієнта (IP або ім'я хоста) поступили невдалі спроби входу, припускаючи, що невдалі спроби входу відбулися в іншому DC крім PDCe. PDCe скаже, що "Обліковий запис xyz був заблокований", але він не скаже звідки, якщо невдалі логотипи відбувалися в іншому DC в домені. Тільки DC, який фактично підтвердив вхід, запише помилку входу, включаючи адресу клієнта. (Також не залучайте RODC до цієї дискусії.)

Є два хороших способи з'ясувати, звідки беруться невдалі спроби входу, коли у вас є кілька контролерів домену. Переадресація подій та інструменти блокування облікових записів Microsoft .

Я віддаю перевагу переадресації події до центрального місця. Невдалі спроби входу з усіх ваших контролерів домену на центральний сервер реєстрації. Тоді у вас є лише одне місце, де можна шукати невдалі логотипи у всьому домені. Насправді я особисто не люблю інструменти блокування облікових записів Microsoft, тому зараз є один хороший спосіб.

Переадресація подій. Вам сподобається.

Якщо припустити, що інфраструктура є чистою, стандартна Windows без додаткового інструменту управління та мало змін за замовчуванням, чи є спосіб пошуку причин такого блокування заблокувати чи покращити?

Дивись вище. Потім ви можете мати систему моніторингу, таку як SCOM або Nagios, або будь-яку іншу, яку ви використовуєте, розчесати цей єдиний журнал подій і підірвати мобільний телефон текстовими повідомленнями чи будь-яким іншим. Це не стає більш прискореним, ніж це.

Що можна зробити, щоб підвищити стійкість системи проти такого блокування облікових записів DOS?

1. Освіта користувачів. Скажіть їм припинити налаштування служб Windows для роботи під їх обліковими записами користувачів домену, вийдіть із сеансів RDP, коли вони завершені, навчіть їх очищати сховище довірених файлів Windows для кешованих паролів для Outlook тощо.
2. Використовуйте керовані облікові записи служб, де ви зможете, таким чином, користувачам більше не потрібно керувати паролями для цих облікових записів користувачів. Користувачі приховують все. Якщо ви даєте користувачеві вибір, він або вона завжди зробить неправильний вибір. Тож не дайте їм вибору.
3. Забезпечення віддалених таймаутів сеансу через GPO. Якщо користувач простоює протягом сесії RDP протягом 6 годин, відключіть їх.

У нас була та сама проблема під час очищення облікових записів адміністраторів у більшому середовищі. Хоча журнали аудиту ДК технічно надають необхідну інформацію, ми вирішили застосувати продукт ADAudit Plus ManageEngine, який сканує ці журнали та шукає спроби входу, а також будь-які зміни в AD. Використовуючи вбудовану функцію звітування та трохи роботи в Excel, ми змогли відстежити (досить легко), звідки беруться логотипи. У нашому випадку це стосувалося переважно адміністраторів, які використовували акаунти адміністратора замість службових облікових записів при впровадженні різних програм.

Що можна зробити, щоб підвищити стійкість системи проти такого блокування облікових записів DOS?

Ви не можете.

Є багато речей, які можуть спалити ваш будинок. Як і простий код для багаторазового запиту IP-адрес, поки не вичерпається область DHCP. Або простий код, який створює каталоги до повного заповнення MFT, і вам доведеться переформатувати розділ, щоб відновити його. Ви не можете захиститись від усього.

Більш розповсюджений сценарій із блокуваннями - це люди, які вводять свої повноваження на набагато ширший спектр пристроїв, ніж це було звичайно кілька років тому. Наприклад, принтери (для сканування електронною поштою) або смартфон або планшет. Якщо вони забудуть, де вони ввели свої облікові дані, або якщо вони більше не мають доступу до пристрою, можливо, пристрій продовжить спроби автентифікації назавжди. Auth електронної пошти - важкий вектор для відстеження цих пристроїв, і навіть якщо ви це зробите, користувач може не мати до нього доступу або знати, де він знаходиться. IP 10.4.5.27? Я знаю одного користувача, якому довелося щодня телефонувати в службу довідки, щоб розблокувати їхній рахунок, вони негайно входили в систему, а потім їхній рахунок знову закривався. Вони робили це місяцями. Я сказав їм перейменувати свій рахунок.

У житті є перешкоди, ми не можемо їх усунути.