Tw-city.info

IT Новости
96 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Блокируется учетная запись в домене определить

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

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

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

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

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

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

  • Account lockout threshold (Пороговое значение блокировки) – через сколько неудачных попыток набора пароля учетная запись должна быть заблокирована
  • Accountlockoutduration (Продолжительность блокировки учетной записи) – на какое время будет заблокирована учетная запись (по истечении этого времени блокировка будет снята автоматически)
  • Resetaccountlockoutcounterafter (Время до сброса счетчика блокировки)– через какое время будет сброшен счетчик неудачных попыток авторизации

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

Довольно полезную информацию о времени блокировки, задания пароля, количестве попыток набора пароля и прочее можно получить в свойствах учетной записи в консоль ADSIEdit или на дополнительной вкладке Additional Account Info в свойствах пользователя (проще).

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

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

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

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

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

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

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

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

Можно воспользоваться следующим 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 <$_.Computer + " " +$_.Properties[1].value + ' ' + $_.TimeCreated>
>

Выявляем программу, причину блокировки учетной записи в AD

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

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

  1. Монтирование сетевого диска через net use (Map Drive)
  2. В заданиях планировщика Windows (Task Scheduler)
  3. В службах Windows, которые настроены на запуск из-под доменной учетной записи
  4. Сохранённые пароли в менеджере паролей в панели управления (Credential Manager)
  5. Браузеры
  6. Мобильные устройства (например, использующееся для доступа к корпоративной почте)
  7. Программы с автологином
  8. Незавершенные сессии пользователя на других компьютерах или терминальных серверах
  9. И др.

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

Блокируется учетная запись в домене определить

Вопрос

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

Есть практические идеи по диагностики и устранению проблемы?

Ответы

  • Помечено в качестве ответа a_loki 3 марта 2010 г. 9:20

Все ответы

  • Изменено a_loki 2 марта 2010 г. 9:27

Аудит включен(Успех, отказ).

  • Помечено в качестве ответа a_loki 3 марта 2010 г. 9:20

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

я у себя никак не могу найти виновника, 3 день учетка лочится. вирусов нет.

примерно в то же время, как это происходит, в логах следующее:

Имя журнала: System

Дата: 25.08.2011 9:40:56

Код события: 1012

Удаленный сеанс от клиента по имени a превысил максимальное число неудачных попыток входа. Сеанс был принудительно завершен.

Читать еще:  Доменная политика паролей

но непонятно что и куда ломится

проблема в том, что в это время юзера нет за компом, и происходит авторизация. как это прекратить?) Общий алгоритм:
1. Обязательная offline -проверка на вирусы с загрузочного CD/DVD.
2. Проверка Task Scheduler на данной машине — нет ли заданий.
3. Проверка logon-скриптов рабочей станции — любые действия с указанием данного пользователя.

Если нечего больше делать и хочется «развлечься»: раздел «The ALockout.dll Tool» по ссылке. Я рекомендую всё же пройтись по трём пунктам выше.

это все было проверено, и ничего не выявлено

переввел машину в домен, 3 дня полет нормальный

опять начала блокироваться учетка, та же самая.

что характерно: было 2 компа у меня таких, первый вылечился полной переустановкой. у обоих компов (Windows 7) было замечено следующее —

на нормальных — когда юзер залочен (Win+L), нажимаем ctrl+alt+del, автоматом выбирается та учетка, которая залочена и сразу курсор находится в поле ввода пароля.

на тех, где учетка блокируется в АД — после ctrl+alt+del, приходится мышкой выбирать иконку залоченого пользователя, только потом уже набирать пароль.

в аттачах 2 скриншота, надеюсь будет понятнее, проверте пжста у себя есть такое или нет.

поэтому у меня подозрение на баги самой windows, winlogon

Решаем проблему внезапной блокировки учетной записи

Архив номеров / 2009 / Выпуск №11 (84) / Решаем проблему внезапной блокировки учетной записи

