Устранение неполадок с блокировкой учетных записей в службах AD FS в Windows Server

В этой статье описаны действия по устранению блокировок учетных записей в службах федерации Microsoft Active Directory (AD FS) в Windows Server.

Исходная версия продукта: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
Исходный номер статьи базы знаний: 4471013

В службах AD FS в Windows Server может возникнуть ошибка блокировки учетной записи. Чтобы устранить эту проблему, сначала проверьте следующие моменты.

Создание данных для действий пользователя при входе в систему с помощью средства «работоспособность подключения»

Вы можете использовать работоспособность подключения для создания данных о действиях, связанных с входом пользователя.Служба работоспособности подключений создает отчеты о самых неудачных попытках ввода пароля, выполненных в ферме AD FS.

Ознакомьтесь со сведениями, приведенными в этой статье , чтобы проанализировать список учетных записей пользователей и IP-адресов неудачных попыток ввода пароля.Затем перейдите в раздел анализ IP-адреса и имени пользователя учетных записей, на которые влияет неудачные попытки ввода пароля.

Сбор журналов событий AD FS из служб AD FS и прокси-серверов веб-приложений

Шаг 1: сбор журналов событий AD FS из служб федерации Active Directory и прокси-серверов веб-приложений

Для сбора журналов событий необходимо сначала настроить серверы AD FS для аудита. При наличии подсистемы балансировки нагрузки для фермы AD FS необходимо включить аудит на каждом сервере AD FS в ферме. Для прокси-серверов веб-приложений не требуется настраивать аудит.

Чтобы настроить серверы AD FS для аудита, можно использовать один из следующих методов:

Шаг 2: Поиск в журналах AD FS

Для Windows Server 2012 R2 или Windows Server 2016 AD FS выполните поиск по всем журналам событий безопасности серверов служб федерации Active Directory для событий «Event ID 411 Source Audit Audit». Обратите внимание на следующие сведения об элементе «411 Events»:

• Можно скачать сценарий PowerShell для блокировки учетных записей AD FS и неудачного поиска (ad FSBadCredsSearch.ps1) для поиска событий «411» в серверах AD FS. Сценарий предоставляет CSV-файл, который содержит UserPrincipalName, IP-адрес отправителя и время всех неправильных отправок учетных данных в ферму AD FS.Откройте CSV-файл в Excel и быстро примените фильтр по имени пользователя, IP-адресу или времени.
• Эти события содержат имя участника-пользователя (UPN) целевого пользователя.
• Эти события содержат сообщение «сбой проверки маркера», которое указывает на то, что событие указывает на недопустимую попытку ввода пароля или блокировку учетной записи.
• Если на сервере отображаются события «411», но поле IP-адрес отсутствует в событии, убедитесь, что к серверам применено последнее исправление AD FS. Для получения дополнительных сведений обратитесь к разделу MS16 — 020: Обновление для системы безопасности служб федерации Active Directory, чтобы устранить отказ в обслуживании: 9 февраля 2016 г.

Для Windows Server 2008 R2 или Windows Server 2012 AD FS сведения о событии, необходимые для события 411, отсутствуют. Вместо этого скачайте и запустите следующий скрипт PowerShell, чтобы сопоставить события безопасности 4625 (неправильные попытки ввода пароля) и 501 (сведения об аудите AD FS), чтобы найти сведения о затронутых пользователях.

• Вы можете скачать скрипт PowerShell Security Audit Events Parser (ADFSSecAuditParse.ps1) для поиска событий на серверах AD FS. Сценарий предоставляет CSV-файл, который содержит UserPrincipalName, IP-адрес отправителя и время всех неправильных отправок учетных данных в ферму AD FS.
• Этот метод также можно использовать для исследования того, какие подключения успешно выполнены для пользователей в событиях «411». Для получения дополнительных сведений можно выполнить поиск по событиям AD FS «501».
• При выполнении скрипта PowerShell для поиска событий передайте имя участника-пользователя, идентифицированное в событиях «411», или поиск по блокировкам учетных записей.
• IP-адрес вредоносных подправители отображается в одном из двух полей в событиях «501».
• Для веб-сценариев и большинства сценариев проверки подлинности приложений вредоносный IP-адрес будет находиться в поле x-MS-Client-IP .

