код события блокировка учетной записи
4740(S). Учетная запись пользователя была заблокирована.
Описание события:
Это событие создает каждый раз, когда учетная запись пользователя блокируется.
Для учетных записей пользователей это событие создается на контроллерах доменов, серверах членов и рабочих станциях.
Примечание. Рекомендации приведены в разделе Рекомендации по мониторингу безопасности для этого события.
XML события:
Необходимые роли сервера: нет.
Минимальная версия ОС: Windows Server 2008, Windows Vista.
Версии события: 0.
Описания полей:
Тема:
Имя учетной записи [Type = UnicodeString]: имя учетной записи, которая выполняла операцию блокировки.
Домен учетной записи [Type = UnicodeString]: домен или имя компьютера. Форматы различаются и включают в себя следующее:
Пример имени домена NETBIOS: CONTOSO
Полное имя домена в нижнем регистре: contoso.local
Полное имя домена в верхнем регистре: CONTOSO.LOCAL
Для некоторых известных субъектов безопасности, таких как LOCAL SERVICE или ANONYMOUS LOGON, значение этого поля равно «NT AUTHORITY».
Для учетных записей локальных пользователей это поле будет содержать имя компьютера или устройства, к которым принадлежит эта учетная запись, например: «Win81».
Logon ID [Type = HexInt64]: шестнадцатеричное значение, которое может помочь сопоставить это событие с недавними событиями содержащими тот же идентификатор входа, например: “4624: Учетная запись успешно вошла в систему.”
Учетная запись, заблокированная:
Security ID [Type = SID]: SID учетной записи, которая была заблокирована. Зритель событий автоматически пытается разрешить СИД и показать имя учетной записи. Если идентификатор безопасности разрешить не удается, в событии будут отображены исходные данные.
Имя учетной записи [Type = UnicodeString]: имя заблокированной учетной записи.
Дополнительные сведения:
Рекомендации по контролю безопасности
Для 4740 (S): учетная запись пользователя была заблокирована.
Поскольку это событие обычно запускается учетной записью SYSTEM, рекомендуется сообщать об этом, когда «Subject\Security ID» не является SYSTEM.
Если у вас есть высококлассные доменные или локальные учетные записи (например, учетные записи администратора домена), для которых необходимо отслеживать каждую блокировку, отслеживайте все события 4740 со значениями «Учетная запись, которая была заблокирована \Security ID», которые соответствуют учетным записям.
Если у вас есть домен высокой стоимости или локализованная учетная запись, для которой необходимо отслеживать каждое изменение, отслеживайте все события 4740 с помощью «Учетная запись, которая была заблокирована \Security ID», которая соответствует учетной записи.
Если учетная запись пользователя «Учетная запись, которая была заблокирована\Security ID» не должна использоваться (для попыток проверки подлинности) из имени компьютера Additional Information\Caller, то срабатывает оповещение.
Отслеживайте все 4740 событий, в которых дополнительное имя компьютера Information\Caller не из вашего домена. Однако следует помнить, что даже если компьютер не находится в вашем домене, вместо IP-адреса в событии 4740 вы получите имя компьютера.
Выявляем источник блокировки учетной записи пользователя в Active Directory
В этой статье описано, как отслеживать события блокировки учетных записей пользователей на котроллерах домена Active Directory, определять с какого компьютера и из какой конкретно программы выполняется постоянная блокировка. Рассмотрим использование для поиска источника блокировки журнала безопасности Windows и скриптов PowerShell.
Политика безопасности учетных записей в большинстве организаций требует обязательного блокирования учетной записи пользователя в домене Active Directory в случае n-кратного неправильного набора пароля пользователем. Обычно учетная запись блокируется контроллером домена после нескольких попыток ввести неправильный пароль на несколько минут (5-30), в течении которых вход пользователя в систему невозможен. Через определение время, заданное политиками безопасности, учетная запись домена автоматически разблокируется. Временная блокировка учетной записи позволяет снизить риск подбора пароля (простым брутфорсом) учетных записей пользователей AD.
В том случае, если учётная запись пользователя в домене заблокирована, при попытке авторизации в Windows появляется предупреждение:
Политики блокировки учетных записей в домене
Довольно полезную информацию о времени блокировки, задания пароля, количестве попыток набора пароля и прочее можно получить в свойствах учетной записи в консоль ADSIEdit или на дополнительной вкладке Additional Account Info в свойствах пользователя (проще).
Ситуации, когда пользователь забыл свой пароль и сам вызвал блокировку своей учетки случаются довольно часто. Но в некоторых случаях блокировка учеток происходит неожиданно, без каких-либо видимых причин. Т.е. пользоваться «клянется», что ничего особого не делал, не разу не ошибался при вводе пароля, но его учетная запись почему-то заблокировалась. Администратор по просьбе пользователя может вручную снять блокировку, но через некоторое время ситуация повторяется.
Для того, чтобы решить проблему пользователя администратору нужно разобраться с какого компьютера и какой программой была заблокирована учетная запись пользователя в Active Directory.
Поиск компьютера, с которого была заблокирована учетная запись
В первую очередь администратору нужно разобраться с какого компьютера / сервера происходят попытки ввода неверных паролей и идет дальнейшая блокировка учетной записи.
При этом в журнале обоих контроллеров домена фиксируются события 4740 с указанием DNS имени (IP адреса) компьютера, с которого пришел первоначальный запрос на авторизацию пользователя. Логично, что в первую очередь необходимо проверить журналы безопасности на PDC контроллере. Найти PDC в домене можно так:
Событие блокировки учетной записи домена можно найти в журнале Security на контролере домена. Отфильтруйте журнал безопасности по событию с Event ID 4740. Должен появится список последних событий блокировок учетных записей на контроллере домена. Начиная с самого верхнего переберите все события и найдите событие, в котором указано что учетная запись нужного пользователя (имя учетной записи указано в строке Account Name) заблокирована (A user account was locked out).
Откройте данное событие. Имя компьютера (или сервера), с которого была произведена блокировка указано в поле Caller Computer Name. В данном случае имя компьютера – TS01.
Можно воспользоваться следующим PowerShell скриптом для поиска источника блокировки конкретного пользователя на PDC. Данный скрипт вернет дату блокировки и компьютер, с которого она произошла:
Аналогичным образом можно опросить из PowerShell все контроллеры домена в Active Directory:
Выявляем программу, причину блокировки учетной записи в AD
Итак, мы определили с какого компьютера или устройства была заблокирована учетная запись. Теперь хотелось бы понять, какая программа или процесс выполняет неудачные попытки входа и является источником блокировки.
Часто пользователи начинают жаловаться на блокировку своей учетной записи в домене после плановой смены пароля своей доменной учетной записи. Это наталкивает на мысль, что старый (неверный) пароль сохранен в некой программе, скрипте или службе, которая периодически пытается авторизоваться в домене с устаревшим паролем. Рассмотрим самые распространение места, в которых пользователь мог использовать свой старый пароль:
Дождитесь очередной блокировки учетной записи и найдите в журнале безопасности (Security) события с Event ID 4625. В нашем случае это событие выглядит так:
Из описания события видно, что источник блокировки учетной записи – процесс mssdmn.exe (является компонентом Sharepoint). Осталось сообщить пользователю о том, что ему необходимо обновить свой пароль на веб-портале Sharepoint.
После окончания анализа, выявления и наказания виновника не забудьте отключить действие активированных групповых политик аудита.
В том случае, если вы так и не смогли выяснить причину блокировки учетной записи на конкретном компьютере, чтобы избежать постоянной блокировки учетки, стоит попробовать переименовать имя учетной записи пользователя в Active Directory. Это как правило самый действенный метод защиты от внезапных блокировок определенного пользователя.
4767(S). Учетная запись пользователя была разблокирована.
Описание события:
Это событие создает каждый раз, когда учетная запись пользователя разблокирована.
Для учетных записей пользователей это событие создается на контроллерах доменов, серверах членов и рабочих станциях.
Примечание. Рекомендации приведены в разделе Рекомендации по мониторингу безопасности для этого события.
XML события:
Необходимые роли сервера: нет.
Минимальная версия ОС: Windows Server 2008, Windows Vista.
Версии события: 0.
Описания полей:
Тема:
Имя учетной записи [Type = UnicodeString]: имя учетной записи, которая выполняла операцию разблокировки.
Account Domain [Type = UnicodeString]: домен субъекта или имя компьютера. Форматы различаются и включают в себя следующее:
Пример имени домена NETBIOS: CONTOSO
Полное имя домена в нижнем регистре: contoso.local
Полное имя домена в верхнем регистре: CONTOSO.LOCAL
Для некоторых известных субъектов безопасности, таких как LOCAL SERVICE или ANONYMOUS LOGON, значение этого поля равно «NT AUTHORITY».
Для учетных записей локальных пользователей это поле будет содержать имя компьютера или устройства, к которым принадлежит эта учетная запись, например: «Win81».
Logon ID [Type = HexInt64]: шестнадцатеричное значение, которое может помочь сопоставить это событие с недавними событиями содержащими тот же идентификатор входа, например: “4624: Учетная запись успешно вошла в систему.”
Целевая учетная запись:
Security ID [Type = SID]: SID учетной записи, которая была разблокирована. Средство просмотра событий автоматически пытается разрешить идентификатор безопасности SID и отобразить имя учетной записи. Если идентификатор безопасности разрешить не удается, в событии будут отображены исходные данные.
Имя учетной записи [Тип = UnicodeString]: имя учетной записи, которая была разблокирована.
Домен учетной записи [Type = UnicodeString]: домен или имя компьютера целевой учетной записи. Форматы различаются и включают в себя следующее:
Пример имени домена NETBIOS: CONTOSO
Полное имя домена в нижнем регистре: contoso.local
Полное имя домена в верхнем регистре: CONTOSO.LOCAL
Для учетных записей локальных пользователей это поле будет содержать имя компьютера или устройства, к которым принадлежит эта учетная запись, например: «Win81».
Рекомендации по контролю безопасности
Для 4767 (S): учетная запись пользователя была разблокирована.
Код события блокировка учетной записи
Вопрос
В последние дни наблюдаю возросшую блокировку учетных записей в результате применения политики учетных записей в AD. Но с одним пользователем имею проблему. Учетная запись блокируется несколько раз за день. Провели антивирусную проверку, очистили кэш паролей, удалили все лишние программы. Но найти причину блокировки так и не смог. Использование утилиты Netwrix Account Lockout Examiner также не дало ответ на причины блокировки.
До достижения предела числа сбойных попыток входа в журнале событий периодически регистрируется событие:
Источник: Microsoft Windows security auditing.
Категория: Проверка учетных данных
Компьютер попытался проверить учетные данные учетной записи.
Пакет проверки подлинности: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Учетная запись входа: baranova
Исходная рабочая станция: PC-BARANOVA3
Код ошибки: 0xC000006A
Далее учетная запись блокируется. Регистрируется сообщение в журнале событий:
Источник: Microsoft Windows security auditing.
Категория: Управление учетными записями
ID: 4740
Заблокирована учетная запись пользователя.
Субъект:
Идентификатор безопасности: СИСТЕМА
Имя учетной записи: SRV-AD1$
Домен учетной записи: SFH
Идентификатор входа: 0x3E7
Заблокированная учетная запись:
Идентификатор безопасности: SFH\Baranova
Имя учетной записи: Baranova
Дополнительные сведения:
Имя вызывающего компьютера: PC-BARANOVA3
В дальнейшем до разблокировки учетной записи периодически регистрируется ошибка:
Источник: Microsoft Windows security auditing.
Категория: Проверка учетных данных
ID: 4776
Компьютер попытался проверить учетные данные учетной записи.
Пакет проверки подлинности: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Учетная запись входа: baranova
Исходная рабочая станция: PC-BARANOVA3
Код ошибки: 0xC0000234
На рабочей станции (Windows 7 Pro SP1) в журнале регистрируется ошибка:
Источник: Microsoft Windows security auditing.
Категория: Вход в систему
ID: 4625
Учетной записи не удалось выполнить вход в систему.
Субъект:
ИД безопасности: СИСТЕМА
Имя учетной записи: PC-BARANOVA3$
Домен учетной записи: SFH
Код входа: 0x3e7
Учетная запись, которой не удалось выполнить вход:
ИД безопасности: NULL SID
Имя учетной записи: Baranova
Домен учетной записи: SFH
Сведения об ошибке:
Причина ошибки: Неизвестное имя пользователя или неверный пароль.
Состояние: 0xc000006d
Подсостояние: 0xc000006a
Сведения о процессе:
Идентификатор процесса вызывающей стороны: 0x298
Имя процесса вызывающей стороны: C:\Windows\System32\winlogon.exe
Сведения о сети:
Имя рабочей станции: PC-BARANOVA3
Сетевой адрес источника: 127.0.0.1
Порт источника: 0
Данное событие возникает при неудачной попытке входа. Оно регистрируется на компьютере, попытка доступа к которому была выполнена.
Поля «Субъект» указывают на учетную запись локальной системы, запросившую вход. Обычно это служба, например, служба «Сервер», или локальный процесс, такой как Winlogon.exe или Services.exe.
В поле «Тип входа» указан тип выполненного входа. Наиболее распространенными являются типы 2 (интерактивный) и 3 (сетевой).
В полях «Сведения о процессе» указано, какая учетная запись и процесс в системе выполнили запрос на вход.
Поля «Сведения о сети» указывают на источник запроса на удаленный вход. Имя рабочей станции доступно не всегда, и в некоторых случаях это поле может оставаться незаполненным.
Поля сведений о проверке подлинности содержат подробные данные о конкретном запросе на вход.
— В поле «Промежуточные службы» указано, какие промежуточные службы участвовали в данном запросе на вход.
— Поле «Имя пакета» указывает на подпротокол, использованный с протоколами NTLM.
— Поле «Длина ключа» содержит длину созданного ключа сеанса. Это поле может иметь значение «0», если ключ сеанса не запрашивался.
Может быть кто-нибудь кто-нибудь подскажет, как найти источник проблемы.
Блокировка учетных записей Active Directory: руководство по инструментам и диагностике
Блокировка учетных записей доставляет системным администраторам много хлопот, в Active Directory (AD) это частое явление. Согласно рeзультатам исследований, блокировка учетных записей является наиболее распространенной причиной звонков в службу ИТ-поддержки.
А основной причиной блокировки учетных записей Active Directory (помимо случаев, когда пользователи забывают свой пароль) является работающее приложение или фоновая служба на устройстве, которое аутентифицируется с устаревшими учетными данными. Поскольку пользователям требуется использовать больше устройств, эта проблема усугубляется. Для решения этой проблемы системным администраторам нужно найти приложение, которое работает с устаревшими учетными данными, а затем либо остановить его, либо попросить пользователя обновить учетные данные.
Способ обработки блокировок учетных записей в Active Directory не адаптирован к современным условиям. Раньше, когда большинство пользователей Office входили в систему с одного устройства, им было легко отслеживать свои учетные данные. Но теперь ситуация изменилась.
В этой статье мы более подробно объясним, как происходят блокировки учетных записей Active Directory, как их устранять и как создать политику, которая сократит время и ресурсы, затрачиваемые на разблокировку учетных записей.
Краткий обзор: наиболее распространенные причины блокировки Active Directory
Большинство блокировок учетных записей Active Directory происходят по одной из двух причин: либо пользователи забывают свои пароли, либо они обновляют свои учетные данные не на всех устройствах.
В первом случае, когда пользователь забывает пароль, администратору нужно просто сбросить учетные данные пользователя, напомнить ему, что важно создать надежный пароль, или даже посоветовать использовать диспетчер паролей, чтобы сократить количество паролей, которые необходимо помнить. Во втором же случае, когда какое-то устройство или служба пытается выполнить вход со старыми данными, эта проблема требует более сложного решения, и именно этот вопрос мы рассмотрим в нашей статье.
Базовая механика этого вида блокировки учетной записи заключается в следующем. По умолчанию Active Directory блокирует пользователя после трех неудачных попыток входа в систему. В большинстве случаев, когда пользователю предлагается обновить учетные данные своей учетной записи Active Directory, он делает это на наиболее часто используемом устройстве. На любых других устройствах этого пользователя могут быть сохранены старые учетные данные, и программы или службы будут автоматически продолжать попытки доступа к Active Directory с их помощью. Поскольку учетные данные на этих устройствах уже не действительны, они не смогут войти, и Active Directory очень быстро заблокирует учетную запись, чтобы предотвратить действия, выглядящие как попытка взлома методом перебора.
В большинстве случаев системные администраторы будут вынуждены идентифицировать источник этих незаконных попыток входа в систему и либо заблокировать их, либо попросить пользователя обновить свои учетные данные. В современных условиях, когда пользователям может понадобиться входить из десятков различных источников, поиск причины может оказаться весьма непростой задачей, равно как и разработка соответствующей политики блокировок, способной сократить частоту возникновения подобных проблем. Далее в статье мы покажем вам, как справиться и с тем, и с другим.
Распространенные причины блокировки в Active Directory
Прежде чем мы поговорим о решениях, помогающих с проблемой блокировки учетных записей, стоит отметить, что кроме двух вышеупомянутых наиболее распространенных причин блокировки учетных записей существует множество других.
У Microsoft есть целая статья в TechNet по решению проблем с блокировкой, и их список включает:
Разобравшись в этих темах, вы отлично будете понимать, как происходит блокировка учетных записей.
Решение проблемы блокировки учетных записей
В связи с большим количеством потенциальных причин блокировки учетной записи Active Directory системным администраторам часто приходится затрачивать серьезные усилия, чтобы решить эту проблему. Системным администраторам следует настроить систему для отслеживания количества пользователей с включенной блокировкой в доменном лесу, чтобы иметь возможность устранять проблемы с блокировками прежде, чем они окажутся завалены звонками пользователей.
Первые шаги
Когда вы впервые идентифицируете заблокированную учетную запись, первая и самая важная задача — определить, вызвана ли блокировка кибератакой.
Чтобы убедиться, что у вас достаточно информации для расследования, вам следует предпринять несколько ключевых шагов:
Факторы, которые следует учитывать в политике блокировки
Если вы постоянно сталкиваетесь с несколькими видами блокировки учетной записи Active Directory, это можно исправить, пересмотрев свою политику блокировки.
Многие администраторы скажут вам, что большинство, если не все, блокировки учетных записей могут быть устранены с помощью внедрения более интеллектуальной политики блокировки учетных записей Active Directory. Сторонники этого подхода рекомендуют администратору зайти в объект групповой политики, установленный по умолчанию для домена, и изменить соответствующие параметры блокировки на более подходящие.
Параметр «Порог блокировки учетной записи» (account lockout threshold) должен быть изменен на гораздо большее число, чем 3 — возможно, 20 или 30 — так, чтобы блокировка вызывалась только действиями хакера по перебору паролей, (в этом случае такие попытки исчисляются сотнями).
Для параметра «Продолжительность блокировки учетной записи» (account lockout duration) — время ожидания перед автоматической разблокировкой учетной записи — следует установить значение в 10 минут (вместо, скажем, 12 часов), или значения по умолчанию, равного нулю (что означает постоянную блокировку).
И, наконец, хитрый параметр «Сброс политики блокировки учетной записи через» (reset account lockout policy after) по умолчанию установлен на 1 минуту. Подробнее об этом подходе можно прочитать тут.
Получив профессиональные советы от нескольких инженеров Varonis, я узнал, что также может помочь изменение параметров блокировки Active Directory по умолчанию. Но с этим нужно быть осторожными, так как сначала необходимо проверить общую надежность паролей сотрудников. Если ваша политика в отношении паролей надежна, то увеличение «порога блокировки учетной записи» может иметь смысл, иначе это может не сработать. Кроме того, есть хороший аргумент в пользу того, что этот пороговый параметр всегда должен быть равен нулю. В итоге пользователи будут вынуждены обращаться в службу поддержки, чтобы разблокировать свои учетные записи.
В конечном итоге выбранный вами подход будет зависеть от вашей среды и количества случаев блокировки, с которыми вы ежедневно сталкиваетесь. Вы должны стремиться внедрить политику блокировки, которая позволит управлять количеством попыток сброса учетной записи, при этом сохраняя возможность отлавливать попытки злоумышленников проникнуть в вашу сеть.
Три инструмента для работы с блокировками учетных записей Active Directory
Блокировка учетных записей Active Directory — это настолько распространенное явление и такой источник фрустрации для сетевых администраторов, что для решения этой проблемы были специально созданы несколько инструментов. Некоторые из них предоставляются Microsoft, а другие являются предложениями сторонних разработчиков. Вот список лучших из них:
Программные средства Account Lockout Status
Это стандартный набор инструментов, который Microsoft предоставляет для управления блокировкой учетных записей Active Directory. Он состоит из ряда отдельных компонентов.
Каждый из них поможет вам исследовать различные аспекты вашей сети:
ADLockouts
Это простая программа, которая пытается отследить источник попыток ввода неверного пароля, приведший к блокировке Active Directory.
Этот инструмент отлично подходит для небольших сетей, но в более обширной среде не так эффективен. Приложение ищет в каждом домене и контроллере домена неудачный вход в систему, а затем анализирует все связанные с ним события. Его целью является определение причины блокировки. После этого программа анализирует каждую машину и выводит все типичные случаи блокировок учетных записей по ряду объектов: подключенные диски, старые сеансы удаленной работы, запланированные задания и другое.
PowerShell
Конечно, вы можете использовать самый прямой подход к расследованию причин блокировки учетных записей Active Directory и использовать PowerShell. Этот процесс может длиться чуть дольше и быть более сложным по сравнению с вышеперечисленными инструментами, но он также даст вам более подробную информацию о том, что именно происходит в ваших системах.
Используя PowerShell, вы можете легко отфильтровать журнал событий на предмет событий, связанных с определенной учетной записью, чтобы определить источник блокировки учетной записи:
Заключение
Если вы сетевой администратор, то вам наверняка не нужно объяснять, сколько хлопот доставляет блокировка учетных записей Active Directory. Учитывая это, возникает соблазн просто рассматривать блокировку учетных записей как неотъемлемую функцию Active Directory и автоматически разблокировать учетные записи пользователей, как только вы получите запрос в службу поддержки.
Однако это неправильный подход. Потратив время на расследование истинных причин блокировок учетных записей, вы можете предотвратить их частое появление. Кроме того, изменение политик блокировки может стать эффективным способом определения случаев, когда блокировка вызвана пользовательской ошибкой, а когда — атакой киберпреступников на вашу сеть.
В конечном итоге от вашего понимания Active Directory будет зависеть, насколько эффективно вы сможете предотвращать блокировки учетных записей и управлять ими. Если вас часто расстраивает невозможность отследить источник этих проблем, вы можете использовать предоставленные нами ресурсы. В частности, ознакомьтесь с нашим руководством о пользователях и компьютерах в Active Directory, а также руководством по маркировке конфиденциальных данных — с их помощью вы сможете еще более эффективно защитить свою сеть от кибератак.