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

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

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

Сегодняшняя статья пригодится в первую очередь корпоративным пользователям компьютеров на базе Windows, работающим со стандартными локальными учётными записями. Тогда как вход в учётные записи со статусом администратора могут выполнять только доверенные лица компании в виде сотрудников IT-раздела. Хотя при определённом семейном микроклимате с описываемой ниже проблемой можно столкнуться, используя домашние устройства. Что же за проблема такая? А это невозможность доступа к Windows с уведомлением на экране блокировки «Учётная запись пользователя заблокирована и не может быть использована для входа в сеть». Что за блокировка такая, и как с ней бороться?

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

Итак, не можем войти в Windows, потому что на экране блокировки видим это.

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

Блокировка учётных записей Windows

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

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

При установке такого порогового значения другие параметры политики – время до сброса счётчика блокировки и длительность самой блокировки – автоматически будут установлены на 30 минут.

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

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

Распространяется такая защита только на локальные учётки и не работает при попытках подбора пароля или пин-кода для подключённых аккаунтов Microsoft.

Разблокировать заблокированную учётную запись можно несколькими путями:
• Дождаться завершения времени блокировки. Но здесь есть нюанс: сколько времени нужно ждать, система не уведомляет. Об этом знает только администратор компьютера;
• Войти в систему с учётки администратора и снять блокировку;
• Если доступ к учётке администратора невозможен, снять блокировку, загрузившись со съёмного устройства и подправив кое-что в реестре Windows.

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

Если своя учётка заблокирована, но есть доступ к учётке администратора, необходимо войти в последнюю и разблокировать свою таким образом. Жмём клавиши Win+R, вводим:

В открывшемся окне в папке «Пользователи» ищем свою учётную запись и делаем на ней двойной клик.

В окошке открывшихся свойств снимаем галочку «Заблокировать учётную запись». Применяем.

Пробуем войти в свою учётку.

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

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

Если доступа к учётной записи администратора нет, добываем DVD-диск или флешку с процессом установки любой версии Windows или Live-диск с возможностью правки реестра операционной системы. Загружаем компьютер со съёмного устройства, в нашем случае это флешка установки Windows 10. Важно: запуск со съёмного устройства должен проводиться только при перезагрузке систем Windows 8.1 и 10. Нельзя использовать обычное завершение работы, поскольку в этих версиях из-за функции ускоренного запуска системное ядро загружается из ранее сохранённого на диске файла. Нам же нужно, чтобы ядро загрузилось с изменёнными параметрами реестра.

На первом этапе установки Windows жмём Shift+F10. Запускаем реестр командной строкой:

Кликаем раздел HKEY_LOCAL_MACHINE. Далее жмём меню «Файл», здесь нам нужен пункт «Загрузить куст».

В окне обзора выходим в корень устройств «Этот компьютер» и заходим в раздел Windows. У нас он обозначен как диск (C:), но диск системы также может значиться и под другой буквой. Тут нужно ориентироваться по объёму раздела. На системном разделе раскрываем папки «Windows», далее – «System32», далее – «config». Внутри последней нам нужен файл SAM, это так называемый куст реестра, открываем его.

Открытый куст нужно как-то назвать, имя непринципиально. Назовём его 777.

Внутри раздела реестра HKEY_LOCAL_MACHINE теперь наблюдаем новую ветвь 777. Раскрываем внутри неё путь:
777 – SAM – Domains – Account – Users – Names

Находим имя своей учётки в папке «Names». Нам, например, нужен пользователь Вася. Смотрим, что при выборе Васи отображается на панели реестра справа. У нас значение 0x3f8. Такое же значение, но только в ином формате написания — с лишними нулями спереди и капсом – ищем теперь выше, внутри папки «Users».

Ставим курсор теперь на это значение с нулями и капсом. В правой панели реестра ищем параметр «F» и двойным кликом раскрываем его.

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

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

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

Перезагружаемся. И можем снова пытаться войти в свою учётку. Друзья, если блокировка вашей учётки – это следствие превышения допустимого числа авторизаций из-за того, что вы забыли пароль (или его, возможно, сменил кто-то без вашего ведома), вы можете просто убрать пароль. Сделать это можно, в частности, тем же способом путём правки реестра со съёмного носителя, что описан выше, только там нужны чуть другие действия.

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

Вопрос

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

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

Ответы

• Помечено в качестве ответа 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

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

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

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

В том случае, если вы все-таки хотите хранить учетные данные для доступа к сетевым ресурсам в локальной сети, знайте, что в Windows 7 существует специальный менеджер Credential Manager. Данный менеджер позволяет хранить авторизационные данные для доступа к серверам, сетевым папкам и дискам, сайтам и т.д.

Чтобы в Windows 7 познакомиться со списком пользователей, для которых система уже хранит имена и пароле, необходимо открыть: Control Panel >All Control Panel Items > Credential Manager.

Перед вами появится список сетевых ресурсов, для которых в вашей системе хранятся данные доступа.

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

Отсюда же можно изменить имя пользователя/пароль.

Либо же удалить сохранённую информацию.

Менеджер паролей также позволяет выполнить резервное копирование и восстановление сохраненных учетных данных (кнопки Back up Vault и Restore Vault).

В том случае, если доступ к менеджеру паролей закрыт (это может сделать администратор через групповую политику), Credential Manager можно открыть из командной строки (работает и в Windows XP и в Windows 7).

Для этого в командной строке наберите:

В появившемся окне Stored User Names and Passwords, возможно выполнение все тех же процедур по управлению хранимыми паролями.

Вы можете задать вопрос по статье специалисту.

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.