Entender o Identity Service Engine e o Ative Diretory

Introdução

Este documento descreve como o Identity Service Engine (ISE) e o Ative Diretory (AD) se comunicam, os protocolos que são usados, os filtros do AD e os fluxos.

---

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento básico de:

• Autenticação de identidade externa no ISE
• ISE 2.x e integração com o Ative Diretory

---

Componentes Utilizados

• ISE 2.x 
• Windows Server (Ative Diretory) 

---

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

---

Protocolos AD

Protocolo Kerberos  

Os três chefes do Kerberos compreendem o Centro de Distribuição de Chaves (KDC), o usuário cliente e o servidor a ser acessado. O KDC é instalado como parte do Controlador de Domínio (DC) e executa duas funções de serviço: O Serviço de Autenticação (AS) e o Serviço de Concessão de Tíquetes (TGS).

---

Três trocas são envolvidas quando o cliente acessa inicialmente um recurso de servidor:

1. AS Exchange
2. Troca TGS
3. Intercâmbio cliente/servidor (CS)

---

---

• Controlador de domínio = KDC (AS + TGS)
• Autenticar no AS (o portal SSO) com sua senha
• Obter um TGT (Tíquete de Concessão de Tíquete) (um cookie de sessão)
• Solicitar login em um serviço (SRV01)
• SRV01 o redireciona para KDC
• Mostrar TGT para KDC - (já estou autenticado)
• KDC oferece TGS para SRV01
• Redirecionar para SRV01
• Mostra o tíquete de serviço para SRV01
• O SRV01 verifica/confia no tíquete de serviço
• O tíquete de serviço tem todas as minhas informações
• O SRV01 me conecta

---

Quando conectados inicialmente a uma rede, os usuários devem negociar o acesso e fornecer um nome e uma senha de login a serem verificados pela parte AS de um KDC em seu domínio. O KDC tem acesso às informações de conta de usuário do Ative Diretory. Depois de autenticado, o usuário recebe um TGT (Ticket Granting Ticket, Tíquete de concessão de tíquete) válido para o domínio local. O TGT tem um tempo de vida padrão de 10 horas e é renovado durante toda a sessão de logon do usuário sem a necessidade do usuário digitar a senha novamente. O TGT é armazenado em cache na máquina local em espaço de memória volátil e é usado para solicitar sessões com serviços em toda a rede.

---

O usuário apresenta o TGT à parte TGS do KDC quando o acesso a um serviço de servidor é necessário. O TGS no KDC autentica o usuário TGT e cria um tíquete e uma chave de sessão para o cliente e o servidor remoto. Essas informações (o tíquete de serviço) são armazenadas em cache localmente na máquina cliente. O TGS recebe o cliente TGT e lê com sua própria chave. Se o TGS aprovar a solicitação do cliente, um tíquete de serviço será gerado para o cliente e o servidor de destino. O cliente lê sua parte com a chave de sessão TGS recuperada anteriormente da resposta do AS. O cliente apresenta a parte do servidor da resposta TGS para o servidor de destino na próxima troca cliente/servidor.

---

Exemplo:

---

Capturas de pacotes do ISE para um usuário autenticado:

---

O AS-REQ contém o nome de usuário. Se a senha estiver correta, o serviço AS fornece um TGT criptografado com a senha do usuário. O TGT recebe o serviço TGT para receber um tíquete de sessão. A autenticação é bem-sucedida quando um tíquete de sessão é recebido.

---

Este é um exemplo onde a senha fornecida pelo cliente está incorreta:

---

Se a senha estiver incorreta, a solicitação de AS falha e o TGT não é recebido:

---

Neste próximo exemplo, estes são logs no arquivo ad_agent.log quando a senha está incorreta:

2020-01-14 13:36:05,442 DEPURAÇÃO ,140574072981248,krb5: Solicitação enviada (276 bytes) para RALMAAIT.COM,LwKrb5TraceCallback(),lwadvapi/threaded/lwkrb5.c:1325

2020-01-14 13:36:05,444 DEPURAÇÃO ,140574072981248,krb5: Erro recebido do KDC: -1765328360/Falha na pré-autenticação,LwKrb5TraceCallback(),lwadvapi/threaded/lwkrb5.c:1325

2020-01-14 13:36:05,444 DEPURAÇÃO ,140574072981248,krb5: Tipos de entrada de tentativa de pré-autenticação: 16, 14, 19, 2,LwKrb5TraceCallback(),lwadvapi/threaded/lwkrb5.c:1325

2020-01-14 13:36:05,444 AVISO,140574072981248,[LwKrb5GetTgtImpl ../../lwadvapi/threaded/krbtgt.c:329] KRB5 Código do erro: -1765328360 (Mensagem: Falha na pré-autenticação),LwTranslateKrb5Error(),lwadvapi/threaded/lwkrb5.c:892

2020-01-14 13:36:05,444 DEBUG ,140574072981248,[LwKrb5InitializeUserLoginCredentials()] Código do erro: 40022 (símbolo: LW_ERROR_PASSWORD_MISMATCH),LwKrb5InitializeUserLoginCredentials(),lwadvapi/threaded/lwkrb5.c:1453

---

Protocolo MS-RPC

O ISE usa o MS-RPC sobre o SMB, e o SMB fornece a autenticação e não exige uma sessão separada para localizar onde um determinado serviço RPC está localizado. Ele usa um mecanismo chamado "pipe nomeado" para se comunicar entre o cliente e o servidor.

---

• Criar uma conexão de sessão SMB
• Transporte de mensagens RPC pela porta SMB/CIFS.TCP 445 como um transporte 
• A sessão SMB identifica qual porta um serviço RPC específico é executado e manipula a autenticação do usuário
• Conecte-se ao compartilhamento oculto IPC$ para comunicação entre processos
• Abra um pipe nomeado apropriado para o recurso/função RPC desejado
• Transacionar o intercâmbio RPC sobre SMB

---

---

A linha negociar solicitação/resposta de protocolo negocia o dialeto do SMB e a solicitação/resposta de configuração de sessão executa a autenticação. Solicitação e Resposta de Conexão de Árvore conecta-se ao recurso solicitado. Você está conectado a um compartilhamento especial IPC$. Esse compartilhamento de comunicação entre processos fornece os meios de comunicação entre hosts e também como um transporte para funções MSRPC.

---

O pacote 77 é Create Request File e o nome do arquivo é o nome do serviço conectado (o serviço netlogon neste exemplo).

Os pacotes 83 e 86 são a solicitação NetrlogonSamLogonEX, que é onde você envia o nome de usuário para a autenticação do cliente no ISE para o AD no campo Network_INFO. O pacote de resposta NetrlogonSamLogonEX responde com os resultados.

---

Alguns sinalizam valores para a resposta NetrlogonSamLogonEX:

0xc000006a é STATUS_WRONG_PASSWORD
0x00000000 é STATUS_SUCCESS
0x00000103 é STATUS_PENDING

---

Integração do ISE com o Ative Diretory (AD)

O ISE usa LDAP, KRB e MSRBC para se comunicar com o AD durante o processo de ingresso/saída e autenticação. As próximas seções fornecem os protocolos, o formato de pesquisa e os mecanismos usados para conectar a um DC específico no AD e a autenticação de usuário nesse DC. Se o controlador de domínio ficar off-line por qualquer motivo, o ISE efetuará failover para o próximo controlador de domínio disponível e o processo de autenticação não será afetado.

---

Um servidor de Catálogo Global (GC) é um controlador de domínio que armazena cópias de todos os objetos do Ative Diretory na floresta. Ele armazena uma cópia completa de todos os objetos no diretório do seu domínio e uma cópia parcial de todos os objetos de todos os outros domínios da floresta. O Catálogo Global permite que usuários e aplicativos localizem objetos em qualquer domínio da floresta atual com uma pesquisa por atributos incluídos no GC. O Catálogo Global contém um conjunto básico (mas incompleto) de atributos para cada objeto da floresta em cada domínio (Conjunto de Atributos Parciais, PAT).

