Вирус блокирует учетные записи в домене

Обновлено: 19.04.2024

WannaCry, NotPetya, BadRabbit и другие — вирусы-шифровальщики, которые гремели на весь мир ещё около года-двух назад. Сегодня об атаках таким типов вирусов шума меньше, но истории с атаками всё равно происходят. В этой статье я покажу один из инструментов для остановки атаки такого вируса: быстро выявить вторжение и локализовать проблему. Всё это при помощи инструмента для лог-аналити и защиты от вторжений Quest InTrust. Под катом скриншоты и ссылка на репозитории вредоносных скриптов. Погнали!

Quest InTrust — это интегрированное решение, которое включает в себя сбор разных типов логов, syslog-данных и готовых парсеров для разного типа оборудования. Здесь же есть предустановленные правила для выполнения действий в целях предотвращения атак. Сейчас подробнее со всем этим разберёмся на примерах разбора атаки вируса-шифровальщика и получения доступа к контроллеру домена

Принцип атаки — создание новых зашифрованных файлов или папок и удаление оригинальных. Ну а дальше запрос выкупа в биткоинах или другим способом. Определение такого типа атаки основано на выявлении массового удаления и создания файлов. Особенно если это происходит во внеурочное время.

Для сбора событий по изменениям мы используем интеграцию с решением для аудита Quest Change Auditor (о нём уже писали в предыдущей статье и даже сравнивали с продуктом от конкурента). Для событий из этого источника в InTrust есть предустановленные правила для выявления аномалий. Конечно, сюда можно добавить любую логику обработки событий. В моём примере определено, что при массовом создании файлов (более 5 штук за 1 минуту) учётная запись пользователя будет блокирована и ему будет запрещён доступ к общим директориям.

После проверки всех настроек, перейдём к заранее заготовленному скрипту-шифровальщику. И запустим его.

Затем выполним заранее заготовленный скрипт. На выходе получаем вывод, в котором находим реквизиты нашего тестового пользователя.

На следующем шаге выясняем в какие группы входит этот пользователь. Группы администраторов присутствуют.

Теперь узнаём имена контроллеров домена. В моём примере он один.

Следующий шаг потенциально возможной атаки — вход на контроллер домена. Остаётся ввести уже засвеченный пароль.

И получить доступ к исполнению любых команд на контроллере домена.

Среди действий, указанных в InTrust, были прерывание сессии терминального доступа и блокировка пользователя. Что и произошло.

Теперь проверим эту учётную запись ещё раз.

Атака предотвращена, пользователь заблокирован, мир спасён.

Если у вас есть свои политики борьбы с вторжениями различных типов — их также можно указать в InTrust. Вместе с другими продуктами Quest (Change Auditor и Enterprise Reporter) на базе InTrust можно построить полноценную SIEM систему для выявления и предотвращения тяжёлых последствий цифровых атак для бизнеса.

InTrust и другие продукты Quest можно попробовать в вашем окружении в рамках пилотного проекта. Оставьте заявку, чтобы узнать подробности.

26.05.2020

itpro

Active Directory, PowerShell

комментария 74

В этой статье мы покажем, как отслеживать события блокировки учеток пользователей на котроллерах домена Active Directory, определять с какого компьютера и из какой конкретно программы постоянно блокируется учетная запись пользователя. Для поиска источника блокировки аккаунтов пользователей можно использовать журнал безопасности Windows, скрипты PowerShell или утилиту Account Lockout and Management Tools (Lockoutstatus.exe).

Учетная запись пользователя заблокирована и не может быть использована для входа в сеть

Политика безопасности учетных записей в большинстве организаций требует обязательного блокирования учетной записи пользователя в домене Active Directory, если он несколько раз подряд ввел неправильный пароль. Обычно учетная запись блокируется контроллером домена на несколько минут (5-30), в течении которых вход пользователя в домен невозможен. Через определение время (задается в политике безопасности домена), учетная запись пользователя автоматически разблокируется. Временная блокировка учетной записи позволяет снизить риск подбора пароля (простым брутфорсом) к учетным записям пользователей AD.

Если учётная запись пользователя в домене заблокирована, то при попытке входа в Windows появляется предупреждение:

Как проверить, что аккаунт пользователя AD заблокирован?

Вы можете проверить, что аккаунт заблокирован в графический консоли ADUC или с помощью комнадлета Get-ADUser из модуля Active Directory для PowerShell:

Get-ADUser -Identity aaivanov -Properties LockedOut,DisplayName | Select-Object samaccountName, displayName,Lockedout

