Integração da 3ª parte ISE 2.0 com exemplo da configuração sem fio de Aruba

Introdução

A versão 2.0 do Cisco Identity Services Engine (ISE) apoia a integração da 3ª parte. Este é exemplo de configuração que apresenta como integrar a rede Wireless controlada por Aruba IAP 204 com o ISE para traz seus próprios serviços do dispositivo (BYOD).

Os documentos explicam como pesquisar defeitos a característica da integração da 3ª parte no ISE e podem ser usados como guia para a integração com os outros fornecedores e os fluxos.

Aviso: Esteja por favor ciente que Cisco não é responsável para a configuração ou o apoio dos dispositivos dos outros fornecedores.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Conhecimento básico da configuração de Aruba IAP
• O conhecimento básico de BYOD flui no ISE
• Conhecimento básico da configuração do Identity Services Engine (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

Configurar

Diagrama de Rede

Há duas redes Wireless controladas por Aruba AP. Primeiro (mgarcarz_byod) está sendo usado para o acesso do 802.1x EAP-PEAP. Depois que o controlador de Aruba da autenticação bem sucedida 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 é executado e o certificado é fornecida e instalado no cliente do Windows. O ISE CA interno é usado para esse processo (configuração padrão). O assistente da instalação de rede é igualmente responsável para a criação do perfil wireless para o segundo SSID controlado por Aruba (mgarcarz_byod_tls) - esse é usado para a autenticação EAP-TLS do 802.1x.

Em consequência o usuário corporativo pode executar onboarding do dispositivo pessoal e obter o acesso seguro na rede corporativa.

O exemplo seguinte podia 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 para a autenticação EAP-PEAP o diretório ativo é usado (para manter este usuários internos curtos do artigo ISE é usado)
• Tipicamente para o abastecimento SCEP do certificado o server externo está sendo usado, o serviço do registro do dispositivo da rede Microsoft (NDE) para manter geralmente este artigo que o ISE interno curto CA é usado.

Desafios com apoio da 3ª parte

Que são os desafios ao usar o convidado ISE fluem (como BYOD, CWA, NSP, CPP) com dispositivos da 3ª parte?

Sessões

Os dispositivos de acesso da rede Cisco (NAD) estão usando o Cisco-av-pair do raio chamado auditoria-sessão-identificação para informar o servidor AAA sobre a identificação da sessão que o valor está usado pelo ISE para seguir as sessões e para 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.

Após ter recebido 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 localmente um significado 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 para correlacioná-la com a sessão correta e para continuar o fluxo.

A URL reorienta

O ISE está usando o Cisco-av-pair do raio chamado URL-reorienta e URL-reorientar-ACL para 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 a reorientação estática URL que aponta ao serviço específico (perfil da autorização) no ISE. Uma vez que o usuário está iniciando a sessão de HTTP aquela NADs está reorientando a essa URL e igualmente está anexando argumentos adicionais (como o endereço IP de Um ou Mais Servidores Cisco ICM NT ou o MAC address) para permitir o ISE identifica a sessão específica e continue o fluxo.

CoA

O ISE está usando o Cisco-av-pair do raio chamado subscritor: comando, subscritor: reauthenticate-tipo para indicar que ações se a tomada NAD para uma sessão específica. Os outros fornecedores não apoiam os pares Cisco-AV. Tão tipicamente aqueles dispositivos estão usando o CoA RFC (3576 ou 5176) e uma de duas mensagens definidas: 

• a solicitação de desconexão (chamada igualmente pacote de desconexão) - esse é usada para desligar a sessão (muito o ofter 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

Para apoiar os vendedores ISE 2.0 da 3ª parte 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

Step1 adicionam o controlador wireless de Aruba aos dispositivos de rede

Vá à administração > aos recursos de rede > aos dispositivos de rede. Escolha o perfil de dispositivo correto para o vendedor selecionado, nesse caso: ArubaWireless. Certifique-se configurar a porta compartilhada do segredo e CoA.

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.

Step2 configuram o perfil da autorização

Da política > dos elementos da política > resultam > a autorização > os perfis da autorização escolhem o mesmo perfil do dispositivo de rede que em etapa 1: ArubaWireless. O perfil de seguimento foi configurado:

• Aruba-reoriente-BYOD com portal BYOD como mostrado abaixo:

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.

Step3 configuram regras da autorização

Sob as regras da política > da autorização foram configuradas em seguinte maneira:

Primeiramente, o usuário conecta a SSID “mgracarz_aruba” e o perfil da autorização dos retornos ISE “Aruba-reorienta-BYOD” que reorientam o cliente para optar pelo portal BYOD. Após a terminação o cliente do processo BYOD conecta usando o EAP-TLS e o acesso direto à rede é concedido.

Aruba AP

Configuração Step1 portal prisioneira

A fim configurar o portal prisioneiro em Aruba 204, navegue à Segurança > portal prisioneiro externo e adicionar o novo. Seguir é precisado para a configuração apropriada:

• 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 abaixo da configuração da reorientação da Web,

• Porta: o número de porta em que selecionou o portal é hospedado no ISE (à revelia: 8443).

Configuração de servidor RADIUS Step2

Security > Authentication dos server certifique-se de que a porta CoA é a mesma que configurada no ISE. (Em Aruba 204 é ajustada à revelia a 5999, contudo que não é complacente com RFC 5176 e igualmente não está trabalhando com ISE).

Configuração Step3 SSID

• ABA de segurança:

• Aba do acesso: escolha a regra Com base na rede do acesso configurar o portal prisioneiro no SSID:

Use o portal prisioneiro que foi configurado em Step1. Você pode adicionar-lo que usa o botão “novo”, escolhendo o tipo da regra: O portal e o respingo prisioneiros paginam o tipo como externo.

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.

Verificar

Conexão Step1 ao mgarcarz_aruba SSID usando 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:

O ISE está retornando a mensagem da aceitação de acesso do raio com sucesso EAP. Observe por favor que nenhum atributo adicional está sendo retornado (nenhum par Cisco AV URL-reorienta ou URL-reorientar-ACL)

Aruba relata que a sessão está estabelecida (identidade EAP-PEAP é Cisco) e o papel selecionado é mgarcarz_aruba:

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 para verificar a identificação 138 ACL 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:

Reorientação do tráfego do navegador da Web Step2 para BYOD

Uma vez que o navegador da Web aberto do usuário e datilografa toda a reorientação do endereço ocorre:

Olhando as capturas de pacote de informação confirmou que Aruba é destino da falsificação (5.5.5.5) e Redireção do HTTP de retorno ao ISE. Observe por favor que é a mesma URL estática como configurado no ISE e copiada ao portal prisioneiro em Aruba - mas os argumentos múltiplos estão sendo adicionados adicionalmente:

• 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 2 aqueles 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 o audit_session_id dos dispositivos Cisco seria usado normalmente mas isso não é apoiado por outros fornecedores.

Para confirmar isso do ISE debugar-lo é 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

No cliente das requisições subsequente é a página reorientada 3 BYOD onde o assistente da instalação de rede é transferido e executado

Execução do assistente da instalação de rede Step3

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 o usuário deste tempo não tem uma possibilidade para datilografar o endereço IP de Um ou Mais Servidores Cisco ICM NT (como no navegador da Web) que esse tráfego é gerado automaticamente. O gateway padrão está sendo usado (igualmente enroll.cisco.com poderia ser usado):

Resposta ele exatamente o mesmos 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. Logs corretos do cliente (em Windows esteja em %temp%/spwProfile.log). Algumas saídas 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.

Observe por favor que CoA do raio não está exigido aqui. É o aplicativo (NSA) que força a reconexão a um SSID recentemente configurado.

Nesse usuário da fase pode ver que o sistema está tentando associar a um SSID final. Se ter mais então um certificado de usuário selecionar correto:

Após a conexão bem sucedida o NSA relata aquele:

Isso pode ser confirmado igualmente no ISE - as segundas batidas autenticação EAP-TLS do log, combinando todas as condições para Basic_Authenticated_Access (EAP-TLS, empregado, e verdadeiro registrado BYOD):

Igualmente a opinião da identidade do valor-limite pode confirmar que o valor-limite tem a bandeira de BYODRegistered ajustada para retificar:

No perfil wireless novo do PC Windows foi criado automaticamente como preferido (e configurado para o EAP-TLS):

Nessa fase Aruba confirma o usuário é conectada ao SSID final.

O papel que é criado automaticamente e nomeou o mesmos como a rede está fornecendo o acesso de rede completo:

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 abaixo:

As regras de seguimento da autorização foram configuradas:

O usuário conecta ao SSID usando a autenticação MAB e uma vez tentando conectar a algum página da web, a reorientação ao portal registrado auto do convidado acontece, onde o convidado pode criar a conta nova ou usar o existência:

Depois que o convidado é conectado com sucesso a mensagem CoA é envia do ISE ao dispositivo de rede a fim mudar o estado da autorização.

Pode-se verificar sob operações > Authenitcations:

 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 Diconnect-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

 Capturas de pacote de informação com Diconnect-pedido CoA (40) e Diconnect-ACK (41):

Observe por favor que o CoA RFC esteve usado para a autenticação relativa ao perfil de dispositivo Aruba (configurações padrão). Para a autenticação relativa ao dispositivo Cisco seria tipo CoA de Cisco reauthenticate.

Troubleshooting

Portal prisioneiro de Aruba com endereço IP de Um ou Mais Servidores Cisco ICM NT 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 assistente da instalação de rede ISE PSN falha:

Warning - [HTTPConnection] Abort the HTTP connection due to invalid certificate 
CN

A razão para o esse é validação certificada restrita ao conectar ao ISE. Quando usar o endereço IP de Um ou Mais Servidores Cisco ICM NT para 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 ser presentado com o certificado ISE com o nome do sujeito = a validação FQDN falham.

Observe por favor que o navegador da Web continua com portal BYOD (com aviso que precisa de ser aprovado pelo usuário).

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 assistente da instalação de rede não deve poder conectar à porta 8905 tcp para obter o perfil do xml do ISE. O seguinte erro é seja 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 estava respondendo a tais pedidos.

Captura de pacote de informação:

Usar a porta 3799 CoA como descrito no RFC 5176 seria a melhor opção aqui.

Reorientação em alguns dispositivos de Aruba

Em Aruba 3600 com v6.3 observou-se que a reorientação está trabalhando levemente diferente então em outros controladores. A captura de pacote de informação e a explicação podem ser encontradas abaixo:

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

Referências

• Guia do administrador do Cisco Identity Services Engine, liberação 2.0
• Perfis de dispositivo do acesso de rede com Cisco Identity Services Engine
• Suporte Técnico e Documentação - Cisco Systems