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

После смены пароля учётная запись пользователя начала блокироваться. Я пытался разбирать логи, в том числе с помощью PowerShell-скриптов, но объём логов огромен и ручной анализ нерентабелен; обращение к нейросетям тоже не дало результата. Цель — выяснить, какой клиент вызывает блокировки (мобильный клиент, классический Outlook и т.п.) и собрать максимально полную информацию, чтобы найти источник проблемы. Есть ли готовые решения или инструменты для автоматического анализа логов Exchange и IIS, которые помогут в расследовании?
  • 7 июля 2026 г. 9:01
Ответы на вопрос 2
Коротко — алгоритм расследования и набор инструментов, которые реально помогают быстро найти «что именно» и «какой клиент» вызывает блокировки.

1) Общее правило — сначала найти событие блокировки в контроллере домена
- На контроллере домена ищите событие 4740 (Account locked out). В нём есть время блокировки и иногда имя вызывающего компьютера.
- Запишите точное время блокировки (UTC/Local) — дальше будем коррелировать логи по этому времени.

2) Коррелируйте с событиями неудачных аутентификаций на контроллерах
- Ищите 4625 (Failed logon), 4771/4776 (Kerberos/NTLM failures) вокруг времени 4740.
- У 4625 в полях будет Source Network Address (IP) и Workstation name; у 4625/4771 часто есть Logon Type (3 = network, 10 = remote interactive/RDP и т. п.) — это помогает понять, откуда пришёл запрос.
- Если есть KDC/TGS ошибки (4771) — включите расширенное KDC-логирование на контроллерах, чтобы получить больше деталей.

