Comunicações do motor (ISE) e do diretório ativo do serviço da identidade (AD); Protocolos, filtros e fluxo.

Introdução

Este original descreve como o serviço Enginer(ISE) e Directory(AD) ativo de Identitity se comunica, e todos os protocolos que estão sendo usados. Igualmente cobre filtros AD e flui.

Pré-requisitos

Requisitos

Reccomends de Cisco que você tem o conhecimento básico de:

• ISE 2.x e integração do ative directory.
• Autenticação externo da identidade no ISE.

Componentes Utilizados

• ISE 2.x.
• Windows Server (diretório ativo).

Protocolos AD

Protocolo do Kerberos  

O nome de protocolo do Kerberos é baseado na figura três-dirigida do cão da mitologia grega conhecida como o Kerberos. As três cabeças do Kerberos compreendem o Key Distribution Center (KDC), o usuário cliente e o server com o serviço desejado para alcançar. O KDC é instalado como parte do domínio Controller(DC) e executa duas funções de serviço: O serviço de autenticação (COMO) e o serviço de consessão de licensa (TG). Como exemplificado em figura 1, três trocas são involvidas quando o cliente alcança inicialmente uns recursos de servidor:

1. COMO a troca.
2. Troca TG.
3. Troca do cliente/server (CS).

• Controlador de domínio = KDC (COMO + TG).
• Autentique a COMO (o portal SSO) com sua senha.
• Obtenha um bilhete de concessão do bilhete (TGT) (um Cookie da sessão do la).
• Peça o início de uma sessão a um serviço (SRV01).
• SRV01 “reorienta-o” ao KDC.
• Mostre o TGT ao KDC – Eu sou autenticado já.
• O KDC dá-lhe TG para SRV01.
• “Reoriente” a SRV01.
• Mostre o bilhete do serviço a SRV01.
• SRV01 verifica/confia o bilhete do serviço.
• O bilhete do serviço tem toda minha informação.
• SRV01 registra-me dentro.
  
  

Ao inicialmente entrar a uma rede, os usuários devem negociar o acesso fornecendo um nome do início de uma sessão e uma senha a fim ser verificado pelo COMO a parcela de um KDC dentro de seu domínio. O KDC tem o acesso à informação de conta de usuário do diretório ativo. Uma vez que autenticado com sucesso, o usuário é concedido um bilhete para obter os bilhetes (TGT) que seja válido para o domínio local. O TGT tem uma duração padrão das horas 10 e pode ser renovado durante todo a sessão do fazer logon do usuário sem exigir o usuário reenter sua senha. O TGT é posto em esconderijo na máquina local no espaço de memória volátil e usado para pedir sessões com serviços durante todo a rede. O seguinte é um exame do processo da recuperação TGT.

O usuário apresenta o TGT à parcela TG do KDC ao desejar o acesso a um serviço do servidor. Os TG no KDC autenticam o TGT do usuário e criam um bilhete e uma chave de sessão para o cliente e o servidor remoto. Esta informação, conhecida como o bilhete do serviço, é posta em esconderijo então localmente na máquina cliente.

Os TG recebem o TGT do cliente e leem-no que usa sua própria chave. Se os TG aprovam o pedido do cliente, um bilhete do serviço está gerado para o cliente e o servidor de destino. O cliente lê sua parcela usando a chave de sessão TG recuperada mais cedo do COMO a resposta. O cliente apresenta a parcela do server da resposta TG ao servidor de destino na troca do cliente/server que vem em seguida.
está abaixo um exemplo ao aplicar o usuário de teste no ISE usando o Kerberos:

Capturas de pacote de informação do ISE para um usuário que autenticasse com sucesso:

O AS-REQ contém o username, se a senha é correto PORQUE o serviço nos fornece um TGT cifrados com senha do usuário, e em seguida que o TGT está fornecido ao serviço TGT para obter um bilhete da sessão, uma vez que você obtém um bilhete da sessão então a autenticação é feita com sucesso.

Abaixo das captações é para a encenação era a senha dada pelo cliente é errada:

Como visto se a senha é lese COMO o pedido falhará daqui, você não obterá um TGT:


entra o arquivo de ad_agent.log quando a senha é errada:

2020-01-14 13:36:05,442 DEBUGAM, 140574072981248,krb5: Enviando o pedido (276 bytes) a RALMAAIT.COM para user1@RALMAAIT.COM,LwKrb5TraceCallback(),lwadvapi/threaded/lwkrb5.c:1325

2020-01-14 13:36:05,444 DEBUGAM, 140574072981248,krb5: Erro recebido do KDC: -1765328360/Preauthentication failed,LwKrb5TraceCallback(),lwadvapi/threaded/lwkrb5.c:1325

2020-01-14 13:36:05,444 DEBUGAM, 140574072981248,krb5: Tipos da entrada do tryagain de Preauth: 16, 14, 19, 2,LwKrb5TraceCallback(),lwadvapi/threaded/lwkrb5.c:1325

2020-01-14 13:36:05,444 WARNING,140574072981248,[LwKrb5GetTgtImpl ../../lwadvapi/threaded/krbtgt.c: Código de erro 329] KRB5: -1765328360 (mensagem: Failed),LwTranslateKrb5Error(),lwadvapi/threaded/lwkrb5.c:892 Pré-autenticação

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

Protocolo MS-RPC

O ISE usa MSRPC sobre o SMB, SMB fornece a autenticação e não exige uma sessão separada encontrar onde um serviço dado RPC é encontrado, ele usa um mecanismo chamado “tubulação nomeada” para comunicar-se entre o cliente e servidor.

o fluxo é como abaixo:

• Crie uma conexão de sessão SMB.
• Transporte mensagens RPC sobre a porta 445 SMB/CIFS.TCP como um transporte 
• A sessão SMB toma de encontrar em que porta um serviço particular RPC executa e segura a autenticação de usuário também.
• Conecte para compartilhar hidden de IPC$ para o Inter-Process Communication.
• Abra uma tubulação nomeada apropriada para o recurso desejado/função RPC.

Transacione a troca RPC sobre o SMB.

O pedido/resposta do protocolo do negócio negocia o dialeto do SMB, a requisição de instalação da sessão/resposta executa a autenticação. A requisição de conexão e a resposta da árvore conectam ao recurso pedido. Você está conectando a uma parte especial IPC$, esta parte do Inter-Process Communication fornece os meios da comunicação entre anfitriões e igualmente como um transporte para funções MSRPC.

Então você está no pacote #77 onde está cria o arquivo do pedido e o nome de arquivo é o nome do serviço que você está conectando a, neste caso ele é o serviço do netlogon.

Agora você está em pacotes número 83 e 86, o NetrlogonSamLogonEX que o pedido é onde você envia o username para o cliente que autentica no ISE ao AD no campo Network_INFO, a resposta do pacote de resposta de NetrlogonSamLogonEX com o resultado, valores de algumas bandeiras para

Significado da resposta de NetrlogonSamLogonEX:
0xc000006a é STATUS_WRONG_PASSWORD
0x00000000 é STATUS_SUCCESS
0x00000103 é STATUS_PENDING

Integração ISE com Directory(AD) ativo

O ISE usará o LDAP, o KRB, e o MSRBC para comunicar-se com o AD durante a junta/licença e o processo de autenticação. Você encontrará nas próximas seções os protocolos, procurando o formato e o mecanismo usado para conectar a um DC específico no AD e autenticando os usuários contra esse DC. Caso que o DC se torna off line por qualquer razão o ISE Failover ao DC disponível seguinte e o processo de autenticação não será afetado.

Junte-se ao ISE ao AD

Condições prévias para o diretório ativo de integração e o ISE

1. Assegure-se de que você tenha os privilégios de um Admin super ou do System Admin no ISE.
2. Use as configurações de servidor do Network Time Protocol (NTP) para sincronizar o tempo entre o servidor Cisco e o diretório ativo. O máximo permitiu a diferença de horário entre o ISE e o AD é os minutos 5
3. O DNS configurado no ISE deve poder responder a perguntas SRV para DC, GCs, e KDC com ou sem a informação adicional do local.

