Назад | Перейти на главную страницу

Не удается найти неудачную аутентификацию в средстве просмотра событий

Я пытаюсь собрать неудачные события входа / аутентификации от DC в домене 2016.

Я могу видеть 4625 событий сбоя аудита в журналах безопасности на контроллерах домена, когда пользователю не удается войти в систему на экране входа в систему.

Когда я пытаюсь запустить приложение от имени другого пользователя и не могу правильно войти в систему, я вижу 4025 в локальном (настольном) журнале событий, но не могу найти соответствующее событие ни на одном DC.

Я просмотрел, но, возможно, пропустил !, другие типы событий / журналы одновременно, но не вижу ничего, что могло бы соответствовать действию.

Может ли кто-нибудь указать мне, как я собираю эту информацию централизованно (от DC)?

Когда пользователю не удалось войти на рабочую станцию ​​или сервер с использованием учетных данных домена, это обычно вызывает два типа событий:

  • исходное устройство (к которому подключен пользователь): обычно выдает ID 4625 и / или 4776
  • контроллер домена: не будет сообщать о каких-либо событиях с идентификатором 4625, связанных с этим предварительным входом в систему. Вместо этого он будет сообщать о событиях Kerberos с идентификатором 4771 или 4768, связанных с билетами TGT. ID 4776 также может сообщаться в зависимости от используемого протокола аутентификации (NTLM или Kerberos). Однако обратите внимание, что если вам не удалось войти в систему на контроллере домена, идентификатор 4625 и связанные идентификаторы Kerberos будут отображаться на одном устройстве, поскольку источник и место назначения совпадают.

Итак, чтобы увидеть неудачные попытки на ваших контроллерах домена, включите успешные и неудачные возможности аудита Kerberos на ваших контроллерах домена с помощью GPO. Некоторую помощь можно найти Вот. Затем я могу предложить вам настроить сервер Windows Event Collector (источник), чтобы централизовать все ваши события, прежде чем пересылать их в SIEM (ELK, Splunk, ArcSight, ...).