Mejores prácticas y consideraciones del despliegue de la postura ISE

Introducción

Este documento describe algunas configuraciones de la línea de fondo que dirijan varios casos del uso con la postura cambio de dirección-basada. En estas configuraciones el cliente sigue siendo obediente, pero el dispositivo de acceso a la red (NAD) limita el acceso porque está en el estado de la reorientación.

Restricciones

Las configuraciones en este documento trabajan para Cisco NAD, pero no no necesariamente para el otro vendedor NAD.

Comportamiento del cliente de la postura

El cliente de la postura accionará las puntas de prueba en estas horas:

• Conexión con el sistema inicial
• Cambio de la capa 3 (L3)/cambio del indicador luminoso LED amarillo de la placa muestra gravedad menor de interfaz de red (NIC) (nueva dirección IP, cambio de estado NIC)

Utilice los casos

Utilice el caso 1 - El reauthentication del cliente fuerza el NAD para generar un nuevo ID de sesión.

En este caso del uso, el cliente es todavía obediente, pero debido al reauthentication, el NAD está en el estado de la reorientación (reoriente el URL y la lista de acceso).

Por abandono, el Identity Services Engine (ISE) se configura para realizar una evaluación de la postura cada vez que conecte con la red, más concretamente para cada nueva sesión.

Esta configuración se configura bajo los centros de trabajo > la postura > las configuraciones > opciones generales de la postura.

Para guardar el NAD de generar un nuevo ID de sesión en el reauthentication, configure estos valores del reauthentication en el perfil de la autorización. El temporizador del reauthentication visualizado no es una recomendación estándar, los temporizadores del reauthentication se debe considerar por el despliegue basado en el Tipo de conexión (inalámbrico/atado con alambre), diseño (cuáles son las reglas de la persistencia en el loadbalancer), y así sucesivamente.

La directiva > los elementos de la directiva > resulta > autorización > los perfiles de la autorización

En el Switches, usted necesita configurar cada interfaz, o la plantilla, para conseguir su temporizador del reauthentication de ISE. 

authentication timer reauthenticate server

Nota: Si hay un balanceador de la carga, usted necesita asegurarse de que la persistencia esté configurada de una manera que los reauthentications serán vueltos al servicio original de la directiva (PSN).

Utilice el caso 2 - El conmutador se configura con la orden MAB DOT1X y la prioridad DOT1X MAB (atada con alambre).

En este caso los reauthentications serán terminados, porque una parada de las estadísticas para la sesión del 802.1x será enviada cuando puente de la autenticación MAC (MAB) se intenta durante el reauthentication.

• La parada de las estadísticas que se envía para el proceso MAB cuando falla la autenticación está correcta, pues el username para el cliente cambia del username del 802.1x al username MAB.
• Dot1x como la método-identificación en la parada de las estadísticas está también tan correcto que el método que autorizaba estaba dot1x.
• Cuando el método Dot1x tiene éxito, envía un comienzo de las estadísticas con la método-identificación como dot1x. Aquí también, este comportamiento está como se esperaba.

Para resolver este problema, configure el cisco av-pair: terminación-acción-modificante = 1 en el perfil del authZ usado cuando una punto final es obediente. Este par del valor de atributo (sistema de pesos americano) especifica que el NAD debe reutilizar el método elegido en la autenticación original sin importar el orden configurado.

Utilice el caso 3 - Los clientes de red inalámbrica vagan por y las autenticaciones para diversos APs van a diversos reguladores.

Para esta situación, la red inalámbrica necesitará ser diseñada de modo que los Puntos de acceso (APs) dentro del alcance a otros APs para el uso de itinerancia el mismo controlador activo. Un ejemplo es Conmutación por falla stateful inalámbrica del intercambio del regulador LAN (WLC) (SSO). Para más información sobre la Alta disponibilidad (ha) SSO para WLC, vea el Guía de despliegue de gran disponibilidad (SSO).

Utilice el caso 4 - Implementaciones con los balanceadores de la carga (pre 2.6 parchean 6, 2.7 la corrección P2, y 3.0).

En las implementaciones con los balanceadores de la carga implicados, es importante asegurarse de que después de que usted realice los cambios en los casos anteriores del uso, las sesiones continúan yendo al mismo PSN. Antes de la versión/de las correcciones enumeradas para este paso, el estatus de la postura no se replica entre los Nodos vía los datos ligeros Dirstribution (antes directorio ligero de la sesión). Debido a esto, es posible que diverso PSNs vuelva diversos resultados del estatus de la postura.

Si la persistencia no se configura correctamente, las sesiones que reauthenticate podrían ir a un diverso PSN que el que fue utilizado originalmente. Si sucede esto, el nuevo PSN podría marcar el Estado de cumplimiento de las sesiones como desconocido y pasar el resultado del authZ con el Access Control List de la reorientación (ACL) /URL y limitar el acceso de las puntos finales. Una vez más este cambio en el NAD no sería reconocido por el módulo de la postura y las puntas de prueba no serán accionadas.