МИХАИЛ ДАНЬШИН, эксперт в области ИТ. Специализируется на Exchange и смежных технологиях. Ведет блог (http://danshin.ms), выступает на конференциях и в MCP-клубе.Награжден премией Microsoft MVP

Решаем проблему
внезапной блокировки учетной записи

Доводилось ли вам сталкиваться с тем, что пользователи не могут войти в компьютер? Что же делать, если учетная запись существует, она не отключена, да еще и пароль правильный?

Иногда возникают ситуации, когда при попытке входа в компьютер пользователь получает сообщение:

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

Оказалось, что данная тема актуальна до сих пор. И мне постоянно приходится отвечать на вопросы не только начинающих, но и опытных администраторов.

Сообщение о блокировке учетной записи выглядит, как показано на рис 1.

Рисунок 1. Сообщение об ошибке, которое получает пользователь с заблокированной учетной записью

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

Для того чтобы определить политику, запустите Group Policy Management Consoleю. По умолчанию политика выглядит так, как показано на рис. 2.

Рисунок 2. Политика Account Lockut Policy по умолчанию

Предположим, что вы хотите ограничить количество неправильных вводов пароля пятью попытками, а потом блокировать акаунт на 30 минут. Для этого вам нужно отредактировать Default Domain Policy (помним, что политики паролей в доменах Win 2003 применяются к уровню домена). Выберите Computer Configuration -> Windows Settings -> Security Settings -> Account Policy -> Account Lockout Policy. Затем отредактируйте параметры групповой политики. Значение параметров:

  • Account lockout duration – определяет время, на которое акаунт будет заблокирован.
  • Account lockout threshold – определяет количество попыток ввода, после которого акаунт будет заблокирован.
  • Reset account lockout counter after – определяет время, по истечении которого будет сброшен счетчик попыток. Например, если вы определили, что после пяти попыток акаунт будет заблокирован, а сделали только две попытки входа, а потом, например, ушли пить чай, то по истечении этого установленного времени счетчик обнулится, и у вас опять будет пять попыток.

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

Рисунок 3. Значения, которые предлагает система

Вы можете согласиться, а потом при необходимости изменить их по своему усморению. Например, если вы установите значение параметра Account lockout threshold, соответствющее 5, а затем нажмете OK, то система предложит вам 30-минутное значение для остальных параметров, как показано на рис. 3.

После того как политика будет определена, вы можете известить ваших пользователей о том, что после того как они введут неверный пароль несколько раз, их учетная запись будет заблокирована (locked). Чтобы снять блокировку, нужно снять галочку Account is locked out в свойствах пользователя, как показано на рис. 4.

Рисунок 4. Account is locked out в свойствах пользователя

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

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

В журнале безопасности для отслеживания подобных событий существует запись с кодом 680 от источника Security категории Account Logon. В этой записи (см. рис. 5) показана информация о том, в какое время и с какого компьютера была предпринята попытка ввода неверного пароля. Конечно, есть способ реагировать на событие немедленно. Я писал о нем в статье «Как отреагировать на событие?» [1].

Рисунок 5. Вид сообщения из «Журнала Событий»

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

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

В решении проблемы нам может помочь утилита Microsoft Account Lockout Status, которая входит в пакет утилит Account Lockout and Management Tools. Получить этот пакет можно на сайте Microsoft3. Утилита была выпущена еще в 2003 году. Удивительно, что спустя много лет она все еще востребована.

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

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

Чтобы приступить к работе с утилитой, вам нужно запустиь файл LockoutStatus.exe. Когда программа запустится, выберите меню File, а затем Select Target. В появившемся диалоговом окне (см. рис. 6) в поле Target User Name введите имя пользователя, у которого возникает проблема с учетной записью, а в поле Target Domain Name введите имя домена, в котором находится учетная запись пользователя.

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

Обратите внимание на галочку – Use Alternate Credentials. В случае если программа запущена с правами обычного пользователя, то, установив эту галочку, вы можете запустить проверку от имени другого пользователя, входящего в группу «Администраторы домена». Если же вы запустили программу от имени пользователя с правами доменного администратора, то устанавливать галку не нужно.

После непродолжительного процесса сбора информации вы увидите результаты работы, в которых будет отражено, на каком контроллере домена была заблокирована запись, в какое время, сколько попыток ввода неверного пароля было предпринято и т.д. Все это показано на рис. 7.

Рисунок 7. Результат работы программы

Из меню этой же программы вы можете снять блокировку с учетной записи. Для этого выберите контроллер домена, нажмите правую кнопку мыши и в контекстном меню выбирите Unlock Account (см. рис. 8).

Читать еще:  Изменение часового пояса в домене

Рисунок 8. Снимаем блокировку с учетной записи

Это изменение моментально будет реплицировано на все контроллеры домена, и пользователь может тут же повторить попытку входа. Если пользователь забыл пароль, то, выбрав Reset User’s Password, вы можете его сменить.

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

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

Второй распространённый вариант – это использование одной учетной записи несколькими пользователями одновременно. В этом случае кто-то может постоянно вводить неверный пароль и тем самым мешать работе остальных пользователей.

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

Как видно на рис. 7, программа сообщает нам эти сведения. Надо щелкнуть правой кнопки мыши по контроллеру домена и выбрать в контекстном меню Open Event Viewer (открыть журнал событий). Так как мы теперь знаем точное время, когда была попытка входа, которая привела к блокировке учетной записи, мы без труда сможем найти событие и определить, с какого компьютера было произведено действие, повлекшее блокировку. Проблема решена – виновные наказаны!

Но кроме человеческого фактора, есть еще и другие причины. Пожалуй, самая распространенная причина – это когда вы настраиваете «Назначенное Задание», которое выполняется от имени пользователя, затем меняете пароль этого пользователя, а ваше задание все еще пытается выполнить вход со старым паролем. Естественно, у него это не получается, и акаунт блокируется.

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

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

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

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

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

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

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

  • Account lockout threshold (Пороговое значение блокировки) – через сколько неудачных попыток набора пароля учетная запись должна быть заблокирована
  • Accountlockoutduration (Продолжительность блокировки учетной записи) – на какое время будет заблокирована учетная запись (по истечении этого времени блокировка будет снята автоматически)
  • Resetaccountlockoutcounterafter (Время до сброса счетчика блокировки)– через какое время будет сброшен счетчик неудачных попыток авторизации

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

Довольно полезную информацию о времени блокировки, задания пароля, количестве попыток набора пароля и прочее можно получить в свойствах учетной записи в консоль ADSIEdit или на дополнительной вкладке Additional Account Info в свойствах пользователя (проще).

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

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

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

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

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

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

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

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

Можно воспользоваться следующим 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

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

$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 <$_.Computer + " " +$_.Properties[1].value + ' ' + $_.TimeCreated>
>

Выявляем программу, причину блокировки учетной записи в AD

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

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

  1. Монтирование сетевого диска через net use (Map Drive)
  2. В заданиях планировщика Windows (Task Scheduler)
  3. В службах Windows, которые настроены на запуск из-под доменной учетной записи
  4. Сохранённые пароли в менеджере паролей в панели управления (Credential Manager)
  5. Браузеры
  6. Мобильные устройства (например, использующееся для доступа к корпоративной почте)
  7. Программы с автологином
  8. Незавершенные сессии пользователя на других компьютерах или терминальных серверах
  9. И др.

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

  • Audit process tracking: Success , Failure
  • Audit logon events: Success , Failure
Читать еще:  Как пронумеровать страницы в word 2020

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

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

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

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

DmitSh

Blog about IT.

Блокировка учетной записи Event ID: 529, 680

Системным администраторам часто приходится сталкиваться с проблемой блокировки учетной записи пользователя. Часто причиной блокировки учетной записи является банальная невнимательность или забывчивость пользователя. Но иногда бывают случаи когда пользователь не имеет отношения к блокировки учетной записи. В данной заметке описан один из таких случаев. Один из пользователей стал жаловаться что с утра прийдя на работу не может зайти на свой компьютер под своей учетной записью. Посмотрев в консоле Active Directory — пользователи и компьютеры свойства учетной записи выяснил что запись была заблокирована. Разблокировал запись. В течении дня учетная запись пользователя снова заблокировалась. Стал выяснять что стало причиной блокировки учетной записи. Для начала запустил утилиту LockoutStatus.exe из набора утилит ALTools, для определения контроллера домена (КД) на котором запись была заблокирована. Запускаем утилиту LockoutStatus.exe последовательно выбираем меню File->Select Target… в открывшемся окне вводим в поле Target User Name — имя заблокированной учетной записи, в поле Target Domain Name — имя домена. Так же можно указать альтернативные учетные данные для доступа к каталогу AD.

Затем нажимаем OK и ждем завершения процесса сбора данных. После окончания сбора данных в окне программы будут отображены имена всех КД в данном домене и информация о состоянии учетной записи на каждом из них. Интересующая нас информация распологается в столбцах: Last Bad Pwd — время когда пользователь последний раз неправильно ввел пароль и Orig Lock — имя КД на котором выполнилась блокировка учетной записи пользователя.

Определив время и КД на котором была заблокирована учетная запись переходим к поиску причины блокировки записи. Основным источником информации о блокировки является журнал «Безопасность» на КД (при условии что включена политика аудита). Открываем журнал «Безопасность» на КД, это можно выполнить непосредственно из утилиты щелкнув правой клавишей мыши по строке с нужным КД и в открывшемся контекстном меню выбрать пункт «Open Event Viewer«. В журнале «Безоспасность», времени блокировки записи, соответствовали две записи аудита отказов с кодами событий 680 и 529. Событие с кодом 680 не дает много полезной информаци, а вот событие с кодом 529 более информативно.

Тип события: Аудит отказов
Источник события: Security
Категория события: Вход/выход
Код события: 529
Дата: 2011-05-17
Время: 08:53
Пользователь: NT AUTHORITYSYSTEM
Компьютер: SRV-MAIL
Описание:
Сбой входа в систему:
Причина: неизвестное имя пользователя или неверный пароль
Пользователь: smirnaya@domen.ru
Домен:
Тип входа: 3
Процесс входа: Advapi
Пакет проверки: Negotiate
Рабочая станция: SRV-MAIL
Имя вызывающего пользователя: SRV-MAIL$
Домен вызывающего: DOMEN
Код входа вызывающего: (0x0,0x3E7)
Код процесса вызывающего: 5524
Промежуточные службы: —
Адрес сети источника: —
Порт источника: —

Из события видно что причиной блокировки учетной записи является неправильно введеный пароль т.к. имя учетной записи указано верно. Но не указан адрес источника, но есть код вызываещего процесса. Данный код процесса соответсвует процессу inetinfo.exe. На данном КД так же расположен Exchange сервер и настроен Outlook Web Access. Проверив все настройки на данном сервере обнаружить причину блокировки записи не удалось. В логах Exchange много различных записей и разобрать является ли причиной вход на Exchange не представлялось возможным.

Использование Debugging Tools For Windows

Для того чтобы определить что же является причиной блокировки учетной записи воспользуемся утилитами Debugging Tools For Windows для отладки работы процесса inetinfo.exe. Я использую версию 6.11.1.404 . Cкачиваем желаемую версию и устанавливаем на наш контроллер домена. Для работы отладчика необходим набор символов (symbols). Скачиваем с сайта [3] набор символов для своей версии операционной системы. Скачав набор символов распаковываем его в папку c:symbols и переходим к работе с отладчиком. Идем в меню Пуск->Все программы->Debugging Tools for Windows (x86)->WinDbg. Перед началом работы необходимо указать путь от куда отладчик будет брать набор символов, для этого идем в меню File->Symbol File Path.. В открывшемся окне нажимаем кнопку Browse и указываем папку куда был установлен набор символов. У меня это папка C:Symbols.

Затем переходим непосредственно к отладке процесса inetinfo.exe для этого в окне программы WinDbg выбираем в меню File->Attach to a Process… В открывшемся дереве процессов находим процесс inetinfo.exe выбираем его и нажимаем OK. Запустится окно отладчика WinDbg в нем последовательно вводим следующие команды:
.symfix c:symcache
bp ADVAPI32!LogonUserA «k 100;.time;g»
g

По прошествии некоторого времени в журнале безопасности было зарегистрировано новое событие с id 529. Используя время записи события в журнале смотрим какое событие было в данное время в окне отладчика WinDbg. Времени возникновения события соответсвуют следующие записи в отладчике:
Как видно из отладочной информации причиной блокировки учетной записи является почтовое сообщение которое кто то пытается отправить через наш SMTP серер. Теперь необходимо выяснить какая служба или хост пытается отправить письмо от имени пользователя и с какого хоста идет соединение. Для определения откуда исходит проблема я воспользовался сетевым снифером Wireshark. Скачиваем и устанавливаем снифер на сервер. Запускаем Wireshark и ждем когда в журнале безопасности будет зарегистрировано новое событие с кодом 529. После регистрации события останавливаем захват трафика. Т.к. записий довольно много то для более быстрого поиска необходимой информации используем фильтр для этого в панели фильтра (View->Filter Toolbar) нажимаем Expression. В отрывшемся окне настроек фильтра устанавливаем курсов на любое поле окна Field name и вводим нужный нам протокол SMTP:

Раскрываем содержимое протокола SMTP и выбираем параметр smtp.rsp.parameter — Response parametr в поле Relation выбираем constains в поле Value вводим строку Authentication unsuccessful и нажимаем кнопку OK.

Затем применяем наш фильтр нажав на кнопку Apply на панели фильтра. После применения фильтра будут отображены только пакеты удовлетворяющие нашему фильтру. Щелкаем по одному из показанных пакетов правой клавишей мыши и в открывшемся контекстном меню выбираем пункт Follow TCP Stream:

Будет отображен весь процесс SMTP сессии с нашим почтовым сервером. Необходимо убедиться что данная SMTP сессия соответствует искомой учетной записи. Учетные данные отображаются в кодировке Base64. Нас интересуют два основных поля сессии, это ip — адрес клиентского компьютера и имя пользователя. Если с определением ip адреса проблем не возникает, то для определения имени пользователя необходимо использовать Base64 Decoder. Копируем строку содержащую логин пользователя см. рис. и декодируем ее на сайте.

Как видно из следующего рисунка пользователь оказался именно тем который нужен.

Соотвественно из SMTP -сессии определяем что отправка почты от имени пользователя происходит с клиентской машины с ip — адресом 192.168.1.1. Если клиентская машина является частью корпоративной сети, то возможно она заражена (в моем случае служба rphost.exe — 1C Предприятие, пыталась отправить почту от имени пользователя и использовала просроченный пароль) вирусом. Если ip-адрес не принадлежит корпоративной сети, то скорее всего идет подбор пароля учетной записи. Eof.

Ссылка на основную публикацию
ВсеИнструменты 220 Вольт
Adblock
detector