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

Понедельник, как известно, день тяжелый. Поэтому в конце рабочего дня мне позвонили из соседнего филиала и попросили помочь: «сегодня начались массовые блокировки топ-менеджера, ранее работавшего в вашем филиале. Был найден компьютер, с которого происходит блокировка, заявку перекинули на вашу техподдержку. Можно ли как-то попросить их быстрее посмотреть?».

Источник блокировки был быстро найден благодаря SCOM Audit Collector — им оказался ноутбук NB022. Проблема была лишь в том, что коллеги из тех.поддержки уже сходили и проверили ноутбук, не найдя никаких следов блокируемого пользователя.

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

Наверное, вирус, подумали мы с руководителем техподдержки. Ноутбук был изъят у пользователя и загружен с флешки с убунтой для проверки антивирусом. На этом мы разошлись 🙂

Утро вторника принесло несколько вестей: вирусов на ноутбуке не было, а вот несколько блокировок опять состоялось с этого ноутбука. Ага, того самого, который отключен от сети и сидит под «левой» убунтой. Под покровом ночи!

Первым делом я проверил все контроллеры домена, что на них развернут агент SCOM и настроен сбор событий. Затем от безысходности поискал события с «логином» пользователя — ничего, только событие 4740 — пользователь заблокирован.

Ааааа 🙂

Начал гуглить вспоминать, что в этой ситуации должны делать администраторы Active Directory. О, Debug Netlogon.

Парам пам пам

07/05 14:41:04 [LOGON] [8808] DOMAIN: SamLogon: Transitive Network logon of DOMAIN\user from NB022 (via LYNC) Entered

07/05 14:41:04 [LOGON] [8808] DOMAIN: SamLogon: Transitive Network logon of DOMAIN\user from NB022 (via LYNC) Returns 0xC0000234

Посмотрел отказы аудитов на Skype For Business (далее S4B) сервере — действительно, пользователь лезет с ноутбука NB022 и не может авторизоваться.

Запустил логирование далее S4B с помощью CSClsLogger Gui, входящего в состав дебаггинг тулз для S4B. Нацелил его на этот сервер и на S4B Edge. Дождался очередного сеанса блокировки пользователя, после чего проанализировал «трассировку» с помощью Snooper (вторая утилита из дебаггинг тулз).

sip

И нашел замечательный публичный айпишник, с которого прилетают Request. По мнению гео-айпи-сервисов, это айпишник из Германии, Мюнхена. Сильно удивился, так как по специфике логона (старый sip-адрес пользователя) это не было похоже на хакерскую атаку. Сказал об этом пользователю — тот обрадовался и побежал куда-то звонить 🙂

Хэппи энд!

Поиск источника блокировки учетной записи: 2 комментария

  1. Доброго дня.

    А можете поделится настройками для SCOM Audit Collector, что снимаете (какие события).

    Спасибо.

  2. Current query: ‘select * from AdtsEvent WHERE ((EventID>=21 AND EventID=4722 AND EventID=4739 AND EventID=4743 AND EventID=4756 AND EventID=4764 AND EventID=4780 AND EventID=5136 AND EventID=5139) OR EventID=5141 OR EventID=5376 OR EventID=5377 OR EventID=6279)’

    Только не спрашивайте, что все это значит )))

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *