SPN e seu papel no Active Directory e na segurança

Os Nomes de Principais de Serviço (SPNs) são identificadores únicos no Active Directory usados para mapear instâncias de serviço a contas de serviço para autenticação Kerberos. Este artigo explica a estrutura do SPN, registro, requisitos de unicidade, ferramentas (por exemplo, setspn) e implicações de segurança. Abrange ataques como Kerberoasting, melhores práticas, métodos de detecção e casos de uso avançados em ambientes híbridos, na nuvem e conteinerizados.

Introdução aos Service Principal Names (SPNs)

O que é um SPN? Mesmo um Administrador do Windows com alguma experiência em Active Directory pode não estar ciente do papel que os Service Principal Names têm em ambientes de domínio. Um nome de principal de segurança (SPN) é um identificador único que liga uma instância específica de serviço à conta que o executa, permitindo que os clientes autentiquem e se conectem ao serviço correto dentro do Active Directory (AD). Isso é particularmente importante em ambientes empresariais de grande porte, onde múltiplas instâncias de um serviço podem ser executadas em servidores diferentes. Neste artigo, discutiremos o que é o SPN do active directory, qual sua contribuição para a segurança e como seus usos continuam a se expandir em redes modernas hoje.

Papel dos SPNs na autenticação Kerberos

Assim como você precisa de um ingresso para embarcar em um avião ou entrar em um cinema, você também precisa de um ingresso para acessar recursos dentro do Active Directory (AD). Quando um cliente solicita acesso a um serviço hospedado no AD, o processo se desenrola da seguinte forma:

1. Um cliente que tenta usar um serviço cria um SPN para esse serviço
2. O cliente solicita ao controlador de domínio um ticket usando esse SPN
3. O controlador de domínio pesquisa no Active Directory pelo SPN
4. Uma vez encontrado, o controlador de domínio emite um bilhete de serviço
5. O cliente usa este ticket para se autenticar no serviço sem a necessidade de uma senha

Desvendando o Básico

Componentes de um SPN

SPN é composto por múltiplos componentes que, quando combinados, fornecem uma identidade completa para um serviço específico:

1. Classe de Serviço: Este é o nome da instância do serviço, como “MSSQLSvc” para Microsoft SQL Server ou “www” para serviços web.
2. Hostname: Especifica o servidor ou host onde o serviço está em execução. Pode ser o nome NetBIOS de uma máquina Windows, como “FilerServer”, ou o nome de domínio totalmente qualificado, como “fileserver.company.com”
3. Account: The Active Directory account associated with the service. This is not part of the SPN string itself but is the account to which the service principal name is registered.
4. Porta (Opcional): Se o serviço estiver sendo executado em uma porta não padrão, ela pode ser especificada no SPN.

Exemplos de SPNs comuns no Active Directory

• Serviços Web – HTTP/webserver.netwrix.com
• SQL Server – MSSQLSvc/myhost.redmond.microsoft.com:1433
• Compartilhamentos de Arquivos – CIFS/fileserver.contoso.com
• Remote Desktop Services – TERMSRV/rdserver.abcdomain.com
• Autenticação LDAP – LDAP/domaincontroller.fabricam.com

SPNs e Active Directory: A Conexão

Como os SPNs se integram com objetos do Active Directory

Os SPNs são atributos associados a objetos do AD, como contas de usuário, contas de serviço ou objetos de computador. Eles funcionam como etiquetas que indicam quais serviços são executados sob quais contas. Essa conexão permite que os computadores usem o Kerberos para autenticação segura sem enviar senhas pela rede. Quando um serviço é instalado ou configurado, ele registra um SPN que permite ao Kerberos mapear solicitações de autenticação para a conta correta. Sem um SPN configurado adequadamente, a autenticação Kerberos falhará, podendo causar erros de autenticação e interrupções no serviço.

Armazenamento SPN no atributo servicePrincipalName

Os SPNs são armazenados no Active Directory como parte do atributo servicePrincipalName de um objeto. Este atributo existe em contas de computador e contas de serviço. Você pode ver este atributo nas propriedades avançadas de um objeto usando Active Directory Users and Computers conforme mostrado na captura de tela abaixo.

O atributo contém uma lista de SPNs que foram atribuídos ao objeto. Cada entrada de SPN segue um formato estruturado que inclui o tipo de serviço, host e número de porta opcional.

Você pode visualizar os SPNs de um objeto AD utilizando o comando: setspn –L hostname. No exemplo abaixo, o comando foi usado para ver a lista de SPNs gerados por um controlador de domínio para um domínio chamado ABCDomain.com

Importância da unicidade de SPN em uma floresta AD

Cada nome de principal de serviço deve ser único em toda a floresta do Active Directory. Essa unicidade garante que o Kerberos possa encaminhar corretamente as solicitações de serviço para a conta apropriada. SPNs duplicados em contas diferentes causam conflitos de autenticação, resultando em comportamentos imprevisíveis ou falhas de autenticação.

Configurando SPNs: Guia Passo a Passo

Ferramentas necessárias para a configuração de SPN

A principal ferramenta para configuração de SPN é o setspn.exe, que vem integrado aos sistemas operacionais Windows Server. Esta ferramenta de linha de comando permite que administradores leiam, modifiquem e excluam nomes de entidade de serviço para contas de serviço do Active Directory.

Em um exemplo anterior, usamos o setspn -L para visualizar o SPN de um objeto de computador. Você também pode usar o setspn -S para adicionar um SPN. Por exemplo, para adicionar um SPN HTTP a um computador chamado webserver1, o comando seria:

setspn -S HTTP/webserver1.abcdomain.com abcdomain\serviceaccount

Observe que o comando setspn -S verifica automaticamente a existência de SPNs idênticos antes de criar novos para evitar entradas duplicadas.

Para remover um SPN, utilize o comando setspn -D. Você também pode usar o PowerShell de várias maneiras para SPNs. Por exemplo, o seguinte cmdlet do PowerShell encontrará todos os SPNs registrados no Active Directory:

Get-ADObject -Filter {servicePrincipalName -like “*”} -Property servicePrincipalName | Select-Object Name, servicePrincipalName

Enquanto este irá detectar todos os SPNs duplicados.

$SPNs = Get-ADObject -Filter {servicePrincipalName -like “*”} -Property servicePrincipalName |

Select-Object -ExpandProperty servicePrincipalName

Melhores práticas para registro de SPN

• Conceda as permissões mínimas necessárias para contas de serviço para registro de SPN
• Use o PowerShell para verificar duplicatas antes de registrar um novo SPN:
• Realize auditorias periódicas de SPNs para identificar e remover entradas desnecessárias ou desatualizadas
• Use um formato de nomeação SPN padronizado ao adicionar SPNs

Resolução de Problemas Comuns de SPN

SPNs duplicados podem causar falhas de autenticação e devem ser resolvidos. Fique atento a usuários relatando problemas de acesso intermitentes, pois isso pode indicar conflitos de SPN. Você pode usar o comando setspn -x para encontrar duplicatas dentro de um único domínio, conforme mostrado na captura de tela abaixo.

Utilize o comando setspn -F para pesquisar em toda a floresta. Para resolver SPNs duplicados:

1. Identifique as contas que possuem os SPNs duplicados.
2. Determine qual conta deve legitimamente deter o SPN.
3. Remova o SPN da conta incorreta usando setspn -D <SPN> <AccountName>8.
4. Adicione o SPN à conta correta usando setspn -S <SPN> <AccountName>

Além de duplicatas, algumas outras configurações incorretas comuns de SPN incluem:

• SPNs ausentes para serviços
• SPNs registrados em contas incorretas
• SPNs desatualizados após mudanças no nome do servidor

(Não há necessidade de listar novamente as mesmas ferramentas aqui que já cobrimos)

Conceitos avançados de SPN

O papel dos SPNs em ambientes multi-serviço e multi-host

As contas de serviço são contas de usuário especializadas criadas para serviços executados no Windows Server. Elas ajudam a isolar e proteger contas de domínio em aplicações críticas como o Internet Information Services (IIS). Em ambientes complexos, vários serviços frequentemente operam na mesma máquina, cada um requerendo Nomes de Principal de Serviço (SPNs) distintos para autenticação adequada.

Um exemplo comum é um servidor que hospeda uma aplicação web pode executar tanto o SQL Server quanto o IIS. Cada serviço precisa do seu próprio SPN para garantir a autenticação Kerberos correta:

• Para IIS: HTTP/servername.domain.com
• Para SQL Server: MSSQLSvc/servername.domain.com:1433

Em ambientes multi-host, onde um serviço é executado em vários servidores para balanceamento de carga ou failover, a configuração de SPN torna-se mais complexa. Considere uma aplicação web hospedada em vários servidores (Web01, Web02, Web03) sob um nome DNS compartilhado. Neste cenário, os SPNs devem ser registrados em uma única conta de serviço para permitir autenticação contínua em todos os hosts:

Casos especiais: HOST SPNs e seu comportamento único

Os SPNs de HOST são um tipo especial de SPN automaticamente registrados em objetos de computador no Active Directory. Eles funcionam como um identificador geral para serviços executados sob a conta de sistema local ou de serviço de rede de uma máquina. Isso simplifica a gestão de muitos serviços padrão do Windows e reduz a necessidade de configuração manual de SPN.

O gráfico a seguir resume quando você deve usar HOST SPNs vs. Custom SPNs:

