Что заставляет мой контроллер домена регистрировать десятки успешных попыток аутентификации в секунду?

У нас есть домен с около 15 серверов и около 30 рабочих станций. Серверы в основном 2008r2 и рабочие станции в основном Windows 7. Два DC 2012r2. Каждые несколько недель одна из наших учетных записей администратора блокируется. Я пытаюсь сузить причину, и я зашел в тупик.

Вот что у меня есть.

Журнал событий на PDC показывает событие 4776 - аудит успешен:

Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon Account:  username
Source Workstation: 
Error Code: 0x0

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

На основе идентификаторов событий это логины NTLM, а не Kerberos. Хотя тип используемой аутентификации менее беспокоит меня, чем величина сдвига. Это происходит несколько раз в секунду и повторяется каждые несколько секунд до бесконечности, все часы день или ночь или выходные.

Журнал событий также показывает события успеха ID 4624 (вход в систему) и 4634 (выход из системы) для этого имени пользователя, но, как и в случае выше, поле «рабочая станция» пусто.

Я включил подробное ведение журнала netlogon, и netlogon.log показывает

02/28 17:11:03 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation1) Entered
02/28 17:11:03 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation1) Returns 0x0
02/28 17:11:04 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation2) Entered
02/28 17:11:04 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation2) Returns 0x0
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via server1) Entered
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via server1) Returns 0x0
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via server2) Entered
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via server2) Returns 0x0
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation3) Entered
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation3) Returns 0x0
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation2) Entered
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation2) Returns 0x0
02/28 17:11:19 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation4) Entered
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation5) Entered
02/28 17:11:19 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation4) Returns 0x0
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation5) Returns 0x0
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via server3) Entered
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via server3) Returns 0x0
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via server4) Entered
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via server4) Returns 0x0

И так далее. Очевидный источник этих имен входа (через XYZ) может включать рабочие станции и серверы со всей сети.

Очевидно, это выглядит как автоматизация или сценарий. Поскольку вход в систему в целом успешен, я не верю, что это попытка вторжения. Однако некоторые входы в систему время от времени терпят неудачу, но я не определил какой-либо шаблон ошибки, и они происходят так редко, что (в большинстве дней) они не блокируют учетную запись. Код ошибки при его наличии обычно равен 0xc0000022 (доступ запрещен)

Я отключил и удалил наш агент удаленного мониторинга (в настоящее время Kaseya, но мы наконец-то переходим на LabTech) с одного из серверов, но все еще видел новые события, происходящие с этого сервера, поэтому это исключает задачи автоматизации. Я также проверил планировщик задач на нескольких серверах и не нашел ничего необычного. Я проверил службы для проверки учетных записей, и эта учетная запись не используется ни в каких службах.

Я долго запускал Netstat и видел в основном соединения с PDC из «System» и «System Idle Process». Я видел случайные соединения от spoolsrv, lsass и ismserv (сервер, на котором я тестирую, - это сервер Citrix XenApp, но другие «исходные» серверы не входят в ферму XenApp, и, конечно, «исходные» рабочие станции тоже нет). Я остановил службу диспетчера очереди печати только для проверки, и это не повлияло на события входа в систему.

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

Кто-нибудь испытывал что-то подобное раньше и смог определить источник?

active-directory windows-server-2008-r2 windows-server-2012-r2 Томас
источник

Для тех, кому интересно большое количество серверов, у них есть серверы XenApp с общедоступным SharePoint для высокопрофессиональной рабочей силы с BYOD. У них также был предыдущий ИТ-персонал, который немного перегружал свою инфраструктуру размером своего бизнеса. С тех пор, как они заключили с нами контракт, мы пытались немного их уменьшить, чтобы они соответствовали их потребностям.

Томас

Что-то, что вы можете попробовать, это установить Microsoft Network Monitor на одном из серверов, запустить захват, подождать, пока запись с сервера войдет в журнал netlogon, а затем посмотреть на захват и посмотреть, сможете ли вы найти диалог в Network Monitor. , Сетевой монитор должен показать вам процесс, ответственный за разговор. Если этого недостаточно, вы можете использовать Network Monitor вместе с Process Monitor для определения ответственного процесса.

Joeqwerty

Microsoft Network Monitor устарел и заменен Microsoft Message Analyzer. То же самое, что и Wireshark. Я запустил захват пакета и не нашел абсолютно ничего полезного. Единственными событиями, которые тесно связаны с событиями NetLogon, являются соединения WMI и RPC.

Томас

Да, NetMon устарела, но все же это хороший инструмент. Если вы раньше не использовали Message Analyzer, это может быть немного сложным. NetMon довольно прост и интуитивно понятен. Я обычно использую это прежде всего. Что касается вашего захвата, трафик RPC может содержать некоторые подсказки.

Joeqwerty

Да ничего. Отправлено одно связывание MSRPC, а получено Ack для создания зашифрованного сеанса, за которым следует отправка и получение пакета NRPC, содержащего запрос и ответ NetrLogonSamLogonEx, причем последние два шифруются. Вызывающим процессом на исходном компьютере является LSASS, который запускает службу Netlogon. В пакетных данных трафика Bind вообще нет полезных подробностей, и, конечно, зашифрованные пакеты для меня бесполезны.

Томас

Что заставляет мой контроллер домена регистрировать десятки успешных попыток аутентификации в секунду?

Ответы: