Contents

Introdução

Terminologia

Conhecimento e requisitos

Fluxo de rede Kerberos

Fluxo de autenticação Kerberos no WSA

Qual é a finalidade do SPN?

Configuração do Servidor do Ative Diretory

Troubleshooting de Kerberos com Comandos SPN

Exemplos de comandos SPN e saída

Cenário 1: SPN Não Encontrado

Cenário 2: SPN Encontrado

Troubleshooting de Kerberos no WSA

Informações adicionais e referências

Introdução

Este documento descreve o Protocolo Kerberos usando tickets para verificar com segurança identidades em sites e sistemas de Signon único.

Terminologia

WSA

Dispositivos de segurança da Web

CLI

Interface da linha de comando

ANÚNCIO

Diretório ativo

SPN

Nome da Entidade de Serviço

KDC

Centro de Distribuição de Chaves Kerberos

TGT

Tíquete de autenticação

TGS

Serviço de concessão de tíquete

HA

Alta Disponibilidade

VRRP

Virtual Router Redundancy Protocol (Protocolo de redundância de roteador virtual)

CARPA

Common Address Redundancy Protocol (Protocolo de redundância de endereço comum)

Conhecimento e requisitos

- Ative Diretory e autenticação.

- Autenticação e territórios no WSA

Fluxo de rede Kerberos

Estas são as etapas básicas da autenticação em um ambiente Kerberizado:

1. O cliente solicita um TGT (Tíquete de Concessão de Tíquete) do KDC (Centro de Distribuição de Chaves).

2. O KDC verifica as credenciais do usuário da máquina cliente e envia de volta um TGT criptografado e uma chave de sessão.

3. O TGT é criptografado com a chave secreta do TGS (Serviço de Concessão de Tíquete).

4. O cliente armazena o TGT e solicita automaticamente um novo quando ele expira.

Para acessar um serviço ou recurso:

1. O cliente envia o TGT ao TGS junto com o Nome da Entidade de Serviço (SPN) do recurso desejado.

2. O KDC verifica o TGT e os direitos de acesso à máquina cliente do usuário.

3. O TGS envia uma chave de sessão específica de serviço ao cliente.

4. O cliente fornece a chave de sessão ao serviço para comprovar o acesso e o serviço concede o acesso.

Fluxo de autenticação Kerberos no WSA

1. O cliente solicita acesso a www.google.com através do WSA.

2. O WSA responde com um status HTTP 407, solicitando autenticação.

3. O cliente solicita um tíquete de serviço do servidor AD para o serviço HTTP/wsa.domain.com usando o TGT que obtém durante o ingresso no domínio.

4. O servidor do AD valida o cliente e emite um tíquete de serviço. Se for bem-sucedido e o SPN (nome da entidade de serviço) do WSA for encontrado, ele prosseguirá para a próxima etapa.

5. O cliente envia esse tíquete para o WSA.

6. O WSA descriptografa o tíquete e verifica a autenticação.

7. Se a autenticação for bem-sucedida, o WSA verificará as políticas.

8. O WSA envia uma resposta HTTP 200 OK ao cliente se a transação for permitida.

Qual é a finalidade do SPN?

Um SPN (Nome da Entidade de Serviço) identifica exclusivamente uma instância de serviço na autenticação Kerberos. Ela vincula uma instância de serviço a uma conta de serviço, permitindo que os clientes solicitem autenticação para o serviço sem precisar do nome da conta. Cada conta em uma implementação do Centro de Distribuição de Chaves (KDC), como AD ou Open LDAP, tem um SPN. Embora o SPN identifique estritamente um serviço, às vezes ele é usado por engano para se referir ao nome do cliente (UPN) em cenários onde o serviço também atua como um cliente.

No Kerberos, um Service Principal Name (SPN) identifica exclusivamente uma instância de serviço em uma rede. Permite que os clientes solicitem autenticação para um serviço específico. O SPN vincula a instância do serviço à sua conta, permitindo que o Kerberos autentique e autorize corretamente as solicitações de acesso a esse serviço.

Configuração do Servidor do Ative Diretory

- Criar uma nova conta de usuário ou escolher uma conta de usuário existente para usar

- Registrar o SPN a ser usado na conta de usuário escolhida

- Certifique-se de que nenhum SPN duplicado esteja registrado

Tip: Como o Kerberos com balanceador de carga atrasado do WSA ou um Gerenciador de Tráfego/Modelador de Tráfego é diferente? Em vez de associar o SPN para o nome de host virtual HA a uma conta de usuário, associe o SPN para o dispositivo de redirecionamento de tráfego HTTP (por exemplo:LoadBalancer ou Gerenciador de tráfego) a uma conta de usuário no AD.

Troubleshooting de Kerberos com Comandos SPN

Esta é uma lista de comandos `setspn` úteis para gerenciar SPNs (Nomes da Entidade de Serviço) em um ambiente Kerberos. Esses comandos são normalmente executados em uma interface de linha de comando com privilégios administrativos em um ambiente Windows.