Анализ IP-адреса и имени пользователя учетных записей, на которые влияют неправильные попытки ввода пароля

После перечисления IP-адресов и имен пользователей определите IP-адреса, которые находятся в непредвиденных местах доступа.

Выполняются попытки от внешних неизвестных IP-адресов?

• Если попытки попытаться получить с внешних неизвестных IP-адресов, перейдите на страницу Обновление серверов AD FS с последними исправлениями.
• Если попытки не поступать от внешних неизвестных IP-адресов, перейдите на страницу, чтобы убедиться, что учетные данные обновлены в службе или приложении.

Обновление серверов AD FS с использованием последних исправлений

Чтобы убедиться, что на серверах AD FS установлены последние функциональные возможности, установите последние исправления для серверов службы AD FS и прокси-серверов веб-приложений. Кроме того, в Windows Server 2012 R2 требуется исправление 3134222 для ведения журнала IP-адресов в событии 411, которое будет использоваться позже.

Проверьте, включена ли блокировка экстрасети

Используйте Get-адфспропертиес , чтобы проверить, включена ли блокировка экстрасети.

• Если включена блокировка экстрасети, перейдите к разделу Проверка блокировки экстрасети и внутренних пограничных значений блокировки.
• Если блокировка экстрасети не включена, выполните указанные ниже действия для соответствующей версии AD FS.

Действия для проверки состояния блокировки

Для Windows Server 2012 R2 или более поздней версии

Интеллектуальная блокировка — это новая функция, которая вскоре будет доступна в службах AD FS 2016 и 2012 R2 с помощью обновления. В этом разделе будут добавлены действия по включению интеллектуальной блокировки, как только станет доступна функция. Затем перейдите в раздел Проверка блокировки экстрасети и внутренних пограничных значений блокировки.

Для Windows Server 2008 R2 или более ранней версии

Рекомендуется обновить серверы AD FS до Windows Server 2012 R2 или Windows Server 2016. Дополнительные сведения см в статье обновление до AD FS в Windows Server 2016. Затем выполните действия, описанные в статье Windows Server 2012 R2 или более поздней версии.

Шаг 1: Проверка блокировки экстрасети и внутренних пороговых значений блокировки

Проверьте правильность настройки пограничных параметров блокировки экстрасети и внутренних блокировок. Дополнительные сведения приведены в статье Рекомендуемые конфигурации безопасности. Как правило, значение параметра екстранетлоккаутсрешолд должно быть меньше порогового значения блокировки для AD, чтобы пользователь блокировал доступ только к экстрасети без блокировки в Active Directory для внутреннего доступа.

Шаг 2: включение современной проверки подлинности и проверки подлинности на основе сертификатов

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

Развертывание современной проверки подлинности

В дополнение к удалению одного из направлений атак, которые в настоящее время используются в Exchange Online, развертывание современной проверки подлинности для клиентских приложений Office позволяет организации пользоваться преимуществами многофакторной проверки подлинности.Современная проверка подлинности поддерживается всеми последними приложениями Office на платформах Windows, iOS и Android.

Так как имя пользователя и запросы на доступ на основе паролей будут по-прежнему подвержены воздействию уязвимости, несмотря на ваши профилактическые и реактивные защиты, организациям следует запланировать, как можно быстрее, внедрять методы доступа, не основанные на паролях.

Следующие типы проверки подлинности, не основанные на паролях, доступны для AD FS и прокси веб-приложения.

Проверка подлинности на основе сертификатов

Если проверка подлинности на основе сертификатов используется в качестве альтернативы имени пользователя и доступу на основе паролей, учетные записи пользователей и доступ защищены следующим образом:

Так как пользователи не используют свои пароли через Интернет, эти пароли менее подвержены воздействию уязвимости. Конечные точки имени пользователя и пароля можно полностью заблокировать на брандмауэре. При этом будет удалено направление атаки для атак с блокировкой или принудительной перебора.

Даже если конечные точки имени пользователя и пароля доступны на брандмауэре, вредоносные имя пользователя и запросы на основе пароля, которые приводят к блокировке, не влияют на запросы доступа, использующие сертификаты. Таким образом, доступ к законному пользователю сохраняется.

Дополнительные сведения о проверке подлинности на основе сертификатов для Azure Active Directory и Office 365 вы найдете в этой статье в блоге по удостоверению Azure Active Directory.

