O que é SPN e qual é o 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.