Prácticas recomendadas y consideraciones sobre la implementación del estado de ISE

Introducción

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.

Restricciones

Las configuraciones de este documento funcionan para Cisco NAD, pero no necesariamente para NAD de terceros.

Comportamiento del cliente de postura

El cliente de estado activará sondas en estos momentos:

• Inicio de sesión inicial
• Cambio de capa 3 (L3)/cambio de tarjeta de interfaz de red (NIC) (nueva dirección IP, cambio de estado de NIC)

Casos de uso

Caso de uso 1: la reautenticación del cliente fuerza al NAD a generar un nuevo ID de sesión.

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).

Caso de uso 2: el switch se configura con el pedido MAB DOT1X y la prioridad DOT1X MAB (con cables).

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.

• La parada de contabilidad que se envía para el proceso MAB cuando falla la autenticación es correcta, ya que el nombre de usuario del cliente cambia del nombre de usuario 802.1X al nombre de usuario MAB.
• Dot1x como id de método en la parada de contabilidad también es correcto, ya que el método de autorización era dot1x.
• Cuando el método Dot1x se realiza correctamente, envía un inicio de contabilización con id de método como dot1x. Aquí también, este comportamiento es como se espera.

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.

Caso de uso 3 - Los clientes inalámbricos vagan y las autenticaciones para diferentes AP van a diferentes controladores.

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.

Caso de uso 4: implementaciones con equilibradores de carga (anterior a 2.6 parche 6, 2.7 parche P2 y 3.0).

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.

Caso de uso 5 - Las sondas de detección de Etapa 2 son respondidas por un servidor diferente al con el que se autentica el cliente (Parche previo 2.6 6, Parche 2.7 y 3.0).

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:

• No se recibe una parada de contabilización para un terminal cuando se desconecta de la red.
• El NAD falló de un PSN a otro.
• Un equilibrador de carga reenvía las autenticaciones a diferentes PSN para el mismo terminal.

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.

Cambio de comportamiento posterior a 2.6 parche 6, 2.7 parche 2 y 3.0

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.

Consideraciones al Mantener el Mismo IdSesión

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.