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

Учетная запись блокируется в течение 5 минут, кажется, около 1 запроса в минуту.

Первоначально я пытался запустить procmon (из sysinternals), чтобы увидеть, не появляется ли новый START PROCESS после того, как я разблокирую учетную запись. Ничего подозрительного не возникает. После запуска ProcMon на моей рабочей станции и повышения к UAC оболочки (conscent.exe), похоже из стека , что ntdll.dllи rpct4.dllполучить вызывается при попытке авторизовать против AD (не уверен).

Есть ли в любом случае, чтобы сузить, какой процесс вызывает запрос аутентификации для нашего DC? Это всегда один и тот же DC, поэтому мы знаем, что на этом сайте должен быть сервер. Я мог бы попытаться найти вызовы в Wireshark, но я не уверен, что это сузило бы, какой процесс фактически вызывает его.

Учетная запись домена также не используется ни службами, ни сопоставлением дисков, ни запланированными задачами, поэтому она должна быть сохранена. На любом сервере нет открытых сеансов RDP с этой учетной записью домена (мы проверили).

Дальнейшие заметки

Да, аудит входа в систему «Успех / Сбой» включен на соответствующем контроллере домена - события сбоев не регистрируются, пока учетная запись не будет фактически заблокирована.

Дальнейшее рытье показывает , что LSASS.exeделает KERBEROSвызов к DC в вопросе , как только счет будет разблокирован. Ему предшествует (как правило) java, которая, кажется, vpxd.exeвызывается процессом vCenter. НО, когда я смотрю на другой «server2», где может (также) может произойти блокировка учетной записи, я никогда не вижу вызова, lsass.exeи порождаются только процессы apache. Единственное отношение, которое они имеют, заключается в том, что SERVER2 является частью кластера vSphere SERVER1 (сервер1 является операционной системой vSphere).

Ошибка на DC

Так что, похоже, все, что мне скажет AD, это то, что это ошибка Kerberos перед авторизацией. Я проверил и не было билетов с klistи сделал флеш на всякий случай. До сих пор не знаю, что является причиной этой ошибки Kerberos.

Index              : 202500597
EntryType          : FailureAudit
InstanceId         : 4771
Message            : Kerberos pre-authentication failed.

                     Account Information:
                         Security ID:        S-1-5-21-3381590919-2827822839-3002869273-5848
                         Account Name:        USER

                     Service Information:
                         Service Name:        krbtgt/DOMAIN

                     Network Information:
                         Client Address:        ::ffff:x.x.x.x
                         Client Port:        61450

                     Additional Information:
                         Ticket Options:        0x40810010
                         Failure Code:        0x18
                         Pre-Authentication Type:    2

                     Certificate Information:
                         Certificate Issuer Name:
                         Certificate Serial Number:
                         Certificate Thumbprint:

                     Certificate information is only provided if a certificate was used for pre-authentication.

                     Pre-authentication types, ticket options and failure codes are defined in RFC 4120.

                     If the ticket was malformed or damaged during transit and could not be decrypted, then many fields
                      in this event might not be present.

События входа регистрируют процесс, пытающийся войти в систему. Включите неудачный аудит входа в систему (Параметры безопасности> Локальные политики> Политика аудита> Аудит событий входа в систему) в локальной политике безопасности (secpol.msc), а затем найдите в журнале событий безопасности событие. Вы также можете включить его через групповую политику, если это предпочтительнее.

Будет раздел «Информация о процессе», в котором будет записан как путь к исполняемому файлу, так и идентификатор процесса.

Пример:

Process Information:
    Process ID:         0x2a4
    Process Name:       C:\Windows\System32\services.exe

Я нашел этот старый вопрос при исследовании другой проблемы, но для тех, у кого похожая проблема:

Код ошибки 0x18 означает, что учетная запись уже была отключена или заблокирована, когда клиент пытался пройти проверку подлинности.

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

Затем вы можете посмотреть адрес клиента в этих событиях, чтобы увидеть, какая система передает неверные учетные данные. Оттуда вам придется выяснить, является ли это сервис со старым паролем, подключенным сетевым диском и т. Д.

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

Kerberos 0x18 действительно неудачная попытка ввода пароля.

Kerberos 0x12 - ограничение учетной записи отключено, просрочено, заблокировано или время входа в систему.

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4771

Я провел много времени сегодня и выяснил причину. Я пошёл не так, как надо - из перехваченной информации с помощью сетевого сниффера (идентификатор процесса ошибки Kerberos был 566 = lsass.exe). Позвольте мне обобщить информацию.

1. Войдите на проблемный ПК, запустите powershell с повышенными правами.

2. Включить аудит входа

   auditpol /set /subcategory:"logon" /failure:enable

3. Проверьте источник

   Get-WinEvent -Logname 'Security' -FilterXPath "*[System[EventID=4625]]" -MaxEvents 2 | fl

Если ты видишь:

Обрабатывать информацию:

Идентификатор вызывающего процесса: 0x140

Имя вызывающего процесса: C: \ Windows \ System32 \ services.exe

Это означает, что у вас запущен какой-то сервис из проблемной учетной записи со старым паролем

Это сверху заметки. Похоже, инициатор этого поста заявил в своем последнем комментарии. Java вызывает процесс vpxd.exe.

Дополнительные примечания Да, проверки входа в систему «Успех / Сбой» включены на соответствующем контроллере домена - события сбоев не регистрируются, пока учетная запись фактически не заблокирована.

Дальнейшее копание показывает, что LSASS.exe делает соответствующий вызов KERBEROS DC, когда учетная запись разблокирована. Ему предшествует (как правило) java, которая, кажется, вызывается vpxd.exe, который является процессом vCenter. НО, когда я смотрю на другой «server2», с которого может (и) может произойти блокировка учетной записи, я никогда не вижу вызова lsass.exe, и порождаются только процессы apache. Единственное отношение, которое они имеют, заключается в том, что SERVER2 является частью кластера vSphere SERVER1 (сервер1 является операционной системой vSphere).