O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve como solucionar problemas do recurso de integração de terceiros no Cisco Identity Services Engine (ISE). Ele pode ser usado como um guia para integração com outros fornecedores e fluxos. O ISE versão 2.0 suporta integração de terceiros. Este é um exemplo de configuração que apresenta como integrar a rede sem fio gerenciada pelo Aruba IAP 204 com o ISE para os serviços BYOD (Bring Your Own Device).
Note: Esteja ciente de que a Cisco não é responsável pela configuração ou suporte de dispositivos de outros fornecedores.
A Cisco recomenda que você tenha conhecimento destes tópicos:
As informações neste documento são baseadas nestas versões de software:
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Há duas redes sem fio gerenciadas pelo Aruba AP. O primeiro (mgarcarz_byod) é usado para acesso EAP (EAP-PEAP) 802.1x Extensible Authentication Protocol. Após uma autenticação bem-sucedida, o controlador Aruba deve redirecionar o usuário para o portal ISE BYOD - fluxo Native Supplicant Provisioning (NSP). O usuário é redirecionado, o aplicativo Network Setup Assistant (NSA) é executado e o certificado é provisionado e instalado no cliente Windows. A CA interna do ISE é usada para esse processo (configuração padrão). O NSA também é responsável pela criação de perfil sem fio para o segundo Service Set Identifier (SSID) gerenciado pela autenticação Aruba (mgarcarz_byod_tls) - que é usado para 802.1x Extensible Authentication Protocol-Transport Layer Security (EAP-TLS).
Como resultado, o usuário corporativo pode fazer a integração de dispositivos pessoais e obter acesso seguro à rede corporativa.
Este exemplo pode ser facilmente modificado para diferentes tipos de acesso, por exemplo:
Quais são os desafios quando você usa fluxos de convidados do ISE (como BYOD, CWA, NSP, Client Provisioning Portal (CPP)) com dispositivos de terceiros?
O Cisco Network Access Devices (NAD) usa o par de porta cisco-av Radius chamado audit-session-id para informar o servidor de Autenticação, Autorização e Contabilidade (AAA) sobre a ID da sessão. Esse valor é usado pelo ISE para rastrear as sessões e fornecer os serviços corretos para cada fluxo. Outros fornecedores não suportam o par cisco-av. Portanto, o ISE precisa confiar nos atributos IETF recebidos em Solicitação de Acesso e Solicitação de Contabilidade.
Depois de receber a solicitação de acesso, o ISE cria a ID de sessão da Cisco sintetizada (de Calling-Station-ID, NAS-Port, NAS-IP-Address e segredo compartilhado). Esse valor tem um significado local apenas (não enviado pela rede). Como resultado, é esperado de cada fluxo (BYOD, CWA, NSP, CPP) para anexar atributos corretos - portanto, o ISE é capaz de recalcular a ID da sessão da Cisco e executar uma pesquisa para correlacioná-la com a sessão correta e continuar o fluxo.
O ISE usa o par de porta cisco-av Radius chamado url-redirect e url-redirect-acl para informar ao NAD que o tráfego específico deve ser redirecionado.
Outros fornecedores não suportam o par cisco-av. Normalmente, esses dispositivos devem ser configurados com um URL de redirecionamento estático que aponte para um serviço específico (Perfil de autorização) no ISE. Quando o usuário inicia a sessão HTTP, esses NADs redirecionam para a URL e também anexam argumentos adicionais (como endereço IP ou endereço MAC) para permitir que o ISE identifique uma sessão específica e continue o fluxo.
O ISE usa o radius cisco-av-pair chamado subscriber:command, subscriber:reauthenticate-type para indicar quais ações o NAD deve executar para uma sessão específica. Outros fornecedores não suportam o par cisco-av. Normalmente, esses dispositivos usam RFC CoA (3576 ou 5176) e uma das duas mensagens definidas:
O ISE suporta o Cisco CoA com par Cisco av e também o RFC CoA 3576/5176.
Para oferecer suporte a fornecedores terceirizados, o ISE 2.0 introduziu um conceito de perfis de dispositivo de rede que descreve como o fornecedor específico se comporta - como as sessões, o redirecionamento de URL e o CoA são suportados.
Os perfis de autorização são de tipo específico (Perfil do dispositivo de rede) e quando a autenticação ocorre, o comportamento do ISE é derivado desse perfil. Como resultado, os dispositivos de outros fornecedores podem ser gerenciados facilmente pelo ISE. Além disso, a configuração no ISE é flexível e permite ajustar ou criar novos perfis de dispositivo de rede.
Este artigo apresenta o uso do perfil padrão para o dispositivo Aruba.
Mais informações sobre o recurso:
Perfis de dispositivo de acesso à rede com o Cisco Identity Services Engine
Navegue até Administração > Recursos de rede > Dispositivos de rede. Escolha o perfil de dispositivo correto para o fornecedor selecionado, neste caso: ArubaSem fio. Certifique-se de configurar a porta Shared Secret e CoA conforme mostrado nas imagens.
Caso não haja nenhum perfil disponível para o fornecedor desejado, ele pode ser configurado em Administração > Recursos de rede > Perfis de dispositivo de rede.
Navegue até Policy > Policy Elements > Results > Authorization > Authorization Profiles escolha o mesmo Network Device Profile como na Etapa 1. ArubaWireless. O perfil configurado é o Aruba-redirect-BYOD com o BYOD Portal e como mostrado nas imagens.
Falta parte da configuração do Web Redirection, onde é gerado um link estático para o perfil de autorização. Embora o Aruba não suporte o redirecionamento dinâmico para o portal do convidado, há um link atribuído a cada perfil de autorização, que é então configurado no Aruba e como mostrado na imagem.
Navegue até Política > Regras de autorização e a configuração é como mostrado na imagem.
Primeiro, o usuário se conecta ao SSID mgracarz_aruba e o ISE retorna o perfil de autorização Aruba-redirect-BYOD, que redireciona o cliente para o portal BYOD padrão. Após a conclusão do processo de BYOD, o cliente se conecta ao EAP-TLS e o acesso total à rede é concedido.
Para configurar o Portal cativo no Aruba 204, navegue para Segurança > Portal cativo externo e adicione um novo. Insira essas informações para obter a configuração adequada e conforme mostrado na imagem.
Navegue até Segurança > Servidores de autenticação para garantir que a porta CoA seja igual à configurada no ISE, como mostrado na imagem. (por padrão no Aruba 204, ele é definido como 5999, no entanto, não é compatível com o RFC 5176 e também não funciona com o ISE).
Use o portal cativo configurado na Etapa 1. Clique em Novo, escolha Tipo de regra: Portal cativo, Tipo de página inicial: Externo como mostrado na imagem.
Além disso, permita todo o tráfego para o servidor ISE (portas TCP no intervalo de 1 a 20000), enquanto regra configurada por padrão em Aruba: Permitir qualquer destino a todos os destinos parece não estar funcionando corretamente, como mostrado na imagem.
Use esta seção para confirmar se a sua configuração funciona corretamente.
O primeiro log de autenticação no ISE é exibido. A política de autenticação padrão foi usada, o perfil de autorização Aruba-redirect-BYOD foi retornado, como mostrado na imagem.
O ISE retorna uma mensagem de reconhecimento de acesso ao rádio com êxito do EAP. Observe que nenhum atributo adicional é retornado (nenhum url-redirect de par av da Cisco ou url-redirect-acl) como mostrado na imagem.
Aruba relata que a sessão foi estabelecida (a identidade EAP-PEAP é cisco) e a Função selecionada é mgarcarz_aruba, como mostrado na imagem.
Essa função é responsável pelo redirecionamento para o ISE (funcionalidade de portal cativo em Aruba).
Na CLI de Aruba, é possível confirmar qual é o status 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 ID da ACL 138 quanto às 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 corresponde ao que foi configurado na GUI para essa função, como mostrado na imagem.
Quando o usuário abre o navegador da Web e digita qualquer endereço, o redirecionamento ocorre conforme mostrado na imagem.
Olhando para as capturas de pacote, confirma-se que Aruba falsifica o destino (5.5.5.5) e retorna o redirecionamento HTTP para ISE.
Observe que é a mesma URL estática configurada no ISE e copiada para o portal cativo em Aruba - mas, além disso, vários argumentos são adicionados da seguinte forma e como mostrado na imagem:
Por causa desses argumentos, o ISE pode recriar a ID da sessão da Cisco, descobrir a sessão correspondente no ISE e continuar com o fluxo de BYOD (ou qualquer outro fluxo configurado). Para dispositivos Cisco, audit_session_id seria normalmente usado, mas isso não é suportado por outros fornecedores.
Para confirmar isso a partir das depurações do ISE, é possível ver a geração do valor de audit-session-id (que nunca é enviado pela 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, a correlação disso após o registro do dispositivo no BYOD Página 2:
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
Em solicitações subsequentes, o cliente é redirecionado para a página 3 do BYOD. onde a NSA é baixada e executada.
O NSA tem a mesma tarefa do navegador da Web. Primeiro, ele precisa detectar qual é o endereço IP do ISE. Isso é obtido através do redirecionamento HTTP. Mas como esse tempo o usuário não tem a possibilidade de digitar o endereço IP (como no navegador da Web), esse tráfego é gerado automaticamente. O gateway padrão é usado (também enroll.cisco.com pode ser usado) como mostrado na imagem.
A resposta é exatamente a mesma do navegador da Web. Dessa forma, a NSA é capaz de se conectar ao ISE, obter perfil xml com a configuração, gerar solicitação SCEP, enviá-lo para o ISE, obter certificado assinado (assinado pela CA interna do ISE), configurar o perfil sem fio e finalmente se conectar ao SSID configurado. Coletar registros do cliente (no Windows estão 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
Esses registros são exatamente iguais aos do processo BYOD com dispositivos da Cisco.
Note: Radius CoA não é necessário aqui. É o aplicativo (NSA) que força a reconexão a um SSID recém-configurado.
Nesse estágio, o usuário pode ver que o sistema tenta se associar a um SSID final. Se tiver mais de um certificado de usuário, você deverá selecionar o certificado correto conforme mostrado na imagem.
Após uma conexão bem-sucedida, os relatórios NSA são como mostrado na imagem.
Isso pode ser confirmado no ISE - o segundo log atinge a autenticação EAP-TLS, que corresponde a todas as condições para Basic_Authenticated_Access (EAP-TLS, Employee, e BYOD Registered true), como mostrado na imagem.
Além disso, a exibição de identidade do endpoint pode confirmar se o sinalizador BYOD registrado está definido como verdadeiro, como mostrado na imagem.
No PC Windows, o novo perfil sem fio foi criado automaticamente como preferido (e configurado para EAP-TLS) e como mostrado na imagem.
Nesse estágio, a Aruba confirma que o usuário está conectado ao SSID final, como mostrado na imagem.
A função que é criada automaticamente e nomeada como Rede fornece acesso total à rede como mostrado na imagem.
Enquanto no fluxo de BYOD não há mensagens de CoA, o fluxo de CWA com Portal de Convidado Autorregistrado é demonstrado aqui:
As regras de autorização configuradas são as mostradas na imagem.
O usuário se conecta ao SSID com a autenticação MAB e, uma vez que tenta se conectar a alguma página da Web, ocorre o redirecionamento para o Portal de Convidado Autorregistrado, onde o Convidado pode criar uma nova conta ou usar a atual como mostrado na imagem.
Depois que o convidado é conectado com êxito, a mensagem de CoA é enviada do ISE para o dispositivo de rede para alterar o estado de autorização como mostrado na imagem.
Ele pode ser verificado em Operações > Autenticações e conforme mostrado na imagem.
Mensagem de CoA em depurações do ISE:
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 Disconnect-ACK, que vem da 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
O pacote captura com CoA Diconnect-Request (40) e Diconnect-ACK (41) é como mostrado na imagem.
Note: O RFC CoA foi usado para autenticação relacionada ao Perfil de dispositivo Aruba (configurações padrão). Para autenticação relacionada ao dispositivo Cisco, teria sido reautenticado o tipo CoA da Cisco.
Esta seção disponibiliza informações para a solução de problemas de configuração.
Se o Captive Portal em Aruba estiver configurado com o endereço IP em vez de FQDN do ISE, o PSN NSA falhará:
Warning - [HTTPConnection] Abort the HTTP connection due to invalid certificate
CN
O motivo para isso é a validação rigorosa de certificado quando você se conecta ao ISE. Quando você usa o endereço IP para se conectar ao ISE (como resultado de um URL de redirecionamento com endereço IP em vez de FQDN) e é apresentado um certificado ISE com Nome do assunto = falha na validação do FQDN.
Note: O navegador da Web continua com o portal BYOD (com um aviso que precisa ser aprovado pelo usuário).
Por padrão, a Aruba Access-Policy configurada com o Captive Portal permite as portas tcp 80, 443 e 8080.
O NSA não pode se conectar à porta TCP 8905 para obter o perfil 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
Por padrão, a Aruba fornece o número de porta para a porta CoA 5999 do CoA Air Group. Infelizmente, o Aruba 204 não respondeu a tais solicitações como mostrado na imagem.
A captura de pacotes é como mostrado na imagem.
A melhor opção a ser usada aqui pode ser a porta 3977 do CoA, conforme descrito em RFC 5176.
No Aruba 3600 com v6.3, percebe-se que o redirecionamento funciona ligeiramente diferente de outros controladores. A captura e explicação de pacotes podem ser encontradas aqui e como mostrado na 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