Dica: Você nunca deve modificar manualmente os SPNs do HOST, pois eles são gerenciados pelo AD.

SPNs e Implicações de Segurança

Por que é crítico garantir a segurança dos SPNs em um ambiente AD

O motivo pelo qual a segurança é importante para SPNs é simples. Contas de serviço frequentemente possuem privilégios elevados. Elas também têm acesso contínuo a sistemas críticos dentro da rede e muitas vezes são esquecidas assim que são criadas. Tudo isso as torna alvos de alto valor para atacantes. Comprometer um SPN pode levar a acesso não autorizado a serviços críticos e potencialmente permitir que atacantes se movimentem lateralmente dentro da rede e escalem seus privilégios

Como SPNs fracos podem ser explorados

Quando os SPNSs estão configurados de forma fraca, eles podem ser explorados através de ataques como o Kerberoasting. Eis como um atacante realizaria tal ataque:

• Um atacante com privilégios mínimos de domínio pode solicitar tickets de serviço para qualquer SPN Solicita tickets de serviço para esses SPNs
• O ticket de serviço, criptografado com o hash da senha da conta de serviço, pode ser extraído e levado offline para ser decifrado
• Realiza a quebra de senha offline nestes e, se a senha for fraca, os atacantes podem potencialmente decifrá-la e obter acesso à conta de serviço, muitas vezes com privilégios elevados

Uma vez que o atacante descobre a senha de uma conta de serviço e se essa conta possui altos privilégios, eles podem se mover lateralmente pela rede ou escalar seu acesso.

Melhores práticas para proteger SPNs e contas de serviço

Abaixo está uma lista de melhores práticas para mitigar riscos de segurança associados a SPNs:

• Use senhas longas e complexas para contas com SPN e troque-as regularmente
• Evite atribuir SPNs a contas de alto privilégio, como Administradores de Domínio
• Restrinja contas de serviço apenas às permissões necessárias para a sua função
• Desative o logon interativo para contas de serviço
• Monitore o uso inesperado de comandos relacionados a SPN no PowerShell.
• Uma vez que qualquer usuário com autenticação de domínio pode procurar por SPNs, você deve limitar quem pode realizar essas consultas alterando as permissões no Active Directory.

Detectando e Mitigando Abuso de SPN

Monitoramento e auditoria de atividades relacionadas a SPN

O monitoramento contínuo do seu ambiente AD e a auditoria de eventos relacionados ao Kerberos podem ser altamente eficazes para prevenir o abuso de SPN. Algumas das coisas que você deve detectar incluem:

• Pedidos incomuns de enumeração de SPN, pois atacantes podem consultar o AD por SPNs usando ferramentas LDAP.
• Solicitações frequentes de tickets Kerberos, pois qualquer aumento repentino nas solicitações de tickets de serviço pode indicar um ataque em andamento.
• Logins de contas de serviço de locais inesperados em vez dos locais designados usuais.
• Tentativas de autenticação falhadas, pois falhas repetidas sugerem ataques de força bruta ou de password spraying.

Implementando estratégias de mitigação contra ataques baseados em SPN

Se a sua organização opera dentro de um ambiente Windows Active Directory, você deve considerar os seguintes controles de segurança preventivos para minimizar o risco de abuso de SPN e ataques de Kerberoasting.

• Utilize senhas longas e complexas (mínimo absoluto de 14 caracteres) para contas de serviço
• Previna a reutilização de senhas em diferentes contas e rotacione as senhas regularmente
• Aplique o princípio do privilégio mínimo para limitar as permissões das contas.
• Aplique tempos de vida mais curtos para tickets Kerberos para minimizar a janela de ataque
• Revise e remova regularmente SPNs desatualizados ou desnecessários
• Adote uma estratégia de defesa multicamadas combinando um forte gerenciamento de contas de serviço, monitoramento sofisticado e programas regulares de treinamento.

Usando Contas de Serviço Gerenciadas por Grupo e métodos de criptografia fortes

Implemente Contas de Serviço Gerenciadas em Grupo (gMSAs) para se beneficiar do gerenciamento de senhas automatizado. Contas de Serviço Gerenciadas em Grupo (gMSAs) são contas de serviço especializadas no Active Directory que oferecem recursos de segurança aprimorados em comparação com contas de serviço tradicionais. Elas são particularmente úteis para servidores associados a domínios que executam serviços como SQL Server, aplicações web IIS, tarefas agendadas e outros serviços que precisam ser executados em um contexto de segurança com permissões específicas. Utilizar gMSAs eliminará a atribuição manual de senhas e reduzirá o risco de roubo de credenciais. Em relação à criptografia, imponha uma criptografia Kerberos AES128/AES256 forte enquanto desabilita os tipos de criptografia DES e RC4 mais fracos no Active Directory.

Aplicações Práticas e Casos de Uso

Como mencionado, os SPNs são usados na autenticação Kerberos para aplicações web e bancos de dados. O IIS utiliza o SPN no formato “HTTP/ServerName” que é mapeado para a conta de domínio que executa o pool de aplicações, enquanto “MSSQLSvc/host.domain.com:1433” é um exemplo de conta de serviço SQL. O papel dos Nomes de Principal de Serviço (SPNs) está evoluindo além dos casos de uso tradicionais, à medida que as empresas adotam cada vez mais arquiteturas de rede híbridas. Hoje, até estamos vendo os SPNs facilitarem a autenticação segura entre recursos locais e aplicações nativas da nuvem. Outros exemplos incluem:

• Os SPNs estão sendo usados para gerenciar identidades e acessos para aplicações e serviços conteinerizados localizados em ambientes conteinerizados.
• Ambientes de borda utilizam SPNs para facilitar a comunicação segura entre dispositivos de borda e recursos centralizados na nuvem.
• O Azure AD Connect utiliza SPNs para serviços de sincronização entre o AD local e o Azure AD.

Há também um uso crescente de SPNs dentro de ambientes empresariais hoje em dia. Por exemplo, equipes de segurança estão monitorando logs de uso de SPN para detectar tentativas de acesso não autorizadas ou falhas no Kerberos. Outros exemplos incluem:

• Single Sign-On (SSO): SPNs habilitam o SSO baseado em Kerberos em múltiplas aplicações e serviços.
• Integração de aplicativos: SPNs facilitam a comunicação segura entre diferentes aplicativos e serviços empresariais.
• Autenticação delegada: SPNs permitem que serviços autentiquem em nome dos usuários para aplicações multi-camadas.

Conclusão

Os Service Principal Names (SPNs) têm sido um pilar da autenticação Kerberos desde o início da criação do Active Directory. Eles têm sido fundamentais para muitos dos serviços clássicos em que os usuários de rede confiam e os SPNs desempenham um papel vital na garantia de operações seguras e contínuas em inúmeros serviços de fundo. À medida que as organizações continuam a expandir e evoluir, as aplicações dos SPNs estão se alargando para áreas como integração na nuvem e IoT. Com o crescente enfoque na segurança nas empresas hoje em dia, é provável que os SPNs desempenhem um papel ainda maior, adaptando-se a novas tecnologias e desafios de segurança na paisagem digital que está sempre a expandir-se.

O que é SPN?

Um Service Principal Name (SPN) é um identificador único que vincula uma instância específica de serviço à conta do Active Directory que a executa. Os SPNs devem ser únicos em toda a floresta do Active Directory.

Se duas contas possuem o mesmo SPN, o controlador de domínio não consegue determinar para qual emitir um ticket, e a autenticação falha. Se nenhuma conta possuir o SPN, a solicitação falha completamente e o cliente geralmente recorre ao NTLM, que traz seus próprios riscos.

Um SPN registrado em uma conta de usuário pessoal em vez de uma conta de serviço gerenciada torna esse ataque viável. A defesa é a higiene da conta de serviço. Use Group Managed Service Accounts. Aplique senhas longas e geradas aleatoriamente em qualquer conta que ainda possua um SPN. Monitore o Evento ID 4769 para picos em solicitações de tickets que denunciam o ataque.

Papel dos SPNs na autenticação Kerberos

Eles também são a superfície de ataque para Kerberoasting. Qualquer usuário autenticado no domínio pode solicitar um ticket de serviço Kerberos para uma conta com SPN e decifrá-lo offline para obter a senha da conta, sem acionar um limite de bloqueio.

1. O cliente constrói um SPN para o serviço que deseja acessar.

Um ambiente Active Directory que executa SQL Server, IIS, Exchange e aplicações personalizadas precisa que cada serviço se autentique sem solicitar credenciais dos usuários a cada requisição ou embutir senhas em arquivos de configuração. Os Service Principal Names tornam isso possível.

Quando um cliente solicita acesso a um serviço, o fluxo de autenticação Kerberos segue uma sequência definida:

Os SPNs existem em objetos de computador e contas de serviço como um atributo multivalorado chamado servicePrincipalNameExpand. Cada entrada nesse atributo representa um serviço registrado. Uma conta que executa vários serviços, ou um serviço acessível por vários nomes de host, possui várias entradas SPN.

1. O cliente solicita um ticket de serviço do controlador de domínio usando esse SPN.
2. O cliente apresenta o ticket ao serviço para autenticação, e nenhuma senha é transmitida pela rede.
3. O controlador de domínio procura o SPN no Active Directory.
4. Uma vez encontrado, o controlador de domínio emite um ticket de serviço criptografado com as credenciais da conta de serviço.

Estrutura e componentes do SPN

Esta sequência mostra por que a precisão do SPN é importante. Um SPN ausente, duplicado ou mal configurado interrompe a pesquisa na etapa 3, causando falha na autenticação ou retorno ao NTLM.

Componentes de um SPN

Um SPN não é um valor único, mas uma string estruturada composta por vários componentes. Entender essa estrutura é essencial para o registro correto, solução de problemas e revisão de segurança.

Cada SPN segue um formato definido que identifica o serviço, o host em que ele é executado e, opcionalmente, a porta que utiliza. Os componentes são:

Formatos comuns de SPN no Active Directory

• Conta: a conta do Active Directory associada ao serviço. Isso não faz parte da string SPN em si, mas é o objeto ao qual o SPN está registrado.
• Porta (opcional): incluída quando o serviço é executado em uma porta não padrão (por exemplo, MSSQLSvc/host.domain.com:1433Expand).
• Classe de serviço: o nome do tipo de serviço, como MSSQLSvcExpand para Microsoft SQL Server ou HTTPExpand para serviços web.
• Nome do host: o servidor ou host onde o serviço está em execução, expresso como um nome NetBIOS (por exemplo, FileServerExpand) ou um nome de domínio totalmente qualificado (por exemplo, fileserver.company.comExpand).

O formato ServiceClass/Hostname: PortExpand produz strings previsíveis e reconhecíveis entre tipos de serviço. Exemplos comuns incluem:

• Serviços web: HTTP/webserver.netwrix.comExpand
• SQL Server: MSSQLSvc/myhost.redmond.microsoft.com:1433Expand
• Compartilhamentos de arquivos: CIFS/fileserver.contoso.comExpand
• Serviços de Área de Trabalho Remota: TERMSRV/rdserver.abcdomain.comExpand

Como o Active Directory armazena e resolve SPNs

• Autenticação LDAP: LDAP/domaincontroller.fabrikam.comExpand

O atributo servicePrincipalName

SPNs são atributos associados a objetos AD, como contas de usuário, contas de serviço ou objetos de computador. Eles funcionam como etiquetas que indicam quais serviços são executados sob quais contas. Essa conexão permite que os computadores usem Kerberos para autenticação segura sem enviar senhas pela rede.

Quando você instala ou configura um serviço, ele registra um SPN que permite ao Kerberos mapear solicitações de autenticação para a conta correta. Sem um SPN configurado corretamente, a autenticação Kerberos falhará, podendo causar erros de autenticação e interrupções no serviço.

Quando um cliente solicita acesso a um serviço, ele constrói um SPN para esse serviço, envia-o ao controlador de domínio, e o DC procura esse SPN no diretório. Se encontrado, emite um ticket de serviço Kerberos. Nenhuma senha é transmitida pela rede.

Como a exclusividade do SPN permite a resolução correta do serviço

Você pode visualizar os SPNs de um objeto AD usando o comando: setspn –L hostname. No exemplo abaixo, o comando foi usado para visualizar a lista de SPNs gerados por um controlador de domínio para um domínio chamado ABCDomain.com.

Os SPNs são armazenados no Active Directory como parte do atributo servicePrincipalName de um objeto. Esse atributo existe em contas de computador e contas de serviço e contém uma lista de todos os SPNs registrados para esse objeto. Você pode visualizá-lo na aba das propriedades de um objeto em Active Directory Users and Computers, conforme mostrado na captura de tela abaixo.

HOST SPNs e quando o AD os gerencia automaticamente

A tabela abaixo resume quando usar HOST SPNs versus SPNs personalizados:

HOST SPNs são uma categoria especial de SPNs que são registrados automaticamente em objetos de computador pelo Active Directory. Eles atuam como um identificador universal para serviços executados sob a conta Local System ou Network Service em uma máquina, abrangendo muitos serviços padrão do Windows sem exigir entradas SPN manuais.

Ao solucionar problemas de autenticação, SPNs duplicados devem estar entre as primeiras coisas verificadas. Use setspn -XExpand para detectar duplicatas dentro de um domínio, e setspn -FExpand para pesquisar em toda a floresta.

Cada SPN deve ser único em toda a floresta do Active Directory. Essa unicidade permite que Kerberos authentication direcione as solicitações de serviço para a conta correta. Se duas contas tiverem o mesmo SPN, o controlador de domínio não poderá determinar qual usar, resultando em falhas de autenticação, erros intermitentes de login e conexões de serviço quebradas.

Nunca modifique manualmente os HOST SPNs. O Active Directory os gerencia automaticamente e alterações podem interromper serviços essenciais.

Como configurar e gerenciar SPNs

Passo 1: Identifique o serviço e a conta alvo

Passo 2: Verifique SPNs existentes ou duplicados

A configuração correta do SPN é um pré-requisito para o funcionamento da autenticação Kerberos. O processo segue uma sequência consistente, independentemente do tipo de serviço, e pular etapas é a causa mais comum de problemas relacionados ao SPN.

Antes de registrar, confirme que o SPN não existe já em outra conta. Use os seguintes comandos para consultar o diretório:

Registrar um SPN duplicado pode causar falhas de autenticação e ser difícil de diagnosticar depois.

Passo 3: Registre o SPN com setspn

Antes de registrar um SPN, identifique duas coisas: a classe e o formato do serviço necessários, e a conta do Active Directory que executará o serviço. Para serviços padrão (SQL Server, IIS, Exchange), a classe do serviço é bem documentada. Para a conta, prefira uma Active Directory service account dedicada ou, quando possível, uma Group Managed Service Account (gMSA) em vez de uma conta compartilhada ou pessoal.

Para SQL Server executando em uma porta não padrão:

Use setspn -SExpand (adição segura) para registrar o SPN. A flag -S verifica automaticamente duplicatas antes de criar a entrada, tornando-a mais segura que a antiga flag -A:

Passo 4: Verifique o registro

Você também pode registrar SPNs via PowerShell usando os cmdlets Set-ADUser ou Set-ADComputer, útil para implantações automatizadas ou registros em massa.

Você também pode verificar usando PowerShell:

Após o registro, confirme que o SPN aparece na conta correta:

A saída deve listar o SPN recém-registrado junto com quaisquer outros já atribuídos a essa conta.

Passo 5: Teste a autenticação Kerberos

Correção de configurações incorretas comuns de SPN

A maioria dos problemas de SPN se enquadra em poucas categorias. Cada um requer uma solução direcionada:

No Visualizador de Eventos do Windows, uma solicitação bem-sucedida de ticket de serviço Kerberos aparece como Evento ID 4769. Se a autenticação retornar para NTLM, é provável que o SPN esteja ausente, malformado ou registrado na conta errada.

Com o SPN registrado, teste se a autenticação Kerberos é bem-sucedida. Conecte-se ao serviço usando credenciais de domínio e execute klistExpand para confirmar que o DC emitiu um ticket de serviço Kerberos (não um ticket NTLM).

Melhores práticas para registro de SPN

• SPNs duplicados: Use setspn -DExpand para remover o SPN da conta incorreta e depois verifique se permanece na conta correta. Duplicatas geralmente aparecem após renomeações de servidor ou migrações de conta.
• SPNs obsoletos após renomear um servidor: SPNs antigos que fazem referência ao nome do host anterior devem ser removidos e novos registrados com o nome atual.
• SPNs ausentes: Se o Kerberos falhar e voltar para NTLM, verifique se o SPN existe usando setspn -QExpand. Registre-o se estiver ausente.
• SPNs registrados na conta errada: Remova com setspn -DExpand e registre novamente na conta de serviço correta.

Estabelecer práticas consistentes para o gerenciamento de SPN reduz tanto falhas operacionais quanto riscos de segurança:

• Realize auditorias regulares do PowerShell para identificar SPNs registrados em contas inadequadas.
• Atribua SPNs a contas de serviço dedicadas, não a contas de usuário pessoais ou contas Domain Admin.
• Use setspn -SExpand (não -A) ao registrar para evitar duplicatas acidentais.
• Use um formato de nomenclatura padronizado em todo o seu ambiente para simplificar auditorias.

Riscos de segurança de SPNs mal configurados

Kerberoasting

• Conceda às contas as permissões mínimas necessárias. O registro SPN requer acesso de gravação ao atributo servicePrincipalNameExpand, que não deve ser concedido amplamente.

Contas de serviço associadas a SPNs estão entre as identidades mais visadas no Active Directory. Diferente das contas de usuário padrão, frequentemente possuem privilégios elevados, mantêm acesso persistente a sistemas críticos e raramente são revisadas após a criação. Essa combinação gera riscos de segurança associados a SPNs mal configurados.

Ataques de ticket prateado

Um invasor pode solicitar o ticket, extraí-lo e realizar a quebra de senha offline sem acionar bloqueios ou gerar ruído significativo na rede.

Kerberoasting é a técnica de ataque baseada em SPN mais prevalente. Qualquer usuário autenticado no domínio, incluindo contas com poucos privilégios, pode solicitar um ticket de serviço Kerberos para qualquer SPN no diretório. Esse ticket é criptografado com o hash da senha da conta de serviço.

A criptografia RC4 torna esse ataque significativamente mais rápido porque os tickets Kerberos criptografados com RC4 são mais fáceis de quebrar do que os modernos protegidos por AES, por isso a Microsoft está descontinuando ativamente o RC4 em ambientes AD.

Se a conta de serviço usar uma senha fraca ou reutilizada, o invasor pode recuperar as credenciais em texto simples e obter acesso ao serviço, frequentemente com privilégios elevados.

Movimentação lateral via contas de serviço comprometidas

Como se defender contra ataques baseados em SPN

Escalada de privilégios através de SPNs com altos privilégios

SPNs registrados em contas com permissões excessivas, especialmente contas com direitos de Domain Admin ou acesso irrestrito a sistemas críticos, representam as configurações de maior risco. Um ataque Kerberoasting bem-sucedido contra uma dessas contas não compromete apenas um serviço; pode dar ao invasor controle em nível de domínio.

Detecção de Kerberoasting e enumeração de SPN

Uma consequência natural do Kerberoasting é o ataque de ticket prateado. Uma vez que um invasor quebra o hash da senha de uma conta de serviço, ele pode usá-lo para forjar tickets de serviço Kerberos totalmente offline, sem interação adicional com o controlador de domínio. Esses tickets prateados concedem acesso persistente ao serviço alvo e são particularmente difíceis de detectar porque contornam completamente o DC.

As contas de serviço geralmente têm acesso a vários sistemas. Quando um invasor compromete uma, ele ganha um ponto de apoio que permite movimentação lateral pelo ambiente. Como as contas de serviço costumam ser excluídas das regras padrão de monitoramento e detecção de anomalias, esse movimento pode passar despercebido por longos períodos.

O monitoramento contínuo do seu ambiente AD é a primeira linha de defesa. Indicadores a serem observados incluem:

A defesa contra ataques baseados em SPN atua em três áreas: detectar abusos precocemente, responder eficazmente quando ocorrem e fortalecer o ambiente para reduzir a superfície de ataque antes que um incidente aconteça.

• Consultas incomuns de enumeração de SPN. Atacantes geralmente usam ferramentas LDAP para listar todos os SPNs em um domínio durante o reconhecimento.
• Logins de contas de serviço a partir de hosts inesperados ou em horários incomuns.

Restringir quem pode consultar SPNs modificando permissões no Active Directory reduz a janela de reconhecimento disponível para atacantes com poucos privilégios.

Conter e responder ao abuso de SPN

• Um aumento repentino no ID do Evento 4769 (solicitações de ticket de serviço Kerberos), especialmente aqueles que usam criptografia RC4 (tipo de criptografia 0x17), indica fortemente Kerberoasting, pois os atacantes preferem tickets RC4 para uma quebra mais rápida.
• Tentativas repetidas de autenticação falhada, que podem indicar ataques de força bruta ou password-spraying contra credenciais comprometidas.

Quando é detectado abuso baseado em SPN, a prioridade é limitar a capacidade do atacante de usar as credenciais comprometidas:

• Redefina imediatamente a senha da conta de serviço afetada com uma credencial longa gerada aleatoriamente.
• Verifique se a conta possui mais privilégios do que sua função exige e reduza-os.
• Revise todos os sistemas aos quais a conta de serviço tem acesso e audite as atividades recentes em busca de sinais de movimentação lateral.

Endurecimento de contas de serviço habilitadas para SPN

O fortalecimento proativo elimina muitas das condições que tornam ataques baseados em SPN viáveis:

• Use senhas longas geradas aleatoriamente (mínimo de 25 caracteres) para contas de serviço e altere-as em um cronograma definido.
• Revogue quaisquer tickets Kerberos ativos emitidos para a conta redefinindo as chaves de criptografia Kerberos da conta (não é necessário redefinir o krbtgt para mitigar silver tickets; redefinir a senha da conta de serviço invalida tickets forjados).
• Desative o login interativo para contas de serviço para limitar sua utilidade se forem comprometidas.
• Aplique o princípio do menor privilégio. Contas de serviço devem ter acesso apenas aos sistemas e dados que sua função exige.

Uso de gMSAs e criptografia AES para eliminar risco permanente

• Migre para Group Managed Service Accounts sempre que possível, pois automatizam o gerenciamento de senhas e tornam o Kerberoasting significativamente mais difícil.

As Group Managed Service Accounts (gMSAs) são contas de serviço especializadas que eliminam completamente a necessidade de gerenciamento manual de senhas. O Active Directory gerencia automaticamente as senhas gMSA, rotacionando-as em um cronograma definido usando credenciais longas e geradas aleatoriamente que os administradores de serviço e de domínio nunca veem ou manipulam diretamente.

SPNs em ambientes híbridos e modernos

Por padrão, o Windows rotaciona as senhas gMSA a cada 30 dias, e o intervalo é controlado pelo atributo msDS‑ManagedPasswordInterval (ou pelo parâmetro ManagedPasswordIntervalInDays ao criar o gMSA), que só pode ser definido no momento da criação.

Para serviços que não suportam gMSAs, aplique criptografia Kerberos AES-128 ou AES-256 e desative explicitamente os tipos de criptografia mais fracos RC4 e DES no Active Directory. A criptografia RC4 é a padrão usada em ataques Kerberoasting; removê-la força o uso de AES, que é significativamente mais resistente à quebra offline.

• Nunca atribua SPNs a contas com associações a Domain Admin ou outros grupos de alto privilégio.

SPNs e Microsoft Entra Connect

O papel dos SPNs expandiu-se além do tradicional Active Directory local, à medida que as organizações adotam arquiteturas híbridas e cargas de trabalho conteinerizadas. Os SPNs continuam relevantes onde quer que a autenticação Kerberos seja usada e, em alguns contextos mais recentes, permitem padrões de autenticação que não existiam no design original do AD.

SPNs em ambientes containerizados

Autenticação delegada em aplicações multinível

Microsoft Entra Connect usa SPNs para seus serviços de sincronização entre Active Directory local e Entra ID (anteriormente Azure AD). A conta do serviço de sincronização requer SPNs configurados corretamente para autenticar em ambos os diretórios. SPNs mal configurados ou ausentes podem interromper silenciosamente a sincronização do diretório, fazendo com que os dados de identidade fiquem desatualizados em todo o ambiente híbrido.

Delegação Kerberos permite que um serviço se autentique em recursos downstream em nome de um usuário. Isso é comum em aplicações multinível onde uma interface web precisa passar a identidade do usuário para um banco de dados backend.

Workloads conteinerizadas executadas no Windows Server podem usar gMSAs e, por extensão, SPNs, para Active Directory security. Implantações do Kubernetes e Docker em hosts ingressados no domínio podem ser configuradas para solicitar credenciais gMSA, permitindo que serviços conteinerizados autentiquem recursos integrados ao AD usando Kerberos sem incorporar credenciais nas imagens dos contêineres.

Os SPNs são essenciais para isso: a delegação é configurada na conta de serviço que possui o SPN, e cada etapa na cadeia de autenticação depende de SPNs corretamente registrados.

Os SPNs são fundamentais e cada vez mais visados

A delegação irrestrita, onde um serviço pode se passar por qualquer usuário para qualquer recurso, representa uma superfície de ataque significativa e deve ser substituída por delegação restrita ou delegação restrita baseada em recursos sempre que possível.

Os Service Principal Names são uma pedra angular da autenticação Kerberos desde o início do Active Directory. Eles permitem uma autenticação segura de serviços sem senha em ambientes empresariais, mas somente quando configurados corretamente, auditados regularmente e rigidamente controlados.

Netwrix oferece ferramentas específicas para os dois maiores desafios de segurança SPN: detectar ataques em andamento e manter a visibilidade das alterações no AD que introduzem riscos.

Como a Netwrix pode ajudar

À medida que as organizações expandem para infraestruturas híbridas, containers e sistemas de identidade integrados na nuvem, os SPNs aparecem em mais lugares e estão vinculados a contas com acesso mais amplo do que nunca.

O cálculo da ameaça mudou de acordo. Kerberoasting tornou-se uma das técnicas de movimento lateral mais comumente observadas em violações empresariais, precisamente porque os SPNs são tanto onipresentes quanto pouco monitorados. Configurações incorretas que antes causavam falhas de autenticação agora fazem parte da superfície de ataque.

Entender os SPNs, como são estruturados, como o AD os resolve e como os atacantes exploram configurações fracas é o primeiro passo para protegê-los. As etapas operacionais abordadas neste artigo fornecem uma base. Com isso, o monitoramento contínuo, auditorias regulares de SPN e, quando possível, a migração para gMSAs ajudam as organizações a se antecipar à ameaça.

Netwrix Threat Manager detecta ataques baseados em identidade, incluindo Kerberoasting, consultas de enumeração SPN e solicitações suspeitas de tickets de serviço no Active Directory local e Entra ID.

Correla com atividade anômala no nível da conta. Quando um usuário com poucos privilégios solicita repentinamente 50 tickets de serviço, as equipes de segurança veem isso como um único alerta consolidado, e não como entradas de log isoladas.

Solicite uma demonstração para ver como Netwrix pode ajudar a detectar abuso de SPN, auditar alterações em AD em tempo real e reduzir a superfície de ataque antes que adversários a explorem.

Netwrix Auditor registra cada alteração no atributo servicePrincipalName em todo o seu ambiente AD, com valores antes e depois e a conta responsável por cada alteração. Quando um SPN é registrado em uma conta de alto privilégio ou removido inesperadamente de uma conta de serviço, Auditor exibe essa alteração imediatamente.