Nota: Um servidor global catalog (GC) é um controlador de domínio que armazene cópias de todos os objetos do diretório ativo na floresta. Armazena uma cópia completa de todos os objetos no diretório de seu domínio e uma cópia parcial de todos os objetos de todos domínios restantes da floresta. Assim, o catálogo global permite usuários e aplicativos encontrar objetos em todo o domínio da floresta atual procurando pelos atributos incluídos ao GC. O catálogo global contém um básico (mas incompleto) ajustou-se dos atributos para cada objeto da floresta em cada domínio (grupo, PANCADINHA parciais do atributo). O GC recebe dados de todas as separações do diretório do domínio na floresta, eles é copiado usando o serviço da replicação do padrão AD. para mais informação você pode verificar https://theitbros.com/global-catalog-active-directory/

4. Assegure-se de que todos os servidores DNS possam responder a perguntas dianteiras e reversas DNS para todo o domínio de DNS que possível do diretório ativo você quiser se usar.
5. O AD deve ter pelo menos um servidor global catalog operacional e acessível por Cisco, no domínio a que você se está juntando a Cisco.

Junte-se ao domínio AD

O primeiro ISE aplicará a descoberta de domínio para obter a informação sobre o domínio da junta em três fases:

1. As perguntas juntaram-se a domínios — Descobre domínios de sua floresta e domínios confiados externamente ao domínio juntado.
2. Pergunta domínios da raiz em sua floresta — Estabelece a confiança com a floresta.
3. Pergunta domínios da raiz em florestas confiadas — Descobre domínios das florestas confiadas.
4. Adicionalmente, Cisco ISE descobre Domain Name DNS (sufixos UPN), sufixos alternativos UPN e Domain Name NTLM.

Então o ISE aplicará uma descoberta DC para obter toda a informação sobre os DC e o GCs disponíveis, e continua como abaixo:

1. O processo da junta será começado incorporando as credenciais dos admin super no AD que existem no domínio próprio. Se existe em um domínio ou em um subdomínio diferente, o username deve ser notado em uma notação UPN (username@domain).
2. O ISE enviará uma pergunta DNS que pede todos os registros DC, GCs e KDC se a resposta DNS não teve um deles em sua resposta a integração será falhada então que com erro relacionado DNS.
3. O ISE usará o sibilo CLDAP para descobrir todos os DC e GCs enviando pedidos CLDAP aos DC de acordo com suas prioridades no registro SRV; a primeira resposta DC será usada, e o ISE será conectado a esse DC. Um do fator que se usou para calcular a prioridade DC é o tempo tomado pelo DC à resposta aos sibilos CLDAP; uma resposta mais rápida obterá uma prioridade mais alta.

Nota: CLDAP é o mecanismo que o ISE se usa para estabelecer e manter a Conectividade com os DC.  Mede o tempo de resposta até a primeira resposta DC. Falha se você não vê nenhuma resposta do DC. Advirta se o tempo de resposta é mais grande de 2.5 segundos. Sibilo CLDAP todos os DC no local (se nenhum local então todos os DC no domínio). A resposta CLDAP contém o local DC e a site de cliente (por exemplo o local a que a máquina ISE é atribuída).

4. Então o ISE obterá o TGT com “junta-se credenciais ao usuário”.
5. Gerencia o nome da conta da máquina ISE usando MSRPC. (SAM e SPN)
6. Procure o AD por SPN se a conta de máquina ISE é já existente (por exemplo PRE-criado), se a máquina ISE não existe contudo o ISE criará um novo (você pode encontrar a breve descrição sobre o SPN e o SAM na próximo seção).
7. A conta de máquina aberta, ajustou a senha de conta da máquina ISE, e verificou-a que conta de máquina ISE é acessível.
8. Ajuste os atributos da conta de máquina ISE (por exemplo SPN, o dnsHostname, etc.).
9. Obtenha o TGT com credenciais da máquina ISE usando KRB5 e descubra todos os domínios confiável.
10. Quando a junta está completa, o nó ISE atualizará seus grupos AD e SIDS correspondente e automaticamente começará o processo de atualização de SID. Você deve assegurar-se de que este processo possa terminar no lado AD.

Deixe o domínio AD

Quando licença que ISE o AD abaixo deve tomar em considerações:

1. Você precisa de usar um usuário admin completo AD para executar os processos da licença, isto segurará que a conta de máquina ISE estará removida do base de dados do diretório ativo.
2. Se o AD foi deixado sem as credenciais, a seguir a conta ISE não será removida do AD e você tem que suprimir d manualmente.
3. Quando você restaurar a configuração ISE do CLI ou restaurar a configuração depois que um backup ou uma elevação, ele executam uma operação restante, desligando o nó ISE do domínio do diretório ativo, se é juntado já. Contudo, a conta do nó ISE não será removida do domínio do diretório ativo. você recomenda que você executa uma operação restante do portal Admin com as credenciais do diretório ativo porque igualmente remove a conta do nó do domínio do diretório ativo. Isto é recomendado igualmente quando você muda o hostname ISE.

Failover DC

Quando o DC conectado ao ISE se torna autônomo ou inacessível por qualquer razão o Failover DC provocado automaticamente no ISE. O Failover DC pode ser provocado pelas circunstâncias abaixo:

1. O conector AD detecta o DC atualmente selecionado tornou-se não disponível durante tentativa de uma alguma comunicação CLDAP, LDAP, RPC ou de Kerberos. Nesses casos, o conector AD inicia a seleção DC e falha sobre ao DC recentemente selecionado.
2. O DC é ascendente e responde ao sibilo CLDAP, mas o conector AD não pode comunicar-se com ele por qualquer motivo (por exemplo a porta RPC é obstruída, DC está “no estado da replicação quebrada”, DC não foi etc. corretamente desarmado). Nesses casos, o conector AD inicia a seleção DC com uma lista preta (o DC “ruim” é colocado na lista preta) e tenta-a comunicar-se com o DC selecionado. Nem o DC selecionado com a lista negra nem a lista negra são postos em esconderijo.

O conector AD deve terminar o Failover dentro do tempo razoável (ou para falhar se não é possível). Por este motivo, o conector AD tenta o número limitado de DC durante o Failover (as “tentativas” significam obtêm o DC da seleção DC e o tentam se comunicar com ela). O ISE põr controladores de domínio AD se há uma rede ou um erro do servidor unrecoverable para impedir que o ISE use um DC ruim daqui, reduzindo o tempo e a dor de cabeça proccing. Mantenha por favor na mente que o DC não estará adicionado para enegrecer a lista se não faz respostas aos sibilos CLDAP, ISE abaixará somente a prioridade do DC que não faz resposta.

Uma comunicação ISE-AD com o LDAP

O ISE procurará pela máquina ou o usuário no AD usando um dos formatos de pesquisa abaixo, se a busca era para a máquina então ISE adicionará “$” no fim do nome de máquina, é abaixo uma lista de tipos da identidade que serão usados a identfy um usuário no AD:

• Nome SAM: o username ou o nome de máquina sem nenhuma margem de benefício do domínio, isto serão o nome de logon do usuário no AD.

Exemplo: sajeda ou sajeda$

• NC: é o nome do indicador do usuário no AD, ele não deve ser mesmo que o SAM.

Exemplo: sajeda Ahmed.

• Nome principal do usuário (UPN): é uma combinação do nome SAM e do Domain Name (SAM_NAME@domian).

Exemplo: sajeda@cisco.com ou sajeda$@cisco.com

• Alternativa UPN: são uns sufixos adicionais e/ou alternativos UPN que configurem no AD a não ser o Domain Name. Esta configuração é adicionada globalmente no AD (não configurado pelo usuário) e não é necessário ser um sufixo real do Domain Name. Cada AD pode ter multiplicar UPN suffix(@alt1.com,@alt2.com,…, etc.).

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

• NetBIOS prefixou o nome: é o Domain Name \ username do nome de máquina.

Exemplo: CISCO \ sajeda ou CISCO \ machine$

• Host/prefixo com máquina incompetente: isto será usado para a autenticação da máquina quando o nome de máquina somente é usado, ele será host/nome de máquina somente

        Exemplo: host/máquina

• Prefixo do anfitrião com máquina totalmente qualificado: isto estará usado para a autenticação da máquina quando o FQDN da máquina é usado, geralmente em caso do certificado de autenticação, ele será host/FQDN da máquina

Exemplo: host/machine.cisco.com