Listar SPNs para uma conta específica:

setspn -L <User/ComputerAccountName>

Lista todos os SPNs registrados para a conta especificada.

Adicionar um SPN a uma conta:

setspn -A <SPN> <User/ComputerAccountName>

Adiciona o SPN especificado à conta fornecida.

Excluir um SPN de uma conta:

setspn -D <SPN> <User/ComputerAccountName>

Remove o SPN especificado da conta fornecida.

Verifique se um SPN já está registrado:

setspn -Q <SPN>

Verifica se o SPN especificado já está registrado no domínio.

Listar todos os SPNs no domínio

setspn -L <Conta do usuário/computador>

Lista todos os SPNs no domínio.

Defina um SPN para uma conta de computador:

setspn -S <SPN> <User/ComputerAccountName>

Adiciona um SPN a uma conta de computador, garantindo que não haja entradas duplicadas.

Redefinir SPNs para uma conta específica:

setspn -R <User/ComputerAccountName>

Redefine os SPNs da conta especificada, ajudando a resolver problemas de SPN duplicados.

Exemplos de comandos SPN e saída

Os exemplos fornecidos demonstram o uso:

Conta de Usuário/Computador: vrrpserviceuser

SPN: http/WsaHostname.com ou http/proxyha.localdomain

- Verifique se o SPN já está associado a uma conta de usuário:

setspn -q <SPN>

setspn -q http/proxyha.localdomain

Cenário 1: SPN Não Encontrado

Cenário 2: SPN Encontrado

- Associe um SPN a uma conta de usuário/computador válida:

Sintaxe: setspn -s <SPN> <Conta do usuário/computador>

Por exemplo: setspn -s http/proxyha.localdomain vrrpserviceuser

- Excluir/Remover um SPN que já esteja associado a um

conta de usuário/computador:

Sintaxe: setspn -d <SPN> <Conta do usuário/computador>

Por exemplo: setspn -d http/proxyha.localdomain pod1234-wsa0

Certifique-se de que não haja SPNs duplicados para o nome de host virtual HA, pois as falhas podem ocorrer mais tarde:

Comando a ser usado: setspn -x

Como resultado, o tíquete do Serviço Kerberos não é fornecido ao cliente e a autenticação Kerberos falha.

Caution: Se forem encontradas duplicatas, remova-as usando o comando setspn -d

- Liste todos os SPNs associados a uma conta:

Sintaxe: setspn -l <Conta do usuário/computador>

Por exemplo: setspn -l vrrpserviceuser

Troubleshooting de Kerberos no WSA

Informações que o TAC precisa obter ao solucionar problemas de autenticação kerberos

- Detalhes da configuração atual

- Logs de autenticação (preferencialmente no modo de depuração ou rastreamento)

- Capturas de pacotes usadas (com filtros apropriados):

a) Dispositivo cliente

b) WSA

- Logs de acesso com o especificador de formato personalizado %m habilitado. Isso deve mostrar o mecanismo de autenticação que foi usado para uma transação específica.

Tip: Para obter detalhes de autenticação, adicione esses campos personalizados aos logs de acesso de proxies funcionais/não funcionais para obter mais informações

Na GUI do WSA, navegue até > Administração do sistema > Inscrição no log > Logs de acesso > Campos personalizados > Adicionar esta cadeia de caracteres para problemas de autenticação

endereço IP do servidor = %k, endereço IP do cliente= %a, Auth-Mech = %m, Auth_Type= %m, Auth_group= %g, Authenticated_Username= %A, Date= %L, Transaction_ID= %I Resposta de autenticação = %:<a, Total de autenticação = %:>a;

Instantâneo de log de acesso WSA para detalhes de autenticação do usuário

- Um caso de erro comum são solicitações da Web que falham com "Servidor não encontrado no banco de dados Kerberos":

curl -vx proxyha.localdomain:3128 —proxy-negotiation -u: http://www.google.com/

* Prestes a conectar() ao proxy proxyha.localdomain porta 3128 (#0)

* Conectado a proxyha.localdomain (10.8.96.30) porta 3128 (#0)

< HTTP/1.1 407 Autenticação de proxy necessária

< Via: 1.1 pod1234-wsa02.localdomain:80 (Cisco-WSA/10.1.2-003)

< Tipo de conteúdo: texto/html

Falha em gss_init_sec_context(): : Servidor não encontrado no banco de dados Kerberos

< Autenticação de proxy: Negotiate

< Conexão: fechar

* Conexão de proxy HTTP/1.1 definida fechada!

Nesse caso, o erro indica que o Nome da Entidade de Serviço correspondente ao valor de endereço de proxy proxyha.localdomain não está registrado no servidor do Ative Diretory. Para resolver o problema, seria necessário confirmar se o SPN http/proxyha.localdomain está registrado no AD DC e adicionado a uma conta de serviço apropriada.

- As Melhores formas de aprendizado para a implementação do kerberos estão documentadas neste hiperlink:

Práticas recomendadas de dispositivos da Web seguros

Informações adicionais e referências