Integración de las de otras compañías ISE 2.0 con el ejemplo de la configuración de red inalámbrica de Aruba

Introducción

La versión 2.0 del Cisco Identity Services Engine (ISE) soporta la integración de las de otras compañías. Éste es ejemplo de configuración que presenta cómo integrar la red inalámbrica manejada por Aruba IAP 204 con el ISE para trae sus propios servicios del dispositivo (BYOD).

Los documentos explican cómo resolver problemas la característica de la integración de las de otras compañías en el ISE y se pueden utilizar como guía para la integración con los otros vendedores y los flujos.

Aviso: Sea por favor consciente que Cisco no es responsable de la configuración o del soporte de los dispositivos de los otros vendedores.

Prerrequisitos

Requisitos

Cisco recomienda que tenga conocimiento sobre estos temas:

• Conocimiento básico de la configuración de Aruba IAP
• El conocimiento básico de BYOD fluye en el ISE
• Conocimiento básico de la configuración del Identity Services Engine (ISE) para la contraseña y la autenticación certificada

Componentes Utilizados

La información que contiene este documento se basa en estas versiones de software:

• Software 6.4.2.3 de Aruba IAP 204
• Cisco ISE, libera 2.0 y posterior

Configurar

Diagrama de la red

Hay dos redes inalámbricas manejadas por Aruba AP. Primer (mgarcarz_byod) se está utilizando para el acceso del 802.1x EAP-PEAP. Después de que el regulador de Aruba de la autenticación satisfactoria deba reorientar al usuario al portal ISE BYOD - supplicant nativo Provisioning el flujo (NSP). Reorientan al usuario, se ejecuta la aplicación auxiliar de la configuración de la red y el certificado es aprovisionado y instalado en el cliente de Windows. El ISE CA interno se utiliza para ese proceso (configuración predeterminada). El ayudante de la configuración de la red es también responsable de la creación del perfil inalámbrico para el segundo SSID manejado por Aruba (mgarcarz_byod_tls) - aquél se utiliza para el 802.1x autenticación EAP-TLS.

Como consecuencia el usuario corporativo puede realizar onboarding del dispositivo personal y conseguir el acceso seguro en la red corporativa.

El siguiente ejemplo se podía modificar fácilmente para diversos tipos de acceso, por ejemplo:

• Autenticación Web central (CWA) con el servicio BYOD
• autenticación del 802.1x con la postura y el cambio de dirección BYOD
• Típicamente para la autenticación EAP-PEAP se utiliza el Active Directory (guardar se utiliza este a los usuarios internos del cortocircuito del artículo ISE)
• Típicamente para el aprovisionamiento SCEP del certificado el servidor externo se está utilizando, el servicio de la inscripción del dispositivo de la red de Microsoft (NDE) para guardar comúnmente este cortocircuito del artículo que se utiliza el ISE interno CA.

Desafíos con el soporte de las de otras compañías

¿Cuáles son los desafíos al usar al invitado ISE fluyen (como BYOD, CWA, el NSP, CPP) con los dispositivos de las de otras compañías?

Sesiones

Los dispositivos de acceso de la red de Cisco (NAD) están utilizando el Cisco-av-pair del radio llamado auditoría-sesión-identificación para informar al servidor de AAA sobre la identificación de la sesión que el valor es utilizado por el ISE para seguir las sesiones y para proporcionar los servicios correctos para cada flujo. Los otros vendedores no soportan los pares Cisco-AV. El ISE tiene que confiar tan en los atributos IETF recibidos en la petición del pedido de acceso y de las estadísticas.

Después de recibir el pedido de acceso el ISE construye el ID de sesión sintetizado de Cisco (del Llamar-Estación-ID, del NAS-puerto, del Nas-ip-address y del secreto compartido). Que el valor tiene localmente una significación solamente (no enviado vía la red). Como consecuencia ha esperado de cada flujo (BYOD, CWA, NSP, CPP) asociar los atributos correctos - así que el ISE puede recalcular el ID de sesión de Cisco y realizar las operaciones de búsqueda para correlacionarlas con la sesión correcta y para continuar el flujo.

El URL reorienta

