Comparação do estilo da postura ISE para pre e cargo 2.2

Transcrição

1 Comparação do estilo da postura ISE para pre e cargo 2.2 Índice Introdução Pré-requisitos Requisitos Componentes Utilizados Informações de Apoio Fluxo pre ISE 2.2 da postura Fluxo da postura em ISE 2.2 Configurar Diagrama de Rede Configurações Configuração do abastecimento do cliente Políticas e condições da postura Configurar o portal do abastecimento do cliente Configurar perfis e políticas da autorização Verificar Troubleshooting Informação geral Troubleshooting dos problemas comuns Problemas relacionados SSO Pesquise defeitos a seleção da política de abastecimento do cliente Pesquise defeitos o processo da postura Introdução Este documento descreve a funcionalidade nova que é adicionada no motor do serviço da identidade (ISE) 2.2. Reserva apoiar um fluxo da postura sem nenhum tipo do apoio da reorientação no dispositivo do acesso de rede (NAD) ou no ISE. Para compreender melhor a funcionalidade nova, este documento contém comparação detalhada entre o fluxo da postura pre em versões ISE 2.2 e em ISE 2.2. Pré-requisitos Requisitos A Cisco recomenda que você tenha conhecimento destes tópicos: Fluxo da postura no ISE Configuração de componentes da postura no ISE

2 Configuração adaptável da ferramenta de segurança (ASA) para a postura sobre o Virtual Private Networks (VPN) Componentes Utilizados As informações neste documento são baseadas nestas versões de software e hardware: Versão 2.2 de Cisco ISE Cisco ASAv com software 9.6(2) 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 sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando. Informações de Apoio A postura é um componente central de Cisco ISE. A postura como um componente pode ser representada por três elementos principais: 1. ISE como uma distribuição e um ponto de decisão da configuração das normas. Da perspectiva do administrador no ISE você configura as políticas da postura (que circunstâncias exatas devem ser estadas conformes para marcar o dispositivo como um complacente corporativo), as políticas de abastecimento do cliente (que agente de software deve ser instalado em que tipos de dispositivos) e políticas da autorização (que tipo das permissões deve ser atribuído, depende em cima de seu estado da postura). 2. Dispositivo do acesso de rede como um ponto do reforço de política. Na autorização real lateral NAD as limitações são aplicadas na época da autenticação de usuário. O ISE como um ponto da política fornece parâmetros de autorização como o Access Control List transferido ACL (dacl) /VLAN/Redirect-URL/Redirect (ACL). Tradicionalmente, para que a postura aconteça, NADs é exigido para apoiar a reorientação (para instruir o usuário ou o agente de software que o nó ISE deve ser contactado) e a mudança da autorização (CoA) reauthenticate o usuário depois que o estado da postura do valor-limite é determinado. 3. Agente de software como o ponto do levantamento de dados e da interação com utilizador final. Cisco ISE usa três tipos de agente de software: Módulo da postura de AnyConnect, agente NAC, agente da Web. O agente recebe a informação sobre exigências da postura do ISE e fornece o relatório ao ISE em relação ao estado da exigência. Nota: Este documento é baseado no módulo da postura de Anyconnect que é único que apoia a postura inteiramente sem reorientação. Quando você considera pre a postura do fluxo ISE 2.2 confia em NADs não somente para a autenticação de usuário e a restrição de acesso mas também para o abastecimento da informação ao agente de software sobre o nó específico ISE que tem que ser contactado. A informação sobre o nó ISE é retornada ao agente de software como parte do processo de redirecionamento.

3 Historicamente, o apoio da reorientação no NAD ou no lado ISE era uma exigência chave para a aplicação da postura. Na exigência ISE 2.2 apoiar a reorientação é eliminado para o abastecimento do cliente da inicial e o processo da postura. Abastecimento do cliente sem redirectioin- em ISE 2.2 você pode alcançar o portal do abastecimento do cliente (CPP) diretamente através do nome de domínio totalmente qualificado portal (FQDN). Isto é similar à maneira que você alcança o portal do patrocinador ou o portal de MyDevice. O processo da postura sem reorientação durante o instalation do agente da informação portal CPP sobre server ISE salvar no lado do cliente que torna uma comunicação direta possível. Fluxo pre ISE 2.2 da postura Esta é uma explicação passo a passo do fluxo do módulo da postura de Anyconnect ISE antes de ISE 2.2 Etapa 1. A autenticação é uma primeira etapa do fluxo, ele poderia ser dot1x, MAB ou VPN. Stpe 2. ISE precisa de selecionar a política da authentication e autorização para o usuário. Na encenação da postura a política selecionada da autorização tem que conter uma referência ao estado da postura, que inicialmente deve ser desconhecido ou não aplicável. Para cobrir ambo isto os casos, circunstância com o complacente desigual do estado da postura podem ser usados.

4 O perfil selecionado da autorização tem que conter a informação sobre a reorientação: A reorientação da Web para o exemplo da postura, tipo da reorientação da Web deve ser especificada como o abastecimento do cliente (postura). Esta seção ACL precisa de conter o nome ACL que é configurado no lado NAD. Este ACL é usado para instruir o NAD que o tráfego deve contornear a reorientação e que deve realmente ser reorientado. DACL- pode ser usado junto com reorienta a lista de acesso mas você deve manter-se na mente que as Plataformas diferentes processam DACL e reorientam ACL na ordem diferente. Por exemplo: O processo DACL ASA sempre antes reorienta o ACL. Ao mesmo tempo algumas plataformas do switch processam o da mesma forma como o ASA e o outro processo das plataformas do switch reorientam o ACL primeiramente, e uma verificação mais atrasada DACL/Interface ACL se o tráfego for deixado cair ou permitido. Nota: Depois que você permite a opção da reorientação da Web no perfil da autorização, o portal do alvo para a reorientação tem que ser selecionado. Etapa 3. O ISE retorna a aceitação de acesso com atributos da autorização. Reoriente a URL em atributos da autorização é gerado automaticamente pelo ISE. Contém aqueles componentes: FQDN do nó ISE em que a autenticação aconteceu. O FQDN em alguns casos dinâmico pode ser overwritten pela configuração de perfil da autorização (IP/Host estático name/fqdn) na seção da reorientação da Web. Se o valor estático é devido apontar ao mesmo nó ISE onde a autenticação foi processada. Em caso do equilibrador da carga (LB) este FQDN pode apontar a LB VIP mas somente caso que quando o LB é configurado para amarrar junto o raio e as conexões SSL. Mova o valor de porta é obtido da configuração portal do alvo. A identificação da sessão este valor é tomada pelo ISE do ID de sessão da auditoria dos pares do AV Cisco apresentado na solicitação de acesso. O valor próprio é gerado dinamicamente pelo NAD. Identificador portal identificação de um portal do alvo no lado ISE. Etapa 4. O NAD aplica a política da autorização à sessão. Adicionalmente, se DACL é configurado, é índice é pedido antes que as políticas da autorização estejam aplicadas. Considerações importantes: Todo o dispositivo de NADs- deve localmente ter configurado o ACL com o mesmo nome que esse recebido na aceitação de acesso como o reorientar-acl. O endereço IP de Um ou Mais Servidores Cisco ICM NT dos interruptores do cliente deve ser

5 apresentado na saída do comando dos detalhes da relação da sessão da autenticação da mostra aplicar com sucesso a reorientação e os ACL. O endereço IP cliente é aprendido pelos recursos de tracking do dispositivo IP (IPDT). Etapa 5. O cliente envia o pedido DNS para o FQDN que é incorporado ao navegador da Web. Nesta fase o tráfego DNS deve contornear a reorientação e o endereço IP de Um ou Mais Servidores Cisco ICM NT correto deve ser retornado pelo servidor DNS. Etapa 6. O cliente envia TCP SYN ao endereço IP de Um ou Mais Servidores Cisco ICM NT que é recebido na resposta DNS. O endereço IP de origem no pacote é IP de cliente, endereço IP de destino é um IP do recurso pedido. A porta do destino iguala 80, à exceção dos casos quando o proxy HTTP direto é configurado no navegador da Web do cliente. A etapa 7.NAD intercepta o pedido do cliente e prepara o pacote SYN-ACK com o IP da fonte igual ao IP pedido do recurso, IP de destino igual ao IP de cliente, porta de origem igual a 80. Considerações importantes: NADs deve ter o server HTTP que é executado na porta em que o cliente envia pedidos. À revelia é a porta 80. Se os usos do cliente dirigem o servidor de Web do proxy HTTP, no server HTTP NAS deve ser executado na porta de proxy. Esta encenação é fora do espaço deste documento. Nos casos quando o NAD não tem um endereço IP local na sub-rede de cliente SYN-ACK é enviado com tabela de roteamento NAD (sobre a interface de gerenciamento geralmente). Nesta encenação o pacote é distribuído sobre a infraestrutura L3 e deve ser distribuído para trás para o cliente por um dispositivo L3 ascendente. Se o dispositivo L3 é um firewall stateful, a exceção adicional precisa de ser dada para tal roteamento asymetric. Etapa 8. O cliente termina o cumprimento de três vias TCP pelo ACK. Etapa 9. O HTTP GET para o recurso do alvo é enviado por um cliente. Etapa 10. Os retornos NAD reorientam a URL ao cliente com código 302 HTTP (página movida), em algum NADs reorientam podem ser retornados dentro da mensagem da APROVAÇÃO HTTP 200 no encabeçamento do lugar.

6 Etapa 11. O cliente envia o pedido DNS para o FQDN de reorienta a URL. O FQDN deve ser solucionável no lado do servidor DNS. Etapa 12. A conexão SSL sobre a porta recebida dentro reorienta a URL é estabelecida (padrão 8443). Esta conexão é protegida pelo certificado portal do lado ISE. O portal do abastecimento do cliente (CPP) é apresentado ao usuário. A etapa 13.Before que fornece a opção da transferência ao cliente, ISE tem que escolher a política do abastecimento do cliente do alvo (CP). O sistema da operação (OS) do cliente detectado do agente de usuário do navegador, a outra informação exigida para a seleção da política CPP é recuperado da sessão da autenticação (como grupos AD/LDAP e tão um). O ISE sabe que sessão do alvo do ID de sessão apresentado dentro reorienta a URL. Etapa 14. O link assistente da transferência da instalação de rede (NSA) é retornado ao cliente. O cliente transfere o aplicativo. Nota: Normalmente você pôde ver que o NSA como parte de BYOD flui para Windows e Android mas também este aplicativo pode ser usado para instalar Anyconnect ou seus componentes do ISE. A etapa 15.User executa o aplicativo NSA. Etapa 16. O NSA envia a primeira prova de descoberta - HTTP /auth/discovery ao gateway padrão. O NSA espera a reorientar-url em consequência.

7 Nota: Para conexões sobre o VPN em dispositivos do MAC OS esta ponta de prova é ignorada porque o MAC OS não tem o gateway padrão no adaptador de VPN. A etapa 17.NSA envia em segundo a ponta de prova se primeira uma falha. Em segundo a ponta de prova é um HTTP GET /auth/discovery a enroll.cisco.com. Este FQDN tem que ser com sucesso solucionável pelo servidor DNS. No cenário VPN com túnel em divisão, o tráfego a enroll.cisco.com precisa de ser distribuído através do túnel. Etapa 18. Se algumas das pontas de prova sucedem, o NSA estabelece a conexão SSL sobre a porta 8905 com a informação obtida da reorientar-url. Esta conexão é protegida pelo certificado ISE admin. Dentro desta conexão o NSA transfere Anyconnect. Considerações importantes: Antes de ISE 2.2 libere uma comunicação SSL sobre a porta 8905 é uma exigência para a postura. Para evitar o portal de advertência do certificado e os Certificados admin tem que ser confiada no lado do cliente. Na multi-relação ISE as disposições conectam outro que G0 pode ser limitado ao FQDN diferente do sistema FQDN (que usa o comando CLI do host IP). Isto pôde causar problemas com assunto Name(SN)/validação alternativa nome do assunto (SAN). Porque o cliente poderia ser reorientado ao FQDN da relação G1 por exemplo mas para o certificado de 8905 comunicações com sistema FQDN é retornado que não pôde combinar ao FQDN reorienta dentro a URL. Como uma solução para esta encenação que você pôde considerar adicionar FQDNs das interfaces adicionais em campos do certificado SAN admin, ou você pode usar o convite no certificado admin.

