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

Идентификатор события аудита сбоев Kerberos 4769 на контроллере домена

В журнале событий безопасности контроллера домена Windows 2012R2 регистрируется в среднем 17-18 событий аудита сбоев в час, связанных с попытками рядового сервера Windows 2008R2 получить билет службы Kerberos.

A Kerberos service ticket was requested. 

Account Information: 
Account Name:   TORPDC01$@ACME.COM 
Account Domain: ACME.COM 
Logon GUID: {00000000-0000-0000-0000-000000000000} 

Service Information: 
Service Name:   krbtgt/ACME.COM 
Service ID: S-1-0-0 

Network Information: 
Client Address: ::ffff:192.168.1.15 
Client Port:    28904 

Additional Information: 
Ticket Options: 0x60810010 
Ticket Encryption Type: 0xFFFFFFFF 
Failure Code:   0xE 
Transited Services: - 

This event is generated every time access is requested to a resource such as a computer or a Windows service. The service name indicates the resource to which access was requested. 

This event can be correlated with Windows logon events by comparing the Logon GUID fields in each event. The logon event occurs on the machine that was accessed, which is often a different machine than the domain controller which issued the service ticket. 

Ticket options, encryption types, and failure codes are defined in RFC 4120.

Код ошибки 0xE указывает на неподдерживаемый тип аутентификации. Я отслеживал трафик между серверами с помощью Wireshark и вижу, что сервер Windows 2008R2 делает запрос к контроллеру домена, чтобы начать сеанс с использованием типа шифрования aes256-cts-hmac-sha1-96. Этот запрос отклоняется с кодом ошибки «Тип шифрования не поддерживается», и ошибка аудита записывается в журнал событий. Затем сервер Windows 2008 отправляет список из 5 типов шифрования, и от него контроллер домена отвечает выбранным типом: ARCFOUR-HMAC-MD5. После этого трафик продолжается в обычном режиме, и я предполагаю, что два сервера используют согласованные параметры шифрования. Других проблем между двумя серверами я не вижу. Есть предложения, как избавиться от этих событий? Это просто вопрос политики аудита? Может быть, я могу заставить сервер Windows 2008R2 запускать свои запросы с другим набором параметров протоколов шифрования?

Вам необходимо поднять свой DFL, чтобы использовать «более новые» (примерно 2008 г.) типы шифрования AES. Обратите внимание, что при повышении с 2003 года пароли учетной записи krbtgt будут изменены (оба), и это может повлиять на ситуацию, поэтому вы должны быть готовы перезапустить серверы / службы по мере необходимости для восстановления.

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

Для получения дополнительной информации см. Следующее:

https://technet.microsoft.com/en-us/library/understanding-active-directory-functional-levels(v=ws.10).aspx

Что странно, так это то, что контроллер домена 2012 R2 отклоняет тип шифрования на основе AES256, поскольку он поддерживается по умолчанию. Есть ли в вашем домене какие-либо групповые политики, которые намеренно ограничивают поддерживаемые по умолчанию типы шифрования?

Я бы запустил отчет RSOP на вашем DC и посмотрел, что настроено. В частности, проверьте Windows Settings - Security Settings - Local Policies - Security Options раздел. Там есть настройка под названием Сетевая безопасность: настройка типов шифрования, разрешенных для Kerberos который можно настроить на запрет одного или нескольких алгоритмов AES. В некоторых организациях этот параметр отключен, чтобы лучше поддерживать устаревшие клиенты, не поддерживающие новые типы шифрования.