Id de evento de auditoria de falha de Kerberos 4769 no controlador de domínio

Question

Eu tenho uma média de 17-18 eventos de auditoria de falha por hora registrados no log de eventos de segurança de um controlador de domínio do Windows 2012R2, relacionado a tentativas de um servidor membro do Windows 2008R2 obter um tíquete de serviço Kerberos

A Kerberos service ticket was requested. 

Account Information: 
Account Name:   [email protected] 
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.

O código de falha 0xE indica um tipo de autenticação não suportado. Eu monitorei o tráfego entre os servidores com o Wireshark e vejo que o servidor Windows 2008R2 está fazendo uma solicitação ao controlador de domínio para iniciar uma sessão usando o tipo de criptografia aes256-cts-hmac-sha1-96. Essa solicitação é rejeitada com um código de erro "tipo de criptografia não suportado" e a falha de auditoria é registrada no log de eventos. O servidor do Windows 2008, em seguida, envia uma lista de 5 tipos de criptografia e, a partir dele, o controlador de domínio responde com o tipo selecionado: ARCFOUR-HMAC-MD5. Depois disso, o tráfego continua normalmente, e estou assumindo que os dois servidores estão usando os parâmetros de criptografia que eles concordaram. Não há outro problema que eu possa ver entre os dois servidores. Alguma sugestão sobre como se livrar desses eventos? É apenas uma questão de política de auditoria? Talvez eu possa forçar o servidor Windows 2008R2 a iniciar suas solicitações com um conjunto diferente de parâmetros de protocolos de criptografia?

    

Answer 1

Você precisa aumentar seu DFL para usar os tipos de criptografia AES 'mais recentes' (cerca de 2008). Observe que, ao aumentar de 2003, as senhas da conta krbtgt serão alteradas (ambas), e isso pode resultar em impacto, portanto, você deve estar preparado para reiniciar os servidores / serviços conforme necessário para recuperar.

Além disso, você não deve ativar o tipo de criptografia DES se não for necessário, e mesmo desabilitar os tipos de criptografia RC4 e usar apenas o AES seria preferível se for compatível com o ambiente devido à segurança RC4 não ser ideal.

Veja o seguinte para mais informações:

link

    

Answer 2

O que é estranho aqui é o DC 2012 R2 rejeitar o tipo de criptografia baseado no AES256, porque ele é suportado por padrão. Há alguma política de grupo configurada em seu domínio que limitará intencionalmente os tipos de criptografia padrão suportados?

Eu executei um relatório RSOP no seu DC e analisei o que está configurado. Em particular, verifique a seção Windows Settings - Security Settings - Local Policies - Security Options . Há uma configuração lá chamada Segurança de rede: Configurar tipos de criptografia permitidos para o Kerberos que pode ser configurado para desautorizar um ou mais dos algoritmos AES. Algumas organizações desativaram esta opção para oferecer melhor suporte a clientes legados que não suportam os tipos de criptografia mais recentes.