Configure la integración de las de otras compañías ISE 2.0 con la Tecnología inalámbrica de Aruba
Contenido
Introducción
Este documento describe cómo resolver problemas la característica de la integración de las de otras compañías en el Cisco Identity Services Engine (ISE). Puede ser utilizado como guía para la integración con los otros vendedores y los flujos. La versión 2.0 ISE soporta la integración de las de otras compañías. Éste es un ejemplo de configuración que presenta cómo integrar la red inalámbrica manejada por Aruba IAP 204 con el ISE para los servicios de Bring Your Own Device (BYOD).
Prerrequisitos
Requisitos
Cisco recomienda que tenga conocimiento sobre estos temas:
- Configuración de Aruba IAP
- BYOD fluye en el ISE
- Configuración 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
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). 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 manejadas por Aruba AP. Primer (mgarcarz_byod) se utiliza para el acceso Protocolo-protegido autenticación ampliable del 802.1x EAP (EAP-PEAP). Después de una autenticación satisfactoria, el regulador de Aruba debe 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 (NSA) 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 NSA es también responsable de la creación del perfil inalámbrico para el identificador del conjunto del segundo servicio (SSID) manejado por Aruba (mgarcarz_byod_tls) - aquél se utiliza para la autenticación de la Seguridad de la capa del Protocolo-transporte de la autenticación ampliable del 802.1x (EAP-TLS).
Como consecuencia, el usuario corporativo puede realizar onboarding del dispositivo personal y conseguir el acceso seguro en la red corporativa.
Este ejemplo se puede 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, porque Active Directory de la autenticación EAP-PEAP se utiliza (guardar se utiliza este a los usuarios internos del cortocircuito del artículo ISE)
- Típicamente, porque aprovisionamiento del certificado que el servidor externo del protocolo simple certificate enrollment (SCEP) se utiliza, el servicio de la inscripción del dispositivo de la red de Microsoft (NDE) para guardar comúnmente este cortocircuito del artículo, ISE interno CA se utiliza.
Desafíos con el soporte de las de otras compañías
Cuáles son los desafíos cuando usted utiliza los flujos del invitado ISE (como BYOD, CWA, NSP, portal de disposición del cliente (CPP)) ¿con los dispositivos de las de otras compañías?
Sesiones
Los dispositivos de acceso de la red de Cisco (NAD) utilizan el Cisco-av-pair del radio llamado auditoría-sesión-identificación para informar al servidor del Authentication, Authorization, and Accounting (AAA) sobre el ID de sesión. Ese valor es utilizado por el ISE para seguir las sesiones y proporcionar los servicios correctos para cada flujo. Los otros vendedores no soportan los pares Cisco-AV. Así pues, el ISE tiene que confiar en los atributos IETF recibidos en la petición del pedido de acceso y de las estadísticas.
Después de que usted reciba 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 una importancia local 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 continuar el flujo.
El URL reorienta
El Cisco-av-pair del radio de las aplicaciones ISE 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. Tan típicamente, esos dispositivos se deben configurar 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 los iniciados del usuario HTTP session, esos NAD reorientan al URL y también asocie los argumentos adicionales (como la dirección IP o la dirección MAC) para permitir el ISE identifican la sesión específica y continúan el flujo.
CoA
El ISE utiliza el Cisco-av-pair del radio llamado suscriptor: comando, suscriptor: reauthenticate-tipo para indicar deben qué acciones toma NAD para una sesión específica. Los otros vendedores no soportan los pares Cisco-AV. Tan típicamente, esos dispositivos utilizan el CoA RFC (3576 o 5176) y uno de los dos mensajes definidos:
- el pedido de desconexión (llamado también paquete de desconexión) - aquél se utiliza para desconectar la sesión (muy a menudo 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 de las de otras compañías, el ISE 2.0 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
Paso 1. Agregue el regulador inalámbrico de Aruba a los dispositivos de red
Navegue 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 este caso: ArubaWireless. Asegure para configurar el puerto del secreto compartido y CoA tal y como se muestra en de las imágenes.
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.
Paso 2. Perfil de la autorización de la configuración
Navegue a la directiva > a los elementos de la directiva > a los resultados > a la autorización > a los perfiles de la autorización eligen el mismo perfil del dispositivo de red que en el paso 1. ArubaWireless. El perfil configurado es Aruba-reorienta-BYOD con BYOD porta y tal y como se muestra en de las imágenes.
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 y tal y como se muestra en de la imagen.
Paso 3. Reglas de la autorización de la configuración
Navegue a las reglas de la directiva > de la autorización y la configuración está tal y como se muestra en de la imagen.
Primero, el usuario conecta con el mgracarz_aruba SSID y el perfil de la autorización de las devoluciones ISE Aruba-reorienta-BYOD que reorienta al cliente para omitir el portal BYOD. Después de la realización del proceso BYOD, el cliente conecta con el EAP-TLS y el acceso total a la red se concede.
Aruba AP
Paso 1. Configuración porta prisionera
Para configurar el portal prisionero en Aruba 204, navegue a la Seguridad > porta prisionero externo y agregue el nuevo. Ingrese esta información para la configuración adecuada y tal y como se muestra en de la imagen.
- 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 aquí bajo 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) tal y como se muestra en de la imagen.
Paso 2. Configuración de servidor de RADIUS
Navegue Security > Authentication a los servidores se aseguran de que el puerto CoA es lo mismo según lo configurado en el ISE tal y como se muestra en de la imagen. (por abandono en Aruba 204 se fija a 5999, sin embargo, que no es obediente con el RFC 5176 y también no trabaja con el ISE).
Paso 3. Configuración SSID
- La ficha de seguridad está tal y como se muestra en de la imagen.
- Lengueta del acceso: seleccione la regla de acceso Basada en red para configurar el portal prisionero en el SSID.
Utilice el portal prisionero que fue configurado en el tecleo del paso 1. nuevo, eligen el tipo de la regla: Portal prisionero, tipo de la página del chapoteo: Externo tal y como se muestra en de la imagen.
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 tal y como se muestra en de la imagen.
Verificación
Utilize esta sección para confirmar que su configuración funcione correctamente.
Paso 1. Conexión al mgarcarz_aruba SSID con EAP-PEAP
El primer inicio ISE de la autenticación aparece. La directiva de la autenticación predeterminada se ha utilizado, Aruba-reorienta-BYOD el perfil de la autorización se ha vuelto tal y como se muestra en de la imagen.
Mensaje del access-accept del radio de las devoluciones ISE con el éxito EAP. Observe que no se vuelve ningunos atributos adicionales (ningún cisco av-pair URL-reorienta o URL-reorientar-ACL) tal y como se muestra en de la imagen.
Aruba señala que la sesión está establecida (identidad EAP-PEAP es Cisco) y el papel seleccionado es mgarcarz_aruba tal y como se muestra en de la imagen.
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 ACL ID 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 ... >
Ese coincidencias con qué fue configurada en el GUI para ese papel tal y como se muestra en de la imagen.
Paso 2. Cambio de dirección del tráfico del buscador Web para BYOD
Una vez que el usuario abre al buscador Web y teclea cualquier direccionamiento, el cambio de dirección ocurre tal y como se muestra en de la imagen.
Mirando a las capturas de paquetes, se confirma que las parodias de Aruba el destino (5.5.5.5) y vuelve la redirección de HTTP al ISE.
Observe 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 agregan además como sigue y tal y como se muestra en de 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, 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 los dispositivos de Cisco, el audit_session_id sería utilizado normalmente pero eso no es soportada por los otros vendedores.
Para confirmar que de los debugs ISE, 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 los pedidos posteriores, reorientan al cliente a la página 3. BYOD donde se descarga y se ejecuta el NSA.
Paso 3. Ejecución del ayudante de la configuración de la red
El NSA tiene la misma tarea que el buscador Web. Primero, necesita detectar cuál es la dirección IP del ISE. Eso se alcanza vía la redirección de HTTP. Pero desde este tiempo el usuario no tiene una posibilidad para teclear el IP address (como en el buscador Web), ese tráfico se genera automáticamente. El default gateway se utiliza (también enroll.cisco.com puede ser utilizado) tal y como se muestra en de la imagen.
La respuesta es 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. Recoja los registros del cliente (en Windows esté en %temp%/spwProfile.log). Algunas salidas se omiten 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.
En esa etapa, el usuario puede ver que el sistema intenta asociarse a un SSID final. Si usted tiene más entonces un Certificado de usuario, usted debe seleccionar el correcto tal y como se muestra en de la imagen.
Después de una conexión satisfactoria, los informes NSA están tal y como se muestra en de la imagen.
Eso se puede confirmar en el ISE - los segundos golpes del registro autenticación EAP-TLS, que hace juego todas las condiciones para Basic_Authenticated_Access (EAP-TLS, empleado, y verdad registrado BYOD) tal y como se muestra en de la imagen.
También, la opinión de la identidad del punto final puede confirmar que el punto final tiene indicador registrado BYOD fijado para verdad tal y como se muestra en de la imagen.
En el PC de Windows, el nuevo perfil inalámbrico se ha creado automáticamente según lo preferido (y configurado para el EAP-TLS) y tal y como se muestra en de la imagen.
En esa etapa, Aruba confirma que el usuario está conectado con el SSID final tal y como se muestra en de la imagen.
El papel que se crea automáticamente y nombró lo mismo que la red proporciona el acceso a la red completo tal y como se muestra en de la imagen.
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 aquí:
Las reglas de la autorización configuradas están tal y como se muestra en de la imagen.
El usuario conecta con el SSID con la autenticación MAB y una vez cuando intenta conectar con un poco de página web, cambio de dirección con el invitado registrado uno mismo que sucede el portal, donde el invitado puede crear la nueva cuenta o utilizar la corriente una tal y como se muestra en de la imagen.
Después de que el invitado esté conectado con éxito, el mensaje CoA se envía del ISE al dispositivo de red para cambiar el estado de la autorización tal y como se muestra en de la imagen.
Puede ser verificado bajo las operaciones > Authenitcations y tal y como se muestra en de la imagen.
El mensaje CoA en el ISE hace el debug de:
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 Desconexión-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 la Diconnect-petición CoA (40) y Diconnect-ACK (41) están tal y como se muestra en de la imagen.
Troubleshooting
Esta sección brinda información que puede utilizar para la solución de problemas en su configuración.
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 ISE, el PSN NSA falla:
Warning - [HTTPConnection] Abort the HTTP connection due to invalid certificate
CN
La razón de ese es validación de certificado estricta cuando usted conecta con el ISE. Cuando usted utiliza la dirección IP para conectar con el ISE (como resultado del cambio de dirección URL con la dirección IP en vez del FQDN) y se presenta con el certificado ISE con el asunto = la validación FQDN falla.
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 NSA no puede conectar con el puerto 8905 tcp para conseguir el perfil del xml del ISE. Este error 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 respondió a tales peticiones tal y como se muestra en de la imagen.
La captura de paquetes está tal y como se muestra en de la imagen.
La mejor opción a utilizar aquí puede ser el puerto 3977 CoA según lo descrito en el RFC 5176.
Cambio de dirección en algunos dispositivos de Aruba
En Aruba 3600 con v6.3 se nota que los trabajos del cambio de dirección levemente diferentes entonces en otros reguladores. La captura de paquetes y la explicación pueden ser encontradas aquí y tal y como se muestra en de 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)