После недавнего инцидента с Outlook мне стало интересно, как я могу наиболее эффективно решить следующую проблему:
Предположим, что достаточно типичная инфраструктура AD малого и среднего размера: несколько контроллеров домена, несколько внутренних серверов и клиентов Windows, несколько служб, использующих AD и LDAP для аутентификации пользователей из DMZ (ретранслятор SMTP, VPN, Citrix и т. Д.) И несколько внутренних все службы, использующие AD для аутентификации (Exchange, SQL-сервер, файловые серверы и серверы печати, серверы служб терминалов). У вас есть полный доступ ко всем системам, но их слишком много (с учетом клиентов), чтобы проверить их индивидуально.
Теперь предположим, что по неизвестной причине одна (или несколько) учетных записей пользователей блокируется из-за политики блокировки пароля каждые несколько минут.
Добавление чего-то, чего я не вижу в приведенных ответах.
Как лучше всего найти сервис / машину, отвечающую за это?
Ты не можешь просто посмотрите журнал безопасности на PDCe, потому что, хотя PDCe имеет самую последнюю информацию о блокировках учетных записей для всего домена, у него нет информации о том, с какого клиента (IP или имя хоста) произошел сбой входа в систему попытки исходили из предположения, что неудачные попытки входа в систему произошли на другом контроллере домена, помимо PDCe. PDCe скажет, что «Учетная запись xyz заблокирована», но не скажет, откуда, если неудачные попытки входа в систему произошли на другом DC в домене. Только контроллер домена, который действительно подтвердил вход в систему, запишет ошибку входа в систему, включая адрес клиента. (Также не вовлекаем RODC в это обсуждение.)
Есть два хороших способа узнать, откуда происходят неудачные попытки входа в систему, если у вас несколько контроллеров домена. Пересылка событийи Microsoft Инструменты блокировки учетной записи.
Я предпочитаю пересылку событий в центральное место. Перенаправляйте неудачные попытки входа в систему со всех контроллеров домена на центральный сервер регистрации. Тогда у вас будет только одно место для поиска неудачных попыток входа в систему во всем домене. На самом деле мне лично не нравятся инструменты блокировки учетных записей Microsoft, так что теперь есть один хороший способ.
Пересылка событий. Тебе это понравится.
Предполагая, что инфраструктура чистая, стандартная Windows без дополнительных инструментов управления и с небольшими изменениями по умолчанию, есть ли способ ускорить или улучшить процесс поиска причины такой блокировки?
См. Выше. Затем вы можете заставить свою систему мониторинга, такую как SCOM или Nagios или что-то еще, что вы используете, прочесать этот единственный журнал событий и взорвать свой мобильный телефон текстовыми сообщениями или чем-то еще. Это не может быть более ускоренным, чем это.
Что можно сделать для повышения устойчивости системы к такой блокировке учетных записей DOS?
Некоторое время назад у нас была такая же проблема при очистке учетных записей администраторов в более крупной среде. Хотя журналы аудита контроллеров домена технически предоставляют необходимую информацию, мы решили внедрить продукт ADAudit Plus от ManageEngine, который сканирует эти журналы и ищет попытки входа в систему, а также любые изменения в AD. Используя встроенную функцию отчетов и немного поработав в Excel, мы смогли (довольно легко) отследить, откуда пришли входы в систему. В нашем случае это было в основном связано с тем, что администраторы использовали учетные записи администратора вместо учетных записей служб при реализации различных приложений.
Что можно сделать для повышения устойчивости системы к такой блокировке учетных записей DOS?
Вы не можете.
Есть много вещей, которые могут сжечь ваш дом. Как простой код для многократного запроса IP-адресов до тех пор, пока область DHCP не будет исчерпана. Или простой код, который создает каталоги до тех пор, пока MFT не заполнится, и вам придется переформатировать раздел, чтобы восстановить его. От всего не защитишься.
Более распространенный сценарий с локаутом - это люди, которые вводят свои учетные данные на гораздо большем количестве устройств, чем это было обычным делом всего несколько лет назад. Например, принтеры (для сканирования по электронной почте), смартфон или планшет. Если они забудут, где ввели свои учетные данные, или если у них больше нет доступа к устройству, возможно, что устройство будет продолжать попытки аутентификации бесконечно. Электронная почта - сложный вектор для отслеживания этих устройств, и даже если вы это сделаете, пользователь может не иметь к нему доступа или не знать, где оно находится. IP 10.4.5.27? Я знаю одного пользователя, которому приходилось каждый день звонить в службу поддержки, чтобы разблокировать свою учетную запись, затем они немедленно входили в систему, а затем их учетная запись снова блокировалась. Они делали это месяцами. Я сказал им переименовать свой аккаунт.
В жизни есть сдерживающие факторы, мы не можем удалить их все.