Configuración de la integración de ISE 2.0 de terceros con Aruba Wireless
Contenido
Introducción
Este documento describe cómo resolver problemas de la función de integración de terceros en Cisco Identity Services Engine (ISE). Se puede utilizar como guía para la integración con otros proveedores y flujos. ISE versión 2.0 admite integración de terceros. Este es un ejemplo de configuración que muestra cómo integrar la red inalámbrica gestionada por Aruba IAP 204 con ISE para los servicios Traiga su propio dispositivo (BYOD).
Prerequisites
Requirements
Cisco recomienda que tenga conocimiento sobre estos temas:
- Configuración IAP de Aruba
- Flujos de BYOD en ISE
- Configuración de ISE para la autenticación de contraseña y certificado
Componentes Utilizados
La información que contiene este documento se basa en estas versiones de software:
- Aruba IAP 204 software 6.4.2.3
- Cisco ISE, versión 2.0 y posteriores
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. Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Configurar
Diagrama de la red
Hay dos redes inalámbricas gestionadas por Aruba AP. La primera (mgarcarz_byod) se utiliza para el acceso EAP protegido por protocolo de autenticación extensible 802.1x (EAP-PEAP). Después de una autenticación correcta, el controlador de Aruba debe redirigir al usuario al portal de ISE BYOD: flujo de aprovisionamiento de suplicante nativo (NSP). Se redirige al usuario, se ejecuta la aplicación Network Setup Assistant (NSA) y el certificado se aprovisiona e instala en el cliente de Windows. La CA interna de ISE se utiliza para ese proceso (configuración predeterminada). La NSA también es responsable de la creación del perfil inalámbrico para el segundo identificador del conjunto de servicios (SSID) administrado por Aruba (mgarcarz_byod_tls), que se utiliza para la autenticación 802.1x de protocolo de autenticación ampliable-seguridad de la capa de transporte (EAP-TLS).
Como resultado, los usuarios corporativos pueden realizar la incorporación de dispositivos personales y obtener acceso seguro a la red corporativa.
Este ejemplo se puede modificar fácilmente para diferentes tipos de acceso, por ejemplo:
- Autenticación web central (CWA) con servicio BYOD
- Autenticación 802.1x con redirección de estado y BYOD
- Normalmente, para la autenticación EAP-PEAP se utiliza Active Directory (para mantener este artículo, se utilizan los usuarios de ISE internos)
- Normalmente, para el aprovisionamiento de certificados se utiliza el servidor externo SCEP (del inglés Simple Certificate Enrollment Protocol, protocolo simple de inscripción de certificados), normalmente el servicio de inscripción de dispositivos de red (NDES) de Microsoft para mantener este artículo corto, se utiliza la CA de ISE interna.
Retos con soporte de terceros
¿Cuáles son los retos a los que se enfrenta el uso de flujos de invitados ISE (como BYOD, CWA, NSP, Client Provisioning Portal (CPP)) con dispositivos de terceros?
SESIONES
Cisco Network Access Devices (NAD) utiliza Radius cisco-av-pair denominada audit-session-id para informar al servidor de autenticación, autorización y contabilidad (AAA) sobre el ID de sesión. ISE utiliza ese valor para realizar un seguimiento de las sesiones y proporcionar los servicios correctos para cada flujo. Otros proveedores no admiten el par cisco-av. Por lo tanto, ISE debe confiar en los atributos IETF recibidos en Solicitud de acceso y Solicitud de contabilidad.
Después de recibir la solicitud de acceso, ISE genera una ID de sesión de Cisco sintetizada (desde Calling-Station-ID, NAS-Port, NAS-IP-Address y secreto compartido). Ese valor tiene un significado local solamente (no se envía a través de la red). Como resultado, se espera que cada flujo (BYOD, CWA, NSP, CPP) adjunte atributos correctos, de modo que ISE pueda recalcular el ID de sesión de Cisco y realizar una búsqueda para correlacionarlo con la sesión correcta y continuar con el flujo.
Redirección de URL
ISE utiliza Radius cisco-av-pair llamado url-redirect y url-redirect-acl para informar a NAD de que se debe redirigir el tráfico específico.
Otros proveedores no admiten el par cisco-av. Por lo general, estos dispositivos deben configurarse con una URL de redirección estática que apunte a un servicio específico (perfil de autorización) en ISE. Una vez que el usuario inicia la sesión HTTP, esos NAD se redirigen a la URL y también adjuntan argumentos adicionales (como la dirección IP o la dirección MAC) para permitir que ISE identifique una sesión específica y continúe con el flujo.
CoA
ISE utiliza Radius cisco-av-pair llamado subscriber:command, subscriber:reauthenticate-type para indicar qué acciones debe NAD realizar para una sesión específica. Otros proveedores no admiten el par cisco-av. Por lo general, estos dispositivos utilizan RFC CoA (3576 o 5176) y uno de los dos mensajes definidos:
- solicitud de desconexión (también llamada paquete de desconexión): se utiliza para desconectar la sesión (muy a menudo para forzar la reconexión)
- inserción de CoA: se utiliza para cambiar el estado de la sesión de forma transparente sin desconexión (por ejemplo, sesión de VPN y nueva ACL aplicada)
ISE admite tanto Cisco CoA con Cisco-av-pair como RFC CoA 3576/5176.
Solución para ISE
Para admitir proveedores externos, ISE 2.0 introdujo un concepto de perfiles de dispositivos de red que describe el comportamiento específico del proveedor: cómo se soportan las sesiones, la redirección de URL y la CoA.
Los perfiles de autorización son de un tipo específico (perfil de dispositivo de red) y una vez que se produce la autenticación, el comportamiento de ISE deriva de ese perfil. Como resultado, ISE puede gestionar fácilmente los dispositivos de otros proveedores. Además, la configuración en ISE es flexible y permite ajustar o crear nuevos perfiles de dispositivos de red.
Este artículo presenta el uso del perfil predeterminado para el dispositivo Aruba.
Más información sobre la función:
Perfiles de dispositivos de acceso a la red con Cisco Identity Services Engine
ISE de Cisco
Paso 1. Agregar controlador inalámbrico Aruba a dispositivos de red
Vaya a Administration > Network Resources > Network Devices. Elija el perfil de dispositivo correcto para el proveedor seleccionado, en este caso: ArubaWireless. Asegúrese de configurar Shared Secret y puerto CoA como se muestra en las imágenes.
En caso de que no haya un perfil disponible para el proveedor deseado, puede configurarse bajo Administración > Recursos de Red > Perfiles de Dispositivo de Red.
Paso 2. Configurar perfil de autorización
Vaya a Policy > Policy Elements > Results > Authorization > Authorization Profiles elija el mismo perfil de dispositivo de red que en el Paso 1. ArubaWireless. El perfil configurado es Aruba-redirect-BYOD con el portal BYOD y como se muestra en las imágenes.
Falta parte de la configuración de redirección web, donde se genera el enlace estático al perfil de autorización. Aunque Aruba no soporta la redirección dinámica al portal de invitados, hay un link asignado a cada perfil de Autorización, que luego se configura en Aruba y como se muestra en la imagen.
Paso 3. Configurar reglas de autorización
Vaya a Policy > Authorization Rules y la configuración es como se muestra en la imagen.
En primer lugar, el usuario se conecta a SSID mgracarz_aruba e ISE devuelve Perfil de autorización Aruba-redirect-BYOD, que redirige al cliente al portal de BYOD predeterminado. Después de completar el proceso BYOD, el cliente se conecta con EAP-TLS y se concede acceso completo a la red.
AP Aruba
Paso 1. Configuración del portal cautivo
Para configurar el Portal cautivo en Aruba 204, navegue hasta Security > External Captive Portal y agregue uno nuevo. Ingrese esta información para la configuración correcta y tal como se muestra en la imagen.
- Tipo: Autenticación RADIUS
- IP o nombre de host: servidor ISE
- URL: link que se crea en ISE en la configuración del perfil de autorización; es específico de un perfil de autorización determinado y se puede encontrar aquí en la configuración de redirección web
- Puerto: número de puerto en el que se aloja el portal seleccionado en ISE (de forma predeterminada: 8443) como se muestra en la imagen.
Paso 2. Configuración del servidor de RADIUS
Navegue hasta Seguridad > Servidores de autenticación asegúrese de que el puerto CoA sea el mismo que el configurado en ISE como se muestra en la imagen. (de forma predeterminada, en Aruba 204 se establece en 5999; sin embargo, no es compatible con RFC 5176 y tampoco funciona con ISE).
Paso 3. Configuración SSID
- La ficha Seguridad es la que se muestra en la imagen.
- Ficha Acceso: seleccione Regla de acceso basada en la red para configurar el portal cautivo en SSID.
Utilice el portal cautivo que se configuró en el Paso 1. Haga clic en Nuevo, elija Tipo de regla: Portal cautivo, Tipo de página de bienvenida: Externo, como se muestra en la imagen.
Además, permita todo el tráfico al servidor ISE (puertos TCP en el rango 1-20000), mientras que la regla se configura de forma predeterminada en Aruba: Allow any to all destination parece no funcionar correctamente como se muestra en la imagen.
Verificación
Utilize esta sección para confirmar que su configuración funcione correctamente.
Paso 1. Conexión a SSID mgarcarz_aruba con EAP-PEAP
Aparece el primer registro de autenticación en ISE. Se ha utilizado la política de autenticación predeterminada, se ha devuelto el perfil de autorización de Aruba-redirect-BYOD como se muestra en la imagen.
ISE devuelve el mensaje de aceptación de acceso de RADIUS con EAP Success (Éxito de EAP). Tenga en cuenta que no se devuelven atributos adicionales (no se muestra ningún url-redirect o url-redirect-acl de Cisco av-pair) como se muestra en la imagen.
Aruba informa que la sesión está establecida (la identidad EAP-PEAP es cisco) y el rol seleccionado es mgarcarz_aruba como se muestra en la imagen.
Esa función es responsable de la redirección a ISE (funcionalidad cautiva del portal en Aruba).
En la CLI de Aruba, es posible confirmar cuál es el estado de autorización actual para esa sesión:
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#
Y para verificar el ID de ACL 138 para los permisos actuales:
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 ... >
Esto coincide con lo que se configuró en la GUI para esa función, como se muestra en la imagen.
Paso 2. Redirección del tráfico del navegador web para BYOD
Una vez que el usuario abre el explorador web y escribe cualquier dirección, la redirección se produce como se muestra en la imagen.
Al observar las capturas de paquetes, se confirma que Aruba falsifica el destino (5.5.5.5) y devuelve la redirección HTTP a ISE.
Tenga en cuenta que es la misma URL estática configurada en ISE y copiada en el portal cautivo en Aruba, pero además se agregan varios argumentos como se muestra en la imagen:
- cmd = login
- mac = c0:4a:00:14:6e:31
- essid = mgarcarz_aruba
- ip = 10.62.148.7
- apname = 4bd88c38814 (mac)
- url = http://5.5.5.5
Debido a estos argumentos, ISE puede recrear la ID de sesión de Cisco, averiguar la sesión correspondiente en ISE y continuar con BYOD (o cualquier otro flujo configurado). Para los dispositivos Cisco, audit_session_id se utilizaría normalmente, pero no es compatible con otros proveedores.
Para confirmar que a partir de depuraciones de ISE, es posible ver la generación de valor audit-session-id (que nunca se envía a través de la red):
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
Y, a continuación, correlación de lo anterior después del registro del dispositivo en la página 2 de 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
En las solicitudes posteriores, el cliente se redirige a la página 3 de BYOD. donde se descarga y se ejecuta la NSA.
Paso 3. Ejecución de Network Setup Assistant
La NSA tiene la misma tarea que el navegador web. En primer lugar, debe detectar cuál es la dirección IP de ISE. Esto se logra a través de la redirección HTTP. Sin embargo, como en este momento el usuario no tiene la posibilidad de escribir la dirección IP (como en el navegador web), ese tráfico se genera automáticamente. Se utiliza la gateway predeterminada (también se puede utilizar enroll.cisco.com), como se muestra en la imagen.
La respuesta es exactamente la misma que para el navegador web. De esta manera, la NSA puede conectarse a ISE, obtener un perfil xml con configuración, generar una solicitud SCEP, enviarla a ISE, obtener un certificado firmado (firmado por la CA interna de ISE), configurar el perfil inalámbrico y finalmente conectarse al SSID configurado. Recopile registros del cliente (en Windows se encuentran en %temp%/spwProfile.log). Algunos resultados se omiten para mayor claridad:
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
Estos registros son exactamente los mismos que para el proceso BYOD con los dispositivos de Cisco.
En esa etapa, el usuario puede ver que el sistema intenta asociarse a un SSID final. Si dispone de más de un certificado de usuario, debe seleccionar el correcto, tal y como se muestra en la imagen.
Después de una conexión correcta, los informes de la NSA son como se muestra en la imagen.
Esto se puede confirmar en ISE: el segundo registro se produce con la autenticación EAP-TLS, que coincide con todas las condiciones de Basic_Authenticated_Access (EAP-TLS, Employee y BYOD Registered true), como se muestra en la imagen.
Además, la vista de identidad del terminal puede confirmar que el terminal tiene el indicador BYOD Registered establecido en true, como se muestra en la imagen.
En el PC con Windows, el nuevo perfil inalámbrico se ha creado automáticamente como se prefiere (y se ha configurado para EAP-TLS) y como se muestra en la imagen.
En esa etapa, Aruba confirma que el usuario está conectado al SSID final como se muestra en la imagen.
La función que se crea automáticamente y se denomina de la misma forma que Red proporciona acceso completo a la red, como se muestra en la imagen.
Otros flujos y soporte de CoA
CWA con CoA
Aunque en el flujo de BYOD no hay mensajes de CoA, el flujo de CWA con el portal de invitados registrado automáticamente se muestra aquí:
Las reglas de autorización configuradas son como se muestra en la imagen.
El usuario se conecta al SSID con la autenticación MAB y una vez que intenta conectarse a alguna página web, se produce la redirección al portal de invitados registrado automáticamente, donde el invitado puede crear una nueva cuenta o utilizar la actual, como se muestra en la imagen.
Una vez que el invitado se ha conectado correctamente, se envía un mensaje de CoA desde ISE al dispositivo de red para cambiar el estado de autorización, como se muestra en la imagen.
Se puede verificar en Operaciones > Autenticaciones y como se muestra en la imagen.
Mensaje de CoA en depuraciones de 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
y Disconnect-ACK que viene 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
Las capturas de paquetes con CoA Diconnect-Request (40) y Diconnect-ACK (41) son como se muestra en la imagen.
Troubleshoot
En esta sección se brinda información que puede utilizar para resolver problemas en su configuración.
Portal cautivo de Aruba con dirección IP en lugar de FQDN
Si el portal cautivo en Aruba está configurado con dirección IP en lugar de FQDN de ISE, la NSA PSN falla:
Warning - [HTTPConnection] Abort the HTTP connection due to invalid certificate
CN
El motivo de esto es la validación estricta del certificado cuando se conecta a ISE. Cuando utiliza una dirección IP para conectarse a ISE (como resultado de la dirección URL de redirección con dirección IP en lugar de FQDN) y se le presenta un certificado ISE con nombre de asunto = falla la validación de FQDN.
Política de acceso incorrecta del portal cautivo de Aruba
De forma predeterminada, Aruba Access-Policy configurada con el portal cautivo permite los puertos TCP 80, 443 y 8080.
La NSA no puede conectarse al puerto TCP 8905 para obtener el perfil xml de ISE. Se informa de este error:
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 puerto CoA de Aruba
De forma predeterminada, Aruba proporciona el número de puerto para el puerto CoA CoA Air Group 5999. Desafortunadamente, Aruba 204 no respondió a esas solicitudes como se muestra en la imagen.
La captura de paquetes es como se muestra en la imagen.
La mejor opción para utilizar aquí puede ser el puerto 3977 de CoA como se describe en RFC 5176.
Redirección en algunos dispositivos Aruba
En Aruba 3600 con v6.3 se observa que la redirección funciona ligeramente diferente que en otros controladores. La captura y explicación de paquetes se puede encontrar aquí y como se muestra en la imagen.
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
Información Relacionada
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)