El ISE está utilizando el Cisco-av-pair del radio llamado URL-reorienta y URL-reorientar-ACL para informar al NAD que el tráfico específico debe ser reorientado.

Los otros vendedores no soportan los pares Cisco-AV. Esos dispositivos se deben configurar tan típicamente con el cambio de dirección estático URL que señala al servicio específico (perfil de la autorización) en el ISE. Una vez que el usuario está iniciando HTTP session esos NAD está reorientando a ese URL y también está asociando los argumentos adicionales (como el IP Address o el MAC address) para permitir el ISE identifica la sesión específica y continúe el flujo.

CoA

El ISE está utilizando el Cisco-av-pair del radio llamado suscriptor: comando, suscriptor: reauthenticate-tipo para indicar qué acciones si la toma NAD para una sesión específica. Los otros vendedores no soportan los pares Cisco-AV. Esos dispositivos están utilizando tan típicamente el CoA RFC (3576 o 5176) y uno de dos mensajes definidos: 

• el pedido de desconexión (llamado también paquete de desconexión) - aquél se utiliza para desconectar la sesión (mismo el ofter para forzar la reconexión)
• empuje coa - aquél se utiliza para cambiar el estatus de la sesión transparente sin la desconexión (por ejemplo sesión de VPN y nuevo ACL aplicados)

El ISE soporta el CoA de Cisco con el Cisco-av-pair y también ambo CoA 3576/5176 RFC.

Solución en el ISE

Para apoyar a los vendedores ISE 2.0 de las de otras compañías introdujo un concepto de perfiles del dispositivo de red que describe cómo el vendedor específico se comporta - cómo las sesiones, URL reorientan y se soporta el CoA.

Los perfiles de la autorización son de tipo específico (perfil del dispositivo de red) y una vez que ocurre la autenticación el comportamiento ISE se deriva de ese perfil. Como consecuencia los dispositivos de los otros vendedores se pueden manejar fácilmente por el ISE. También la configuración en el ISE es flexible y permite ajustar o crear los nuevos perfiles del dispositivo de red.

Este artículo presenta el uso del perfil predeterminado para el dispositivo de Aruba.

Más información sobre la característica:

Perfiles del dispositivo de acceso a la red con el Cisco Identity Services Engine

Cisco ISE

Step1 agregan el regulador inalámbrico de Aruba a los dispositivos de red

Vaya a la administración > a los recursos de red > a los dispositivos de red. Elija el perfil del dispositivo correcto para el vendedor seleccionado, en ese caso: ArubaWireless. Aseegurese configurar el puerto del secreto compartido y CoA.

En caso de que no haya perfil disponible para el vendedor deseado puede ser configurado bajo la administración > los recursos de red > perfiles del dispositivo de red.

Perfil de la autorización de la configuración Step2

De la directiva > de los elementos de la directiva > resulta > la autorización > los perfiles de la autorización eligen el mismo perfil del dispositivo de red que en el paso 1: ArubaWireless. El perfil de siguiente fue configurado:

• Aruba-reoriente-BYOD con el portal BYOD como se muestra abajo:

Parte de que falta la configuración del cambio de dirección de la red, donde el link estático al perfil de la autorización se genera. Mientras que Aruba no soporta el cambio de dirección dinámico al portal del invitado, hay un link asignado a cada perfil de la autorización, que entonces se configura en Aruba.

Reglas de la autorización de la configuración Step3

Bajo reglas de la directiva > de la autorización fueron configuradas de la manera siguiente:

Primero, el usuario conecta con SSID “mgracarz_aruba” y el perfil de la autorización de las devoluciones ISE “Aruba-reorienta-BYOD” que reorientan al cliente para omitir el portal BYOD. Después de completar el cliente de proceso BYOD conecta con el EAP-TLS y el acceso total a la red se concede.

Aruba AP

Configuración porta prisionera Step1

Para configurar el portal prisionero en Aruba 204, navegue a la Seguridad > porta prisionero externo y agregue el nuevo. Lo que sigue es necesario para la configuración adecuada:

• Tipo: Autenticación de RADIUS,
• IP o nombre de host: Servidor ISE,
• URL: conecte que se crea en el ISE bajo configuración del perfil de la autorización; es específica al perfil determinado de la autorización y puede ser encontrada debajo de la configuración del cambio de dirección de la red,