8 O processo da postura da etapa 19.Anyconnect é lançado. Começos do módulo da postura em qualqueras um situações: Após a instalação Após a alteração de status da interface de rede (Up/Down) Após a mudança do valor do gateway padrão Após o evento do início de uma sessão do usuário de sistema, Etapa 20. Nesta fase o módulo da postura de Anyconnect inicia a detecção do servidor da política. Isto é realizado com séries ou pontas de prova que são enviadas ao mesmo tempo pelo módulo da postura: Ponta de prova 1 - O HTTP obtém /auth/discovery ao IP do gateway padrão. Você deve recordar que os dispositivos do MAC OS não têm o gateway padrão no adaptador de VPN. O resultado esperado para a ponta de prova é reorientar-url. Ponta de prova 2 - HTTP GET /auth/discovery a enroll.cisco.com. Este FQDN precisa de ser com sucesso solucionável pelo servidor DNS. No cenário VPN com túnel em divisão, o tráfego a enroll.cisco.com tem que ser distribuído através do túnel. O resultado esperado para

9 a ponta de prova é reorientar-url. Ponta de prova 3 - O HTTP obtém /auth/discovery ao host da descoberta. O valor do host da descoberta é retornado do ISE durante a instalação no perfil da postura AC. O resultado esperado para a ponta de prova é reorientar-url. Ponta de prova 4 - HTTP GET /auth/status sobre o SSL na porta 8905 ao PSN previamente conectado. Este pedido contém a informação sobre o cliente IPs e MAC alista para a consulta da sessão no lado ISE. Este proble não presneted durante a primeira tentativa da postura. A conexão é protegida pelo certificado ISE admin. Em consequência desta ponta de prova o ISE pode retornar o ID de sessão de volta ao cliente se nó onde a ponta de prova aterrada é o mesmo nó onde o usuário foi autenticado. Nota: Em consequência desta ponta de prova, a postura pode ser feita com sucesso mesmo sem reorientação de trabalho sob algumas circunstâncias. A postura bem sucedida sem reorientação exige esse PSN atual que autenticou a sessão deve ser o mesmo que o PSN com sucesso conectado precedente. Mantenha na mente que a postura bem sucedida ISE 2.2 prévios sem reorientação é um pouco exceção do que uma regra. As próximas etapas descrevem o processo da postura caso que quando reoriente a URL é recebida (fluxo identificado por meio de letra a) em consequência de uma das pontas de prova: Etapa 21. O módulo da postura estabelece a conexão ao abastecimento URL de utilização portal do cliente recuperado durante a fase da descoberta. Nesta fase o ISE faz a validação da política de abastecimento do cliente que usa mais uma vez a informação da sessão autenticada. A política de abastecimento do cliente da etapa 22.If é detectada, retornos ISE reorienta à porta Etapa 23. O agente estabelece a conexão ao ISE sobre a porta Durante esta conexão o ISE retorna URL para o perfil da postura, o módulo da conformidade e as atualizações do anyconnect.

10 Transferência da configuração de módulo da postura da etapa 24.AC do ISE. Transferência e instalação da etapa 25.Updates se for necessário. O módulo da etapa 26.Posture recolhe a informação inicial sobre o sistema (como a versão de OS, produtos de segurança instalados, sua versão da definição). Nesta fase o módulo da postura envolve OPSWAT API para recolher o infromation sobre produtos de segurança. Os dados recolhidos são enviados ao ISE. Como uma resposta a este pedido ISE fornece a lista das exigências da postura. A lista das exigências é selecionada em consequência do processamento da política da postura. Para combinar a versão de OS correta do dispositivo da política, dos usos ISE (presente no pedido) e o valor do ID de sessão para escolher outros atributos requerido (grupos AD/LDAP). O valor do ID de sessão é enviado pelo cliente também. Etapa 27. Nesta etapa o cliente envolve atendimentos OPSWAT e o outro mecanismo para verificar exigências da postura. O relatório final com exigências alista e seu estado é enviado ao ISE. O ISE precisa de fazer a decisão final sobre o staus da conformidade do valor-limite. Se o mercado do valor-limite como não complacente neste grupo da etapa de ações da remediação é retornado. Para o valor-limite complacente o ISE escreve o status de conformidade na sessão e põe também o último timestamp da postura aos atributos do valor-limite se o aluguer da postura é configurado. O resultado da postura é enviado para trás ao valor-limite. Caso que quando o tempo da reavaliação da postura (PRA) para o PRA pôs pelo ISE neste pacote também. Na encenação NON-complacente leve em conta aqueles pontos:

11 Algumas ações da remediação (como o mensagem de texto do indicador, a remediação do link, a remediação do arquivo e a outro) são executadas pelo agente próprio da postura. A outra remediação datilografa (como o AV. O as, WSUS, SCCM) exigem uma comunicação do opswat API entre o agente da postura e o produto do alvo. Nesta postura da encenação o agente apenas envia o pedido da remediação ao produto. Remidiation próprio é feito por produtos de segurança diretamente. Nota: Caso que quando os produtos de segurança tiverem que se comunicar com os recursos externos (server interno/externo da atualização) você precisa de se assegurar de que esta comunicação esteja permitida em Redirect-ACL/DACL. A etapa 28.ISE envia o pedido COA ao NAD que deve provocar a autenticação nova para o usuário. O NAD deve confirmar este pedido por COA ACK. Mantenha na mente que para o impulso COA do caso VPN é usada, assim que nenhum pedido de autenticação novo é enviado. Em lugar do ASA remove os parâmetros de autorização precedentes (reoriente a URL, reorientam o ACL, o DACL) da sessão e aplica parâmetros novos do pedido COA. Pedido de autenticação de Stpe 29.New para o usuário. Considerações importantes: Tipicamente para Cisco NAD o reauth COA é usado pelo ISE, e este instrui o NAD para iniciar o pedido de autenticação novo com ID de sessão precedente. No lado ISE o mesmo valor do ID de sessão é uma indicação que que recolha previamente atributos de sessão deva ser reutilizada (estado da queixa em nosso caso) e o perfil novo da autorização baseado naqueles atributos deve ser atribuído. Em caso do ID de sessão mude esta conexão é tratado como um processo novo e completo da postura é reiniciado. Para evitar a re-postura em cada ID de sessão mude o aluguer da postura pode ser usado. Nesta encenação a informação sobre o estado da postura é armazenada nos atributos do valor-limite que fica no ISE mesmo se o ID de sessão obtém mudado. A política da autorização da etapa 30.New é selecionada no lado ISE baseado no estado da postura. Etapa 31. A aceitação de acesso com atributos novos da autorização é enviada ao NAD. O fluxo seguinte descreve a encenação quando reoriente a URL não é recuperado (identificado por meio de letra b) por toda a ponta de prova da postura e PSN previamente conectado esteve perguntado pela última ponta de prova. Todas as etapas aqui são exatamente as mesmas que no caso com reoriente a URL exceto a repetição que é retornada pelo PSN em consequência da ponta de prova 4. Se esta ponta de prova aterrou no mesmo PSN que é um proprietário para a sessão atual do authenitcation, a repetição contém o valor do ID de sessão que é usado mais tarde pelo agente da postura para terminar o processo. Caso que quando o final do cabeçalho conectado precedente não é o mesmo que o proprietário da sessão atual, a consulta da sessão falha e a resposta vazia está retornada ao módulo da postura. Como um resultado final disto,

12 nenhum mensagem Detected Message do servidor da política é retornado ao utilizador final. Fluxo da postura em ISE 2.2 O ISE 2.2 apoia o estilo velho e novo simultaneamente. Esta é a explicação detalhada para o fluxo novo:

13 A etapa 1.Authentication é uma primeira etapa do fluxo, ele poderia ser dot1x, MAB ou VPN. A etapa 2.ISE tem que selecionar a política da authentication e autorização para o usuário. Na encenação da postura a política selecionada da autorização precisa de conter uma referência ao estado da postura, que inicialmente deve ser desconhecido ou não aplicável. Para cobrir ambo isto os casos, circunstância com o complacente desigual do estado da postura podem ser usados. Para a postura sem a reorientação não há nenhuma necessidade de usar nenhuma configuração da reorientação da Web no perfil da autorização. Você pôde ainda considerar usar um DACL ou um espaço aéreo ACL para limitar o acesso de usuário na fase quando o estado da postura não está disponível. A etapa 3.ISE retorna a aceitação de acesso com atributos da autorização. Etapa 4. Se o nome DACL é retornado na aceitação de acesso, o NAD inicia a transferência do índice DACL e aplica o perfil da autorização à sessão depois que é obtido. Etapa 5. A aproximação nova supõe que a reorientação não é possível assim que o usuário precisa de incorporar manualmente o FQDN do portal do abastecimento do cliente. O FQDN do portal CPP precisa de ser definido na configuração portal no sdie ISE. Da perspectiva do servidor DNS o Um-registro precisa de apontar ao server ISE com o papel PSN permitido. Etapa 6. O cliente envia o HTTP obtém ao FQDN do portal do abastecimento do cliente, este pedido é analisado gramaticalmente no lado ISE e o portal completo URL é retornado de volta ao cliente.

14 A conexão da etapa 7.SSL sobre a porta recebida dentro reorienta a URL é estabelecida (padrão 8443). Esta conexão é protegida pelo certificado portal do lado ISE. O portal do abastecimento do cliente (CPP) é apresentado ao usuário. Etapa 8. Nesta etapa dois os eventos acontecem no ISE: Único sinal sobre (SSO) - O ISE tenta à autenticação bem sucedida precedente da consulta. O ISE usa o endereço IP de origem do pacote como um filtro da busca para sessões vivas do raio. Nota: A sessão é recuperada baseou na harmonia entre o IP da fonte no pacote e quadro o endereço IP de Um ou Mais Servidores Cisco ICM NT na sessão. O endereço IP de Um ou Mais Servidores Cisco ICM NT do Framed é recuperado normalmente pelo ISE das atualizações provisórias da contabilidade, assim que exige-se para ter a contabilidade permitida no lado NAD. Também você deve recordar que o SSO é somente possível no nó que possui a sessão. Se por exemplo a sessão é autenticada em PSN 1 mas em FQDN próprio aponta ao mecanismo PSN2 SSO falha. Consulta da política de abastecimento do cliente - em caso do SSO bem sucedido, o ISE pode usar dados da sessão e do agente de usuário autenticados do navegador cliente. Em caso do SSO mal sucedido o usuário tem que fornecê-la credenciais e depois que a informação de autenticação de usuário está recuperada das lojas internas e externos da identidade (grupos AD/LDAP/Internal), pode ser usado para a verificação da política de abastecimento do cliente.

15 Nota: Devido ao erro CSCvd11574 você pôde ver o erro na altura da seleção da política de abastecimento do cliente para não o caso SSO quando o usuário externo é um membro dos grupos múltiplos AD/LDAP adicionados na configuração externo da loja da identidade. Etapa 9. Depois que a seleção ISE da política de abastecimento do cliente indica a transferência URL do agente ao usuário. Depois que você clica sobre a transferência NSA, o aplicativo está empurrado para o usuário. O nome de arquivo NSA contém o FQDN do portal CPP. A etapa 10.At esta etapa NSA executa pontas de prova para estabelecer a conexão ao ISE. Duas pontas de prova são as clássicas, e terceira uma é projetado permitir a descoberta ISE nos ambientes sem reorientação URL. O NSA envia a primeira prova de descoberta - HTTP /auth/discovery ao gateway padrão. O NSA espera a reorientar-url em consequência. O NSA envia em segundo a ponta de prova se primeira uma falha. Em segundo a ponta de prova é um HTTP GET /auth/discovery a enroll.cisco.com. Este FQDN tem que ser com sucesso solucionável pelo servidor DNS. No cenário VPN com túnel em divisão, o tráfego a enroll.cisco.com tem que ser distribuído através do túnel. O NSA envia a terceira ponta de prova sobre a porta portal CPP ao FQDN do portal do abastecimento do cliente. Este pedido contém a informação sobre o ID de sessão portal que permite que o ISE identifique que recursos têm que ser provided.n Etapa 11. O NSA transfere Anyconnect e/ou os módulos específicos. O processo da transferência é feito sobre a porta do portal do abastecimento do cliente.

16 Etapa 12. Em ISE 2.2, o processo da postura é dividido em duas fases. A primeira fase contém o grupo de provas de descoberta tradicionais da postura para apoiar a compatibilidade retrógrada com disposições que retransmite na URL reorienta. Etapa 13. A primeira fase contém todas as provas de descoberta tradicionais da postura. Para obter mais detalhes sobre as pontas de prova satisfazem reveem etapa 20 pre no fluxo da postura ISE 2.2. A etapa 14.Stage dois contém duas provas de descoberta que permite que o módulo da postura AC estabeleça a conexão ao PSN onde a sessão é autenticada nos ambientes onde a reorientação não é apoiada. Durante a fase duas todas as pontas de prova são sequenciais. Ponta de prova 1 - Durante o primeiro módulo da postura da ponta de prova AC tenta estabelecer com o IP/FQDNs do da lista Call Home. A lista dos alvos para a ponta de prova tem que ser configurada no perfil da postura AC no lado ISE. Você pode definir IPs/FQDNs separado por vírgulas, com dois pontos que você pode definir o número de porta para cada destino do Call Home. Esta porta precisa de ser igual à porta em que o portal do abastecimento do cliente é corridas. No lado que do cliente sobre server do Call Home é encontrado em ISEPostureCFG.xml, este arquivo pode ser encontrada no dobrador - a postura segura do cliente da mobilidade de C:\ProgramData\Cisco\Cisco AnyConnect \ ISE \ O alvo do Call Home não pôde possuir a sessão e nesta fase a consulta do proprietário da sessão precisa de acontecer. O módulo da postura instrui o ISE para começar a consulta do proprietário usando o alvo especial URL - /auth/ng-discovery, o pedido contém também o cliente IPs e MAC alista. Depois que esta mensagem é recebida pela consulta da sessão PSN é primeira feita

17 localmente. Se a sessão não é encontrada o PSN inicia a pergunta do nó MNT. Este pedido contém o clint IPs/MAC alista, em consequência o FQDN do proprietário deve ser obtido do MNT. Após este PSN retorna o FQDN do proprietário de volta ao cliente. O pedido seguinte do cliente é enviado ao FQDN do proprietário da sessão com AUTH/estado na URL e na lista de IPs e de MAC. Ponta de prova 2 - Nesta fase o módulo da postura tenta PSN FQDNs que são ficadas situados em ConnectionData.xml. Você pode encontrar este arquivo no user> <current \ AppData \ Local \ Cisco de C:\Users\ \ Cliente de mobilidade Cisco AnyConnect Secure \. Retrievs do módulo da postura este arquivo na época da primeira tentativa da postura. O arquivo contém a lista de FQDN ISE PSN. O índice da lista pôde dinamicamente ser atualizado durante a tentativa de conexão seguinte. O objetivo do fim da ponta de prova é obter o FQDN do proprietário da sessão atual. A aplicação é idêntica sondar 1 com a única diferença na seleção do destino da ponta de prova. O arquivo próprio está ficado situado no dobrador do usuário atual caso que o dispositivo é usado por usuários múltiplos. O usuário diferente não pode usar a informação deste arquivo. Isto pôde conduzir usuários ao problema da galinha e do ovo nos ambientes sem reorientação quando os alvos do Call Home não são especificados. Etapa 15. Depois que a informação sobre o proprietário da sessão é obtida, todas as etapas subsequentes são idênticas pre ao fluxo ISE 2.2. Configurar Para este documento, ASAv é usado como um dispositivo do acesso de rede. Todos os testes são conduzidos com postura sobre o VPN. A configuração ASA para a postura sobre o apoio VPN é fora do espaço do documento, refere para mais detalhes: Postura da versão ASA VPN com exemplo de configuração ISE Diagrama de Rede A topologia acima é usada nos testes. Com ASA ele possível simular facilmente a encenação quando o mecanismo SSO para o portal do abastecimento do cliente falhar no lado PSN, devido

18 aos recursos NAT. Em caso do fluxo regular da postura sobre o VPN, o SSO os trabalhos multarem o seno NAT não está reforçado normalmente para VPN IPs quando os usuários entram na rede corporativa. Configurações Configuração do abastecimento do cliente Estas são as etapas para preparar a configuração de Anyconnect. Etapa 1. Transferência do pacote de Anyconnect. O pacote próprio de Anyconnect não está disponível para a transferência direta do ISE assim que antes que você comece, assegura-se de que o AC esteja disponível em seu PC. Este link pode ser usado para a transferência AC - neste pacote do documento anyconnect-win webdeploy-k9.pkg é usado. Etapa 2. A fim transferir arquivos pela rede o pacote AC ao ISE, navegue à política > aos elementos da política > aos resultados > ao abastecimento > ao Resourcesand do cliente clique adicionam. Escolha recursos de agente do disco local. Na nova janela escolha Cisco forneceu pacotes, o clique consulta e seleciona o pacote AC em seu PC. O clique submete-se para terminar a importação. Etapa 3. O módulo da conformidade tem que ser transferido arquivos pela rede ao ISE. No mesmo clique da página adicionar e escolha recursos de agente do local de Cisco. Na lista de recursos você deve verificar um módulo da conformidade. Para este módulo da conformidade de AnyConnectComplianceModuleWindows do documento é usado. Etapa 4. Agora o perfil da postura AC tem que ser criado. Clique adicionam e escolhem o perfil do agente NAC ou da postura de Anyconnect.

19 Escolha o tipo do perfil. AnyConnect se seja usado para esta encenação. Especifique o nome de perfil. Navegue para posture a seção de protocolo do perfil Especifique regras do nome do servidor, este campo não pode estar vazio. O campo pode conter o FQDN com convite que restringe a conexão de módulo da postura AC aos PSN do namespace apropriado. Põe a estrela se qualquer FQDN for permitido. Os nomes e os IPs especificados aqui estão no uso durante a fase 2 da descoberta da postura. Você pode separar nomes pelo número de porta do coma também pode ser adicionado após FQDN/IP usando dois pontos. Nota: Mantenha na mente que a presença de endereços de Call Home é crítica para PC multiusuários. Reveja por favor etapa 14. no cargo ISE 2.2 do fluxo da postura. Configuração da etapa 5.Create AC. Navegue à política > aos elementos da política > aos resultados > ao abastecimento > aos recursos do cliente e o clique adiciona, a seguir seleciona a configuração de AnyConnect.

20 Selecione o pacote AC. Forneça o nome de configuração AC. Escolha a versão do módulo da conformidade. Selecione o perfil da configuração da postura AC da lista de drop-down. Etapa 6. Configurar a política de abastecimento do cliente. Navegue à política > ao abastecimento do cliente. Em caso da configuração inicial você pode encher valores vazios na política apresentada com os padrões. Em você precise de adicionar a política a configuração existente da postura, para navegar à política que pode ser reutilizada e escolhido a duplicata acima ou a duplicar abaixo. A política brandnew pode igualmente ser criada. Este é o exemplo da política usada no documento.

21 Escolha sua configuração AC na seção do resultado. Mantenha na mente, isso em caso da falha ISE SSO pode ter somente atributos do início de uma sessão ao portal. Isto atribui é limitado à informação que pode ser recuperada sobre o usuário das lojas internas e externos da identidade. Neste documento, o grupo AD é usado como uma circunstância na política de abastecimento do cliente. Políticas e condições da postura A verificação simples da postura é usada. O ISE é configurado para verificar o estado do serviço do defensor do indicador no lado do dispositivo final. Os cenários de vida reais podem ser muito mais complicados mas as etapas da configuração geral são as mesmas. Etapa 1. Crie a condição da postura. As condições da postura são ficadas situadas na política > nos elementos > nas condições > na postura da política. Escolha o tipo de condição da postura. Abaixo de você pode encontrar o exemplo da condição do serviço que deve verificar se o serviço de Windows Defender está sendo executado. Configuração das exigências da etapa 2.Posture. Navegue à política > aos elementos > aos resultados > à postura > às exigências da política. Este é um exemplo para a verificação do

22 defensor do indicador: Escolha sua condição da postura na exigência nova e especifique a ação da remediação. Etapa 3. Configuração das normas da postura. Navegue à política > à postura. Abaixo de você pode encontrar o exemplo da política usado para este documento. A política tem a exigência de Windows Defender atribuída como imperativo e contém somente o nome do grupo externo AD como uma circunstância. Configurar o portal do abastecimento do cliente Para a postura sem reorientação, a configuração do portal do abastecimento do cliente tem que ser editada. Navegue à administração > ao Gerenciamento portal > ao cliente que do dispositivo ProvisioningYou pode usar o portal do padrão ou criar seus próprios. O mesmo portal pode ser usado para ambos postura com e sem a reorientação. Aqueles ajustes devem ser editados na configuração portal para a encenação da NONreorientação:

23 Na autenticação, especifique a sequência da fonte da identidade que deve ser usada se o SSO não pode encontrar a sessão para o usuário. De acordo com a lista selecionada da sequência da fonte da identidade de grupos disponíveis é povoado. Neste momento você precisa de selecionar os grupos que são autorizados para o início de uma sessão portal. O FQDN do portal do abastecimento do cliente tem que ser especificado. Este FQDN deve ser solucionável a ISE PSN IPs. Os usuários devem ser instruídos especificar o FQDN no navegador da Web durante a primeira tentativa de conexão. Configurar perfis e políticas da autorização Acesso inicial para o cliente quando o estado da postura não for necessidades disponíveis de ser restringido. Isto podia ser conseguido nas formas múltiplas: Atribuição DACL - durante a fase do acesso restrito DACL pode ser atribuído ao usuário para limitar o acesso. Esta aproximação pode ser usada para dispositivos de acesso da rede Cisco. Atribuição de VLAN - antes que o usuário bem sucedido da postura possa ser posto em VLAN restrito, esta aproximação deve trabalhar muito bem para quase todo o vendedor NAD. ID de filtro do raio - com este atributo, o ACL definido localmente no NAD pode ser atribuído ao usuário com estado desconhecido da postura. Porque este é um atributo do padrão RFC, esta aproximação deve trabalhar bem para todos os vendedores NAD. Etapa 1. Configurar DACL. Desde que este exemplo é baseado no ASA, um NAD DACL pode ser usado. Para cenários de vida reais você pôde considerar o VLAN ou o ID de filtro como opções possíveis. A fim criar DACL navegue à política > aos elementos > aos resultados > à autorização da política > clique carregável de ACLsand adicionam Durante estado desconhecido da postura pelo menos aquelas permissões devem ser fornecidas: Tráfego DNS Tráfego DHCP Tráfego ao ISE PSN a que o FQDN do portal CPP indica Tráfego aos server da remediação se necessário Este é um exemplo de DACL sem server da remediação:

24 Etapa 2. Configurar o perfil da autorização. Para a postura dois perfis da autorização são exigidos como de costume. Primeiro um deve conter qualquer tipo das limitações do acesso de rede (perfil com o DACL usado neste exemplo). Este perfil pode ser aplicado às autenticações para que o estado da postura não é igual a complacente. O segundo perfil da autorização pôde conter apenas acces da licença e pode ser aplicado para a sessão com iguais do estado da postura a complacente. Para criar o perfil da autorização navegue à política > aos elementos da política > aos resultados > à autorização > aos perfis da autorização. Exemplo do perfil do acesso restrito

25 Neste exemplo, o perfil PermitAccess do padrão ISE é usado para a sessão após a verificação de status bem sucedida da postura. Etapa 3. Configurar a política da autorização. Durante políticas desta autorização de etapa dois deve ser criado. Um para combinar o pedido de autenticação inicial com o estado desconhecido da postura e em segundo um atribuir o acesso direto após o processo bem sucedido da postura. Éum exemplo de políticas simples da autorização para este caso A configuração da política de autenticação não é parte de este documento mas você deve manter-se na mente que antes da política da autorização processar a autenticação bem sucedida