Многофакторная идентификация Azure (MFA)

Azure MFA — еще один метод доступа на основе паролей, который можно использовать так же, как и проверка подлинности на основе сертификатов, чтобы избежать использования конечных точек пароля и имени пользователя полностью.

Azure MFA можно использовать для защиты учетных записей в следующих сценариях.

Сценарии	Преимущество
Использование Azure MFA в качестве дополнительной проверки подлинности в экстрасети	Добавление Azure MFA или любого дополнительного поставщика проверки подлинности в службы федерации Active Directory и требование использования дополнительным методом для запросов экстрасети обеспечивает защиту учетных записей от кражи или принудительно заменять пароль. Это можно сделать в службах AD FS 2012 R2 и 2016.
Использование Azure MFA в качестве первичной проверки подлинности	Это новая возможность в AD FS 2016 для включения без пароля доступа с помощью Azure MFA вместо пароля. Это защищает от нарушений паролей и блокировок.

Дополнительные сведения о настройке Azure MFA с помощью AD FS приведены в статье Configure AD fs 2016 и Azure MFA

Windows Hello для бизнеса

Windows Hello для бизнеса доступен в Windows 10. Windows Hello для бизнеса обеспечивает свободный доступ с помощью пароля из экстрасети на основе строгих криптографических ключей, которые привязаны к пользователю и устройству.

Служба AD FS поддерживает Hello для бизнеса в Windows Server 2016. Просмотр удостоверений проверки подлинности без паролей с помощью Windows Hello для бизнеса.

Шаг 3: отключение устаревшей проверки подлинности и неиспользуемых конечных точек

Отключите устаревшие конечные точки, используемые клиентами EAS с помощью Exchange Online, как показано ниже:

Это может привести к нарушению работы некоторых функций. Тем не менее, это поможет уменьшить векторы поверхности, которые могут использовать злоумышленники. Кроме того, рекомендуется отключить неиспользуемые конечные точки.

Проверьте, устранена ли проблема.

Убедитесь, что учетные данные обновляются в службе или приложении.

Если учетная запись пользователя используется в качестве учетной записи службы, последние учетные данные могут не обновляться для службы или приложения. В этом случае служба может проследить попытки проверки подлинности с использованием неправильных учетных данных. Это приводит к условию блокировки.

Чтобы устранить эту проблему, проверьте конфигурацию учетной записи службы в службе или приложении, чтобы убедиться в правильности учетных данных. В противном случае выполните следующий шаг.

Очистка кэшированных учетных данных в приложении

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

Windows server сам блокирует пользователя

Добрый день! Уважаемые читатели и гости, крупного IT блога Pyatilistnik.org. В прошлый раз мы с вами рассматривали границы применения групп Active Directory, и надеюсь вы разобрались, где и какие следует использовать. Сегодня я хочу рассмотреть, очень частую и жизненную ситуацию, которая есть в любой доменной среде, а именно блокировка учетной записи Windows в Active Directory. Данную проблему вы легко встретите на предприятиях, где есть свои политики PSO и политики смены паролей. Так, что давайте прокачаем свои знания и научимся разбираться в данной ситуации.

Причина блокировки пользователя Active Directory

Давайте разбираться, какие существуют причины блокирования учетных записей пользователей в Active Directory. Как я и говорил выше, данная ситуация существует в компаниях, где есть политики паролей, которые подразумевают блокировку учетной записи при вводе определенного количества не правильных паролей, это правильно с точки зрения безопасности и выявления таких случаев, когда кто-то пытается скомпрометировать ваши ресурсы.

Вот так вот выглядит сообщение о блокировке:

Как видите в моем примере, пользователь по имени Барбоскин Геннадий Викторович не может начать работать, так как залочен.

Если в оснастке Active Directory — Пользователи и компьютеры, посмотреть свойства заблокированной учетной записи на вкладке «Учетная запись», то вы обнаружите статус:

Ставим галку и разблокируем учетную запись. После этого нужно выявлять причины.

Из основных причин блокировки я могу выделить:

