Как найти причину заблокированной учетной записи пользователя в домене Windows AD

После недавнего инцидента с Outlook мне стало интересно, как мне наиболее эффективно решить следующую проблему:

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

Теперь предположим, что по какой-то неизвестной причине одна (или более) учетная запись пользователя блокируется из-за политики блокировки пароля каждые несколько минут.

• Как лучше всего найти службу / машину, ответственную за это?
• Если предположить, что инфраструктура чистая, стандартная Windows без дополнительного инструмента управления и мало изменений по умолчанию, есть ли способ ускорить или улучшить процесс поиска причины такой блокировки?
• Что можно сделать, чтобы улучшить устойчивость системы против такой блокировки DOS? Отключение блокировки учетной записи является очевидным ответом, но затем вы сталкиваетесь с проблемой пользователей, имеющих возможность легко использовать пароли, даже с навязанной сложностью.

Добавление чего-то, чего я не вижу в ответах.

Как лучше всего найти службу / машину, ответственную за это?

Вы не можете просто посмотреть журнал безопасности на PDCe, потому что, хотя PDCe имеет самую актуальную информацию о блокировке учетных записей для всего домена, он не имеет информации о том, с какого клиента (IP или hostname) произошли неудачные попытки входа в систему, предполагая, что неудачные попытки входа произошли на другом DC, кроме PDCe. PDCe скажет, что «учетная запись xyz заблокирована», но не скажет откуда, если произошел сбой входа в систему на другом контроллере домена. Только DC, который фактически подтвердил вход в систему, будет регистрировать сбой входа, включая адрес клиента. (Также не включать RODC в это обсуждение.)

Есть два хороших способа выяснить, откуда происходят неудачные попытки входа в систему, когда у вас есть несколько контроллеров домена. Переадресация событий и средства блокировки учетных записей Microsoft .

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

Переадресация событий. Тебе это понравится.

Предполагая, что инфраструктура чистая, стандартная Windows без дополнительного инструмента управления и мало изменений по умолчанию, есть ли способ ускорить или улучшить процесс поиска причины такой блокировки?

Смотри выше. Затем вы можете настроить свою систему мониторинга, такую ​​как SCOM или Nagios, или что-то еще, что вы используете, прочесать этот единственный журнал событий и взорвать ваш мобильный телефон текстовыми сообщениями или чем-то еще. Это не становится более ускоренным, чем это.

Что можно сделать, чтобы улучшить устойчивость системы против такой блокировки DOS?

1. Обучение пользователей. Скажите им, чтобы они прекратили настраивать службы Windows для работы под своими учетными записями пользователей домена, выйдут из сеансов RDP после их завершения, научат их очищать хранилище учетных паролей Windows для Outlook и т. Д.
2. Используйте управляемые учетные записи служб, где это возможно, чтобы пользователям больше не приходилось управлять паролями для этих учетных записей. Пользователи все испортили. Если вы предоставляете пользователю выбор, он или она всегда сделает неправильный выбор. Так что не давай им выбора.
3. Обеспечение тайм-аутов удаленного сеанса через GPO. Если пользователь бездействует в сеансе RDP в течение 6 часов, отключите его.

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

Что можно сделать, чтобы улучшить устойчивость системы против такой блокировки DOS?

Ты не можешь

Есть много вещей, которые могут сжечь ваш дом. Как простой код, чтобы многократно запрашивать IP-адреса, пока область DHCP не будет исчерпана. Или простой код, который создает каталоги до тех пор, пока MFT не заполнится, и вам придется переформатировать раздел, чтобы восстановить его. Вы не можете защитить от всего.

Более распространенный сценарий с локаутами - это люди, которые вводят свои учетные данные на гораздо более широком спектре устройств, чем это было несколько лет назад. Например, принтеры (для сканирования по электронной почте), смартфон или планшет. Если они забывают, где они ввели свои учетные данные, или если у них больше нет доступа к устройству, возможно, что устройство продолжит попытки аутентификации навсегда. Проверка подлинности электронной почты - сложная задача для отслеживания этих устройств, и даже если вы это сделаете, пользователь может не иметь к нему доступа или знать, где он находится. IP 10.4.5.27? Я знаю одного пользователя, которому приходилось каждый день звонить в службу поддержки, чтобы разблокировать свою учетную запись, затем он сразу же входил в систему, а затем его учетная запись снова блокировалась. Они делали это месяцами. Я сказал им, чтобы переименовать их аккаунт.

У жизни есть препятствия, мы не можем удалить их все.