O GC recebe dados de todas as partições de diretório de domínio na floresta e eles são copiados com o serviço de replicação do AD padrão.

---

Junte-se ao ISE para o AD

Pré-requisitos para integrações com o Ative Diretory e o ISE.

1. Verifique se você tem privilégios de um Super Admin ou Administrador de sistema no ISE.
2. Use as configurações do servidor Network Time Protocol (NTP) para sincronizar o horário entre o servidor Cisco e o Ative Diretory. A diferença de tempo máxima permitida entre ISE e AD é de 5 minutos.
3. O DNS configurado no ISE deve responder a consultas SRV para DCs, GCs e KDCs com ou sem informações de site adicionais.
4. Certifique-se de que todos os servidores DNS possam responder consultas de encaminhamento e reversão de DNS para qualquer domínio DNS do Ative Diretory possível.
5. O AD deve ter pelo menos um servidor de catálogo global operacional e acessível pela Cisco para o domínio que você planeja adicionar à Cisco.

---

Ingressar no domínio do AD

O ISE aplica a descoberta de domínio para obter informações sobre o domínio de ingresso em três fases:

1. Consulta domínios associados — Descobre domínios de sua floresta e domínios externamente confiáveis para o domínio associado.
2. Consulta domínios raiz em sua floresta — Estabelece confiança com a floresta.
3. Consulta domínios raiz em florestas confiáveis — Descobre domínios das florestas confiáveis.

Além disso, o Cisco ISE descobre nomes de domínio DNS (sufixos UPN), sufixos UPN alternativos e nomes de domínio NTLM.

---

O ISE aplica uma descoberta de DC para obter todas as informações sobre DCs e GCs disponíveis.

1. O processo de ingresso começa com as credenciais de entrada de um superadministrador no AD que existe no próprio domínio. Se existir em um domínio ou subdomínio diferente, o nome de usuário deve ser anotado em uma notação UPN (username@domain).
2. O ISE envia uma consulta DNS para todos os registros de DCs, GCs e KDCs. Se a resposta DNS não receber uma resposta, a integração falha com um erro relacionado ao DNS.
3. O ISE usa o ping do CLDAP para descobrir todos os DCs e GCs através das solicitações do CLDAP enviadas aos DCs que correspondem às suas prioridades no registro SRV. A primeira resposta de DC é usada e o ISE é conectado a esse DC.

Um fator usado para calcular a prioridade de DC é o tempo que o DC leva para responder aos pings do CLDAP; uma resposta mais rápida recebe uma prioridade mais alta.

---

---

4. O ISE recebe TGT com as credenciais de 'usuário associado'.
5. Gerar o nome da conta do computador ISE com o MSRPC (SAM e SPN)
6. Pesquise o AD por SPN se a conta da máquina do ISE já existir. Se a máquina do ISE não existir, o ISE criará uma nova.
7. Abra a conta da máquina, defina a senha da conta da máquina do ISE e verifique se a conta da máquina do ISE está acessível.
8. Defina os atributos da conta da máquina do ISE (SPN, dnsHostname e assim por diante).
9. Receba TGT com credenciais de máquina do ISE com KRB5 e descubra todos os domínios confiáveis.
10. Quando a junção é concluída, o nó do ISE atualiza seus grupos do AD e SIDS associados e inicia automaticamente o processo de atualização do SID. Verifique se este processo pode ser concluído no lado do AD.

---

Sair do domínio do AD

Quando o ISE sair, o AD deve considerar:

1. Use um usuário administrador do AD completo para executar os processos de licença. Isso verifica se a conta da máquina ISE foi removida do banco de dados do Ative Diretory.
2. Se o AD for deixado sem credenciais, a conta ISE não será removida do AD e deverá ser excluída manualmente.
3. Ao redefinir a configuração do ISE a partir da CLI ou restaurar a configuração após um backup ou atualização, ele executa uma operação de licença e desconecta o nó do ISE do domínio do Ative Diretory. No entanto, se ingressada, a conta do nó ISE não é removida do domínio do Ative Diretory.
4. É recomendável executar uma operação de licença no portal do administrador com as credenciais do Ative Diretory, pois ela também remove a conta de nó do domínio do Ative Diretory. Isso também é recomendado quando você altera o nome de host do ISE.