• Puerto: el número del puerto en el cual seleccionó el portal se recibe en el ISE (por abandono: 8443).

Configuración de servidor de RADIUS Step2

Security > Authentication de los servidores aseegurese que el puerto CoA es lo mismo según lo configurado en el ISE. (Por abandono en Aruba 204 se fija a 5999, sin embargo que no es obediente con el RFC 5176 y también no está trabajando con el ISE).

Configuración Step3 SSID

• Ficha de seguridad:

• Lengueta del acceso: elija la regla de acceso Basada en red para configurar el portal prisionero en el SSID:

Utilice el portal prisionero que fue configurado en Step1. Usted puede agregarlo usando el “nuevo” botón, eligiendo el tipo de la regla: Tipo porta y del chapoteo prisionero de la página como externo.

Además permita todo el tráfico al servidor ISE (puertos TCP en el rango 1-20000), mientras que regla configurada por abandono en Aruba: Permita ningunos a todos los destinos parece no trabajar correctamente.

Verificación

Conexión Step1 al mgarcarz_aruba SSID usando EAP-PEAP

El primer inicio ISE de la autenticación aparece. Se ha vuelto la directiva de la autenticación predeterminada se ha utilizado, Aruba-reorienta-BYOD el perfil de la autorización:

El ISE está volviendo el mensaje del access-accept del radio con el éxito EAP. Note por favor que no se está volviendo ningunos atributos adicionales (ningún cisco av-pair URL-reorienta o URL-reorientar-ACL)

Aruba señala que la sesión está establecida (identidad EAP-PEAP es Cisco) y el papel seleccionado es mgarcarz_aruba:

Ese papel es responsable del cambio de dirección al ISE (funciones porta prisioneras en Aruba).  

En Aruba CLI es posible confirmar cuál es el estatus 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 marcar la identificación 138 ACL 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 ... >

Ese coincidencias con qué fue configurada en el GUI para ese papel:

Cambio de dirección del tráfico del buscador Web Step2 para BYOD

Una vez que ocurre el buscador Web abierto del usuario y teclea cualquier cambio de dirección del direccionamiento:

Mirando a las capturas de paquetes ha confirmado que Aruba es destino del spoofing (5.5.5.5) y redirección de HTTP de vuelta al ISE. Note por favor que es el mismo URL estático como está configurado en el ISE y copiado al portal prisionero en Aruba - pero los argumentos múltiples se están agregando además:

• 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 esos argumentos el ISE puede reconstruir el ID de sesión de Cisco, descubrir la sesión correspondiente sobre el ISE y continuar con el flujo BYOD (o cualquier otro configurado). Para el audit_session_id de los dispositivos de Cisco sería utilizado normalmente pero eso no es soportada por los otros vendedores.

Para confirmarlo que del ISE hace el debug de es posible ver la generación de auditoría-sesión-identificación valorar (que nunca se envíe sobre 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 entonces correlación de eso después del registro del dispositivo en la 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

En el cliente de los pedidos posteriores es la página reorientada 3 BYOD donde descargan y se ejecutan al ayudante de la configuración de la red

Ejecución del ayudante de la configuración de la red Step3

El NSA tiene la misma tarea que el buscador Web. Primero necesita detectar cuál es el IP Address del ISE. Eso se alcanza vía la redirección de HTTP. Pero desde el usuario de este tiempo no tiene una posibilidad para teclear el IP Address (como en el buscador Web) que ese tráfico se genera automáticamente. Se está utilizando el default gateway (también enroll.cisco.com se podría utilizar):

Respuesta él exactamente lo mismo que para el buscador Web. Esta manera NSA puede conectar con el ISE, consigue el perfil del xml con la configuración, genera la petición SCEP, la envía al ISE, consigue el certificado firmado (firmado por ISE CA interno), configura el perfil inalámbrico y finalmente conecta con el SSID configurado. Registros correctos del cliente (en Windows esté en %temp%/spwProfile.log). Algunas salidas omitidas para mayor 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

Esos registros son exactamente lo mismo que para el proceso BYOD con los dispositivos de Cisco.

Note por favor que CoA del radio no está requerido aquí. Es la aplicación (NSA) que fuerza la reconexión a un SSID nuevamente configurado.

En ese usuario de la etapa puede ver que el sistema está intentando asociarse a un SSID final. Si tener más entonces un Certificado de usuario selecciona el correcto:

Después de la conexión satisfactoria el NSA señala eso:

Eso se puede confirmar también en el ISE - los segundos golpes del registro autenticación EAP-TLS, correspondiendo con todas las condiciones para Basic_Authenticated_Access (EAP-TLS, empleado, y verdad registrado BYOD):

También la opinión de la identidad del punto final puede confirmar que el punto final tiene indicador de BYODRegistered fijado para verdad:

En el nuevo perfil inalámbrico del PC de Windows se ha creado automáticamente según lo preferido (y configurado para el EAP-TLS):

En esa etapa Aruba confirma al usuario está conectado con el SSID final.

El papel que se crea automáticamente y nombró lo mismo que la red está proporcionando al acceso a la red completo:

Otros flujos y soporte CoA

CWA con el CoA

Mientras que en BYOD fluyen no es mensajes CoA, CWA fluye con el invitado registrado uno mismo que el portal se demuestra abajo:

Las reglas de siguiente de la autorización fueron configuradas:

El usuario conecta con el SSID usando la autenticación MAB y una vez intentando conectar con un poco de página web, el cambio de dirección con el portal registrado uno mismo del invitado sucede, donde el invitado puede crear la nueva cuenta o utilizar el existencia:

Después de que el invitado esté conectado con éxito el mensaje CoA es envía del ISE al dispositivo de red para cambiar el estado de la autorización.

Puede ser verificado bajo las operaciones > Authenitcations:

 Mensaje CoA en los debugs 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 Diconnect-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

 Capturas de paquetes con la Diconnect-petición CoA (40) y Diconnect-ACK (41):

Note por favor que el CoA RFC se ha utilizado para la autenticación relacionada con el perfil del dispositivo Aruba (configuraciones predeterminadas). Para la autenticación relacionada con el dispositivo de Cisco habría sido tipo CoA de Cisco reauthenticate.

Troubleshooting

Portal prisionero de Aruba con el IP Address en vez del FQDN

Si el portal prisionero en Aruba se configura con la dirección IP en vez del FQDN del ayudante de la configuración de la red ISE PSN falla:

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

La razón de ese es validación de certificado estricta al conectar con el ISE. Cuando usar el IP Address para conectar con el ISE (como resultado del URL del cambio de dirección con el IP Address en vez del FQDN) y siendo presentado con el certificado ISE con el asunto = la validación FQDN falla.

Note por favor que el buscador Web continúa con el portal BYOD (con la advertencia que necesita ser aprobada por el usuario).

Política de acceso incorrecta porta prisionera de Aruba

Por abandono la política de acceso de Aruba configurada con el portal prisionero permite los puertos 80, 443 y 8080 tcp.

El ayudante de la configuración de la red no debe poder conectar con el puerto 8905 tcp para conseguir el perfil del xml del ISE. El error siguiente es esté señalado:

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 del puerto CoA de Aruba

Por abandono Aruba proporciona el número del puerto para el puerto 5999 CoA del grupo aéreo CoA. Desafortunadamente Aruba 204 no respondía a tales peticiones.

Captura de paquetes:

Usando el puerto 3799 CoA según lo descrito en el RFC 5176 sea la mejor opción aquí.

Cambio de dirección en algunos dispositivos de Aruba

En Aruba 3600 con v6.3 fue notado que el cambio de dirección está trabajando levemente diferente entonces en otros reguladores. La captura de paquetes y la explicación pueden ser encontradas abajo:

packet 1: PC is sending GET request to google.compacket 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'>\npacket 3: PC is going to link with  Aruba attribute returned in packet 2:http://www.google.com/&arubalp=6b0512fc-f699-45c6-b5cb-e62b3260e5packet 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

Referencias

• Guía del administrador del Cisco Identity Services Engine, versión 2.0
• Perfiles del dispositivo de acceso a la red con el Cisco Identity Services Engine
• Soporte Técnico y Documentación - Cisco Systems