3) Поиск в логах Exchange/IIS — где чаще всего «стреляет» старый пароль
- На сервере Exchange смотрите IIS W3C логи (обычно %SystemDrive%\inetpub\logs\LogFiles\W3SVC*) и логи Exchange (EAS, OWA, EWS, RPC/HTTP, MAPI over HTTP) в папке Exchange\Logging.
- В IIS-логах важные поля: date time c-ip cs-method cs-uri-stem cs(User-Agent) cs-username sc-status sc-substatus sc-win32-status. Ищите sc-status 401/403, cs-username = affectedUser (или анонимные 401 при попытках NTLM).
- По URI можно понять клиентский протокол:
  - /Microsoft-Server-ActiveSync/  — ActiveSync (мобильные устройства).
  - /autodiscover/autodiscover.xml  — Autodiscover (Outlook, мобильные клиенты).
  - /ews/exchange.asmx  — EWS (Outlook, сторонние клиенты).
  - /rpc/rpcproxy.dll  — RPC over HTTP / Outlook (старые версии).
  - /mapi/*, /mapi/emsmdb/*  — MAPI over HTTP / Outlook.
  - /owa/  — OWA веб-клиенты.
- User-Agent часто прямо указывает устройство/программу: Outlook/16.0, Apple-iPhone, Android, Microsoft-HTTPAPI, etc.

4) Как быстро найти подозрительные записи (инструменты и примеры запросов)
- Log Parser (Microsoft) / Log Parser Studio — очень эффективны для быстрых агрегатов по IIS-логам.
  Пример LogParser (SQL-подобный) для подсчёта 401 по User-Agent и IP:
  SELECT cs-username, c-ip, cs(User-Agent), cs-uri-stem, COUNT(*) AS Hits
  FROM C:\inetpub\logs\LogFiles\W3SVC*\u_ex*.log
  WHERE sc-status = 401 AND cs-username = 'domain\\user'
  GROUP BY cs-username, c-ip, cs(User-Agent), cs-uri-stem
  ORDER BY Hits DESC
- PowerShell: можно фильтровать по имени пользователя и статусу:
  Get-ChildItem "C:\inetpub\logs\LogFiles\W3SVC*\*.log" | Select-String -Pattern "domain\\user" | Where-Object { $_ -match " 401 " } | Out-File C:\temp\user_401.txt
  (Это грубо, но быстро даёт выборку; дальше парсить строки в колонки.)
- Splunk / ELK / Graylog / LogRhythm / SIEM: лучшее решение, если у вас большой объём логов. Простая дашборд-запрос по username + status=401 + группировка по c-ip и User-Agent быстро выдаст виновника.

5) Дополнительные источники данных
- Exchange ActiveSync device list (Get-MobileDevice/Get-MobileDeviceStatistics) — покажет зарегистрированные устройства.
- Autodiscover/Outlook-клиенты: в IIS-логах User-Agent + cs-uri-stem (Autodiscover) укажут, что Outlook пытается авторизоваться повторно.
- Если у вас гибрид/Office 365 — посмотрите Azure AD sign-in logs (они покажут IP, client, app, reason).
- DHCP/Firewall прокси/NGINX — сопоставьте подозрительный внутренний IP с устройством (DHCP leases, ARP, MAC).
- Если IP внешний — у вас есть шанс увидеть ASN/geo по IP и понять, это пользователи или сканер.

6) Частые причины и как их распознать по логам
- Мобильное устройство с сохранённым старым паролем: многократные 401 с URI = /Microsoft-Server-ActiveSync и User-Agent мобильного устройства.
- Outlook с cached credentials/старый профиль: 401 с URI = /ews/exchange.asmx или /rpc/rpcproxy.dll и User-Agent Outlook.
- Сервис/задача/скрипт на сервере: повторяющиеся 4625/4624 с Logon Type = 3 и IP адресом сервера.
- Старая сессия на планшете/принтере/сканере/переадресаторе почты — ищите необычные User-Agent или IP в логах.

7) Полезные готовые инструменты/решения
- Бесплатные от Microsoft:
  - Account Lockout and Management Tools (включает LockoutStatus.exe, EventCombMT) — помогает быстро найти события блокировок по DC (отсюда стартовать).
  - Log Parser + Log Parser Studio — парсинг IIS и других текстовых логов.
  - Microsoft Message Analyzer был снят, но Log Parser остаётся рабочим инструментом.
- SIEM/лог-агрегаторы (платные/организационные):
  - Splunk, Elastic Stack (ELK), Graylog, Microsoft Sentinel — подключаете IIS/Exchange/AD логи и делаете корреляцию, алерты и дашборды.
- Коммерческие продукты для анализа блокировок/аудита:
  - ManageEngine ADAudit Plus, Netwrix Auditor, Quest Change Auditor — имеют встроенные отчёты по блокировкам/неудачным аутентификациям.
- Если у вас Exchange Online / Hybrid — используйте Azure AD Sign-in logs + Identity Protection в Azure portal.

8) Практические шаги для вас сейчас (шаг за шагом)
1. На DC найдите событие 4740 — зафиксируйте время.
2. На всех DC в тайм-окне ±5 мин от 4740 соберите 4625/4771/4776 — запишите IP, Workstation, Logon Type.
3. На Exchange/Client Access серверах grep-ом/LogParser’ом вытащите строки IIS с cs-username = user и sc-status = 401/403 в том же окне времени.
4. Агрегируйте по c-ip и cs(User-Agent) — кто чаще всего вызывает 401.
5. По c-ip сверяйте DHCP/firewall/AD (NetBIOS/hostname) — найдите устройство.
6. Если IP внешний — проверьте Azure AD sign-ins (если гибрид) и провайдеры/ендпоинты.
7. Исправление: удалить старые сохранённые креды, принудительно выйти/удалить профили ActiveSync, сбросить/перезавести сервисы или заблокировать IP на сетевом уровне до выяснения.

9) Несколько практических советов/ловушек
- Блокировки могут происходить не сразу при первой неудаче — сервисы часто делают многократные попытки.
- Имя компьютера в 4740 не всегда корректно — чаще надёжнее привязка по IP через события 4625/IIS.
- OAuth/Modern Auth не всегда отображает cs-username в IIS; для них смотреть Azure AD/STS логи.
- Не забывайте про сервисы на серверах (службы/планировщик задач/пул приложений IIS), они часто хранят старые пароли.

Если нужно, могу:
- Прислать готовые LogParser и PowerShell-скрипты, которые автоматически: 1) по заданному пользователю ищут 4740/4625/4771 по DC, 2) парсят IIS-логи и агрегируют по IP и User-Agent, 3) выводят краткий отчёт «IP — UserAgent — URI — count — первые/последние времена». Напишите, какие версии Exchange/Windows у вас (он‑премис/гибрид/Exchange Online), и я подготовлю скрипты под вашу среду.
netwrix account lockout examiner, самый быстрый вариант: копает автоматом, без ручного парсинга логов. Руками — событие 4740 на pdc emulator, поле Caller Computer Name сразу укажет источник блокировки. Тип клиента (мобила или десктопный outlook) видно в iis-логах по User-Agent на 401-х: activesync это мобила, mapi/outlook anywhere это десктоп.
Похожие вопросы