Entender o Identity Service Engine (ISE) e o Ative Diretory (AD)

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 um conhecimento básico de:

• 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).

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 (Troca AS).
2. TGS Exchange (Troca de TGS).
3. Intercâmbio cliente/servidor (CS).

• Controlador de domínio = KDC (AS + TGS).
• Autentique 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)
• O KDC oferece o TGS para SRV01.
• Redirecione 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 me conecta.
  
  

Quando conectados inicialmente a uma rede, os usuários devem negociar o acesso e fornecer um nome e uma senha de login para que sejam 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 uma vida útil padrão de 10 horas e é renovado durante toda a sessão de logon do usuário sem a necessidade do usuário digitar 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.

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 o 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 é então fornecido ao serviço TGT para obter um tíquete de sessão.

A autenticação tem êxito quando um tíquete de sessão é recebido.

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

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


Efetua logon no arquivo ad_agent.log quando a senha está incorreta:

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

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

2020-01-14 13:36:05,444 DEBUG ,140574072981248,krb5: Preauth tente novamente tipos de entrada: 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 de erro: -1765328360 (Mensagem: Falha na pré-autenticação),LwTranslateKrb5Erro(),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, 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.

• Crie 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 trata 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.

Transacione a troca RPC sobre SMB.

O negotiate protocol request/response a linha negocia o dialeto do SMB. O session setup request/response 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.

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

Nos pacotes 83 e 86, a solicitação NetrlogonSamLogonEX é 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.

Caso o DC fique off-line por qualquer motivo, o ISE efetua failover para o próximo DC disponível e o processo de autenticação não é 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 domínio e uma cópia parcial de todos os objetos de todos os outros domínios da floresta.

Assim, 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 de 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. São copiados com o serviço de replicação padrão do AD.

Junte-se ao ISE para o AD

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

1. Verifique se você tem os privilégios de um superadministrador ou de um administrador do 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 ser capaz de 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 a consultas de DNS de encaminhamento e reversão para qualquer domínio DNS possível do Ative Diretory.
5. O AD deve ter pelo menos um servidor de catálogo global operacional e acessível pela Cisco, no domínio ao qual você ingressa na 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 os DCs e GCs disponíveis.

1. O processo de ingresso começa com as credenciais de entrada da superadministração 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 tiver um deles em sua resposta, a integração falhará com o erro relacionado ao DNS.
3. O ISE usa o ping do CLDAP para descobrir todos os DCs e GCs por meio de solicitações do CLDAP enviadas aos DCs que correspondem a 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.

Observação: o CLDAP é o mecanismo que o ISE usa para estabelecer e manter a conectividade com os DCs.  Mede o tempo de resposta até a primeira resposta DC. Ele falhará se você não vir nenhuma resposta do DC. Avisar se o tempo de resposta for maior que 2,5 segundos. CLDAP faça ping em todos os DCs no local (Se não houver local, então todos os DCs no domínio). A resposta do CLDAP contém o site DC e o site Cliente (o site ao qual a máquina do ISE está atribuída).

4. O ISE recebe TGT com credenciais de "usuário associado".
5. Gerar o nome da conta da máquina 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 similares).
9. Obtenha 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 esse 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 do ISE foi 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 deverá ser excluída 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, ele executa uma operação de licença e desconecta o nó do ISE do domínio do Ative Diretory. (se associado). No entanto, 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 controlador de domínio está ativo e responde ao ping do CLDAP, mas o Conector AD não pode se comunicar com ele por algum motivo (exemplos: a porta RPC está bloqueada, o controlador de domínio está em estado de 'replicação interrompida', o controlador de domínio 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 tempo 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.

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 apenas reduz a prioridade do DC que não responde.

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

O ISE procura um computador ou 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 SAM: nome de usuário ou nome de máquina sem nenhuma marcação de domínio; este é o nome de logon do usuário no AD. Exemplo: sajeda ou sajeda$

• CN: é o nome de exibição do usuário no AD e 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: é 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). Exemplo: UPN principal (sajeda@cisco.com), UPN alternativo :sajeda@domain1 , sajeda@domain2

• Nome NetBIOS com prefixo: é 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: usado para autenticação de máquina quando o nome da máquina é usado somente, é somente o nome do host/máquina. Exemplo: host/máquina

• Host/ prefixo com máquina totalmente qualificada: isto é usado para autenticação da máquina quando o FQDN da Máquina é usado, normalmente no caso de autenticação de certificado, é o 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 (exemplos: HTTP, LDAP, SSH) usado somente para máquina.

Autenticação do 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 o nome de usuário. 
2. Pesquisar domínio ou floresta (depende 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. Executar 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, de modo que a conta com uma senha associada seja autenticada e as outras contas aumentem o contador de senha incorreto em 1.
8. Se nenhuma conta corresponder à identidade e à senha de entrada, o AD responderá com a senha incorreta.

ISE Filtros de pesquisa

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

Exemplos de filtros de pesquisa:

1. Pesquisa SAM: se o ISE receber uma identidade como um nome de usuário somente sem nenhuma marcação de domínio, o ISE tratará esse nome de usuário como um SAM e pesquisará no AD todos os usuários de máquina ou computadores que tenham essa identidade como um nome SAM.

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.

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á a comparação binária para resolver a identidade.

2. Pesquisa de UPN ou MAIL: se o ISE receber uma identidade como um username@domain, o ISE pesquisará em cada catálogo global de floresta uma correspondência com essa identidade de UPN ou identidade de email "identity=matched UPN ou email".

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), ele procurará o domínio NetBIOS nas florestas. Uma vez encontrado, ele então procura 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 uma identidade de host/prefixo, o ISE pesquisará na floresta um atributo servicePrincipalName correspondente.

Se um sufixo de domínio totalmente qualificado tiver sido especificado na identidade, por exemplo host/machine.domain.com, o Cisco ISE pesquisará a floresta onde esse 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".

Observação: os mesmos filtros são vistos nos arquivos ad-agent.log do ISE

Nota: patch 4 e anterior e patch 1 do ISE 2.2 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.