Resumen
Este artículo explica cómo utilizar el mecanismo de autenticación seguros (AMA) en escenarios de inicio de sesión interactivo.
Introducción
AMA agrega la pertenencia a un grupo universal, administrador designado al testigo de acceso de un usuario cuando se autentican las credenciales del usuario durante el inicio de sesión mediante un método de inicio de sesión basado en certificados. Esto hace posible que los administradores de recursos de red controlar el acceso a recursos, como archivos, carpetas e impresoras. Este acceso se basa en si el usuario inicia sesión utilizando un método de inicio de sesión basada en certificados y el tipo de certificado que se utiliza para iniciar sesión.
En este artículo
En este artículo se centra en dos escenarios de problema: inicio de sesión/cierre de sesión y bloqueo o desbloqueo. El comportamiento de AMA en estas situaciones es "por diseño" y puede resumirse como sigue:
-
AMA está diseñado para proteger los recursos de la red.
-
AMA no puede identificar ni aplicar el tipo de inicio de sesión interactivo (tarjeta inteligente o nombre de usuario y contraseña) para el equipo del usuario local. Esto es debido a que los recursos que se tiene acceso después de un inicio de sesión de usuario interactivo no protegidos de forma fiable utilizando AMA.
Síntomas
Problema escenario 1 (inicio de sesión/cierre de sesión)
Imagine el siguiente escenario:
-
Un administrador desea aplicar la autenticación de inicio de sesión de tarjeta inteligente (SC) cuando los usuarios tener acceso a determinados recursos de seguridad. Para ello, el administrador implementa AMA según la Comprobación del mecanismo de autenticación de AD DS en la Guía paso a paso de Windows Server 2008 R2 para el identificador de objeto de directiva de emisión que se utiliza en todos los certificados de tarjeta inteligente.
Nota: En este artículo, nos referiremos a este nuevo grupo asignado como "el grupo de seguridad universal de tarjeta inteligente". -
El "inicio de sesión interactivo: requerir tarjeta inteligente" Directiva no está habilitada en estaciones de trabajo. Por lo tanto, los usuarios pueden iniciar sesión utilizando otras credenciales, como nombre de usuario y la contraseña.
-
Local y acceso a recursos de red requiere que el grupo de seguridad universal de tarjeta inteligente.
En este escenario, piensa que sólo el usuario que inicia sesión mediante tarjetas inteligentes puede tener acceso local y recursos de red. Sin embargo, puesto que la estación de trabajo permite optimizado de caché de inicio de sesión, se utiliza el Comprobador en caché durante el inicio de sesión para crear el token de acceso de NT para el escritorio del usuario. Por lo tanto, se utilizan los grupos de seguridad y notificaciones de la sesión anterior en lugar del actual.
Ejemplos de escenario
Nota: En este artículo, pertenencia a grupos se recupera para las sesiones de inicio de sesión interactivo con "whoami/grupos". Este comando recupera los grupos y las notificaciones del token de acceso del escritorio.
-
Ejemplo 1
Si el inicio de sesión anterior se realizó mediante una tarjeta inteligente, el token de acceso para el escritorio tiene el grupo de seguridad universal de tarjeta proporcionado por AMA. Se produce uno de los siguientes resultados:-
El usuario inicia sesión con la tarjeta inteligente: el usuario aún puede acceder a recursos confidenciales de seguridad local. El usuario intenta tener acceso a recursos de red que requieren el grupo de seguridad universal de tarjeta inteligente. Estos intentos de éxito.
-
El usuario inicia sesión utilizando el nombre de usuario y contraseña: el usuario aún puede acceder a recursos confidenciales de seguridad local. Este resultado no esperado. El usuario intenta tener acceso a recursos de red que requieren el grupo de seguridad universal de tarjeta inteligente. Estos intentos fallan como se esperaba.
-
-
Ejemplo 2
Si el inicio de sesión anterior se realizó mediante una contraseña, el token de acceso para equipos de sobremesa no tiene el grupo de seguridad universal de tarjeta proporcionado por AMA. Se produce uno de los siguientes resultados:-
El usuario inicia sesión utilizando un nombre de usuario y una contraseña: el usuario no puede tener acceso a recursos confidenciales de seguridad local. El usuario intenta tener acceso a recursos de red que requieren el grupo de seguridad universal de tarjeta inteligente. Estos intentos fallan.
-
El usuario inicia sesión con la tarjeta inteligente: el usuario no puede tener acceso a recursos confidenciales de seguridad local. El usuario intenta tener acceso a recursos de red. Estos intentos de éxito. Este resultado no esperado por los clientes. Por lo tanto, hace que access control problemas.
-
Problema 2 de escenario (bloqueo o desbloqueo)
Imagine el siguiente escenario:
-
Un administrador desea aplicar la autenticación de inicio de sesión de tarjeta inteligente (SC) cuando los usuarios tener acceso a determinados recursos de seguridad. Para ello, el administrador implementa AMA según la Comprobación del mecanismo de autenticación de AD DS en la Guía paso a paso de Windows Server 2008 R2 para el identificador de objeto de directiva de emisión que se utiliza en todos los certificados de tarjeta inteligente.
-
El "inicio de sesión interactivo: requerir tarjeta inteligente" Directiva no está habilitada en estaciones de trabajo. Por lo tanto, los usuarios pueden iniciar sesión utilizando otras credenciales, como nombre de usuario y la contraseña.
-
Local y acceso a recursos de red requiere que el grupo de seguridad universal de tarjeta inteligente.
En este escenario, se espera que sólo un usuario que inicia sesión mediante tarjetas inteligentes puede tener acceso local y recursos de red. Sin embargo, dado que se crea el token de acceso para el escritorio del usuario durante el inicio de sesión, no se cambia.
Ejemplos de escenario
-
Ejemplo 1
Si el token de acceso para el escritorio tiene el grupo de seguridad universal de tarjeta proporcionado por AMA, se produce uno de los siguientes resultados:-
El usuario desbloquea mediante la tarjeta inteligente: el usuario aún puede acceder a recursos confidenciales de seguridad local. El usuario intenta tener acceso a recursos de red que requieren el grupo de seguridad universal de tarjeta inteligente. Estos intentos de éxito.
-
Desbloquea el usuario utilizando el nombre de usuario y la contraseña: el usuario aún puede acceder a recursos confidenciales de seguridad local. Este resultado no esperado. El usuario intenta tener acceso a recursos de red que requieren el grupo de seguridad universal de tarjeta inteligente. Estos intentos fallan.
-
-
Ejemplo 2
Si el token de acceso para equipos de sobremesa no tiene el grupo de seguridad universal de tarjeta proporcionado por AMA, se produce uno de los siguientes resultados:-
Desbloquea el usuario utilizando el nombre de usuario y contraseña: el usuario no puede tener acceso a recursos confidenciales de seguridad local. El usuario intenta tener acceso a recursos de red que requiere el grupo de seguridad universal de tarjeta inteligente. Estos intentos fallan.
-
El usuario desbloquea mediante la tarjeta inteligente: el usuario no puede tener acceso a recursos confidenciales de seguridad local. Este resultado no esperado. El usuario intenta tener acceso a recursos de red. Estos intentos de éxito como se esperaba.
-
Más información
Debido al diseño de AMA y el subsistema de seguridad que se describe en la sección "Síntomas", los usuarios experimentan los siguientes escenarios en los que AMA confiable no puede identificar el tipo de inicio de sesión interactivo.
Logon/logoff
Si está activa la optimización de inicio de sesión rápido, el subsistema de seguridad Local (lsass) utiliza una caché local para generar la pertenencia a grupos en el token de inicio de sesión. Al hacerlo, la comunicación con el controlador de dominio (DC) no es necesaria. Por lo tanto, se reduce el tiempo de inicio de sesión. Se trata de una característica muy deseable.
Sin embargo, esta situación provoca el siguiente problema: después de SC y SC cierre de sesión, el grupo AMA almacenada localmente en caché es, incorrectamente, estando presente en el token de usuario tras el inicio de sesión interactivo nombre y contraseña de usuario.
Notas:
-
Esta situación se aplica sólo a inicios de sesión interactivos.
-
Un grupo de AMA se almacena en caché de la misma manera y utilizando la misma lógica como otros grupos.
En esta situación, si el usuario entonces intenta tener acceso a recursos de red y pertenencia al grupo almacenada en caché en el lado del recurso no se utiliza para la sesión del usuario de inicio de sesión en el lado del recurso no contendrá un grupo AMA.
Este problema puede fijo desactivando la característica optimización del inicio de sesión rápido ("configuración del equipo > plantillas administrativas > sistema > Inicio de sesión > esperar siempre la detección de red al inicio del equipo e inicio de sesión").
Importante: Este comportamiento sólo es relevante en el escenario de inicio de sesión interactivo. Acceso a recursos de red funcionará como se espera porque no es necesario para la optimización de inicio de sesión. Por lo tanto, no se utiliza en caché de la pertenencia. El controlador de dominio se pone en contacto para crear el nuevo vale mediante la información de pertenencia de grupo AMA más recientes.
Lock/unlock
Imagine el siguiente escenario:
-
Un usuario inicia sesión de forma interactiva mediante la tarjeta inteligente y, a continuación, abre los recursos de red protegida AMA.
Nota: AMA red protegida recursos pueden tener acceso a sólo los usuarios que tienen un grupo AMA en su token de acceso. -
El usuario bloquea el equipo sin cerrar primero el recurso de red protegido AMA abierto anteriormente.
-
El usuario desbloquea el equipo utilizando el nombre de usuario y la contraseña del mismo usuario que iniciado sesión previamente con una tarjeta inteligente).
En este escenario, el usuario todavía puede acceso a los recursos protegidos AMA después de que el equipo se desbloquea. Este comportamiento es por diseño. Cuando se desbloquea el equipo, Windows no crea volver a todas las sesiones abiertas que contaban con los recursos de red. Windows también no volver a comprobar pertenencia al grupo. Esto es porque estas acciones haría que las reducciones del rendimiento inaceptable.
No hay ninguna solución out-of-box para este escenario. Una solución sería crear un filtro de proveedor de credenciales que filtra el proveedor de nombre y contraseña de usuario tras el inicio de sesión de SC y se producen los pasos de bloqueo. Para obtener más información acerca del proveedor de credenciales, consulte los siguientes recursos:
Interfaz ICredentialProviderFilter
Ejemplos de proveedor de credenciales de Windows VistaNota: No podemos confirmar si alguna vez se ha implementado con éxito este enfoque.
Para obtener más información acerca de AMA
AMA no puede identificar ni aplicar el tipo de inicio de sesión interactivo (tarjeta inteligente o nombre de usuario y contraseña). Este comportamiento es por diseño.
AMA está pensado para escenarios en los que los recursos de red exigen una tarjeta inteligente. No se va a utilizar para el acceso local.
Cualquier intento de solucionar este problema mediante la introducción de nuevas características, como la posibilidad de utilizar la pertenencia a grupo dinámico o a grupos de AMA de identificador como un grupo dinámico, podría producir problemas importantes. Por esta razón tokens de NT no son compatibles con la pertenencia a grupos dinámicos. Si el sistema permite grupos recortar en real, los usuarios podrían podrán interactuar con su propio escritorio y aplicaciones. Por lo tanto, la pertenencia a grupos se bloquea en el momento que se crea la sesión y se mantiene durante toda la sesión.
Los inicios de sesión en caché también son problemáticos. Si optimizada de inicio de sesión está habilitado, lsass trata de una caché local antes de invocar una red de ida y vuelta. Si el nombre de usuario y la contraseña son idénticos a los que lsass visto para el inicio de sesión anterior (Esto es verdad para la mayoría de los inicios de sesión), lsass crea un símbolo (token) que tiene las mismas suscripciones de grupo que el usuario tenía previamente.
Si está desactivado el inicio de sesión optimizado, requeriría un ida y vuelta de red. Esto asegurará que las pertenencias a grupos funcionan al iniciar la sesión correctamente.
En un inicio de sesión en caché, lsass mantiene una entrada por cada usuario. Esta entrada incluye la pertenencia a grupos del usuario anterior. Esto está protegido por la última contraseña o la credencial de tarjeta inteligente que vio lsass. Ambos desempaquetar la misma clave de símbolo (token) y credenciales. Si los usuarios intentar iniciar sesión utilizando una clave de credencial obsoletos, perdería datos DPAPI, contenido protegido por EFS y así sucesivamente. Por lo tanto, los inicios de sesión en caché siempre producen la pertenencia al grupo local más reciente, independientemente del mecanismo que se utiliza para iniciar sesión.