---

Failover de DC

Quando o DC conectado ao ISE fica off-line ou inacessível por qualquer motivo, o failover do DC é acionado automaticamente no ISE. O failover de DC pode ser acionado pelas seguintes condições:

1. O conector AD detecta que o controlador de domínio selecionado no momento ficou indisponível durante alguma tentativa de comunicação LDAP, LDAP, RPC ou Kerberos. Nesses casos, o conector AD inicia a seleção de DC e executa o failover para o DC recém-selecionado.
2. O DC está ativo e responde ao ping do CLDAP, mas o Conector AD não pode se comunicar com ele por algum motivo (por exemplo, a porta RPC está bloqueada, o DC está em estado de "replicação interrompida", o DC não foi descomissionado corretamente).

---

Nesses casos, o conector do AD inicia a seleção do DC com uma lista bloqueada (o DC "ruim" é colocado na lista bloqueada) e tenta se comunicar com o DC selecionado. O DC selecionado na lista bloqueada não está armazenado em cache.

O conector AD deve concluir o failover em um período de tempo razoável (ou falhar se não for possível). Por esse motivo, o conector do AD tenta um número limitado de DCs durante o failover. O ISE bloqueia os Controladores de Domínio do AD se houver um erro irrecuperável de rede ou servidor para impedir que o ISE use um controlador de domínio inválido. O DC não será adicionado à lista de bloqueados se não responder aos pings do CLDAP. O ISE só reduz a prioridade do DC se não responder.

---

Comunicação ISE-AD através de LDAP

O ISE procura uma máquina ou um usuário no AD com um destes formatos de pesquisa. Se a pesquisa for por uma máquina, o ISE adicionará "$" ao final do nome da máquina. Esta é uma lista de tipos de Identidade que é usada para identificar um usuário no AD:

---

• Nome do SAM: Nome de usuário ou nome da máquina sem nenhuma marcação de domínio, este é o Nome de logon do usuário no AD. Exemplo: sajeda ou sajeda$

• CN: Este é o nome de exibição do usuário no AD, ele não deve ser igual ao SAM. Exemplo: sajeda Ahmed

• Nome UPN: É uma combinação do nome SAM e do nome de domínio (SAM_NAME@domian). Exemplo: sajeda@cisco.com ou sajeda$@cisco.com

• UPN alternativo: Este é um sufixo UPN adicional/alternativo configurado no AD diferente do nome de domínio. Essa configuração é adicionada globalmente no AD (não configurada por usuário) e não é necessário ser um sufixo de nome de domínio real.
  • Cada AD pode ter vários sufixos UPN (@alt1.com,@alt2.com etc.). Por exemplo, UPN principal (sajeda@cisco.com), UPN alternativo :sajeda@domain1, sajeda@domain2

• Nome NetBIOS Prefixado: Este é o nome de domínio/nome de usuário do nome da máquina. Por exemplo, CISCO\sajeda ou CISCO\machine$

• Host/prefixo com uma máquina não qualificada: É usado para autenticação da máquina quando o nome da máquina é usado somente e é somente o nome do host/máquina. Por exemplo, host/máquina.

• Host/prefixo com máquina totalmente qualificada: Isso é usado para autenticação da máquina quando o FQDN da máquina é usado, geralmente no caso de autenticação de certificado. É o host/FQDN da máquina. Por exemplo, host/machine.cisco.com.

• Nome do SPN: O nome que um cliente identifica exclusivamente uma instância de um serviço (por exemplo, HTTP, LDAP, SSH) usado somente para máquinas.

---

Autenticação de usuário em relação ao fluxo do AD:

1. Resolver Identidade e determinar o tipo de identidade - SAM, UPN, SPN. Se o ISE receber a identidade apenas como um nome de usuário, ele procurará uma conta SAM associada no AD. Se o ISE receber a identidade como um username@domain, ele procurará um UPN ou e-mail correspondente no AD. Em ambos os cenários, o ISE usa filtros adicionais para a máquina ou um nome de usuário. 
2. Pesquise o domínio ou a floresta (dependendo do tipo de identidade).
3. Manter informações sobre todas as contas associadas (JP, DN, UPN, Domínio).
4. Se nenhuma conta associada for encontrada, as respostas do AD com o usuário serão desconhecidas.
5. Execute a autenticação MS-RPC (ou Kerberos) para cada conta associada.
6. Se apenas uma única conta corresponder à identidade e senha de entrada, a autenticação será bem-sucedida.
7. Se várias contas corresponderem à identidade de entrada, o ISE usará a senha para resolver a ambiguidade, e a conta com uma senha associada será autenticada enquanto as outras contas aumentam o contador de senha incorreto em 1.
8. Se nenhuma conta corresponder à identidade e à senha de entrada, o AD responderá com a senha incorreta.

---

Filtros de pesquisa do ISE

Os filtros são usados para identificar uma entidade para se comunicar com o AD. O ISE sempre procura uma entidade no grupo de usuários e máquinas. Exemplos de filtros de pesquisa:

1. Pesquisa SAM: Se o ISE receber uma identidade apenas como um nome de usuário sem nenhuma marcação de domínio, o ISE tratará o nome de usuário como um SAM e pesquisará no AD todos os usuários de máquina ou computadores que tenham a identidade como um nome SAM.
2. Se o nome SAM não for exclusivo, o ISE usará a senha para diferenciar usuários e o ISE será configurado para usar um protocolo sem senha, como EAP-TLS.
3. Não há outros critérios para localizar o usuário correto, portanto, o ISE falha na autenticação com um erro de "Identidade Ambígua". No entanto, se o certificado do usuário estiver presente no Ative Diretory, o Cisco ISE usará uma comparação binária para resolver a identidade.

---

---

2. Pesquisa UPN ou MAIL: Se o ISE receber uma identidade como username@domain, o ISE pesquisará no catálogo global da floresta uma correspondência com a identidade do UPN ou a identidade de e-mail "identity=Match UPN ou e-mail". Se houver uma correspondência exclusiva, o Cisco ISE prossegue com o fluxo de AAA. Se houver vários pontos de união com o mesmo UPN e uma senha, ou o mesmo UPN e Mail, o Cisco ISE falha na autenticação com um erro de "Identidade ambígua".

---

---

3. Pesquisa NetBIOS: Se o ISE receber uma identidade com um prefixo de domínio NetBIOS (por exemplo, CISCO\sajedah), o ISE procurará nas florestas o domínio NetBIOS. Uma vez encontrado, ele procura o nome SAM fornecido (sajeda, por exemplo).

---

---

4. Pesquisa Base da Máquina: Se o ISE receber uma autenticação de máquina com uma identidade de host/prefixo, ele procurará na floresta um atributo servicePrincipalName correspondente. Se um sufixo de domínio totalmente qualificado foi especificado na identidade, como host/machine.domain.com. O Cisco ISE pesquisa a floresta onde o domínio existe. Se a identidade estiver na forma de host/máquina, o Cisco ISE procurará o nome da entidade de serviço em todas as florestas. Se houver mais de uma correspondência, o Cisco ISE falha na autenticação com um erro de "Identidade ambígua".

---

Note: Os mesmos filtros são vistos nos arquivos ad-agent.log do ISE.

Note: Patch 4 do ISE 2.2, patch 2.3, 1 e usuários identificados anteriormente com os atributos SAM, CN ou ambos. O Cisco ISE, versão 2.2 Patch 5 e posterior, e 2.3 Patch 2 e posterior, usa somente o atributo sAMAccountName como o atributo padrão.

---

Histórico de revisões

Revisão	Data de publicação	Comentários
3.0	04-Aug-2026	Introdução Atualizada, Título, ortografia, gramática, linhas horizontais inseridas para seções separadas/legibilidade, texto alt atualizado.
2.0	03-Aug-2022	Gramática, estrutura, tradução automática, estilo, formato
1.0	06-Feb-2020	Versão inicial