Учетная запись сейчас заблокирована и не может быть использована для авторизации в домене (Lockedout = True).

Можно вывести сразу все заблокированные аккаунты в домене с помощью Search-ADAccount:

Вы можете вручную снять блокировку учетной записи с помощью консоли ADUC, не дожидаясь автоматической разблокировки. Для этого в свойствах учетной записи пользователя на вкладке Account, включите опцию Unlock account. This account is currently locked out on this Active Directory Domain Controller (Разблокируйте учетную запись. Учетная запись на этом контроллере домена Active Directory на данный момент заблокирована) и сохраните изменения.

Также можно немедленно разблокировать учетную запись с помощью следующей команды PowerShell:

Get-ADUser -Identity aaivanov | Unlock-ADAccount

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

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

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

Accountlockoutthreshold (Пороговое значение блокировки) – через сколько неудачных попыток набора пароля учетная запись должна быть заблокирована;
Account lockout duration (Продолжительность блокировки учетной записи) – на какое время будет заблокирована учетная запись (по истечении этого времени блокировка будет снята автоматически);
Reset account lockout counter after (Время до сброса счетчика блокировки)– через какое время будет сброшен счетчик неудачных попыток авторизации.

Для защиты от перебора паролей рекомендуется использовать стойкие пароли пользователей в AD (использовать длину пароля не менее 8 символов и включить требования сложности. Это настраивается в разделе Password Policy в политиках Password must meet complexity requirements и Minimum password length. Периодически нужно выполнять аудит паролей пользователей.

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

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

Политики аудита входа на DC

Чтобы в журналах контроллеров домена записывались события блокировки учетных записей, нужно включить следующие подкатегории аудита на контроллерах домена в секции Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy -> Logon/Logoff:

Audit Account Lockout
Audit Logon
Audit Logoff

Проще всего включить эту политику через консоль gpmc.msc, отредактировав политику Default Domain Controller Policy, либо на уровне всего домена с помощью Default Domain Policy.

EventID 4740: событие блокировки учетной записи

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

Если пользователь ввел неверный пароль, то ближайший к пользователю контроллер домена перенаправляет запрос аутентификации на DC с FSMO ролью эмулятора PDC (именно он отвечает за обработку блокировок учетных записей). Если проверка подлинности не выполнилась и на PDC, он отвечает первому DC о невозможности аутентификации. Если количество неуспешных аутентификаций превысило значение, заданное для домена в политике Account lockout threshold, учетная запись пользователя временно блокируется.

При этом в журнале обоих контроллеров домена фиксируются событие с EventID 4740 с указанием DNS имени (IP адреса) компьютера, с которого пришел первоначальный запрос на авторизацию пользователя. Чтобы не анализировать журналы на всех DC, проще всего искать это события в журнале безопасности на PDC контроллере. Найти PDC в домене можно так:

Событие блокировки учетной записи домена можно найти в журнале Security (Event Viewer > Windows Logs) на контролере домена. Отфильтруйте журнал безопасности (Filter Current Log) по событию с Event ID 4740. Должен появиться список последних событий блокировок учетных записей контроллером домена. Переберите все события, начиная с самого верхнего и найдите событие, в котором указано, что учетная запись нужного пользователя (имя учетной записи указано в строке Account Name) заблокирована (A user account was locked out).

Примечание. В большой инфраструктуре AD, в журнале безопасности фиксируется большое количество событий, которые постепенно перезаписываются более новыми. Поэтому желательно увеличить максимальный размер журнала на DC и приступать к поиску источника блокировки как можно раньше.

Откройте данное событие. Имя компьютера (или сервера), с которого была произведена блокировка указано в поле Caller Computer Name. В данном случае имя компьютера – TS01.

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

Можно воспользоваться следующим PowerShell скриптом для поиска источника блокировки конкретного пользователя на PDC. Данный скрипт вернет дату блокировки и компьютер, с которого она произошла:

$Username = ‘username1’
$Pdce = (Get-AdDomain).PDCEmulator
$GweParams = @‘Computername’ = $Pdce
‘LogName’ = ‘Security’
‘FilterXPath’ = "*[System[EventID=4740] and EventData[Data[@Name='TargetUserName']='$Username']]"
>
$Events = Get-WinEvent @GweParams
$Events | foreach

$Username = ‘username1’
Get-ADDomainController -fi * | select -exp hostname | % $GweParams = @‘Computername’ = $_
‘LogName’ = ‘Security’
‘FilterXPath’ = "*[System[EventID=4740] and EventData[Data[@Name='TargetUserName']='$Username']]"
>
$Events = Get-WinEvent @GweParams
$Events | foreach
>

Утилита Microsoft Account Lockout and Management Tools

Для поиска источника блокировки пользователя можно использовать графическую утилиту Microsoft Account Lockout and Management Tools — Lockoutstatus.exe (скачать ее можно тут). Данная утилита проверяет статус блокировки учетной записи на всех контроллерах домена.

Запустите утилиту Lockoutstatus.exe, укажите имя заблокированной учетной записи (Target User Name) и имя домена (Target Domain Name).

В появившемся списке будет содержаться список DC и состояние учетной записи (Locked или Non Locked). Дополнительно отображается время блокировки и компьютер, с которого заблокирована данная учетная запись (Orig Lock).

Прямо из утилиты Lockoutstatus можно разблокировать пользователя, или сменить его пароль.

Основной недостаток утилиты LockoutStatus – она довольно долго опрашивает все контроллеры домена (некоторые из них могут быть недоступны).

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

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

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

Монтирование сетевого диска через net use (Map Drive);
В заданиях планировщика Windows (Task Scheduler);
В службах Windows, которые настроены на запуск из-под доменной учетной записи;
Сохранённые пароли в менеджере паролей в панели управления (Credential Manager);
Браузеры;
Мобильные устройства (например, использующееся для доступа к корпоративной почте);
Программы с автологином или настроенный автоматический вход в Windows;
Незавершенные сессии пользователя на других компьютерах или терминальных серверах (поэтому желательно настраивать лимиты для RDP сессий);
Если пользователь недавно сменил пароль и забыл его, вы можете сбросить его.

Совет. Существует ряд сторонних утилит (в основном коммерческих) позволяющих администратору выполнить проверку удаленной машины и детектировать источник блокировки учетных записей. В качестве довольно популярного решения отметим Account Lockout Examiner от Netwrix.

Для более детального аудита блокировок на найденном компьютере необходимо включить ряд локальных политик аудита Windows. Для этого на локальном компьютере, на котором нужно отследить источник блокировки, откройте редактор групповых политик gpedit.msc и в разделе Compute Configurations -> Windows Settings -> Security Settings -> Local Policies -> Audit Policy включите политики:

Audit process tracking: Success , Failure
Audit logon events: Success , Failure

Дождитесь очередной блокировки учетной записи и найдите в журнале безопасности (Security) события с Event ID 4625. В нашем случае это событие выглядит так:

Из описания события видно, что источник блокировки учетной записи – процесс mssdmn.exe (является компонентом Sharepoint). Осталось сообщить пользователю о том, что ему необходимо обновить свой пароль на веб-портале Sharepoint.

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

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

16.02.2022

itpro

Active Directory, Групповые политики

комментариев 15

Когда доменный пользователь входит в Windows, по умолчанию его учетные данные (Cached Credentials: имя пользователя и хэш пароля) сохраняются на локальном компьютере. Благодаря этому, пользователь сможет войти на локальный компьютер, даже если контроллеры домена AD недоступны, выключены или на компьютере отключен сетевой кабель. Функционал кэширования учетных данных доменных аккаунтов удобен для пользователей ноутбуков, которые могут получить доступ к своим локальным данным на компьютере, когда нет доступа к корпоративной сети.

Сохраненный кэш доменной учетной записи в Windows

Если домен Active Directory недоступен, Windows проверяет, что введенные имя пользователя и пароль соответствуют сохраненному локальному хэшу и разрешает локальный вход на компьютер.

Сохраненные пароли хранятся в ветке реестра HKEY_LOCAL_MACHINE\Security\Cache (файл %systemroot%\System32\config\SECURITY). Каждый сохранённый хэш содержится в Reg_Binary параметре NL$x (где x – индекс кэшированных данных). По умолчанию даже у администратора нет прав на просмотр содержимого этой ветки реестра, но при желании их можно легко получить.

В реестр сохраняет хэш пароля, модифицированный с помощь salt, созданной на основе имени пользователя.

$HKEY_LOCAL_MACHINE\Security\Cache сохраненный хэш пароля в реестре$

Настройка Cached Credentials с помощью групповых политик

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

По-умолчанию в Windows 10 /Windows Server 2016 сохраняются учетные данные для 10 пользователей. Чтобы изменить это количество, используется параметр GPO Interactive logon: Number of previous logons to cache (in case domain controller is not available) (Интерактивный вход в систему: количество предыдущих подключений к кэшу в случае отсутствия доступа к контроллеру домена), который находится в разделе Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options. Можно задать значение от 0 до 50.

Если задать 0, это запретит Windows кэшировать учетные данные пользователей. В этом случае при недоступности домена, при входе пользователя появится ошибка “There are currently no logon servers available to service the logon request”.

Этот параметр также можно настроить с помощью REG_SZ параметра реестра CashedLogonsCount из ветки HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

При входе под сохраненными данными, пользователь не видит, что контроллер домена не доступен. С помощью GPO можно вывести уведомление о входе под кэшированными данными. Для этого нужно включить политику Report when logon server was not available during user logon (Сообщать, когда сервер входа недоступен при входе пользователя) в разделе Compute configuration -> Policies -> Administrative templates -> Windows Components -> Windows Logon Options.

В этом случае при входе пользователя в трее будет появляться уведомление:

Эту настройку можно включить через реестр:
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows NT/Current Version/Winlogon

ValueName: ReportControllerMissing
Data Type: REG_SZ
Values: TRUE

Безопасность кэшированных учетных данных в Windows

Локальное кэширование учетных данных несет ряд рисков безопасности. Злоумышленник, получив физический доступ к компьютеру/ноутбуку с кэшированными данными, может с помощью брутфорса расшифровать хэш пароля (тут все зависит от сложности и длины пароля, для сложных паролей время подбора огромное). Поэтому не рекомендуется использовать кеширование для учетных записей с правами локального администратора (или, тем более, доменного администратора).

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

Для доменов с функциональным уровнем Windows Server 2012 R2 или выше можно добавить учетные записи администраторов домена в группу Protected Users. Для таких пользователей запрещено локальное сохранение кэшированных данных для входа.

Можно создать в домене отдельные политики по использованию кэшированных учетных данных для разных устройств и категорий пользователей (например, с помощью GPO Security filters, WMI фильтров, или распространению настроек параметра реестра CashedLogonsCount через GPP Item level targeting).

Для мобильных пользователей – CashedLogonsCount = 1
Для обычных компьютеров – CashedLogonsCount = 0

Такие политики снизят вероятность получения хэша привелигированных пользователей с персональных компьютеров.

Блокировка учетных записей доставляет системным администраторам много хлопот, в 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 системным администраторам часто приходится затрачивать серьезные усилия, чтобы решить эту проблему. Системным администраторам следует настроить систему для отслеживания количества пользователей с включенной блокировкой в доменном лесу, чтобы иметь возможность устранять проблемы с блокировками прежде, чем они окажутся завалены звонками пользователей.

Первые шаги

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

Чтобы убедиться, что у вас достаточно информации для расследования, вам следует предпринять несколько ключевых шагов:

Убедитесь, что на контроллерах доменов и клиентских компьютерах установлены самые новые пакеты обновлений и исправлений.
Настройте компьютеры для сбора данных:
- включите аудит на доменном уровне;
- включите ведение журнала Netlogon;
- включите ведение журнала Kerberos.
Анализируйте данные из файлов журналов событий и файлов журнала Netlogon. Это поможет определить, где и по какой причине происходят блокировки.
Проанализируйте журналы событий на компьютере, который генерирует блокировки учетной записи, чтобы определить причину.

Факторы, которые следует учитывать в политике блокировки

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

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

Блокировка учетных записей Active Directory — это настолько распространенное явление и такой источник фрустрации для сетевых администраторов, что для решения этой проблемы были специально созданы несколько инструментов. Некоторые из них предоставляются Microsoft, а другие являются предложениями сторонних разработчиков. Вот список лучших из них:

Программные средства Account Lockout Status

Это стандартный набор инструментов, который Microsoft предоставляет для управления блокировкой учетных записей Active Directory. Он состоит из ряда отдельных компонентов.

Каждый из них поможет вам исследовать различные аспекты вашей сети:

ADLockouts

Это простая программа, которая пытается отследить источник попыток ввода неверного пароля, приведший к блокировке Active Directory.

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

PowerShell

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

Get-EventLog

Заключение

Если вы сетевой администратор, то вам наверняка не нужно объяснять, сколько хлопот доставляет блокировка учетных записей Active Directory. Учитывая это, возникает соблазн просто рассматривать блокировку учетных записей как неотъемлемую функцию Active Directory и автоматически разблокировать учетные записи пользователей, как только вы получите запрос в службу поддержки.

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

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

Читайте также: