Configurar a integração da 3ª parte ISE 2.0 com Sem fio de Aruba
Índice
Introdução
Este documento descreve como pesquisar defeitos a característica da integração da 3ª parte no Cisco Identity Services Engine (ISE). Pode ser usado como guia para a integração com outros fornecedores e fluxos. A versão 2.0 ISE apoia a integração da 3ª parte. Este é um exemplo de configuração que apresente como integrar a rede Wireless controlada por Aruba IAP 204 com o ISE para serviços de Bring Your Own Device (BYOD).
Pré-requisitos
Requisitos
A Cisco recomenda que você tenha conhecimento destes tópicos:
- Configuração de Aruba IAP
- BYOD flui no ISE
- Configuração ISE para a senha e o certificado de autenticação
Componentes Utilizados
As informações neste documento são baseadas nestas versões de software:
- Software 6.4.2.3 de Aruba IAP 204
- Cisco ISE, libera 2.0 e mais atrasado
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.
Configurar
Diagrama de Rede
Há duas redes Wireless controladas por Aruba AP. Primeiro (mgarcarz_byod) é usado para o acesso Protocolo-protegido autenticação extensível do 802.1x EAP (EAP-PEAP). Após uma autenticação bem sucedida, o controlador de Aruba deve reorientar o usuário ao portal ISE BYOD - fluxo nativo do abastecimento do suplicante (NSP). O usuário é reorientado, o aplicativo assistente da instalação de rede (NSA) é executado e o certificado é fornecida e instalado no cliente do Windows. O ISE CA interno é usado para esse processo (configuração padrão). O NSA é igualmente responsável para a criação do perfil wireless para o identificador do conjunto do segundo serviço (SSID) controlado por Aruba (mgarcarz_byod_tls) - esse é usado para a autenticação da Segurança da camada do Protocolo-transporte da autenticação extensível do 802.1x (EAP-TLS).
Em consequência, o usuário corporativo pode executar onboarding do dispositivo pessoal e obter o acesso seguro na rede corporativa.
Este exemplo pode facilmente ser alterado para tipos diferentes de acesso, por exemplo:
- Autenticação da Web central (CWA) com serviço BYOD
- autenticação do 802.1x com postura e reorientação BYOD
- Tipicamente, porque diretório ativo da autenticação EAP-PEAP é usado (para manter este usuários internos curtos do artigo ISE é usado)
- Tipicamente, porque abastecimento que do certificado o server externo do protocolo simple certificate enrollment (SCEP) é usado, o serviço do registro do dispositivo da rede Microsoft (NDE) a fim manter geralmente este artigo ISE curto, interno CA é usado.
Desafios com apoio da 3ª parte
O que são os desafios quando você usar fluxos do convidado ISE (como BYOD, CWA, NSP, portal do abastecimento do cliente (o CPP)) com dispositivos da 3ª parte?
Sessões
Os dispositivos de acesso da rede Cisco (NAD) usam o Cisco-av-pair do raio chamado auditoria-sessão-identificação a fim informar o server do Authentication, Authorization, and Accounting (AAA) sobre o ID de sessão. Esse valor é usado pelo ISE a fim seguir as sessões e proporcionar os serviços corretos para cada fluxo. Os outros fornecedores não apoiam os pares Cisco-AV. Assim, o ISE tem que confiar nos atributos IETF recebidos no pedido da solicitação de acesso e da contabilidade.
Depois que você recebe a solicitação de acesso, o ISE constrói o ID de sessão sintetizado de Cisco (do Chamar-Estação-ID, da NAS-porta, do Nas-ip-address e do segredo compartilhado). Que o valor tem um significado local somente (não enviado através da rede). Em consequência, esperou de cada fluxo (BYOD, CWA, NSP, CPP) anexar atributos corretos - assim que o ISE pode voltar a calcular o ID de sessão de Cisco e executar uma consulta a fim correlacioná-la com a sessão correta e continuar o fluxo.
A URL reorienta
O Cisco-av-pair do raio dos usos ISE chamado URL-reorienta e URL-reorientar-ACL a fim informar o NAD que o tráfego específico deve ser reorientado.
Os outros fornecedores não apoiam os pares Cisco-AV. Tão tipicamente, aqueles dispositivos devem ser configurados com reorientação estática URL que aponta ao serviço específico (perfil da autorização) no ISE. Uma vez que o usuário inicia a sessão de HTTP, aquela NADs reorienta à URL e igualmente anexa argumentos adicionais (como o endereço IP de Um ou Mais Servidores Cisco ICM NT ou o MAC address) a fim permitir o ISE identifica a sessão específica e continua o fluxo.
CoA
O ISE usa o Cisco-av-pair do raio chamado subscritor: comando, subscritor: reauthenticate-tipo a fim indicar que ações devem tomada NAD para uma sessão específica. Os outros fornecedores não apoiam os pares Cisco-AV. Tão tipicamente, aqueles dispositivos usam o CoA RFC (3576 ou 5176) e uma das duas mensagens definidas:
- a solicitação de desconexão (chamada igualmente pacote de desconexão) - esse é usada para desligar a sessão (muito frequentemente para forçar a reconexão)
- Impulso CoA - esse é usado para mudar transparentemente o estado da sessão sem desconexão (por exemplo sessão de VPN e ACL novo aplicados)
O ISE apoia o CoA de Cisco com Cisco-av-pair e também ambo CoA 3576/5176 RFC.
Solução no ISE
A fim apoiar vendedores da 3ª parte, o ISE 2.0 introduziu um conceito de perfis do dispositivo de rede que descrevesse como o vendedor específico se comporta - como as sessões, URL reorientam e o CoA é apoiado.
Os perfis da autorização são do tipo específico (perfil do dispositivo de rede) e uma vez que a autenticação ocorre o comportamento ISE é derivado desse perfil. Em consequência, os dispositivos dos outros fornecedores podem ser controlados facilmente pelo ISE. Igualmente a configuração no ISE é flexível e reserva ajustar ou criar perfis novos do dispositivo de rede.
Este artigo apresenta o uso do perfil padrão para o dispositivo de Aruba.
Mais informação na característica:
Perfis de dispositivo do acesso de rede com Cisco Identity Services Engine
Cisco ISE
Etapa 1. Adicionar o controlador wireless de Aruba aos dispositivos de rede
Navegue à administração > aos recursos de rede > aos dispositivos de rede. Escolha o perfil de dispositivo correto para o vendedor selecionado, neste caso: ArubaWireless. Assegure para configurar a porta compartilhada do segredo e CoA segundo as indicações das imagens.
Caso que, não há nenhum perfil disponível para o vendedor desejado, pode ser configurado sob a administração > recursos de rede > perfis do dispositivo de rede.
Etapa 2. Configurar o perfil da autorização
Navegue à política > aos elementos da política > aos resultados > à autorização > aos perfis da autorização escolhem o mesmo perfil do dispositivo de rede que na etapa 1. ArubaWireless. O perfil configurado é Aruba-reorienta-BYOD com portal BYOD e segundo as indicações das imagens.
Faltando parte da configuração da reorientação da Web, onde o link estático ao perfil da autorização é gerado. Quando Aruba não apoiar a reorientação dinâmica ao portal do convidado, há um link atribuído a cada perfil da autorização, que é configurado então em Aruba e segundo as indicações da imagem.
Etapa 3. Configurar regras da autorização
Navegue às regras da política > da autorização e a configuração é segundo as indicações da imagem.
Primeiramente, o usuário conecta ao mgracarz_aruba SSID e o perfil da autorização dos retornos ISE Aruba-reorienta-BYOD que reorienta o cliente para optar pelo portal BYOD. Depois que a conclusão do processo BYOD, cliente conecta com o EAP-TLS e o acesso direto à rede está concedido.
Aruba AP
Etapa 1. Configuração portal prisioneira
A fim configurar o portal prisioneiro em Aruba 204, navegue à Segurança > portal prisioneiro externo e adicionar o novo. Incorpore esta informação para a configuração apropriada e segundo as indicações da imagem.
- digite: Autenticação RADIUS
- IP ou hostname: Server ISE
- URL: ligue que é criado no ISE sob a configuração de perfil da autorização; é específica ao perfil particular da autorização e pode ser encontrada aqui sob a configuração da reorientação da Web
- Porta: o número de porta em que selecionou o portal é hospedado no ISE (à revelia: 8443) segundo as indicações da imagem.
Etapa 2. Configuração de servidor RADIUS
Navegue Security > Authentication aos server asseguram-se de que a porta CoA seja a mesma que configurada no ISE segundo as indicações da imagem. (em Aruba 204 é ajustada à revelia a 5999, contudo, que não é complacente com RFC 5176 e igualmente não trabalha com ISE).
Etapa 3. Configuração SSID
- A ABA de segurança é segundo as indicações da imagem.
- Aba do acesso: selecione a regra Com base na rede do acesso a fim configurar o portal prisioneiro no SSID.
Use o portal prisioneiro que foi configurado no clique de etapa 1. novo, escolhem o tipo da regra: Portal prisioneiro, tipo da página do respingo: Externo segundo as indicações da imagem.
Além, permita todo o tráfego ao server ISE (portas TCP na escala 1-20000), quando regra configurada à revelia em Aruba: Permita alguns a todos os destinos parece não trabalhar corretamente segundo as indicações da imagem.
Verificar
Use esta seção para confirmar se a sua configuração funciona corretamente.
Etapa 1. Conexão ao mgarcarz_aruba SSID com o EAP-PEAP
O primeiro fazer logon ISE da autenticação aparece. A política da autenticação padrão foi usada, Aruba-reorienta-BYOD o perfil da autorização foi retornada segundo as indicações da imagem.
O ISE retorna a mensagem da aceitação de acesso do raio com sucesso EAP. Note que nenhum atributo adicional está retornado (nenhum par Cisco AV URL-reorienta ou URL-reorientar-ACL) segundo as indicações da imagem.
Aruba relata que a sessão está estabelecida (identidade EAP-PEAP é Cisco) e o papel selecionado é mgarcarz_aruba segundo as indicações da imagem.
Esse papel é responsável para a reorientação ao ISE (funcionalidade portal prisioneira em Aruba).
Em Aruba CLI, é possível confirmar o que é o estado de autorização atual para essa sessão:
04:bd:88:c3:88:14# show datapath user
Datapath User Table Entries
---------------------------
Flags: P - Permanent, W - WEP, T- TKIP, A - AESCCM
R - ProxyARP to User, N - VPN, L - local, I - Intercept, D - Deny local routing
FM(Forward Mode): S - Split, B - Bridge, N - N/A
IP MAC ACLs Contract Location Age Sessions Flags Vlan FM
--------------- ----------------- ------- --------- -------- ----- --------- ----- ---- --
10.62.148.118 04:BD:88:C3:88:14 105/0 0/0 0 1 0/65535 P 1 N
10.62.148.71 C0:4A:00:14:6E:31 138/0 0/0 0 0 6/65535 1 B
0.0.0.0 C0:4A:00:14:6E:31 138/0 0/0 0 0 0/65535 P 1 B
172.31.98.1 04:BD:88:C3:88:14 105/0 0/0 0 1 0/65535 P 3333 B
0.0.0.0 04:BD:88:C3:88:14 105/0 0/0 0 0 0/65535 P 1 N
04:bd:88:c3:88:14#
E a fim verificar ACL ID 138 para ver se há as permissões atuais:
04:bd:88:c3:88:14# show datapath acl 138
Datapath ACL 138 Entries
-----------------------
Flags: P - permit, L - log, E - established, M/e - MAC/etype filter
S - SNAT, D - DNAT, R - redirect, r - reverse redirect m - Mirror
I - Invert SA, i - Invert DA, H - high prio, O - set prio, C - Classify Media
A - Disable Scanning, B - black list, T - set TOS, 4 - IPv4, 6 - IPv6
K - App Throttle, d - Domain DA
----------------------------------------------------------------
1: any any 17 0-65535 8209-8211 P4
2: any 172.31.98.1 255.255.255.255 6 0-65535 80-80 PSD4
3: any 172.31.98.1 255.255.255.255 6 0-65535 443-443 PSD4
4: any mgarcarz-ise20.example.com 6 0-65535 80-80 Pd4
5: any mgarcarz-ise20.example.com 6 0-65535 443-443 Pd4
6: any mgarcarz-ise20.example.com 6 0-65535 8443-8443 Pd4 hits 37
7: any 10.48.17.235 255.255.255.255 6 0-65535 1-20000 P4 hits 18
<....some output removed for clarity ... >
Isso combina com o o que foi configurado no GUI para esse papel segundo as indicações da imagem.
Etapa 2. Reorientação do tráfego do navegador da Web para BYOD
Uma vez que o usuário abre o navegador da Web e datilografa todo o endereço, a reorientação ocorre segundo as indicações da imagem.
Olhando as capturas de pacote de informação, confirma-se que paródias de Aruba o destino (5.5.5.5) e retorna-se o Redireção do HTTP ao ISE.
Note que é a mesma URL estática como configurado no ISE e copiada ao portal prisioneiro em Aruba - mas os argumentos múltiplos são adicionados adicionalmente como segue e segundo as indicações da imagem:
- Cmd = início de uma sessão
- Mac = c0:4a:00:14:6e:31
- essid = mgarcarz_aruba
- IP = 10.62.148.7
- apname = 4bd88c38814 (Mac)
- URL = http://5.5.5.5
Devido a estes argumentos, o ISE pode recrear o ID de sessão de Cisco, encontrar a sessão correspondente no ISE e continuar com fluxo BYOD (ou qualquer outro configurado). Para dispositivos Cisco, o audit_session_id seria usado normalmente mas aquele não é apoiado por outros fornecedores.
A fim confirmar isso do ISE debuga, ele é possível para ver a geração de auditoria-sessão-identificação avaliar (que é enviada nunca sobre a rede):
AcsLogs,2015-10-29 23:25:48,538,DEBUG,0x7fc0b39a4700,cntx=0000032947,CallingStationID=
c04a00146e31,FramedIPAddress=10.62.148.71,MessageFormatter::appendValue() attrName:
cisco-av-pair appending value:
audit-session-id=0a3011ebXbiuDA3yUNoLUvtCRyuPFxkqYJ7TT06foOZ7G1HXj1M
E então, correlação disso após o registro do dispositivo na página 2 BYOD:
AcsLogs,2015-10-29 23:25:48,538,DEBUG,0x7fc0b39a4700,cntx=0000032947,CallingStationID=
c04a00146e31,FramedIPAddress=10.62.148.71,Log_Message=[2015-10-29 23:25:48.533 +01:00
0000011874 88010 INFO MyDevices: Successfully registered/provisioned the device
(endpoint), ConfigVersionId=145, UserName=cisco, MacAddress=c0:4a:00:14:6e:31,
IpAddress=10.62.148.71, AuthenticationIdentityStore=Internal Users,
PortalName=BYOD Portal (default), PsnHostName=mgarcarz-ise20.example.com,
GuestUserName=cisco, EPMacAddress=C0:4A:00:14:6E:31, EPIdentityGroup=RegisteredDevices
Staticassignment=true, EndPointProfiler=mgarcarz-ise20.example.com, EndPointPolicy=
Unknown, NADAddress=10.62.148.118, DeviceName=ttt, DeviceRegistrationStatus=Registered
AuditSessionId=0a3011ebXbiuDA3yUNoLUvtCRyuPFxkqYJ7TT06foOZ7G1HXj1M,
cisco-av-pair=audit-session-id=0a3011ebXbiuDA3yUNoLUvtCRyuPFxkqYJ7TT06foOZ7G1HXj1M
Nas requisições subsequente, o cliente é reorientado à página 3. BYOD onde o NSA é transferido e executado.
Etapa 3. Execução do assistente da instalação de rede
O NSA tem a mesma tarefa que o navegador da Web. Primeiramente, precisa de detectar o que é o endereço IP de Um ou Mais Servidores Cisco ICM NT do ISE. Isso é conseguido através do Redireção do HTTP. Mas desde este tempo o usuário não tem uma possibilidade para datilografar o IP address (como no navegador da Web), esse tráfego é gerado automaticamente. O gateway padrão é usado (igualmente enroll.cisco.com pode ser usado) segundo as indicações da imagem.
A resposta é exatamente a mesma que para o navegador da Web. Esta maneira NSA pode conectar ao ISE, obtém o perfil do xml com configuração, gerencie o pedido SCEP, envia-o ao ISE, obtém o certificado assinado (assinado por ISE CA interno), configura o perfil wireless e conecta-o finalmente ao SSID configurado. Recolha logs do cliente (em Windows esteja em %temp%/spwProfile.log). Algumas saídas são omitidas para maior clareza:
Logging started
SPW Version: 1.0.0.46
System locale is [en]
Loading messages for english...
Initializing profile
SPW is running as High integrity Process - 12288
GetProfilePath: searched path = C:\Users\ADMINI~1.EXA\AppData\Local\Temp\ for file name = spwProfile.xml result: 0
GetProfilePath: searched path = C:\Users\ADMINI~1.EXA\AppData\Local\Temp\Low for file name = spwProfile.xml result: 0
Profile xml not found Downloading profile configuration...
Downloading profile configuration...
Discovering ISE using default gateway
Identifying wired and wireless network interfaces, total active interfaces: 1
Network interface - mac:C0-4A-00-14-6E-31, name: Wireless Network Connection, type: wireless
Identified default gateway: 10.62.148.100
Identified default gateway: 10.62.148.100, mac address: C0-4A-00-14-6E-31
redirect attempt to discover ISE with the response url
DiscoverISE - start
Discovered ISE - : [mgarcarz-ise20.example.com, sessionId: 0a3011ebXbiuDA3yUNoLUvtCRyuPFxkqYJ7TT06foOZ7G1HXj1M]
DiscoverISE - end
Successfully Discovered ISE: mgarcarz-ise20.example.com, session id: 0a3011ebXbiuDA3yUNoLUvtCRyuPFxkqYJ7TT06foOZ7G1HXj1M, macAddress: C0-4A-00-14-6E-31
GetProfile - start
GetProfile - end
Successfully retrieved profile xml
using V2 xml version
parsing wireless connection setting
Certificate template: [keysize:2048, subject:OU=Example unit,O=Company name,L=City,ST=State,C=US, SAN:MAC]
set ChallengePwd
creating certificate with subject = cisco and subjectSuffix = OU=Example unit,O=Company name,L=City,ST=State,C=US
Installed [LAB CA, hash: fd 72 9a 3b b5 33 72 6f f8 45 03 58 a2 f7 eb 27^M
ec 8a 11 78^M
] as rootCA
Installed CA cert for authMode machineOrUser - Success
HttpWrapper::SendScepRequest - Retrying: [1] time, after: [2] secs , Error: [0], msg: [ Pending]
creating response file name C:\Users\ADMINI~1.EXA\AppData\Local\Temp\response.cer
Certificate issued - successfully
ScepWrapper::InstallCert start
ScepWrapper::InstallCert: Reading scep response file [C:\Users\ADMINI~1.EXA\AppData\Local\Temp\response.cer].
ScepWrapper::InstallCert GetCertHash -- return val 1
ScepWrapper::InstallCert end
Configuring wireless profiles...
Configuring ssid [mgarcarz_aruba_tls]
WirelessProfile::SetWirelessProfile - Start
Wireless profile: [mgarcarz_aruba_tls] configured successfully
Connect to SSID
Successfully connected profile: [mgarcarz_aruba_tls]
WirelessProfile::SetWirelessProfile. - End
Aqueles logs são exatamente os mesmos que para o processo BYOD com dispositivos Cisco.
Nessa fase, o usuário pode ver que o sistema tenta associar a um SSID final. Se você tem mais então um certificado de usuário, você deve selecionar correto segundo as indicações da imagem.
Após uma conexão bem sucedida, os relatórios NSA são segundo as indicações da imagem.
Isso pode ser confirmado no ISE - a segunda autenticação EAP-TLS das batidas do log, que combina todas as condições para Basic_Authenticated_Access (EAP-TLS, empregado, e verdadeiro registrado BYOD) segundo as indicações da imagem.
Também, a opinião da identidade do valor-limite pode confirmar que o valor-limite tem a bandeira registrada BYOD ajustada para retificar segundo as indicações da imagem.
No PC Windows, o perfil wireless novo foi criado automaticamente como preferido (e configurado para o EAP-TLS) e segundo as indicações da imagem.
Nessa fase, Aruba confirma que o usuário está conectado ao SSID final segundo as indicações da imagem.
O papel que é criado automaticamente e nomeou o mesmos como a rede fornece o acesso de rede completo segundo as indicações da imagem.
Outros fluxos e apoio CoA
CWA com CoA
Quando em BYOD não fluir está nenhuma mensagem CoA, CWA flui com o convidado que registrado auto o portal é demonstrado aqui:
As regras da autorização configuradas são segundo as indicações da imagem.
O usuário conecta ao SSID com a autenticação MAB e uma vez quando tenta conectar a algum página da web, reorientação ao convidado que registrado auto o portal acontece, onde o convidado pode criar a conta nova ou usar a corrente uma segundo as indicações da imagem.
Depois que o convidado é conectado com sucesso, a mensagem CoA está enviada do ISE ao dispositivo de rede a fim mudar o estado da autorização segundo as indicações da imagem.
Pode-se verificar sob operações > Authenitcations e segundo as indicações da imagem.
A mensagem CoA no ISE debuga:
2015-11-02 18:47:49,553 DEBUG [Thread-137][] cisco.cpm.prrt.impl.PrRTLoggerImpl -:::::-
DynamicAuthorizationFlow,DEBUG,0x7fc0e9cb2700,cntx=0000000561,sesn=c59aa41a-e029-4ba0-a31b
-44549024315e,CallingStationID=c04a00157634,[DynamicAuthorizationFlow::createCoACmd]
Processing incoming attribute vendor , name NAS-IP-Address, value=10.62.148.118.,
DynamicAuthorizationFlow.cpp:708
2015-11-02 18:47:49,567 DEBUG [Thread-137][] cisco.cpm.prrt.impl.PrRTLoggerImpl -:::::-
DynamicAuthorizationFlow,DEBUG,0x7fc0e9cb2700,cntx=0000000561,sesn=c59aa41a-e029-4ba0-a31b
-44549024315e,CallingStationID=c04a00157634,[DynamicAuthorizationFlow::createCoACmd]
Processing incoming attribute vendor , name Acct-Session-Id, value=04BD88B88144-
C04A00157634-7AD.,DynamicAuthorizationFlow.cpp:708
2015-11-02 18:47:49,573 DEBUG [Thread-137][] cisco.cpm.prrt.impl.PrRTLoggerImpl -:::::-
DynamicAuthorizationFlow,DEBUG,0x7fc0e9cb2700,cntx=0000000561,sesn=c59aa41a-e029-4ba0-a31b
-44549024315e,CallingStationID=c04a00157634,[DynamicAuthorizationFlow::createCoACmd]
Processing incoming attribute vendor , name cisco-av-pair, v
alue=audit-session-id=0a3011ebisZXypODwqjB6j64GeFiF7RwvyocneEia17ckjtU1HI.,DynamicAuthorizationFlow.cpp:708
2015-11-02 18:47:49,584 DEBUG [Thread-137][] cisco.cpm.prrt.impl.PrRTLoggerImpl -:::::-
DynamicAuthorizationFlow,DEBUG,0x7fc0e9cb2700,cntx=0000000561,sesn=c59aa41a-e029-4ba0-a31b
-44549024315e,CallingStationID=c04a00157634,[DynamicAuthorizationRequestHelper::
setConnectionParams] defaults from nad profile : NAS=10.62.148.118, port=3799, timeout=5,
retries=2 ,DynamicAuthorizationRequestHelper.cpp:59
2015-11-02 18:47:49,592 DEBUG [Thread-137][] cisco.cpm.prrt.impl.PrRTLoggerImpl -:::::-
DynamicAuthorizationFlow,DEBUG,0x7fc0e9cb2700,cntx=0000000561,sesn=c59aa41a-e029-4ba0-a31b
-44549024315e,CallingStationID=c04a00157634,[DynamicAuthorizationRequestHelper::set
ConnectionParams] NAS=10.62.148.118, port=3799, timeout=5, retries=1,
DynamicAuthorizationRequestHelper.cpp:86
2015-11-02 18:47:49,615 DEBUG [Thread-137][] cisco.cpm.prrt.impl.PrRTLoggerImpl -:::::-
DynamicAuthorizationFlow,DEBUG,0x7fc0e9cb2700,cntx=0000000561,sesn=c59aa41a-e029-4ba0-a31b
-44549024315e,CallingStationID=c04a00157634,[DynamicAuthorizationFlow::onLocalHttpEvent]:
invoking DynamicAuthorization,DynamicAuthorizationFlow.cpp:246
e Disconexão-ACK que vem de Aruba:
2015-11-02 18:47:49,737 DEBUG [Thread-147][] cisco.cpm.prrt.impl.PrRTLoggerImpl -:::::-
DynamicAuthorizationFlow,DEBUG,0x7fc0e9eb4700,cntx=0000000561,sesn=c59aa41a-e029-4ba0-a31b
-44549024315e,CallingStationID=c04a00157634,[DynamicAuthorizationFlow::
onResponseDynamicAuthorizationEvent] Handling response
ID c59aa41a-e029-4ba0-a31b-44549024315e, error cause 0, Packet type 41(DisconnectACK).,
DynamicAuthorizationFlow.cpp:303
As capturas de pacote de informação com Diconnect-pedido CoA (40) e Diconnect-ACK (41) são segundo as indicações da imagem.
Troubleshooting
Esta seção fornece informações que você pode usar na solução de problemas de sua configuração.
Portal prisioneiro de Aruba com IP address em vez do FQDN
Se o portal prisioneiro em Aruba é configurado com endereço IP de Um ou Mais Servidores Cisco ICM NT em vez do FQDN do ISE, o PSN NSA falha:
Warning - [HTTPConnection] Abort the HTTP connection due to invalid certificate
CN
A razão para o esse é validação certificada restrita quando você conecta ao ISE. Quando você usa o endereço IP de Um ou Mais Servidores Cisco ICM NT a fim conectar ao ISE (em consequência da reorientação URL com endereço IP de Um ou Mais Servidores Cisco ICM NT em vez do FQDN) e é presentado com o certificado ISE com nome do sujeito = validação FQDN falha.
Política de acesso incorreta portal prisioneira de Aruba
À revelia, a política de acesso de Aruba configurada com portal prisioneiro permite as portas 80, 443 e 8080 tcp.
O NSA não pode conectar à porta 8905 tcp a fim obter o perfil do xml do ISE. Este erro é relatado:
Failed to get spw profile url using - url
[https://mgarcarz-ise20.example.com:8905/auth/provisioning/evaluate?
typeHint=SPWConfig&referrer=Windows&mac_address=C0-4A-00-14-6E-31&spw_version=
1.0.0.46&session=0a3011ebXbiuDA3yUNoLUvtCRyuPFxkqYJ7TT06foOZ7G1HXj1M&os=Windows All]
- http Error: [2] HTTP response code: 0]
GetProfile - end
Failed to get profile. Error: 2
Número de porta CoA de Aruba
À revelia, Aruba fornece o número de porta para a porta 5999 CoA do grupo de ar CoA. Infelizmente, Aruba 204 não respondeu a tais pedidos segundo as indicações da imagem.
A captura de pacote de informação é segundo as indicações da imagem.
A melhor opção a usar-se aqui pode ser a porta 3977 CoA como descrito no RFC 5176.
Reorientação em alguns dispositivos de Aruba
Em Aruba 3600 com v6.3 observa-se que os trabalhos da reorientação levemente diferentes então em outros controladores. A captura de pacote de informação e a explicação podem ser encontradas aqui e segundo as indicações da imagem.
packet 1: PC is sending GET request to google.com packet 2: Aruba is returning HTTP 200 OK with following content: <meta http-equiv='refresh' content='1; url=http://www.google.com/&arubalp=6b0512fc-f699-45c6-b5cb-e62b3260e5'>\n packet 3: PC is going to link with Aruba attribute returned in packet 2: http://www.google.com/&arubalp=6b0512fc-f699-45c6-b5cb-e62b3260e5 packet 4: Aruba is redirecting to the ISE (302 code): https://10.75.89.197:8443/portal/g?p=4voD8q6W5Lxr8hpab77gL8VdaQ&cmd=login&mac=80:86:f2:59:d9:db&ip=10.75.94.213&essid=SC%2DWiFi&apname=LRC-006&apgroup=default&url=http%3A%2F%2Fwww%2Egoogle%2Ecom%2F
Informações Relacionadas
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)