26 tem que acontecer. Verificar A verificação básica do fluxo pode consistir em três etapas principais: Etapa 1. Verificação do fluxo da autenticação 1. Autenticação inicial. Para esta etapa você pode estar interessado na validação que o perfil da autorização foi aplicado. Se o perfil inesperado da autorização foi aplicado por favor investigue relatório detalhado da autenticação. Você pode abrir este relatório clicando na lupa na coluna dos detalhes. Você pode comparar atributos em relatório detalhado da autenticação com a condição na política da autorização que você espera combinar. 2. Evento da transferência DACL. Esta corda está apresentada somente no caso quando o perfil da autorização selecionado para a autenticação inicial contém o nome DACL. 3. Autenticação portal - esta etapa no fluxo indica que o mecanismo SSO não situou a sessão do usuário. Isto pôde acontecer devido às razões múltiplas: O NAD não é configurado para enviar mensagens da contabilidade ou o endereço IP de Um ou Mais Servidores Cisco ICM NT do Framed não está atual nelas.o FQDN do portal CPP foi resolvido ao IP do nó ISE diferente do nó onde a autenticação da inicial foi processada.cliente situado atrás do NAT. 4. Os dados de sessão mudam, neste estado de sessão do exemplo particular mudaram de desconhecido a complacente. 5. COA ao dispositivo do acesso de rede. Este COA deve ser bem sucedido empurrar a autenticação nova do lado NAD e a atribuição nova da política da autorização no lado ISE. Se o COA falhou você pode abrir relatório detalhado para investigar a razão. A maioria de problemas comuns com COA podem ser: Intervalo COA - em tal caso um ou outro PSN que enviou o pedido não é configurado como um cliente COA no lado NAD, ou o COA que o pedido foi deixado cair em algum lugar na maneira.coa ACK negativo - indique que o COA esteve recebido pelo NAD mas devido à operação COA do algum motivo não pode ser confirmado. Para este relatório detalhado da encenação deve conter mais explicação detalhada. Porque o ASA foi usado como um NAD para este exemplo, você pode não ver nenhum pedido da autenticação subsequente para o usuário. Isto acontece dívida que o fato ISE usa o impulso COA para o ASA que evita o interuption do serviço VPN. Em tal encenação, o COA próprio contém parâmetros de autorização novos, assim que o reauthentication não é precisado. Verificação da seleção da política de abastecimento da etapa 2.Client - Para isto você pode

27 executar um relatório no ISE que pode o ajudar a compreender que políticas de abastecimento do cliente eram aplicadas para o usuário. Navegue ao valor-limite das operações > dos relatórios e aos usuários > ao abastecimento do cliente e execute o relatório para a data que você precisa Com este relatório que você pode verificar que política de abastecimento do cliente era seleta e também em caso da falha, razões deve ser apresentado na coluna da razão da falha. Verificação do relatório da etapa 3.Posture - Navegue ao valor-limite das operações > dos relatórios e aos usuários > à avaliação da postura pelo valor-limite. Você pode abrir relatório detalhado de aqui para que cada evento particular verifique por exemplo a que ID de sessão este relatório pertence, que as exigências exatas da postura foram selecionadas pelo ISE para o valor-limite e também o estado para cada exigência. Troubleshooting Informação geral Para o processo da postura que pesquisa defeitos, aqueles componentes ISE têm que ser permitidos dentro debugam nos Nós ISE onde o processo da postura pode acontecer: cliente-webapp - responsável componente para o abastecimento do agente. Arquivos de registro guest.log e ise-psc.log do alvo. guestacess - responsável componente para a consulta portal do proprietário do componente e da sessão do abastecimento do cliente (quando o pedido vier lesar o PSN). Arquivo de registro do alvo - guest.log. abastecimento - responsável componente para o processamento da política de abastecimento do cliente. Arquivo de registro do alvo - guest.log. postura - todos os eventos relacionados da postura. Arquivo de registro do alvo - ise-psc.log. Para o lado do cliente pesquisá-lo defeitos pode usar-se: acisensa.log - No caso da falha do abastecimento do cliente no lado do cliente este arquivo é criado no mesmo dobrador a que o NSA foi transferido (o diretório das transferências para

28 Windows normalmente), AnyConnect_ISEPosture.txt - Este arquivo pode ser encontrado no pacote do DARDO no módulo da postura de Cisco AnyConnect ISE do diretório. Toda a informação sobre a descoberta ISE PSN e as etapas gerais do fluxo da postura são registradas neste arquivo. Troubleshooting dos problemas comuns Problemas relacionados SSO Em caso do SSO bem sucedido você pôde ver estas mensagens em ise-psc.log, este grupo de mensagens indica que a consulta da sessão terminou com sucesso e a autenticação no portal pode ser saltada :07:35,951 DEBUG [http-bio exec-12][] cisco.cpm.posture.runtime.postureruntimefactory -::::- looking for Radius session with input values : sessionid: null, MacAddr: null, ipaddr: :07:35,989 DEBUG [http-bio exec-12][] cisco.cpm.posture.runtime.postureruntimefactory -::::- looking for session using session ID: null, IP addrs: [ ], mac Addrs [null] :07:35,989 DEBUG [http-bio exec-12][] cisco.cpm.posture.runtime.postureruntimefactory -::::- looking for session using IP :07:35,989 DEBUG [http-bio exec-12][] cisco.cpm.posture.runtime.postureruntimefactory -::::- nasporttype = :07:35,989 DEBUG [http-bio exec-12][] cisco.cpm.posture.runtime.postureruntimefactory -::::- nasporttype equal to 5 ( 5 is virtual NAS_PORT_TYPE for VPN ). Found a VPN session null using ip address :07:35,989 DEBUG [http-bio exec-12][] cisco.cpm.posture.runtime.postureruntimefactory -::::- Found session c0a bb8 using ipaddr Você pode usar o endereço IP de Um ou Mais Servidores Cisco ICM NT do valor-limite como uma chave de busca para encontrar esta informação. Um bit mais tarde no log do convidado você deve ver que a autenticação esteve saltada: :07:35,989 DEBUG [http-bio exec-12][] guestaccess.flowmanager.step.cp.cpinitstepexecutor -::- SessionInfo is not null and session AUTH_STATUS = :07:35,989 DEBUG [http-bio exec-12][] com.cisco.ise.portalsessionmanager.portalsession -::- Putting data in PortalSession with key and value: Radius.Session c0a bb :07:35,989 DEBUG [http-bio exec-12][] com.cisco.ise.portalsessionmanager.portalsession -::- Putting data in PortalSession with key : Radius.Session :07:35,989 DEBUG [http-bio exec-12][] guestaccess.flowmanager.step.cp.cpinitstepexecutor -::- Login step will be skipped, as the session =c0a bb8 already established for mac address null, clientipaddress :07:36,066 DEBUG [http-bio exec-12][] cpm.guestaccess.flowmanager.processor.portalflowprocessor -::- After executestepaction(init), returned Enum: SKIP_LOGIN_PROCEED Em caso de não trabalhar o arquivo de registro ISE-psc SSO contém a informação sobre a falha de consulta da sessão: :59:00,779 DEBUG [http-bio exec-2][] cisco.cpm.posture.runtime.postureruntimefactory -::::- looking for Radius session with input values : sessionid: null, MacAddr: null, ipaddr: :59:00,779 DEBUG [http-bio exec-2][]