• Nome SPN: O nome por que um cliente identifica excepcionalmente um exemplo de um serviço, por exemplo, HTTP, o LDAP, o SSH, etc. usaram-se para a máquina somente.

Autenticação de usuário contra o fluxo AD:

1. Resolva a identidade e determine o tipo da identidade - SAM, UPN, SPN etc. Se o ISE recebe a identidade como um username somente, a seguir procurará por uma conta de harmonização SAM no AD. se o ISE recebe a identidade como username@domain então que procurará pelo combinado um UPN ou um correio no AD. na encenação o ISE usará o filtro adicional para a máquina (computador) ou o username (a pessoa)  
2. Domínio ou floresta da busca (depende do tipo da identidade)
3. Mantenha a informação sobre toda a harmonização explica (JP, DN, UPN, domínio etc.)
4. Se nenhum conta de harmonização é encontrado, a seguir o AD responderá com usuário é desconhecido.
5. Execute a autenticação MS-RPC (ou Kerberos) para cada conta de harmonização
6. Se somente únicos fósforos da conta à identidade e à senha entrantes, então autenticação bem sucedida
7. Se as contas múltiplas combinam à identidade entrante então ISE usarão a senha para resolver a ambiguidade, de modo que a conta com uma senha de harmonização esteja autenticada e as outras contas aumentarão o contador da senha incorreta por 1.
8. Se nenhum conta combina à identidade e à senha entrantes, a seguir o AD responderá com senha errada.

ISE que procura filtros

Os filtros serão usados para identificar uma entidade que querem se comunicar com o AD, ISE sempre procurarão por essa entidade nos usuários e fazem à máquina grupos,

alguns exemplos de filtros da busca:

1. Busca SAM: Se o ISE recebe uma identidade como um username somente sem nenhuma margem de benefício do domínio então o ISE tratará este username como um SAM e procurá-lo-á no AD por todos os usuários ou máquina de fatura que têm essa identidade como um nome SAM. Se o nome SAM não é original então o ISE usará a senha para diferenciar-se entre usuários e o ISE é configurado para usar um protocolo passwordless tal como o EAP-TLS, não há nenhum outro critérios para encontrar o usuário correto, assim que o ISE falha a autenticação com “um erro da identidade ambígua”. Contudo, se o certificado de usuário esta presente no diretório ativo, Cisco ISE usa a comparação binária para resolver a identidade.

2. Busca UPN ou de CORREIO: Se o ISE recebe uma identidade como username@domain, o ISE procura os catálogos globais de cada floresta que procuram um fósforo a essa identidade UPN ou identidade “UPN identity=matching do correio ou email”. Se há um fósforo original, os rendimentos de Cisco ISE com o AAA fluem. Se há múltiplo junte-se a pontos com o mesmo UPN e uma senha ou o mesmos UPN e correio, Cisco ISE falham a autenticação com “um erro da identidade ambígua”.

3. Busca de NetBIOS: Se o ISE recebe uma identidade com um prefixo do domínio de NetBIOS (ex: CISCO \ sajedah), então ISE procurará em procura as florestas pelo domínio de NetBIOS, encontradas uma vez, ele procura então o nome fornecido SAM (o sajeda em nosso exemplo)

4. Busca da base da máquina: Se o ISE recebe uma autenticação da máquina, com a identidade que tem um host/prefixo, a seguir o ISE procura a floresta por um atributo de harmonização do servicePrincipalName. Se um sufixo de domínio totalmente qualificado foi especificado na identidade, por exemplo o host/machine.domain.com, Cisco ISE procura a floresta onde esse domínio existe. Se a identidade é sob a forma do host/máquina, Cisco ISE procura todas as florestas pelo nome principal do serviço. Se há mais de um fósforo, Cisco ISE falha a autenticação com “um erro da identidade ambígua”.

Nota: Os mesmos filtros serão vistos em arquivos ISE ad-agent.log

Nota: A correção de programa 4 e prévio e 2.3 ISE 2.2 remenda 1 e prévio identificava os usuários que usam os atributos SAM, NC, ou ambos. Cisco ISE, libera 2.2 a correção de programa 5 e acima, e 2.3 remendam 2 e acima, use somente o atributo do sAMAccountName como o atributo de padrão.