Para más información sobre cómo configurar los balanceadores de la carga, vea Cisco y el Guía de despliegue F5: Equilibrio de carga ISE usando BIG-IP. Proporciona a una descripción general de alto nivel y a una configuración específica F5 de un diseño de la mejor práctica para las implementaciones ISE en un entorno equilibrado carga.

Utilice el caso 5 - Las sondas de detección de la etapa 2 responsed por a un diverso servidor que autentican al cliente con (pre 2.6 parchean 6, 2.7 la corrección 2, y 3.0).

Heche una ojeada las puntas de prueba dentro del cuadro rojo en este diagrama.

PSNs salvará los datos de sesión por cinco días, los datos de sesión para una sesión “obediente” todavía vive tan a veces en el PSN del origninal incluso si el cliente autentica no más con ese nodo. Si las puntas de prueba incluidas en el cuadro rojo se responden por a un PSN con excepción del que autentica actualmente la sesión Y que ha poseído y ha marcado el PSN previamente esta punto final obediente, es posible para que haya una discordancía entre el estatus de la postura del módulo de la postura en la punto final y el PSN de autenticidad actual.

Aquí están algunos escenarios frecuentes donde esta discordancía puede ocurrir:

• Una parada de las estadísticas no se recibe para una punto final cuando desconecta de la red.
• El NAD falló encima a partir de un PSN a otro.
• Autenticaciones de un balanceador de la carga adelante a diverso PSNs para la misma punto final.

Para proteger contra este comportamiento, ISE se puede configurar para permitir solamente que las sondas de detección de un punto final específico alcancen el PSN al cual autentica actualmente. Para alcanzar esto, configure una diversa directiva de la autorización para cada PSN en su despliegue. En estas directivas, refiérase a un diverso perfil del authZ que contenga una lista de control de acceso transferible (DACL) que permita las puntas de prueba SOLAMENTE al PSN especificado en la condición del authZ. Vea este ejemplo::

Cada PSN tendrá una regla para el estatus desconocido de la postura:

Cada perfil del individuo se refiere a un diverso DACL.

Nota: Para la Tecnología inalámbrica, utilice Airespace ACL.

Cada DACL permite solamente el acceso de la punta de prueba al PSN que maneja la autenticación.

En el ejemplo anterior, 10.10.10.1 es la dirección IP de PSN 1. El DACL referido se puede alterar para cualquier servicios adicional /IP según las necesidades, pero debe limitar el acceso solamente al PSN que maneja la autenticación.

La corrección 6 del poste 2.6 del cambio del comportamiento, 2.7 parchea 2, y el 3.0

El estatus de la postura se ha agregado en el directorio de la sesión RADIUS vía el marco ligero de la distribución de los datos. Cada vez que una actualización del estado de la postura se recibe en cualquier PSN, será replicada a TODO EL PSNs en el despliegue. Una vez que este cambio está en efecto, las implicaciones de las autenticaciones y o de las puntas de prueba que alcanzan diverso PSNs en diversas autenticaciones se quitan y cualquier PSN deben poder contestar a todas las puntos finales sin importar donde se autentican actualmente.

En los cinco casos del uso en este documento, considere estos comportamientos:

Utilice el caso 1 - El reauthentication del cliente fuerza el NAD para generar un nuevo ID de sesión. El cliente es todavía obediente, pero debido al reauthentication, el NAD está en el estado de la reorientación (reoriente el URL y la lista de acceso).

- Este comportamiento no cambiará y esta configuración se debe todavía ejecutar en ISE y los NAD.

Utilice el caso 2 - El conmutador se configura con la orden MAB DOT1X y la prioridad DOT1X MAB (atada con alambre).

- Este comportamiento no cambiará y esta configuración se debe todavía ejecutar en ISE y los NAD.

Utilice el caso 3 - Los clientes de red inalámbrica vagan por y las autenticaciones para diversos APs van a diversos reguladores.

- Este comportamiento no cambiará y esta configuración se debe todavía ejecutar en ISE y los NAD.

Utilice el caso 4 - Implementaciones con los balanceadores de la carga.

- Las mejores prácticas definidas en la guía del Equilibrio de carga se deben todavía seguir, pero en caso que las autenticaciones sean remitidas a diverso PSNs por el balanceador de la carga, el estatus correcto de la postura se deben volver al cliente.

Utilice el caso 5 - Las sondas de detección de la etapa 2 responsed por a un diverso servidor que autentican al cliente con

- Esto no debe ser un problema con el nuevo behvaior y el perfil de la autorización por-PSN no debe ser necesario.

Consideraciones al mantener el mismo SessionID

Cuando usted utiliza los métodos enumerados en este documento, un usuario que sigue conectado con la red podría potencialmente seguir siendo obediente por los períodos prolongados de tiempo. Aunque reauthenticate, el sessionID no cambia y por lo tanto ISE continuará pasando el resultado de AuthZ para su regla que corresponde con el estatus obediente.

En este evento, la nueva valoración periódica necesita ser configurada de modo que la postura sea requerida para asegurarse de que la punto final siga siendo obediente con las directivas corporativas en los intervalos definidos.

Esto se puede configurar bajo configuraciones de los centros de trabajo > de la postura > de las configuraciones > de Ressessment.