У нас есть учетная запись домена, которая заблокирована через 1 из 2 серверов. Встроенный аудит говорит нам только об этом (заблокирован для SERVER1, SERVER2).
Учетная запись блокируется в течение 5 минут, примерно 1 запрос в минуту.
Сначала я попытался запустить procmon (из sysinternals), чтобы узнать, не возникает ли какой-либо новый ЗАПУСК ПРОЦЕССА после того, как я разблокирую учетную запись. Ничего подозрительного не всплывает. После запуска procmon на моей рабочей станции и повышения уровня до оболочки UAC (conscent.exe) из стека кажется, что ntdll.dll и rpct4.dll вызывается при попытке авторизации в AD (не уверен).
Есть ли способ сузить, какой процесс вызывает запрос аутентификации к нашему DC? Это всегда один и тот же DC, поэтому мы знаем, что это должен быть сервер на этом сайте. Я мог бы попытаться найти вызовы в wirehark, но я не уверен, что это сузило бы то, какой процесс на самом деле их запускает.
Никакие службы, сопоставления дисков или запланированные задачи также не используют эту учетную запись домена - так что это должно быть что-то, для чего сохранены кредиты домена. Нет открытых сеансов RDP с этой учетной записью домена ни на одном сервере (мы проверили).
Да, аудит входа в систему «Успех / Сбой» включен на рассматриваемом контроллере домена - события сбоя не регистрируются, пока учетная запись не будет фактически заблокирована.
Дальнейшее копание показывает, что LSASS.exe делает KERBEROS позвонить в соответствующий DC после разблокировки учетной записи. Ему предшествует (обычно) java, который, кажется, вызывается vpxd.exe который является процессом vCenter. НО, когда я смотрю на другой "server2", где может (также) произойти блокировка учетной записи, я никогда не вижу вызова lsass.exe и порождаются только процессы apache. Единственная связь между ними заключается в том, что SERVER2 является частью кластера vSphere SERVER1 (server1 является ОС vSphere).
Итак, похоже, все, что мне скажет 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
Kerberos 0x18 это действительно попытка неверного пароля.
Kerberos 0x12 - учетная запись отключена, просрочена, заблокирована или ограничение времени входа в систему.
https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4771
Я нашел этот старый вопрос, исследуя другую проблему, но для всех, у кого есть аналогичная проблема:
Код ошибки 0x18 означает, что учетная запись уже была отключена или заблокирована, когда клиент пытался аутентифицироваться.
Вам нужно найти тот же идентификатор события с кодом ошибки 0x24, который определит неудачные попытки входа в систему, которые привели к блокировке учетной записи. (Предполагается, что это происходит из-за неправильного кешированного пароля.)
Затем вы можете посмотреть адрес клиента для этих событий. чтобы узнать, какая система передает неверные учетные данные. Оттуда вам нужно будет выяснить, является ли это сервисом со старым паролем, подключенным сетевым диском и т. Д.
Существует множество кодов сбоев, поэтому вам следует искать что-либо, кроме 0x18, чтобы определить, что вызвало блокировку учетной записи, если нет событий с кодами 0x24. Я считаю, что единственный тип сбоя, который приведет к блокировке, - это 0x24 (неверный пароль), но я могу ошибаться.
Сегодня я потратил много времени на выяснение первопричины. Я пошел неверным путем - из захваченной информации с помощью сетевого сниффера (идентификатор процесса ошибки kerberos был 566 = lsass.exe). Резюмирую информацию.
Войдите на проблемный ПК, запустите powershell с повышенными правами
Включить аудит входа в систему
auditpol /set /subcategory:"logon" /failure:enable
Проверить источник
Get-WinEvent -Logname 'Security' -FilterXPath "*[System[EventID=4625]]" -MaxEvents 2 | fl
Если ты видишь:
Обрабатывать информацию:
Идентификатор процесса вызывающего абонента: 0x140
Имя вызывающего процесса: C: \ Windows \ System32 \ services.exe
Это означает, что у вас запущена какая-то служба из проблемной учетной записи со старым паролем.
Это из примечаний выше. Похоже, инициатор поста заявил о своем последнем комментарии. Java вызывает процесс vpxd.exe.
Дополнительные примечания. Да, аудит входа в систему «Успех / Сбой» включен на рассматриваемом контроллере домена - события сбоя не регистрируются, пока учетная запись не будет фактически заблокирована.
Дальнейшее копание показывает, что LSASS.exe выполняет вызов KERBEROS на рассматриваемый контроллер домена после разблокировки учетной записи. Ему предшествует (обычно) java, который, кажется, вызывается vpxd.exe, который является процессом vCenter. НО, когда я смотрю на другой «server2», где может (также) произойти блокировка учетной записи, я никогда не вижу вызова lsass.exe, и создаются только процессы apache. Единственная связь между ними заключается в том, что SERVER2 является частью кластера vSphere SERVER1 (server1 является ОС vSphere).