Identity Service Engine (ISE) e Ative Diretory (AD) Communications; Protocolos, filtros e fluxo.

Introduction

Este documento descreve como o Identity Service Enginer (ISE) e o Ative Diretory (AD) se comunicam e todos os protocolos que estão sendo usados. Também abrange filtros e fluxos de AD.

Prerequisites

Requirements

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

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

Componentes Utilizados

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

Protocolos AD

Protocolo Kerberos  

O nome do protocolo Kerberos baseia-se na figura dos cães com três cabeças da mitologia grega conhecida como Kerberos. Os três chefes do Kerberos incluem o Key Distribution Center (KDC), o usuário cliente e o servidor com o serviço desejado para acessar. 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). Como exemplificado na Figura 1, três trocas são envolvidas quando o cliente acessa inicialmente um recurso de servidor:

1. AS Exchange.
2. Troca de TGS.
3. Cliente/Servidor (CS) Exchange.

• Controlador de domínio = KDC (AS + TGS).
• Autentique para o AS (o portal SSO) com sua senha.
• Obtenha um tíquete de concessão de tíquete (TGT) (um cookie de sessão à la).
• Solicite o login em um serviço (SRV01).
• O SRV01 "redireciona" você para o KDC.
• Mostrar TGT para o KDC - Já estou autenticado.
• O KDC oferece TGS para SRV01.
• "Redirecionar" para SRV01.
• Mostrar 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 faz o login.
  
  

Ao fazer logon inicialmente em uma rede, os usuários devem negociar o acesso fornecendo um nome de logon e uma senha para que sejam verificados pela parte AS de um KDC em seu domínio. O KDC tem acesso às informações da conta de usuário do Ative Diretory. Depois de autenticado com êxito, o usuário recebe um Ticket para obter tíquetes (TGT) válido para o domínio local. A TGT tem uma vida útil padrão de 10 horas e pode ser renovada por toda a sessão de logon do usuário sem exigir que o usuário digite novamente sua senha. 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. A seguir, uma discussão sobre o processo de recuperação TGT.

O usuário apresenta o TGT à parte TGS do KDC ao desejar acesso a um serviço de servidor. O TGS no KDC autentica o TGT do usuário e cria um tíquete e uma chave de sessão para o cliente e o servidor remoto. Essas informações, conhecidas como tíquete de serviço, são armazenadas em cache localmente na máquina cliente.

O TGS recebe o TGT do cliente e o lê usando 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 usando a chave de sessão TGS recuperada anteriormente da resposta AS. O cliente apresenta a parte do servidor da resposta TGS para o servidor de destino no intercâmbio cliente/servidor a seguir.
abaixo está um exemplo ao aplicar o usuário de teste no ISE usando Kerberos:

Capturas de pacote do ISE para um usuário que autentiu com êxito:

O AS-REQ contém o nome de usuário, se a senha estiver correta, o serviço AS nos fornecerá um TGT criptografado com a senha do usuário e, depois disso, o TGT será fornecido ao serviço TGT para obter um tíquete de sessão, assim que você obtiver um tíquete de sessão, a autenticação será realizada com êxito.

As capturas abaixo estão relacionadas ao cenário em que a senha fornecida pelo cliente está incorreta:

Como visto se a senha está errada, a solicitação AS falhará, portanto, você não obterá um TGT:


inicia sessão no arquivo ad_agent.log quando a senha está errada:

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

2020-01-14 13:36:05,444 DEBUG ,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 DEBUG ,140574072981248,krb5: Tipos de entrada do Preauth que tentam novamente: 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] Código de erro KRB5: -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 MSRPC sobre SMB, 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.

o fluxo é o seguinte:

• Crie uma conexão de sessão SMB.
• Transportar mensagens RPC pela porta SMB/CIFS.TCP 445 como um transporte 
• A sessão SMB cuida de descobrir em que porta um serviço RPC específico é executado e também lida com a autenticação do usuário.
• Conecte-se ao compartilhamento oculto IPC$ para comunicação entre processos.
• Abra um pipe nomeado apropriado para a função/recurso RPC desejado.

Transacionar a troca RPC em SMB.

A solicitação/resposta do protocolo de negociação negocia o dialeto do SMB, a solicitação/resposta da configuração da sessão executa a autenticação. A Solicitação de Conexão de Árvore e a Resposta se conectam ao recurso solicitado. Você está se conectando 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.

Em seguida, você está no pacote nº 77, onde é Criar arquivo de solicitação e o nome do arquivo é o nome do serviço ao qual você está se conectando. Nesse caso, é o serviço de logon de rede.

Agora que você está nos pacotes números 83 e 86, a solicitação NetrlogonSamLogonEX é onde você envia o nome de usuário do cliente que está autenticando no ISE para o AD no campo Network_INFO, a resposta do pacote de resposta NetrlogonSamLogonEX com o resultado, alguns sinalizadores de valores para o

Resposta NetrlogonSamLogonEX significando:
0xc000006a é STATUS_WRONG_PASSWORD
0x00000000 é STATUS_SUCCESS
0x00000103 é STATUS_PENDING

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

O ISE usará LDAP, KRB e MSRBC para se comunicar com o AD durante o processo de união/saída e autenticação. Você encontrará nas próximas seções os protocolos, o formato de pesquisa e o mecanismo usado para se conectar a um DC específico no AD e autenticar os usuários em relação a esse DC. Caso o DC fique off-line por qualquer motivo, o ISE fará failover para o próximo DC disponível e o processo de autenticação não será afetado.

Participe do ISE para o AD

Pré-requisitos para a integração do Ative Diretory e do ISE

1. Assegure-se de ter os 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 tempo entre o servidor Cisco e o Ative Diretory. A diferença máxima de tempo permitida entre ISE e AD é de 5 minutos
3. O DNS configurado no ISE deve ser capaz de responder consultas SRV para DCs, GCs e KDCs com ou sem informações adicionais do local.

Note: 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 de floresta. Assim, o Catálogo Global permite que usuários e aplicativos localizem objetos em qualquer domínio da floresta atual, procurando por atributos incluídos no GC. O catálogo global contém um conjunto básico (mas incompleto) de atributos para cada objeto de floresta em cada domínio (Conjunto de atributos parcial, PAT). O GC recebe dados de todas as partições de diretório de domínio na floresta, eles são copiados usando o serviço de replicação padrão do AD. para obter mais informações, consulte https://theitbros.com/global-catalog-active-directory/

4. Certifique-se de que todos os servidores DNS possam responder consultas de DNS de encaminhamento e reverso para qualquer possível domínio DNS do Ative Diretory que você queira usar.
5. O AD deve ter pelo menos um servidor de catálogo global operacional e acessível pela Cisco, no domínio para o qual você está ingressando na Cisco.

Ingressar no domínio do AD

O primeiro ISE aplicará o Domain Discovery para obter informações sobre o domínio de união em três fases:

1. Consultas associadas a domínios—Descobre domínios de sua floresta e domínios externamente confiáveis no domínio associado.
2. Consulta domínios raiz em sua floresta—Estabelece a confiança com a floresta.
3. Consulta domínios raiz em florestas confiáveis — Descobre domínios das florestas confiáveis.
4. Além disso, o Cisco ISE descobre nomes de domínio DNS (sufixos UPN), sufixos UPN alternativos e nomes de domínio NTLM.

Em seguida, o ISE aplicará uma descoberta de DC para obter todas as informações sobre os DCs e GCs disponíveis e continuará como abaixo:

1. O processo de junção será iniciado inserindo as credenciais de superadministrador no AD existentes 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 enviará uma consulta DNS solicitando todos os registros DCs, GCs e KDCs se a resposta DNS não tiver um deles na resposta, a integração falhará com erro relacionado ao DNS.
3. O ISE usará o ping CLDAP para descobrir todos os DCs e GCs, enviando uma solicitação CLDAP aos DCs de acordo com suas prioridades no registro SRV; a primeira resposta DC será usada e o ISE será conectado a esse DC. Um dos fatores usados para calcular a prioridade de DC é o tempo gasto pelo DC para responder a pings CLDAP; uma resposta mais rápida obterá uma prioridade mais alta.

Note: CLDAP é o mecanismo que o ISE usa para estabelecer e manter a conectividade com os DCs.  Ele mede o tempo de resposta até a primeira resposta do DC. Ele falha se você não vir nenhuma resposta do DC. Avisar se o tempo de resposta for maior que 2,5 segundos. O CLDAP faz ping em todos os DCs no local (se não houver local, então todos os DCs estarão no domínio). A resposta CLDAP contém site DC e site do cliente (por exemplo, site ao qual a máquina ISE está atribuída).

4. Em seguida, o ISE obterá TGT com credenciais de 'ingressar usuário'.
5. Gerar nome de conta de máquina ISE usando MSRPC. (SAM e SPN)
6. Pesquisar AD por SPN se a conta da máquina ISE já estiver existente (por exemplo, pré-criada), se a máquina ISE ainda não existir, o ISE criará uma nova (você pode encontrar uma breve descrição sobre o SPN e o SAM na próxima seção).
7. Abra a conta da máquina, defina a senha da conta da máquina ISE e verifique se a conta da máquina ISE está acessível.
8. Definir atributos de conta da máquina ISE (por exemplo, SPN, dnsHostname, etc.).
9. Obtenha TGT com credenciais de máquina ISE usando o KRB5 e descubra todos os domínios confiáveis.
10. Quando a junção estiver concluída, o nó ISE atualizará seus grupos AD e SIDS correspondentes e iniciará automaticamente o processo de atualização SID. Você deve garantir que esse processo possa ser concluído no lado do AD.

Deixar domínio do AD

Quando o ISE deixar o AD abaixo deve levar em conta as considerações:

1. Você precisa usar um usuário administrador do AD completo para executar os processos de saída, isso garantirá que a conta da máquina do ISE seja removida do banco de dados do Ative Diretory.
2. Se o AD foi deixado sem credenciais, a conta do ISE não será removida do AD e você terá que excluí-lo manualmente.
3. Quando você redefine a configuração do ISE a partir da CLI ou restaura a configuração após um backup ou atualização, ela executa uma operação de saída, desconectando o nó do ISE do domínio do Ative Diretory, se ele já estiver associado. No entanto, a conta de nó do ISE não será removida do domínio do Ative Diretory. é recomendável executar uma operação de saída do portal Admin com as credenciais do Ative Diretory porque 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 de DC será disparado automaticamente no ISE. O failover de DC pode ser acionado pelas seguintes condições:

1. O conector AD detecta que o DC atualmente selecionado ficou indisponível durante alguma tentativa de comunicação CLDAP, LDAP, RPC ou Kerberos. Nesses casos, o conector do AD inicia a seleção de DC e faz o failover para o DC selecionado recentemente.
2. O DC está ativo e responde ao ping CLDAP, mas o AD Connector não pode se comunicar com ele por algum motivo (por exemplo, a porta RPC está bloqueada, o DC está no estado de "replicação interrompida", o DC não foi descomissionado corretamente etc.). Nesses casos, o conector do AD inicia a seleção de DC com uma lista preta ( a lista preta indica um DC "defeituoso") e tenta comunicar com o DC selecionado. Nem o DC selecionado com a lista negra, nem a lista negra são armazenados em cache.

O conector do AD deve concluir o failover dentro de um prazo razoável (ou falhar se não for possível). Por esse motivo, o conector AD tenta um número limitado de DCs durante o failover ("tentativas" significa obter DC da seleção de DC e tentar se comunicar com ele). O ISE colocará em lista negra os controladores de domínio do AD se houver um erro irrecuperável de rede ou servidor para impedir que o ISE use um DC ruim, reduzindo o tempo de processamento e o problema de cabeça. Lembre-se de que o DC não será adicionado à lista negra se não responder aos pings do CLDAP, o ISE reduzirá apenas a prioridade do DC que não responde.

Comunicação ISE-AD por LDAP

O ISE pesquisará a máquina ou o usuário no AD usando um dos formatos de pesquisa abaixo. Se a pesquisa for a máquina, o ISE adicionará "$" no final do nome da máquina, abaixo uma lista de tipos de identidade que serão usados para identificar um usuário no AD:

• Nome do SAM: nome de usuário ou nome da máquina sem marcação de domínio, esse será o Nome de logon do usuário no AD.

Exemplo: sajeda ou sajeda$

• NC: é o nome de exibição do usuário no AD, não deve ser igual ao SAM.

Exemplo: Sajeda Ahmed.

• Nome principal do usuário (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: é um sufixo UPN adicional e/ou 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 um sufixo UPN multiplex(@alt1.com,@alt2.com,..., etc).

Exemplo: UPN principal (sajeda@ciso.com), UPN alternativo:sajeda@aaa.com , sajeda@ise.com

• Nome prefixo do NetBIOS: é o nome de domínio\nome de usuário do nome da máquina.

Exemplo: CISCO\sajeda ou CISCO\machine$

• Host/prefixo com máquina não qualificada: será usado para autenticação de máquina quando o nome da máquina for usado apenas, ele será apenas o nome do host/máquina

        Exemplo: host/máquina

• Host/prefixo com máquina totalmente qualificada: isso será usado para autenticação de máquina quando o FQDN da máquina for usado, geralmente no caso de autenticação de certificado, ele será host/FQDN da máquina

Exemplo: host/machine.cisco.com

• Nome SPN: O nome pelo qual um cliente identifica exclusivamente uma instância de um serviço, por exemplo, HTTP, LDAP, SSH, etc., usado somente para a máquina.

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

1. Resolver identidade e determinar tipo de identidade - SAM, UPN, SPN etc. Se o ISE receber a identidade como nome de usuário apenas, ele procurará uma conta SAM correspondente no AD. se o ISE receber a identidade como um username@domain, ele procurará um UPN ou correio correspondente no AD. em ambos os cenários, o ISE usará filtro adicional para máquina (computador) ou nome de usuário (pessoa)  
2. Domínio de pesquisa ou floresta (depende do tipo de identidade)
3. Manter informações sobre todas as contas correspondentes (JP, DN, UPN, Domínio etc.)
4. Se nenhuma conta correspondente for encontrada, o AD responderá com o usuário desconhecido.
5. Executar autenticação MS-RPC (ou Kerberos) para cada conta correspondente
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, de modo que a conta com uma senha correspondente seja autenticada e as outras contas aumentarão o contador de senha incorreto em 1.
8. Se nenhuma conta corresponder à identidade e senha de entrada, o AD responderá com uma senha incorreta.

ISE Pesquisando filtros

Os filtros serão usados para identificar uma entidade que deseja se comunicar com o AD. O ISE sempre procurará essa entidade nos grupos de usuários e máquinas,

alguns exemplos de filtros de pesquisa:

1. Pesquisa SAM: Se o ISE receber uma identidade como um nome de usuário somente sem marcação de domínio, o ISE tratará esse nome de usuário como um SAM e pesquisará no AD todos os usuários ou máquinas com essa identidade como um nome SAM. Se o nome do SAM não for exclusivo, o ISE usará a senha para diferenciar entre os usuários e o ISE está configurado para usar um protocolo sem senha, como EAP-TLS, 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 de usuário estiver presente no Ative Diretory, o Cisco ISE usará a comparação binária para resolver a identidade.

2. Pesquisa de UPN ou MAIL: Se o ISE receber uma identidade como username@domain, o ISE pesquisará os catálogos globais de cada floresta procurando uma correspondência com a identidade do UPN ou a identidade do correio "identity=correspondendo ao UPN ou email". Se houver uma correspondência exclusiva, o Cisco ISE prossegue com o fluxo AAA. Se houver vários pontos de união com o mesmo UPN e uma senha ou o mesmo UPN e Correio, 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 (ex:CISCO\sajedah), o ISE pesquisará nas florestas o domínio NetBIOS, uma vez encontrado, ele procurará o nome SAM fornecido (sajeda em nosso exemplo)

4. Pesquisa na base da máquina: Se o ISE receber uma autenticação de máquina, com a identidade com um host/prefixo, o ISE pesquisará a floresta em busca de um atributo servicePrincipalName correspondente. Se um sufixo de domínio totalmente qualificado foi especificado na identidade, por exemplo host/machine.domain.com, o Cisco ISE pesquisa a floresta onde esse domínio existe. Se a identidade estiver na forma de host/máquina, o Cisco ISE pesquisa em todas as florestas o nome do principal do serviço. 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 serão vistos nos arquivos do ISE ad-agent.log

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