29 cisco.cpm.posture.runtime.postureruntimefactory -::::- looking for session using session ID: null, IP addrs: [ ], mac Addrs [null] :59:00,779 DEBUG [http-bio exec-2][] cisco.cpm.posture.runtime.postureruntimefactory -::::- looking for session using IP :59:00,779 DEBUG [http-bio exec-2][] cisco.cpm.posture.runtime.postureruntimefactory -::::- nasporttype = null :59:00,779 DEBUG [http-bio exec-2][] cisco.cpm.posture.runtime.postureruntimefactory -::::- nasporttype == null or is not a virtual NAS_PORT_TYPE ( 5 ) :59:00,779 DEBUG [http-bio exec-2][] cisco.cpm.posture.runtime.postureruntimefactory -::::- No Radius session found Em guest.log em tal caso você deve ver a autenticação de usuário completa no portal: :59:00,779 DEBUG [http-bio exec-2][] cpm.guestaccess.flowmanager.step.stepexecutor -::- Find Next Step=LOGIN :59:00,779 DEBUG [http-bio exec-2][] cpm.guestaccess.flowmanager.step.stepexecutor -::- Step : LOGIN will be visible! :59:00,779 DEBUG [http-bio exec-2][] cpm.guestaccess.flowmanager.step.stepexecutor -::- Returning next step =LOGIN :59:00,780 INFO [http-bio exec-2][] cpm.guestaccess.flowmanager.step.stepexecutor -::- Radius Session ID is not set, assuming in dry-run mode Em caso das falhas de autenticação no portal você precisa de centrar-se sobre a verificação da configuração portal - que a loja da identidade é no uso? Que grupos são autorizados para o início de uma sessão? Pesquise defeitos a seleção da política de abastecimento do cliente Em caso das falhas das políticas de abastecimento do cliente ou da política incorreta processá-lo pode verificar o arquivo de guest.log para mais detalhes: :59:07,080 DEBUG [http-bio exec-2][] guestaccess.flowmanager.step.guest.clientprovstepexecutor -:user1:- In Client Prov : useragent =Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/ Firefox/51.0, radiussessionid=null, idgroupname=s , username=user1, isinunittestmode=false :59:07,080 DEBUG [http-bio exec-2][] cpm.guestaccess.common.utils.osmapper -:user1:- UserAgent : Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/ Firefox/ :59:07,080 DEBUG [http-bio exec-2][] cpm.guestaccess.common.utils.osmapper -:user1:- Client OS: Windows 7 (All) :59:07,080 DEBUG [http-bio exec-2][] guestaccess.flowmanager.step.guest.clientprovstepexecutor -:user1:- Retrieved OS=Windows 7 (All) :59:07,080 DEBUG [http-bio exec-2][] guestaccess.flowmanager.step.guest.clientprovstepexecutor -:user1:- Updating the idgroupname to NAC Group:NAC:IdentityGroups:S :59:07,080 DEBUG [http-bio exec-2][] guestaccess.flowmanager.step.guest.clientprovstepexecutor -:user1:- User Agent/Radius Session is empty or in UnitTestMode :59:07,080 DEBUG [http-bio exec-2][] guestaccess.flowmanager.step.guest.clientprovstepexecutor -:user1:- Calling getmatchedpolicywithnoredirection for user=user :59:07,505 DEBUG [http-bio exec-2][] guestaccess.flowmanager.step.guest.clientprovstepexecutor -:user1:- CP Policy Status =SUCCESS, needtodovlan=false, CoaAction=NO_COA Na primeira corda você pode ver como a informação sobre a sessão é injetada no motor da seleção da política, em caso de nenhum fósforo da política ou do fósforo que incorreto da política você pode comparar atributos de aqui com sua configuração das normas do abastecimento do cliente. A última corda indica o estado da seleção da política.

30 Pesquise defeitos o processo da postura No lado do cliente você deve estar interessado em pontas de prova da investigação e em seus resultados. Este é um exemplo da ponta de prova bem sucedida da fase 2: ****************************************** Date : 02/23/2017 Time : 17:59:57 Type : Unknown Source : acise Description : Function: Target::Probe Thread Id: 0x4F8 File: SwiftHttpRunner.cpp Line: 1415 Level: debug PSN probe skuchere-ise22-cpp.example.com with path /auth/status, status is -1.. ****************************************** Nesta fase o PSN retorna à informação AC sobre o proprietário da sessão, você pode ver mensagens deste par mais tarde: ****************************************** Date : 02/23/2017 Time : 17:59:58 Type : Unknown Source : acise Description : Function: Target::probeRecentConnectedHeadEnd Thread Id: 0xBE4 File: SwiftHttpRunner.cpp Line: 1674 Level: debug Target skuchere-ise22-2.example.com, posture status is Unknown.. ****************************************** Os proprietários da sessão retornam ao agente toda a informação requerida: ****************************************** Date : 02/23/2017 Time : 17:59:58 Type : Unknown Source : acise Description : Function: SwiftHttpRunner::invokePosture Thread Id: 0xFCC File: SwiftHttpRunner.cpp Line: 1339 Level: debug MSG_NS_SWISS_NEW_SESSION, <?xml version="1.0"?> <root> <IP></IP> <FQDN>skuchere-ise22-2.example.com</FQDN>