Kerberos e Active Directory

Se você está pesquisando sobre Active Directory (AD), é provável que encontre o conceito de Kerberos para autenticação de usuários e outras funcionalidades relacionadas a solicitações de serviço.

Vale a pena examinar o protocolo Kerberos em profundidade e, por sua vez, apreciar a dependência do AD no Kerberos. Dado que é um padrão da indústria, você verá que ele se tornou o protocolo de autenticação de rede mais usado para todos os ambientes Windows com sistemas operacionais 2000 e posteriores. Estar familiarizado com a autenticação Kerberos é vital para entender melhor esse protocolo.

Nos termos mais simples, você pode pensar na autenticação Kerberos como o mecanismo de autenticação padrão e mais fundamental usado pelos ambientes do Windows AD.

Essa autenticação baseia-se no conceito de tickets e chaves de sessão que, em última análise, compõem o que geralmente descrevemos como credenciais. Essas credenciais são usadas para autenticar usuários em qualquer domínio necessário. Em seguida, eles fazem solicitações de serviço para estabelecer uma conexão criptografada segura com um servidor de destino, em qualquer rede não segura. O Kerberos garante que todos os clientes que interagem forneçam prova de identidade com os servidores, às vezes mutuamente, se necessário, para permitir um processo de autenticação impecável.

Kerberos, LDAP e sua interseção: conceitos comumente confusos

Muitas vezes, há alguma confusão sobre as diferenças e semelhanças entre como o protocolo LDAP (Lightweight Directory Access Protocol) funciona e o que o Kerberos oferece. Para resolver essa confusão, você pode pensar no Kerberos como um serviço de autenticação de logon único para que os clientes acessem vários aplicações e serviços. E você pode pensar no LDAP em relação ao AD, como um protocolo de comunicação para pesquisar, pesquisar e modificar dados do AD.

O LDAP também autentica os usuários com um procedimento de duas etapas. Ele primeiro verifica o nome distinto de um usuário e a senha que o cliente fornece em relação às informações armazenadas no banco de dados LDAP. A autenticação e a autorização subsequente permitem que os clientes acessem o banco de dados do AD para recuperar e gerenciar os dados de maneira rápida e eficiente.

Kerberos e LDAP geralmente são usados de forma coesa para garantir que os recursos individuais oferecidos por ambos sejam aproveitados à medida que o ambiente AD é configurado.

O modelo de autenticação Kerberos

O mecanismo Kerberos é análogo ao cão de três cabeças, Cerberus, da mitologia grega. O modelo de trabalho deste protocolo é projetado com base em três partes:

• O usuário, ou o cliente, solicitando um determinado serviço
• A aplicação, ou o servidor de destino, fornecendo o serviço necessário
• O servidor confiável de terceiros, chamado de centro de distribuição de chaves (KDC). Isso geralmente é instalado nos controladores de domínio em qualquer ambiente do AD.

O KDC é logicamente identificado por três componentes principais:

• O banco de dados (Db)
• O servidor de concessão de tickets (TGS)
• O servidor de autorização (AS)

Usando várias etapas, incluindo concessão de tíquetes, verificações de criptografia e descriptografia, os tíquetes Kerberos auxiliam no processo de autenticação.

Este fluxo de protocolo explica amplamente o processo de autenticação Kerberos:

• • Qualquer usuário ou cliente que requeira autenticação durante o processo de logon, insere uma senha como parte do processo de logon. Isso é processado para gerar um hash derivado por meio de um algoritmo de hash de senha.

  • O cliente solicita um tíquete de concessão de ticket (TGT) informando seu nome principal de usuário (UPN) para o KDC. O comando Kerberos usado aqui é KRB_AS_REQ.

  • Esse hash de senha é verificado, processado e usado pelo AS do KDC para gerar uma chave secreta de cliente/usuário.

  • O AS nesta fase também gera uma chave secreta TGS após confirmar a disponibilidade do TGS.

  • Uma chave de sessão 1 (SK1) é processada pelo AS, que se torna parte do TGT criptografado entregue ao cliente para provar sua identidade inicial.

  • O TGT é enviado ao cliente do KDC após uma consulta do UPN do cliente no Db do KDC. O comando Kerberos usado aqui é KRB_AS_REP.

  • O TGT tem o ID do cliente, endereço de rede do cliente, carimbo de data/hora, valor da vida útil e o SK1. Aqui, é importante observar que a criptografia das informações no TGT é concluída usando a chave secreta do cliente ou do usuário, bem como a chave secreta do TGS.

  • Após receber essa resposta, o cliente usa seu hash de senha para extrair o SK1.
  • Cada vez que o cliente requer um serviço ou acesso a qualquer recurso de rede específico, o TGT precisará ser renovado após a expiração do KDC.

Isso conclui o primeiro estágio de estabelecimento da identidade primária do cliente, que abre caminho para as etapas subsequentes de autenticação.

Para acessar um serviço específico, como um login remoto em uma nova estação de trabalho, ou acessar um navegador da Web ou um sistema de arquivos, há etapas de autenticação subsequentes necessárias para provar que o cliente tem permissão para acessar esse serviço. Esses passos são:

• • O cliente processa o TGT em posse, adiciona o nome principal do serviço (SPN) do serviço necessário e envia um autenticador criptografado com SK1 e posteriormente pela chave secreta TGS para o TGS. O comando Kerberos usado aqui é KRB_TGS_REQ.

  • O TGS é contatado para solicitar o início da sessão entre o cliente e o servidor de destino por meio de uma chave de sessão de serviço (SK2).

  • O servidor TG usa a chave secreta TGS para descriptografar o autenticador e extrair SK1. Após verificações bem-sucedidas da validade do TGT e uma correspondência das informações do cliente no TGT e no autenticador, o TGS cria o SK2.

  • O KDC inclui o SK2 junto com o ID do cliente, endereço de rede, carimbo de data/hora etc. em um tíquete de serviço e o envia ao cliente. O comando Kerberos usado aqui é KRB_TGS_REP.

  • Esse tickey é criptografado usando uma chave secreta do servidor fornecida pelo banco de dados. Ele é novamente criptografado duas vezes com SK1 e é enviado ao cliente. Ele também tem o certificado de atributo de privilégio (PAC) que indica os privilégios do usuário para o cliente como criptografados e assinados pelo KDC.

  • O cliente só pode descriptografar o ticket de serviço para extrair o SK1, gerar uma nova mensagem do autenticador, criptografá-la com o SK2 e enviá-la ao servidor de destino para descriptografia final e autenticação para acessar o serviço. O comando Kerberos usado aqui é KRB_AP_REQ.

  • O servidor de destino, com sua chave secreta, descriptografa o ticket de serviço. Ele acessa o SK2 e descriptografa o autenticador. Ele pode primeiro identificar-se, ou seja, autenticar-se com o cliente com um comando opcional KRB_AP_REP Kerberos, nos casos em que a autenticação mútua é necessária para aumentar a segurança.
  • Se o ID do cliente e outras informações do PAC corresponderem ao autenticador, uma conexão segura e autenticada será estabelecida entre o cliente e o servidor de destino para oferecer o serviço necessário.

Essas etapas são seguidas para determinar se a autenticação pode ser considerada um sucesso ou uma falha entre cliente e servidor usando o protocolo Kerberos.

Algumas das vantagens mais notáveis de usar esse modelo de autenticação é que as senhas nunca são armazenadas em texto simples, nem são transferidas pela rede em sua forma nativa. Kerberos, no entanto, não é infalível. Para entender este protocolo completamente, você precisará prestar a devida atenção às limitações do fluxo do protocolo, bem como às vulnerabilidades associadas a ele.

Para saber mais como como gerenciar seu AD e conferir uma abordagem prática, confira nossas ferramentas como ADManager, AD360 e mais!