• Идет подбор пароля, так называемый брутфорс, что в итоге приводит к блокировкам
• Бывают моменты, что человек пришел из отпуска и напрочь забыл свой пароль, ввел его несколько раз не правильно, чем вызвал блокирование
• После изменения пароля, у пользователя остались старые подключения WIFI на компьютере или телефоне со старыми учетными данными, которые пытаются автоматически подключиться к сервисам компании, это является основной причиной блокировки в Active Directory
• Как и в случае с WIFI, у пользователя после смены пароля, могут быть закэшированные, старые пароли в доступах к сетевым шарам, Outlook календарям и другим программам, которые однажды попросили ввести логин и пароль.
• Иногда бывают задания в планировщике Windows, которые запускались от имени пользователя, а не системы
• Забытые сессии на удаленном рабочем столе, был у меня случай когда у пользователя были права и он подключался по RDP к серверу. потом у него права забрали, а сессию разлогинить забыли, в итоге у него меняется пароль и его начинает каждый день по 5-10 раз блокировать, пака сессию не убили, проблема была актуальной.
• Сохраненные пароли в браузерах
• Службы работающие из под доменной учетной записи

Где настраивается политика блокировки учетных записей в домене

По рекомендациям компании Microsoft, политику блокировки учетной записи Windows настраивают на уровне домена, и чаще всего используют для этого уже имеющуюся политику «Default Domain Policy». Открываем редактор групповой политики и щелкаем правым кликом мыши по политике «Default Domain Policy», из контекстного меню выберите пункт «Изменить».

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

Тут в политике будет три пункта:

• Время до сброса счетчика блокировки (Reset account lockout counter after) — в данном параметре задается, через какое количество времени система обнулит счетчик неудачных попыток авторизации. (Этот параметр безопасности определяет количество минут, которые должны пройти после неудачной попытки входа в систему до того, как счетчик неудачных попыток входа будет сброшен до 0. Допустимые значения: от 1 до 99999 минут. Если определено пороговое значение блокировки учетной записи, то время сброса должно быть меньше или равно длительности блокировки учетной записи. ). В моем примере я настроил политику «Время до сброса счетчика блокировки» на 10 минут, думаю больше не стоит.

• Пороговое значение блокировки (Account lockout threshold) — Тут вы задаете, сколько будет допустимых неправильных попыток ввода, после превышения которых учетная запись Windows будет заблокирована (Количество неудачных попыток входа в систему может составлять от 0 до 999. Если установить это значение равным 0, то учетная запись никогда не будет разблокирована.Неудачные попытки ввода паролей на рабочих станциях или серверах-членах домена, заблокированных с помощью клавиш CTRL+ALT+DELETE или с помощью защищенных паролем заставок, считаются неудачными попытками входа в систему). Я в своей политике задал пороговое значение блокировки равным 5-ти, этого думаю хватит, чтобы правильно ввести свой пароль.

• Продолжительность блокировки учетной записи (Account lockout duration) — ну тут все просто, собственно время блокировки учетной записи Windows в Active Directory. Допустимые значения: от 0 до 99999 минут. Если продолжительность блокировки учетной записи равна 0, то учетная запись будет заблокирована до тех пор, пока администратор не разблокирует ее. Если определено пороговое значение блокировки учетной записи, то длительность блокировки учетной записи должна быть больше или равна времени сброса.

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

Выше я вас рассказал, из-за чего может все лочиться, теперь нужно выяснить с какого компьютера или устройств, это происходит. Ко мне на работе за неделю попадает 5-7 заявок с подобным вопросом, пользователь сменил пароль и у него началась веселая игра под названием угадайка, где я оставил свои старые данные, по которым меня банит контроллер домена. Чтобы однозначно ответить на этот вопрос вам как системному администратору необходимо настроить специальную политику аудита, призванную следить за соответствующими событиями по которым вы сможете дать однозначный ответ по причинам блокировок. По умолчанию данный вид аудита не настроен.

