Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
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).
Es reemplazado por más Guía de despliegue completo del invitado disponible aquí: https://communities.cisco.com/docs/DOC-77590
No hay requisitos específicos para este documento.
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
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:
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:
La configuración usada es:
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.
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.
Asegúrese de que el ISE valide todas las autenticaciones de MAC del WLC y aseegurelo 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.
Nota: Ahora hay una regla de la autenticación MAB creada en el ISE por abandono.
Configure la directiva de la autorización. Un punto importante a entender es que hay dos autenticaciones/autorizaciones:
Complete estos pasos para crear las reglas de la autorización tal y como se muestra en de las imágenes anteriores:
Nota: Es muy importante que esta nueva regla viene antes de la regla del cambio de dirección 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).
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. Esto no es un diseño recomendado como cambio del cliente vlan después de que consiguiera ya un IP Address interrumpa la Conectividad, algunos clientes pudieron reaccionar incorrecto a ella y requiere los privilegios elevados de Windows de trabajar muy bien.
Si usted asignó un VLA N, complete estos pasos para habilitar la renovación IP:
Nota: Esta opción trabaja solamente para los clientes de Windows.
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 las necesidades no nativas de hacer que el nombre ACL exista (no necesita las entradas ACL). El WLC no nativo enviará el nombre ACL al ancla y será el ancla que aplica el cambio de dirección (y por lo tanto necesita el contenido correcto ALC).
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:
Los puertos de firewall que se requieren para permitir la comunicación entre el WLC y el ISE son:
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 CSCul83594 , 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. Observe que éste no debe ser el caso que comienza más el software WLC 8.6 donde el ID de sesión será compartido entre el ancla y los reguladores no nativos y las estadísticas entonces sea posible habilitar en ambos.
Utilize esta sección para confirmar que su configuración funcione correctamente.
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.
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
Después de esto el cliente reauthenticated y acceso concedido a la red.
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.
Complete estos pasos para resolver problemas o aislar un problema CWA:
Considere este bug Cisco ID que limite la eficacia del proceso CWA en un escenario de la movilidad (especialmente cuando considera se configura):