Introducción
Este documento describe un problema con la Restricción de acceso a equipos (MAR) y proporciona una solución al problema.
Prerequisites
Con el crecimiento de los dispositivos personales, es más importante que nunca que los administradores de sistemas ofrezcan una forma de restringir el acceso a determinadas partes de la red a los recursos propiedad de la empresa únicamente. El problema descrito en este documento tiene que ver con cómo identificar de manera segura estas áreas de preocupación y autenticarlas sin interrupciones en la conectividad del usuario.
Requirements
Cisco recomienda que tenga conocimiento de 802.1X para comprender completamente este documento. Este documento asume que está familiarizado con la autenticación 802.1X del usuario, y resalta los problemas y las ventajas ligadas al uso de MAR, y más generalmente, la autenticación de máquina.
Componentes Utilizados
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). If your network is live, make sure that you understand the potential impact of any command.
Problema
MAR básicamente intenta resolver un problema común inherente a la mayoría de los métodos actuales y populares de protocolo de autenticación extensible (EAP), a saber, que la autenticación de máquina y la autenticación de usuario son procesos independientes y no relacionados.
La autenticación de usuario es un método de autenticación 802.1x que conocen la mayoría de los administradores del sistema. La idea es que las credenciales (nombre de usuario/contraseña) se den a cada usuario, y que el conjunto de credenciales represente a una persona física (también se puede compartir entre varias personas). Por lo tanto, un usuario puede iniciar sesión desde cualquier lugar de la red con esas credenciales.
Técnicamente, una autenticación de equipo es la misma, pero normalmente no se pide al usuario que introduzca las credenciales (o certificado); el equipo o equipo lo hace por sí solo. Esto requiere que la máquina ya tenga credenciales almacenadas. El nombre de usuario enviado es host/<MyPCHostname>, siempre que su máquina tenga <MyPCHostname> configurado como nombre de host. En otras palabras, envía host/ seguido por su nombre de host.
Aunque no está directamente relacionado con Microsoft Windows y Cisco Active Directory, este proceso se representa más fácilmente si el equipo se une a Active Directory porque el nombre de host del equipo se agrega a la base de datos del dominio y las credenciales se negocian (y se renuevan cada 30 días de forma predeterminada) y se almacenan en el equipo. Esto significa que la autenticación de la máquina es posible desde cualquier tipo de dispositivo, pero se representa con mucha más facilidad y transparencia si la máquina está unida a Active Directory y las credenciales permanecen ocultas al usuario.
MAR como solución
Es fácil decir que la solución es que Cisco Access Control System (ACS) o Cisco Identity Services Engine (ISE) completen la MAR, pero antes de implementarla hay que tener en cuenta las ventajas y los inconvenientes. La mejor forma de implementar esto es describirlo en las guías del usuario de ACS o ISE, por lo que este documento simplemente describe si se debe considerar o no, y algunos posibles obstáculos.
Las ventajas
MAR se inventó porque las autenticaciones de usuario y máquina son totalmente independientes. Por lo tanto, el servidor RADIUS no puede aplicar una verificación en la que los usuarios deban iniciar sesión desde los dispositivos propiedad de la empresa. Con MAR, el servidor RADIUS (ACS o ISE, en el lado de Cisco) impone, para una autenticación de usuario determinada, que debe haber una autenticación de máquina válida en las X horas (normalmente 8 horas, pero esto es configurable) que precede a la autenticación de usuario para el mismo terminal.
Por lo tanto, la autenticación de la máquina se realiza correctamente si el servidor RADIUS conoce las credenciales de la máquina, normalmente si la máquina está unida al dominio, y el servidor RADIUS verifica esto con una conexión al dominio. El administrador de la red es el único que puede determinar si una autenticación correcta del equipo proporciona acceso completo a la red o sólo un acceso restringido. Normalmente, esto abre al menos la conexión entre el cliente y Active Directory para que el cliente pueda realizar acciones como la renovación de la contraseña de usuario o la descarga de objetos de directiva de grupo (GPO).
Si la autenticación de un usuario proviene de un dispositivo en el que no se ha realizado la autenticación de una máquina en las dos horas anteriores, se deniega al usuario, incluso si el usuario es normalmente válido.
El acceso completo solo se concede a un usuario si la autenticación es válida y se ha completado desde un terminal en el que se ha realizado una autenticación de equipo en las últimas dos horas.
Los contras
Esta sección describe los inconvenientes del uso de MAR.
MAR y suplicante de Microsoft Windows
La idea detrás de MAR es que para que la autenticación de un usuario sea exitosa, no sólo ese usuario debe tener credenciales válidas, sino que también se debe registrar una autenticación de máquina exitosa desde ese cliente. Si hay algún problema con eso, el usuario no puede autenticarse. El problema que surge es que esta función a veces puede bloquear inadvertidamente a un cliente legítimo, lo que obliga al cliente a reiniciar para recuperar el acceso a la red.
Microsoft Windows realiza la autenticación de la máquina sólo durante el arranque (cuando aparece la pantalla de inicio de sesión); tan pronto como el usuario introduce las credenciales de usuario, se realiza una autenticación de usuario. Además, si el usuario cierra la sesión (vuelve a la pantalla de inicio de sesión), se realiza una nueva autenticación de equipo.
Aquí hay un ejemplo de escenario que muestra por qué MAR a veces causa problemas:
El usuario X trabajó todo el día en su portátil, que se conectaba mediante una conexión inalámbrica. Al final del día, simplemente cierra el portátil y deja el trabajo. Esto coloca el portátil en hibernación. Al día siguiente, vuelve a la oficina y abre su portátil. Ahora no puede establecer una conexión inalámbrica.
Cuando Microsoft Windows hiberna, toma una instantánea del sistema en su estado actual, que incluye el contexto de quién ha iniciado sesión. De la noche a la mañana, la entrada en caché MAR para el portátil del usuario caduca y se purga. Sin embargo, cuando el portátil está encendido, no realiza una autenticación de equipo. En lugar de eso, va directamente a una autenticación de usuario, ya que eso fue lo que registró la hibernación. La única forma de resolver este problema es cerrar la sesión del usuario o reiniciar el equipo.
Aunque MAR es una buena función, tiene el potencial de causar interrupciones en la red. Estas interrupciones son difíciles de solucionar hasta que entienda cómo funciona MAR; cuando implementa MAR, es importante educar a los usuarios finales sobre cómo apagar correctamente los equipos y cerrar sesión en cada equipo al final de cada día.
MAR y varios servidores RADIUS
Es común tener varios servidores RADIUS en la red para fines de balanceo de carga y redundancia. Sin embargo, no todos los servidores RADIUS admiten una caché de sesión MAR compartida. Solo las versiones 5.4 y posteriores de ACS, y la versión 2.3 y posteriores de ISE admiten la sincronización de la caché MAR entre nodos. Antes de estas versiones, no es posible realizar una autenticación de máquina contra un servidor ACS/ISE, y realizar una autenticación de usuario contra otro, ya que no se corresponden entre sí.
MAR y switching por cable o inalámbrico
La memoria caché MAR de muchos servidores RADIUS depende de la dirección MAC. Es simplemente una tabla con la dirección MAC de los portátiles y la marca de tiempo de su última autenticación exitosa de la máquina. De esta manera, el servidor puede saber si el cliente fue autenticado por la máquina en las últimas X horas.
Sin embargo, ¿qué ocurre si arranca el portátil con una conexión con cables (y, por tanto, realiza una autenticación de equipo desde el MAC con cables) y, a continuación, cambia a una conexión inalámbrica durante el día? El servidor RADIUS no tiene medios para correlacionar su dirección MAC inalámbrica con su dirección MAC con cable y para saber que usted fue autenticado por la máquina en las últimas X horas. La única forma es cerrar la sesión y hacer que Microsoft Windows realice otra autenticación de equipo a través de la red inalámbrica.
Solución
Entre otras muchas funciones, Cisco AnyConnect cuenta con la ventaja de contar con perfiles preconfigurados que activan la autenticación de usuarios y máquinas. Sin embargo, se encuentran las mismas limitaciones que las observadas con el suplicante de Microsoft Windows, con respecto a la autenticación del equipo que sólo se produce cuando se cierra la sesión o se reinicia.
Además, con las versiones 3.1 y posteriores de AnyConnect, es posible realizar EAP-FAST con encadenamiento de EAP. Básicamente se trata de una autenticación única, donde se envían dos pares de credenciales, el nombre de usuario/contraseña de la máquina y el nombre de usuario/contraseña del usuario, al mismo tiempo. ISE, por lo tanto, comprueba con mayor facilidad que ambos son correctos. Al no utilizar caché y sin necesidad de recuperar una sesión anterior, esto presenta una mayor fiabilidad.
Cuando se inicia el PC, AnyConnect envía una autenticación de equipo solamente, porque no hay información de usuario disponible. Sin embargo, tras el inicio de sesión del usuario, AnyConnect envía las credenciales del equipo y del usuario simultáneamente. Además, si se desconecta o desconecta/vuelve a conectar el cable, tanto las credenciales del equipo como las del usuario se envían de nuevo en una sola autenticación EAP-FAST, que difiere de las versiones anteriores de AnyConnect sin encadenamiento de EAP.
EAP-TEAP es la mejor solución a largo plazo, ya que está hecha especialmente para soportar este tipo de autenticaciones, pero EAP-TEAP todavía no es soportado en el suplicante nativo de muchos sistemas operativos a partir de este día