El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
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 algunas configuraciones básicas que abordan varios casos de uso con una postura basada en redirección. En estas configuraciones, el cliente sigue siendo compatible, pero el dispositivo de acceso a la red (NAD) limita el acceso porque se encuentra en el estado de redirección.
Las configuraciones de este documento funcionan para Cisco NAD, pero no necesariamente para NAD de terceros.
El cliente de estado activará sondas en estos momentos:
En este caso de uso, el cliente aún cumple con la normativa, pero debido a la reautenticación, el NAD se encuentra en el estado de redirección (redirección URL y lista de acceso).
De forma predeterminada, Identity Services Engine (ISE) se configura para realizar una evaluación del estado cada vez que se conecta a la red, más específicamente para cada nueva sesión.
Esta configuración se configura en Centros de trabajo > Estado > Configuración > Configuración general de estado.
Para evitar que el NAD genere un nuevo ID de sesión en la reautenticación, configure estos valores de reautenticación en el perfil de autorización. El temporizador de reautenticación que se muestra no es una recomendación estándar, los temporizadores de reautenticación deben tenerse en cuenta por implementación en función del tipo de conexión (inalámbrica/por cable), el diseño (cuáles son las reglas de persistencia en el equilibrador de carga), etc.
Política > Elementos de política > Resultados > Autorización > Perfiles de autorización
En los switches, debe configurar cada interfaz o plantilla para obtener su temporizador de reautenticación de ISE.
authentication timer reauthenticate server
Nota: Si hay un equilibrador de carga, debe asegurarse de que la resistencia se configura de forma que las reautenticaciones se devuelvan al servicio de políticas original (PSN).
En este caso, se terminarán las reautenticaciones, porque se enviará una parada de contabilización para la sesión 802.1x cuando se intente la omisión de autenticación MAC (MAB) durante la reautenticación.
Para resolver este problema, configure cisco-av-pair:terminación-action-modifier = 1 en el perfil authZ utilizado cuando un terminal es compatible. Este par attribute-value (AV) especifica que NAD debe reutilizar el método elegido en la autenticación original independientemente del orden configurado.
Para esta situación, la red inalámbrica deberá estar diseñada de modo que los puntos de acceso (AP) al alcance de otros AP para itinerancia utilicen el mismo controlador activo. Un ejemplo es la conmutación por error (SSO) de stateful del controlador de LAN inalámbrica (WLC). Para obtener más información sobre High Availability (HA) SSO para WLC, vea High Availability (SSO) Deployment Guide.
En las implementaciones con equilibradores de carga involucrados, es importante asegurarse de que después de realizar los cambios en los casos prácticos anteriores, las sesiones continúen en el mismo PSN. Antes de la versión/los parches enumerados para este paso, el estado no se replica entre los nodos a través de Light Data Distribution (antes Light Data Directory). Debido a esto, es posible que los diferentes PSN devuelvan diferentes resultados de estado.
Si la resistencia no se configura correctamente, las sesiones que se vuelven a autenticar podrían ir a un PSN diferente al que se utilizó originalmente. Si esto sucede, el nuevo PSN podría marcar el estado de cumplimiento de las sesiones como desconocido y pasar el resultado de authZ con la lista de control de acceso (ACL)/URL de redirección y limitar el acceso de los terminales. De nuevo, este cambio en el NAD no sería reconocido por el módulo de estado y las sondas no se activarán.
Para obtener más información sobre cómo configurar los equilibradores de carga, consulte Guía de implementación de Cisco y F5: Balanceo de Carga ISE Usando BIG-IP. Proporciona una descripción general de alto nivel y una configuración específica F5 de un diseño de prácticas recomendadas para implementaciones de ISE en un entorno con equilibrio de carga.
Eche un vistazo a las sondas del cuadro rojo de este diagrama.
Los PSN almacenarán los datos de sesión durante cinco días, por lo que a veces los datos de sesión para una sesión "conforme" aún permanecen en el PSN original aunque el cliente ya no se autentique con ese nodo. Si las sondas incluidas en el cuadro rojo son respondidas por un PSN distinto del que actualmente autentica la sesión Y que PSN ha poseído y marcado previamente este terminal conforme, es posible que haya una discordancia entre el estado del módulo de estado en el terminal y el PSN que autentica actualmente.
Estos son algunos escenarios comunes donde puede ocurrir esta discordancia:
Para protegerse de este comportamiento, ISE se puede configurar para permitir que sólo las sondas de detección de un terminal determinado alcancen el PSN al que se autentica actualmente. Para lograrlo, configure una política de autorización diferente para cada PSN en su implementación. En estas políticas, haga referencia a un perfil authZ diferente que contiene una lista de control de acceso descargable (DACL) que permite sondeos SOLAMENTE al PSN especificado en la condición authZ. Vea este ejemplo:
Cada PSN tendrá una regla para el estado desconocido:
Cada perfil individual hace referencia a una DACL diferente.
Nota: Para conexión inalámbrica, utilice ACL de Airespace.
Cada DACL sólo permite el acceso de sonda al PSN que maneja la autenticación.
En el ejemplo anterior, 10.10.10.1 es la dirección IP de PSN 1. La DACL a la que se hace referencia se puede modificar para cualquier servicio/IP adicional según sea necesario, pero debe limitar el acceso sólo al PSN que maneja la autenticación.
El estado de estado se ha agregado al directorio de sesiones RADIUS a través del marco de distribución de datos ligeros. Cada vez que se recibe una actualización de estado en cualquier PSN, se replicará en TODOS los PSN de la implementación. Una vez que este cambio está en vigor, se eliminan las implicaciones de las autenticaciones o sondas que llegan a diferentes PSN en diferentes autenticaciones y cualquier PSN debe poder responder a todos los terminales independientemente de dónde estén autenticados actualmente.
En los cinco casos prácticos de este documento, considere estos comportamientos:
Caso de uso 1: la reautenticación del cliente fuerza al NAD a generar un nuevo ID de sesión. El cliente aún cumple con la normativa, pero debido a la reautenticación, el NAD se encuentra en el estado de redirección (redirección URL y lista de acceso).
- Este comportamiento no cambiará y esta configuración debe implementarse en ISE y NAD.
Caso de uso 2: el switch se configura con el pedido MAB DOT1X y la prioridad DOT1X MAB (con cables).
- Este comportamiento no cambiará y esta configuración debe implementarse en ISE y NAD.
Caso de uso 3 - Los clientes inalámbricos vagan y las autenticaciones para diferentes AP van a diferentes controladores.
- Este comportamiento no cambiará y esta configuración debe implementarse en ISE y NAD.
Caso práctico 4: implementaciones con equilibradores de carga.
- Se deben seguir las mejores prácticas definidas en la guía de equilibrio de carga, pero en el caso de que el equilibrador de carga reenvíe las autenticaciones a diferentes PSN, se debe devolver al cliente el estado correcto.
Caso de uso 5: las sondas de detección de la etapa 2 son respondidas por un servidor diferente al que el cliente es autenticado con
- Esto no debería ser un problema con el nuevo comportamiento y no debería ser necesario el perfil de autorización por PSN.
Cuando se utilizan los métodos enumerados en este documento, un usuario que permanezca conectado a la red podría seguir cumpliendo las normativas durante largos períodos de tiempo. Aunque se vuelven a autenticar, el IdSesión no cambia y, por lo tanto, ISE continuará pasando el resultado AuthZ para su regla que coincida con el estado de cumplimiento.
En este caso, es necesario configurar la reevaluación periódica de modo que se requiera la condición para asegurarse de que el terminal cumple las políticas corporativas a intervalos definidos.
Esto se puede configurar en Centros de trabajo > Estado > Configuración > Configuraciones de receso.