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

Под учеткой сервисов нет на сервере. Да и какой сервис будет проверять в произвольное количество времени пароль на контроллере. Тем более что он не менялся с последнего времени, а значит три недели работало нормально, а две недели назад стало не нормально. =)
Мистика.

Добавление от 01.09.2009 01:20:

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

Самое интересное, что блочится только моя учетная запись, у других проблем нет. При этом, сегодня вот пришел и не смог залогиниться - учетка УЖЕ была заблокирована. Но с моей учетки никто точно не сидит.

Итак, у меня теперь сомнения, что дело реально в вирусе. Вот, что удалось выявить.

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

В домен-контроллере есть лог:

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

В логах на файловом сервере появилось

Тут интересна строчка
Logon Process: Advapi
Caller Process ID: 628

Процесс 628 - это w3wp.exe или же IIS. Есть какие-то мысли по этому поводу? На сервере действительно есть веб сервер с рабочим IIS. Но в каком месте он пытается использовать учетку - не ясно.

Вопрос в том, почему и с какой стати IIS на сервере стал использовать учетку будучи запущенным под системным серверным аккаунтом в модуле Advapi. По ссылкам ответа на этот вопрос нет.
Первая ссылка так вообще о домен-контроллере, это последний шаг, домен контроллер три раза получает обращение аутендефикации и блокирует учетку, пишет в лог, что был несанкционированный доступ от файлового сервера.

Добавление от 02.09.2009 12:02:

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

Добавление от 02.09.2009 14:57:

Нашел проблему - какая-то дрянь или глюк IIS использовала ананимус аккаунт веб сервера, который был собственно аккаунт из АД. Самое интересное, что анонимус аккаунт был отключен, но при этом все равно использовался. Интересно и то, что используется он только тогда, когда юзер заходит на сайт, то есть сама эта фигня не живет своей жизнью, а два раза посылает анонимус запрос AD от веб сервера в момент обращения к веб серверу другими пользователями.

Как такое возможно?

какая-то дрянь или глюк IIS использовала анонимэс аккаунт
Девелоперам и техам руки вырвать, поразить в правах, и выгнать с волчьим билетом. Без пособия.

События из логов следует приводить полностью и без отсебятины.

PowerUser
Спасибо большое за помощь.
Да, уже все проверено-перепроверено. Как я ранее сказал галка анонимного пользователя ВСЕГДА была отключена, а аккаунт блочился, потому что в дизейбленных полях он был прописан, понимаете? То есть даже при отключенном анониме сайт пытается обращаться с него - это странно. в метабазе тоже ничего не смог найти. Пока что помогло решить проблему лишь то, что включил анонима, изменил прописанный там аккаунт на несуществующий и снял обратно. Теперь в логах сервера просто пишется,что такого аккаунта нет, но хотя бы старый аккаунт перестал блокироваться.

В web.config проставлено

Добавление от 03.09.2009 16:05:

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

Копать в сторону включения аудита на КД и поиска событий сетевого входа в журнале безопасности КД. Номера нужных событий - 4781 и 4624. Там, в событиях, будет указано, какой IP-адрес у машины, с которой была предпринята попытка подключения. Для правильного поиска, нужно сопоставить параметр LogonID - в искомых событиях он будет совпадать.

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

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

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

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

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

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

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

• Вирус герпеса имеет запах
• Гуанчжоу есть ли там вирус
• У мужа гепатит от чего он может появиться
• Вакцинация гепатита в детям по нарушенной схеме
• Воспаление слюнной железы при гриппе