Про аудит Active Directory я подробно рассказывал, можете посмотреть по ссылке, тут я приведу легкую его выдержку, для полноты статьи. Нам нужно включить политику аудита входа, на уровне домена. (Так же вы можете подробно почитать про расширенный аудит, дающий более тонкие настройки https://technet.microsoft.com/ru-ru/library/mt431761%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396)

Включение политики аудита входа

Открываем редактор групповой политики и находим в нем дефолтную политику «Default Domain Policy», открываем ее и переходим по такому пути.

Тут будут такие политики:

1. Аудит входа в систему
2. Аудит доступа к объектам
3. Аудит доступа к службе каталогов
4. Аудит изменений политики
5. Аудит использования привилегий
6. Аудит отслеживания процессов
7. Аудит системных событий
8. Аудит событий входа в систему
9. Аудит управления учетными записями

Нас будет интересовать включение аудита входа в систему, именно данный вид будет генерировать события 4771 и 4624. Открываем ее и ставим галки «Успех и отказ»

Так же советую задать политику аудита событий входа в систему, так же установите «Успех и отказ»

Ну и настроим еще таким же способом «Аудит управления учетными записями«, чтобы мы видели события с кодом 4740.

Когда политика настроена, то вы можете ее принудительно обновить или дождаться автоматического обновления в течении 90-120 минут.

Какие события отслеживать в журнале безопасность

Чтобы отследить устройство вызывающее блокировки учетной записи, нужно понять алгоритм работы данного механизма. Когда кто-то пытается вводить учетные данные в Active Directory, то он идет на ближайший к нему контроллер домена (Кстати выяснить какой контроллер домена вас аутентифицировал можно очень просто, я об этом рассказывал, если интересно, то посмотрите). Данный контроллер домена видит, что пользователь предоставляет некорректные учетные данные и отсылает этот запрос аутентификации на контроллер, который обладает ролью PDC и FSMO. Так как данная роль PDC-эмулятор и отвечает в доменной среде за обработку блокировок учетных записей. Если PDC-эмулятор видит не корректные данные, то он возвращает ответ контроллеру домена, который ему это прислал, что аутентификация не возможна, и в следствии этого генерируется событие 4740, на обоих контроллерах

• 4771 — Это событие возникает каждый раз, когда не удается центром распространения ключей для выдачи Kerberos билетов предоставить билета (TGT). Это может произойти, когда контроллер домена не установлен сертификат для проверки подлинности смарт-карты (например, с помощью «Контроллера домена» или «Проверка подлинности контроллера домена» шаблона), истек срок действия пароля пользователя или неправильный пароль был предоставленные. 4771 на контроллере домена указывает на неудачную попытку войти через Kerberos на рабочей станции с доменной учетной записью. (Подробнее про 4771 https://docs.microsoft.com/ru-ru/windows/security/threat-protection/auditing/event-4771)

• 4776 — Событие 681/4776 на контроллере домена указывает на неудачную попытку входа в систему через NTLM с доменной учетной записью. Код ошибки указывает, почему именно аутентификация была неудачной. Если происходит сбой попытки проверки учетных данных, вы увидите, что событие отказов с значение параметра Код ошибки не равно «0x0» (Подробнее про событие 4476 https://docs.microsoft.com/ru-ru/windows/security/threat-protection/auditing/event-4776)

• 4740 — Учетная запись указанного пользователя была заблокирована после нескольких попыток входа (Подробнее про событие 4740 https://docs.microsoft.com/ru-ru/windows/security/threat-protection/auditing/event-4740)
• 4662 — Это событие создается только в том случае, если соответствующие SACL настроен для объекта Active Directory и выполнить операцию не удалось (Подробнее https://docs.microsoft.com/ru-ru/windows/security/threat-protection/auditing/event-4662).

Как удобно отслеживать события блокировки

Я приведу примеры, как это делаю я и как это можно автоматизировать и оповещать вас заранее, чем это сделает представитель технической поддержки. Самый правильный вариант, это использование систем мониторинга, таких как SCOM или Zabbix, но если их нет, то можно упростить себе жизнь вот такими утилитами. Могу точно сказать, что у вас в компании, как минимум не один контроллер домена, в противном случае у вас проблемы. Бегать по каждому из контроллеров домена, это не лучший вариант, правильнее будет либо перенаправлять все события на централизованный коллектор или же воспользоваться двумя волшебными утилитами, которые вам упростят жизнь.

Я вам рассказывал про набор утилит от компании Microsoft под названием Active Directory ALTools. Там была утилита LockoutStatus.exe. В задачи которой и входило определение статуса пользовательской учетной записи, заблокирована она или нет, и если до, то на каком контроллере домена. Скачайте ее и запустите. Нажимаете пункт меню «File — Select Target», для того чтобы выбрать логин нужной учетной записи.

В поле «Target User Name» вы указываете логин пользователя, кто подвергся блокировке в Active Directory.

На выходе вы получите отчет по всем контроллерам в домене, о статусе вашей учетной записи. Как видите, мой Барбоскин Геннадий Викторович заблокирован и имеет статус «Locked», видно количество попыток неправильного ввода пароля (Bad Pwd Count) и на каких контроллерах домена, на них мы и будем искать нужные нам события, о которых я говорил выше.

Открываем просмотр событий на нужном контроллере домена. Переходим в журнал «Безопасность (Security)» именно в нем кроется причина блокировки учетной записи Барбоскина Геннадия. Так как событий огромное количество, то нам нужно отфильтровать наш журнал событий. Для этого есть кнопка «Filter Current Log (Фильтр текущего журнала)», она позволит нам выбрать только те события, которые нам нужны.

В поле «Logged (Дата)» указываем за какой срок нужны данные, я укажу 12 часов, и в поле все события, укажем номер ID 4740 и нажимаем «Ок»

Видим нашлось 50 событий, но может быть и больше и чтобы ускорить поиск нужного события, мы воспользуемся поисков, для этого нажмите кнопку «Find (Поиск)»

В поисковом поле указываем нужный вам логин учетной записи Windows и нажимаем поиск, если сообщений много, то он может слегка подвисать, не переживайте по этому поводу.

В итоге у меня нашлось событие с кодом 4740, из которого видна причина блокировки учетной записи. В данном случае это рабочая станция с именем SVTTSETMAIN01, это тестовая виртуальная машина, как видите тут статус «A user account was locked out», можно переходить на эту машину и смотреть в чем там дело.

В событиях 4740 вы можете встреть еще вот такие причины блокировки учетной записи Active Directory, так например у меня имя сервера, где происходит блокирование EXchange, означает, что проблема в Outlook или его календарем. Я вам рассказывал, где кэшируются его данные доступа, в заметка Outlook постоянно запрашивает пароль.

В моей компании используются сервисы Google, такие как G-Sute и общие файловые диски, и вот при смене пароля пользователем, в данных утилитах могут остаться старые данные, в результате чего вы будите видеть в логах в компьютере блокировки имя WORKSTATION. Думаю с событием 4740 все понятно, но оно не всегда показывает подробный источник блокировки, поэтому нужно смотреть событие 4771.

Вот пример блокировки из-за WiFI подключения, об это мне говорит имя компьютера CISCO точки доступа. Как видите причин может быть очень много.

Более подробную причину блокировки учетной записи Windows на покажет событие 4771. Сделаем так же фильтрацию и по нему. Основное сообщение тут «Kerberos pre-authentication failed», обратите внимание тут есть IP-адрес, что уже хорошо, это дополнительная информация, показывающая территориальный источник. В ошибка есть код отказа Kerberos, таблица была представлена выше.

Еще может быть полезным событие с кодом 4776, тут то же будет показано с какой рабочей станции была попытка ввода учетных данных.

Кстати получив IP-адрес вы можете посмотреть его mac адрес на DHCP сервере или же на сетевом оборудовании, например, Cisco, я показывал как там узнать mac-адрес.

Далее с помощью специальных сервисов можно определить, что за производитель у данного mac-адреса, сайтов в интернете полно, которые вам помогу, например, https://2ip.ua/ru/services/information-service/mac-find. Будет полезно с мобильными устройствами.

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

Как видите утилита от компании Mirosoft отлично работает, но можно посмотреть, что-то более удобное, мне нравится утилита Account Lockout Examiner от Netwrix, она бесплатная и позволяет создавать портал для технической поддержки, где они могут видеть кто заблокирован и разблокировать его, а так же причину и она умеет посылать оповещения по электронной почте.

Утилита Account Lockout Examiner проста в установке и потребует от вас две вещи:

1. Указание имени домена для поиска событий блокировки учетных записей Windows
2. Учетные данные от имени которых будет обращение к контроллерам домена

Через некоторое время вы получите табличку со всем пользователями у кого наблюдаются проблемы с блокировкой учеток. Тут вы увидите столбец «Workstation» в котом вы увидите адрес устройства блокировки, есть поле Bad Pwd Count показывающее количество попыток неправильно введенного пароля и дата последнего ввода. В самом конце вы увидите статусы пользователей Not locked или Locked.

Тут же вы можете через правый клик разблокировать пользователя.

В настройках Account Lockout Examine вы можете указать адрес электронной почты и сервер, для уведомлений, о событиях блокировки пользователей.

Если развернете IIS на данном сервер, где установлена утилита, то сможете создать портал для технической поддержки, где можно делегировать права на разблокировку пользователей.

Поиск компьютера блокирующего пользователя через PowerShell

PowerShell, очень мощное средство позволяющее сделать очень многое, вот пример поиска устройства из-за которого блокируется учетная запись. Открываем PowerShell ISE и вводим код:

Единственное не забудьте поменять в $Username = ‘username1’ на своего пользователя, можете скачать уже готовый скрипт у меня. На выходе вы получаете имя компьютера.

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

Надеюсь, что мой скромный опыт слегка вам поможет в поиске причин, по которым у вас в домене блокируются учетные записи Active Directory.

Блокировка учетной записи не в домене Active Directory

В случае с Active Directory все понятно, а как быть если учетная запись заблокировалась на вашем локальном, домашнем компьютере. Тут две ситуации, если у вас есть заблокировалась одна из нескольких учетных записей и у других записей есть права администратора, то вы можете все разблокировать, и вторая ситуация, если у вас одна учетная запись и она залочилась, тут будет повеселее, но так же все поправимо. Я опущу причины блокировки, вероятнее всего у вас стоит политика блокировки и вы ее можете поправить через локальную, для этого в окне выполнить напишите gpedit.msc и отключите пункты, о которых я писал в самом начале, либо же с вами кто-то подшутил таким образом выставив вам эту политику, но не суть.

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

Если у вас блокировка учетной записи windows 10 уже свершилась, и есть в наличии вторая учетная запись, например у папы своя у мамы своя, то сделайте следующее. Чтобы снять блокировку активируйте учетную запись, откройте окно выполнить, через сочетание клавиш WIN и R и введите название оснастки lusrmgr.msc

Открываем контейнер «Пользователи» и находим нужного нам, переходим в его свойства

Снимаем у нее галку «Заблокировать учётную запись» и нажимаем применить, все учетная запись теперь будет в рабочем состоянии.

Как разблокировать свою учётную запись Windows, если нет административного доступа

Чтобы обойти блокировку учетной записи, можно пойти двумя путями, легким и посложнее. Самый простой способ разблокировать учетную запись не имя административных прав, это воспользоваться загрузочным диском SonyaPE. Когда вы сделаете из него загрузочную флешку и загрузитесь с нее, то получите рабочий стол Windows 7. Там есть утилита Active@ Password Changer Professional 3.8, которая позволит вам включить и сбросить пароль от встроенной учетной записи Администратор, которая есть в любой операционной системе Windows, далее зайдя под ней вы разблокируете нужную нам учетную запись, как я описывал выше.

Как видите этот метод позволяет обойти блокировку учетной записи, но он не единственный, допустим у вас под рукой нет такого диска, как SonyaPE, что делать. Можно воспользоваться встроенными средствами восстановления Windows или же ими, но на любом установочном диске с Windows вашей редакции. В заметке «Как вернуть предыдущую версию виндоус 10» я показал метод попадания в дополнительные инструменты Windows 10.

Либо вы можете попасть в эти утилиты, через инструменты восстановления системы, о которых шла речь в заметке про восстановление загрузчика Windows 10.

В том и в другом случае, вам необходимо открыть командную строку.

Выбираем раздел HKEY_LOCAL_MACHINE, после чего в меню «Файл» выберите пункт «Загрузить куст».

У вас откроется проводник Windows. В моем компьютере, перейдите по пути Windows\System32\Config. В этой папке лежит файл локальной базы данных пользователей, по имени SAM. Выбираем его и открываем.

Задаем имя новому кусту, для примера это будет 777.

Выбираем теперь куст 00003f8. В правой панели реестра ищем параметр «F» и двойным кликом раскрываем его.

В окошке параметра нам нужна строка 0038. Её первые два значения (у нас это 10 и 00) заменяем.

Двойным кликом щёлкаем по очереди на каждом из двух значений, и когда те выделятся синим, вписываем другие значения. А эти другие значения должны быть 10 и 02 соответственно.

Теперь в окне реестра кликаем на загруженный и отредактированный куст, у нас это 777. И выгружаем его: жмём «Файл», далее «Выгрузить куст». Все необходимые изменения внесены.