O Kerberos é um protocolo de autenticação amplamente utilizado em ambientes de Active Directory (AD) para permitir que os usuários se autentiquem e acessem serviços de rede de forma segura. Ele opera por padrão na porta 88 e é o protocolo de autenticação padrão para contas de domínio desde o Windows 2000.
Com o Kerberos, um usuário se autentica uma única vez e a partir daí, pode acessar vários serviços na rede sem a necessidade de reinserir sua senha continuamente. Isso elimina a necessidade do serviço conhecer ou armazenar a senha do usuário, garantindo uma autenticação mais segura.
O Kerberos é um protocolo sem estado e baseado em tickets, que dissocia as credenciais do usuário de suas requisições aos serviços da rede. Assim, a senha do usuário nunca é transmitida diretamente pela rede após a autenticação inicial. Em vez disso, o Key Distribution Center ****(KDC) emite um Ticket-Granting Ticket (TGT), que o cliente usa para solicitar um Ticket Granting Service(TGS) sempre que precisar acessar um novo serviço.
O KDC não armazena informações sobre sessões anteriores ou sobre os tickets emitidos, ou seja, ele não mantém um histórico de interações. Cada requisição é tratada de forma independente. Quando um cliente apresenta um TGT válido, o KDC assume que o cliente já passou pelo processo de autenticação inicial e está autorizado a solicitar um Service Ticket via o Ticket Granting Service (TGS). Isso torna o processo eficiente e escalável, uma vez que o KDC não precisa manter registros de transações anteriores.
Um Service Principal Name (SPN) é um identificador exclusivo para um serviço. O protocolo Kerberos utiliza dos SPNs para associar uma instância de serviço a uma conta de login de serviço no Active Directory (AD). O SPN é utilizado para que o cliente saiba qual serviço ele está acessando e para que o AD possa utilizar a senha desse serviço para criptografar o Service Ticket (TS), garantindo que somente o serviço correto possa descriptografá-lo.
Caso o AD tenha um serviço sem um SPN configurado, o Kerberos não será capaz de autenticar a instância do SQL Server. Isso pode resultar em falhas de autenticação e fallback para autenticação NTLM (Podendo resultar em NTLM Rellay Attack, NTLM Fallback Roasting, SPN Spoofing, Pass-the-Hash e etc).
É comum ver SPNs vinculados a contas de serviço não gerenciadas **, pois a configuração de contas de serviço gerenciadas (MSAs/gMSAs) pode ser mais complexa, e nem todos os serviços oferecem suporte adequado, como o Apache HTTP Server, MySQL, e PostgreSQL. Além disso, contas de serviço gerenciadas podem causar problemas em certos ambientes devido a políticas de segurança. Por exemplo, após 30 dias, as contas de serviço gerenciadas podem tentar trocar suas senhas automaticamente, o que pode interromper serviços caso não estejam configuradas corretamente.
Para muitos administradores e fornecedores, a continuidade do serviço é a prioridade, o que frequentemente os leva a optar por *contas de serviço não gerenciadAs*. Isso reduz o risco de interrupções, desde que essas contas sejam protegidas com senhas fortes e políticas de segurança adequadas.
Vamos considerar o cenário em que você tem um serviço de SQL Server rodando em um servidor chamado SQLServer01 e os usuários dentro da rede precisam acessar o banco de dados hospedado nesse servidor.
SQLServer01 está rodando uma instância de Microsoft SQL Server e é acessado pelos usuários por meio de aplicativos como o SQL Server Management Studio (SSMS) ou qualquer outro cliente SQL.Para que o Kerberos consiga autenticar corretamente os acessos a esse serviço, o administrador precisa registrar um SPN associado ao serviço SQL. O SPN para o SQL Server deve incluir o nome do serviço e o nome do servidor. No caso de uma instância padrão de SQL Server rodando no SQLServer01, o SPN seria algo como: