Autenticación Web central en el ejemplo de configuración del WLC y ISE

Introducción

Este documento describe un ejemplo de configuración que se utilice para completar la autenticación Web central (CWA) en el regulador del Wireless LAN (WLC).

Prerrequisitos

Requisitos

No hay requisitos específicos para este documento.

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

• Software Release 2.0 del Cisco Identity Services Engine
  
  
• Versión de software WLC de Cisco 8.2.141.0

Configurar

El primer método de autenticación Web es autenticación Web local. En este caso, el WLC reorienta el tráfico HTTP a un interno o a un servidor externo donde se indica al usuario que autentique. El WLC después trae las credenciales (devueltas vía una petición get HTTP en el caso de un servidor externo) y hace una autenticación de RADIUS. En el caso de un Usuario invitado, un servidor externo (tal como servidor del Identity Services Engine (ISE) o del invitado del NAC (NG)) se requiere porque el portal proporciona las características tales como registro y uno mismo-aprovisionamiento del dispositivo. El flujo incluye estos pasos:

1. Los socios del usuario al Service Set Identifier (SSID) de la autenticación Web.
   
   
2. El usuario abre al navegador.
   
   
3. El WLC reorienta al portal del invitado (tal como ISE o NG) tan pronto como se ingrese un URL.
   
   
4. El usuario autentica en el portal.
   
   
5. El portal del invitado reorienta de nuevo al WLC con las credenciales ingresadas.
   
   
6. El WLC autentica al Usuario invitado vía el RADIUS.
   
   
7. El WLC reorienta de nuevo al URL original.

Este flujo incluye varios cambios de dirección. El nuevo acercamiento es utilizar CWA. Este método trabaja con ISE (versiones más adelante de 1.1) y el WLC (versiones más adelante de 7.2). El flujo incluye estos pasos:

1. El usuario se asocia a la autenticación Web SSID, que es de hecho open+macfiltering y ninguna Seguridad de la capa 3.
   
   
2. El usuario abre al navegador.
   
   
3. El WLC reorienta al portal del invitado.
   
   
4. El usuario autentica en el portal.
   
   
5. El ISE envía un cambio RADIUS de la autorización (CoA - el puerto 1700 UDP) de indicar al regulador que el usuario es válido, y avanza eventual los atributos de RADIUS tales como la lista de control de acceso (ACL).
   
   
6. Se indica al usuario que revise el URL original.

La configuración usada es:

Configuración del WLC

La configuración del WLC es bastante directa. Un truco se utiliza (lo mismo que en el Switches) para obtener la autenticación dinámica URL del ISE (puesto que utiliza el cambio de la autorización (CoA), una sesión debe ser creada y el ID de sesión es parte del URL). El SSID se configura para utilizar la filtración MAC. El ISE se configura para volver un access-accept incluso si la dirección MAC no se encuentra, de modo que envíe el cambio de dirección URL para todos los usuarios. 

Además de esto, el Network Admission Control (NAC) ISE y la invalidación del Authentication, Authorization, and Accounting (AAA) deben ser habilitados. El NAC ISE permite que el ISE envíe una petición CoA que indique que ahora autentican al usuario y pueda acceder la red. También se utiliza para la evaluación de la postura, en este caso el ISE cambia el perfil del usuario basado en el resultado de la postura.

Asegúrese de que el servidor de RADIUS tenga “soporte para el CoA” habilitado, que está por abandono.

El último paso es crear una reorientación ACL. Este ACL se refiere al access-accept del ISE y define qué tráfico debe ser reorientado (negado por el ACL) y qué tráfico no debe ser reorientado (permitido por el ACL). Aquí usted apenas previene del tráfico del cambio de dirección hacia el ISE. Usted puede ser que quiera ser más específico y prevenir solamente el tráfico a/desde el ISE en el puerto 8443 (portal del invitado), pero todavía reorienta si un usuario intenta acceder el ISE en el puerto 80/443.

Nota: Las versiones anteriores del software WLC tales como 7.2 o 7.3 no le requirieron especificar el Domain Name System (DNS), pero las versiones del código más reciente le requieren permitir el tráfico DNS en ese reorientan el ACL.

La configuración es completa ahora en el WLC.

Configuración ISE

Cree el perfil de la autorización

En el ISE, el perfil de la autorización debe ser creado. Entonces, se configuran las directivas de la autenticación y autorización. El WLC se debe configurar ya como dispositivo de red.

En el perfil de la autorización, ingrese el nombre del ACL creado anterior en el WLC.

1. Haga clic la directiva, y después haga clic los elementos de la directiva.
   
   
2. Haga clic los resultados.
   
   
3. Amplíe la autorización, y después haga clic el perfil de la autorización.
   
   
4. Haga clic el botón Add para crear un nuevo perfil de la autorización para el webauth central.
   
   
5. En el campo de nombre, ingrese un nombre para el perfil. Este ejemplo utiliza WLC_CWA.
   
   
6. Elija ACCESS_ACCEPT de la lista desplegable del tipo de acceso.
   
   
7. Marque la casilla de verificación del cambio de dirección de la red, y elija el auth centralizado de la red de la lista desplegable.
   
   
8. En el campo ACL, ingrese el nombre del ACL en el Switch que define el tráfico que se reorientará. Este ejemplo utiliza el cwa_redirect.
   
   
9. En el campo de valor, uno puede elegir el portal porta o Uno mismo-registrado patrocinado del invitado del invitado de la lista desplegable. En el portal patrocinado del invitado, los patrocinadores crean las cuentas de invitado, y los invitados acceden la red usando su nombre de usuario y contraseña asignado mientras que en el portal del invitado del uno mismo-registro, se permite a los invitados crear sus propias cuentas y acceder la red usando su nombre de usuario y contraseña asignado. Este ejemplo utiliza el portal patrocinado del invitado.

Cree una regla de la autenticación

Asegúrese de que el ISE valide todas las autenticaciones de MAC del WLC y aseegurese lo perseguirá la autenticación incluso si no encuentran al usuario.

Bajo menú de la directiva, haga clic la autenticación.

La imagen siguiente muestra un ejemplo de cómo configurar la regla de la política de autenticación. En este ejemplo, se configura una regla que acciona cuando se detecta el MAB.

1. Ingrese un nombre para su regla de la autenticación. Este ejemplo utiliza el MAB, que existe ya por abandono en la versión 1.2 ISE.
   
   
2. Seleccione (+) el icono más en si campo de la condición.
   
   
3. Elija la condición compuesta, y después elija Wired_MAB O Wireless_MAB.
   
   
4. Haga clic la flecha localizada al lado de y… para ampliar la regla más lejos.
   
   
5. Haga clic + icono en el campo de fuente de la identidad, y elija los puntos finales internos.
   
   
6. Elija continúan del si lista desplegable no encontrada del usuario.

Nota: Ahora hay una regla de la autenticación MAB creada en el ISE por abandono.

Cree una directiva de la autorización

Configure la directiva de la autorización. Un punto importante a entender es que hay dos autenticaciones/autorizaciones:

• El primer es cuando el usuario se asocia al SSID (“CWA” en este caso) y se vuelve el perfil CWA.
  En esta Airespace-WLAN-identificación del ejemplo se utiliza como condición. Cuando un cliente conecta con el SSID, la petición del acceso a RADIUS al ISE contiene el atributo Airespace-RED INALÁMBRICA (WLAN)-ID. Este atributo se utiliza para tomar las decisiones de políticas en el ISE. Tan cuando un cliente desconocido conecta con SSID CWA, el ISE envía un acceess-validar con reorienta URL (portal web) y el ACL. El uso de la regla Airespace-WLAN-identificación se asegura de que la página porta esté presentada a los usuarios que conectan solamente con el CWA SSID. 

• El segundo es cuando el usuario autentica en el portal web. Éste hace juego la regla predeterminada (usuarios internos) en esta configuración (puede ser configurado para cumplir sus requisitos). Es importante que la pieza de la autorización no hace juego el perfil CWA otra vez. Si no, habrá un loop del cambio de dirección. El acceso a la red: El atributo del flujo del invitado de los iguales de UseCase se puede utilizar para hacer juego esta segunda autenticación. El resultado parece esto:

Complete estos pasos para crear las reglas de la autorización tal y como se muestra en de las imágenes anteriores:

1. Cree una nueva regla, y ingrese un nombre. Este ejemplo utiliza el cambio de dirección del invitado.
   
   
2. Haga clic (+) el icono más en el campo de la condición, y elija crear una nueva condición.
   
   
3. Amplíe la lista desplegable de la expresión.
   
   
4. Elija el Airespace, y amplíelo.
   
   
5. Haga clic Airespace-Wlan-Id--[1], y elija al operador de los iguales.
   
   
6. Ingrese el ID DE WLAN en el campo derecho, en este ejemplo 1. 
   
   
7. En la página general de la autorización, elija WLC_CWA (perfil de la autorización) en el campo a la derecha de la palabra entonces.
   
   Este paso permite que el ISE continúe aunque no saben cuando está conectado con CWA SSID y lo presenta al usuario (o la dirección MAC) con el portal del login.
   
   
8. Haga clic las acciones abotonan situado en el final de la regla del cambio de dirección del invitado, y eligen insertar una nueva regla antes de ella.
   
   

   Nota: Es muy importante que esta nueva regla viene antes de la regla del cambio de dirección del invitado.

   
   
   
9. Ingrese un nombre para la nueva regla. Este ejemplo utiliza el auth del portal del invitado.
   
   
10. En el campo de la condición, haga clic (+) el icono más, y elija crear una nueva condición.
    
    
11. Elija el acceso a la red, y haga clic UseCase.
    
    
12. Elija los iguales como el operador.
    
    
13. Elija GuestFlow como el operando correcto.
    
    
14. En la página de la autorización, haga clic (+) el icono más (situado al lado de entonces) para elegir un resultado para su regla.
    
    Usted puede elegir una opción del acceso del permiso o crear un perfil de encargo para volver el VLA N o los atributos ese usted tiene gusto. Observe que encima de si GuestFlow, usted puede agregar más condiciones para volver los diversos perfiles del authz basados en el grupo de usuarios. Como se menciona en el paso 7, las coincidencias porta de esta del invitado regla del auth sobre la segunda autenticación de la dirección MAC iniciada después del login porta acertado y después del ISE enviaron un CoA para reauthenticate al cliente. La diferencia con esta segunda autenticación es que, en vez de venir al ISE con simplemente su dirección MAC, el ISE recuerda el nombre de usuario dado en el portal. Usted puede hacer que esta regla de la autorización tiene en cuenta las credenciales ingresadas algunos milisegundos antes en el portal del invitado.

Nota: En un entorno multi del regulador el ID DE WLAN debe ser lo mismo a través del WLCs. Si uno no quiere utilizar el atributo Airespace-WLAN-identificación como condición, después es mejor hacer juego las peticiones de Wireless_MAB (condición incorporada). 

Habilite la renovación IP (opcional)

Si usted asigna un VLA N, el último paso está para PC del cliente para renovar su dirección IP. Este paso es alcanzado por el portal del invitado para los clientes de Windows. Si usted no fijó un VLA N para la 2da regla AUTH anterior, usted puede saltar este paso.

Si usted asignó un VLA N, complete estos pasos para habilitar la renovación IP:

1. Haga clic el acceso de invitado, y después haga clic la configuración.
   
   
2. Haga clic los portales del invitado.
   
   
3. Haga clic el portal patrocinado del invitado (usado en este ejemplo), y después amplíe las paginaciones de la versión del DHCP del VLA N.
   
   
4. Haga clic la casilla de verificación de la versión del DHCP del VLA N.
   
   

   Nota: Esta opción trabaja solamente para los clientes de Windows.

Escenario Ancla-no nativo

Esta configuración puede también trabajar con la característica del auto-ancla del WLCs. La única captura es ésa puesto que este método de autenticación Web es la capa 2, usted tiene que ser consciente que será el WLC no nativo que hace todo el trabajo RADIUS. Solamente el WLC no nativo entra en contacto el ISE, y el cambio de dirección ACL debe estar presente también en el WLC no nativo.

Apenas como en otros escenarios, el WLC no nativo muestra rápidamente al cliente para estar en el estado de FUNCIONAMIENTO, que no es totalmente verdad. Significa simplemente que el tráfico está enviado al ancla de allí. El estado de cliente real se puede considerar en el ancla donde debe visualizar CENTRAL_WEBAUTH_REQD.

Aquí está el flujo en una configuración ancla-no nativa:

1. El cliente conecta con el SSID en el WLC no nativo. El WLC no nativo entra en contacto el servidor ISE para el MAB. El ISE envía el access-accept con la reorientación URL y reorienta el ACL al no nativo.
2. Ahora aseguran al WLC del ancla donde consigue una dirección IP y se ponen al cliente en CENTRAL_WEBAUTH_REQD.
3. Cuando el cliente intenta acceder un sitio web, el WLC del ancla reorienta al cliente a la página porta ISE. Presentan el cliente con la página de registro.
4. Después de la registración satisfactoria, el ISE envía un CoA al WLC no nativo.
5. El WLC no nativo entra en contacto el WLC del ancla para dejarlo saber para poner al cliente en el estado de FUNCIONAMIENTO.
6. Todo el tráfico del cliente se remite de no nativo para asegurar, y sale del WLC del ancla.

Los puertos de firewall que se requieren para permitir la comunicación entre el WLC y el ISE son:

• UDP:1645, 1812 (autenticación de RADIUS)
• UDP:1646, 1813 (estadísticas RADIUS)
• UDP:1700 (CoA RADIUS)
• Invitado TCP:8443 porta o 8905 si usted tiene Posturing. 

Nota: La configuración ancla-no nativa con la autenticación Web central (CWA) trabaja solamente en las versiones 7.3 o más adelante.

Nota: Debido al Id. de bug Cisco CSCuo56780 (incluso en las versiones que incluyen los arreglos), usted no puede ejecutar las estadísticas en el ancla y no nativo porque causa el perfilado a vencer inexacto a una falta potencial del atascamiento IP-a-MAC. También crea muchos problemas con el ID de sesión para los portales del invitado. Si usted desea de configurar las estadísticas, después configurelas en el regulador no nativo.

Verificación

Utilize esta sección para confirmar que su configuración funcione correctamente.

1. Una vez que asocian al usuario al SSID, el WLC entra en contacto el ISE (mientras que se configura la filtración MAC). El ISE se ha configurado para volver el acceso valida con reorienta el URL y el ACL. Ésta es la primera autenticación.

   Los detalles del cliente en el WLC muestran que el cambio de dirección URL y ACL es aplicado.

   

   En el cliente del WLC y el AAA todo el debug, usted puede ver el acceso validar con la reorientación URL y ACL enviados del ISE.

   *radiusTransportThread: 5c:c5:d4:b1:09:95 Access-Accept received from RADIUS server 10.48.39.161
   *radiusTransportThread: AVP[04] Cisco / Url-Redirect-Acl.................cwa_redirect (12 bytes)
   *radiusTransportThread: AVP[05] Cisco / Url-Redirect.....................DATA (177 bytes)
   
   *apfReceiveTask: 5c:c5:d4:b1:09:95 Redirect URL received for client from RADIUS.
    Client will be moved to WebAuth_Reqd state to facilitate redirection. Skip web-auth Flag = 0
   *apfReceiveTask: 5c:c5:d4:b1:09:95 AAA Override Url-Redirect-Acl 'cwa_redirect' 

   La misma cosa se puede también verificar en el ISE. Elija los livelogs de las operaciones > del radio. Haga clic el detalle para ese MAC.

   Usted puede ver que para la primera autenticación (MAC que filtra) el ISE vuelve el perfil WLC_CWA de AuthZ mientras que golpea la regla MAB de la autenticación y el cambio de dirección del invitado de la directiva del authz. 

   

2. En este momento el cliente consigue una dirección IP. Ahora el cliente está en el estado CENTRAL_WEB_AUTH. Cuando cualquier direccionamiento se abre en el cliente, reorientan al navegador al ISE. Asegúrese de que el DNS esté configurado correctamente.

   

3. Una vez que se ingresan las credenciales correctas, se concede el acceso a la red. Ésta es la segunda autenticación.

   

   Cuando se ingresan las credenciales, el ISE autentica al cliente y envía el CoA. 

   

   

   En el WLC esto se puede ver en el AAA todos los debugs.

   *radiusCoASupportTransportThread: audit session ID recieved in CoA = 0a30279c0000003b58887c51 
   *radiusCoASupportTransportThread: Received a 'CoA-Request' from 10.48.39.161
   
   *radiusCoASupportTransportThread: CoA - Received IP Address : 10.48.39.156
   *radiusCoASupportTransportThread: 5c:c5:d4:b1:09:95 Calling-Station-Id ---> 5c:c5:d4:b1:09:95
   *radiusCoASupportTransportThread: Handling a valid 'CoA-Request' regarding station 5c:c5:d4:b1:09:95
   *radiusCoASupportTransportThread: 5c:c5:d4:b1:09:95 Reauthenticating station 5c:c5:d4:b1:09:95
   *radiusCoASupportTransportThread: Sent a 'CoA-Ack' to 10.48.39.161 

4. Después de esto el cliente reauthenticated y acceso concedido a la red. 

   

5. En el regulador, el estado del Administrador de directivas y los cambios de estado del NAC RADIUS de CENTRAL_WEB_AUTH A EJECUTARSE.

   Nota: En la versión 7.2 o anterior, el estado CENTRAL_WEB_AUTH fue llamado POSTURE_REQD.

Observe que el tipo de CoA volvió por el ISE desarrollado a través de las versiones. El ISE 2.0 solicitará el WLC volver a efectuar la autenticación bastante que desconecta llano al cliente.

Ejemplo de la petición CoA ISE 2.0:

El WLC después no enviará una trama de la desasociación al cliente y ejecutará una autenticación de RADIUS otra vez y aplicará el nuevo resultado transparente al cliente.

Sin embargo, las cosas son todavía diferentes si un PSK es funcionando. Desde 8.3, el WLC soporta la determinación de una clave previamente compartida WPA en un CWA SSID. En ese tipo de situación, tras la recepción del mismo CoA del ISE que arriba, el WLC tendrá que accionar un nuevo intercambio de claves WPA otra vez. Por lo tanto en caso del PSK, el WLC tendrá que enviar una trama de la desasociación al cliente que tendrá que volver a conectar. En los escenarios clásicos del NON-PSK, el WLC no enviará una trama de la desasociación al cliente y aplicará simplemente el nuevo resultado de la autorización. No obstante una “respuesta de la asociación” todavía será enviada ot al cliente aunque no se recibiera ninguna “petición de la asociación” nunca del cliente, que pudo parecer curioso al analizar las trazas de sniffer.

Troubleshooting

Complete estos pasos para resolver problemas o aislar un problema CWA:

1. Ingrese el cliente del debug < el MAC address del comando del client> en el regulador y el monitor para determinar si el cliente alcanza el estado CENTRAL_WEBAUTH_REQD. Se observa un problema común cuando el ISE vuelve una reorientación ACL que no exista (o no está correctamente entrar) en el WLC. Si éste es el caso, después el cliente deauthenticated una vez que se alcanza el estado CENTRAL_WEBAUTH_REQD, que hace el proceso comenzar otra vez.
   
   
2. Si el estado del cliente correcto puede ser alcanzado, después navegue para monitorear > los clientes en la red GUI del WLC y para verificar que el correctos reorientan el ACL y el URL son aplicados para el cliente.
   
   
3. Verifique que el DNS correcto esté utilizado. El cliente debe tener la capacidad de resolver los sitios web de Internet y el nombre de host ISE. Usted puede verificar esto vía el nslookup.
   
   
4. Verifique que todos los pasos de la autenticación ocurran en el ISE:
   
   
   • La autenticación de MAC debe ocurrir primero, a la cual se vuelven los atributos CWA.
     
     
   • La autenticación de inicio de sesión porta ocurre.
     
     
   • La autorización dinámica ocurre.
     
     
   • La autenticación final es una autenticación de MAC que muestra el nombre de usuario porta en el ISE, al cual se vuelven los resultados finales de la autorización (por ejemplo el VLA N y el ACL finales).

Consideraciones especiales para asegurar los escenarios

Considere este bug Cisco ID que limite la eficacia del proceso CWA en un escenario de la movilidad (especialmente cuando considera se configura):

• CSCuo56780 - Vulnerabilidad del rechazo de servicio del servicio RADIUS ISE
  
  
• CSCul83594 - El ID de sesión no se sincroniza a través de la movilidad, si la red está abierta