Resumen
En este artículo se explica cómo usar La garantía del mecanismo de autenticación (AMA) en escenarios de inicio de sesión interactivos.
Introducción
AMA agrega una pertenencia a grupo universal designada por el administrador al token de acceso de un usuario cuando las credenciales del usuario se autentican durante el inicio de sesión mediante un método de inicio de sesión basado en certificado. Esto permite a los administradores de recursos de red controlar el acceso a los recursos, como archivos, carpetas e impresoras. Este acceso se basa en si el usuario inicia sesión con un método de inicio de sesión basado en certificado y el tipo de certificado que se usa para iniciar sesión.
En este artículo
Este artículo se centra en dos escenarios de problemas: inicio de sesión/cierre de sesión y bloqueo/desbloqueo. El comportamiento de AMA en estos escenarios es "por diseño" y se puede resumir como sigue:
-
AMA está pensada para proteger los recursos de red.
-
AMA no puede identificar ni exigir el tipo de inicio de sesión interactivo (tarjeta inteligente o nombre de usuario/contraseña) para el equipo local del usuario. Esto se debe a que los recursos a los que se accede después de un inicio de sesión de usuario interactivo no se pueden proteger confiablemente mediante AMA.
Síntomas
Escenario del problema 1 (inicio/cierre de sesión)
Imagine la siguiente situación:
-
Un administrador quiere exigir la autenticación de inicio de sesión con tarjeta inteligente (SC) cuando los usuarios tengan acceso a determinados recursos confidenciales de la seguridad. Para ello, el administrador implementa AMA según la garantía del mecanismo de autenticación para AD DS en Windows Server guía paso a paso de R2 de 2008 para el identificador de objeto de directiva de emisión que se usa en todos los certificados de tarjeta inteligente. Nota En este artículo, nos referimos a este nuevo grupo asignado como "el grupo de seguridad universal de tarjeta inteligente".
-
La directiva "Inicio de sesión interactivo: Requerir tarjeta inteligente" no está habilitada en las estaciones de trabajo. Por lo tanto, los usuarios pueden iniciar sesión con otras credenciales, como el nombre de usuario y la contraseña.
-
El acceso a recursos locales y de red requiere el grupo de seguridad universal de tarjeta inteligente.
En este escenario, espera que solo los usuarios que inician sesión con tarjetas inteligentes puedan acceder a los recursos locales y de red. Sin embargo, como la estación de trabajo permite el inicio de sesión optimizado o almacenado en caché, el comprobador en caché se usa durante el inicio de sesión para crear el token de acceso NT para el escritorio del usuario. Por lo tanto, se usan los grupos de seguridad y las notificaciones del inicio de sesión anterior en lugar del actual.
Ejemplos de escenarios
Nota En este artículo, la pertenencia a grupos se recupera para las sesiones de inicio de sesión interactivas mediante "whoami/groups". Este comando recupera los grupos y notificaciones del token de acceso del escritorio.
-
Ejemplo 1Si el inicio de sesión anterior se realizó con una tarjeta inteligente, el token de acceso para el escritorio tiene el grupo de seguridad universal de tarjeta inteligente 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 acceder a los recursos de red que requieren el grupo de seguridad universal de tarjeta inteligente. Estos intentos tienen éxito.
-
El usuario inicia sesión con el nombre de usuario y la contraseña: el usuario aún puede acceder a los recursos locales confidenciales de seguridad. Este resultado no es el esperado. El usuario intenta acceder a los recursos de red que requieren el grupo de seguridad universal de tarjeta inteligente. Estos intentos fallan según lo esperado.
-
-
Ejemplo 2Si el inicio de sesión anterior se realizó con una contraseña, el token de acceso para el escritorio no tiene el grupo de seguridad universal de tarjeta inteligente proporcionado por AMA. Se produce uno de los siguientes resultados:
-
El usuario inicia sesión con un nombre de usuario y una contraseña: el usuario no puede acceder a los recursos confidenciales de seguridad locales. El usuario intenta acceder a los 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 acceder a los recursos confidenciales de seguridad local. El usuario intenta acceder a los recursos de red. Estos intentos tienen éxito. Los clientes no esperan este resultado. Por lo tanto, causa problemas de control de acceso.
-
Escenario del problema 2 (bloqueo/desbloqueo)
Tenga en cuenta el siguiente escenario:
-
Un administrador quiere exigir la autenticación de inicio de sesión con tarjeta inteligente (SC) cuando los usuarios tengan acceso a determinados recursos confidenciales de la seguridad. Para ello, el administrador implementa AMA según la garantía del mecanismo de autenticación para AD DS en Windows Server guía paso a paso de R2 de 2008 para el identificador de objeto de directiva de emisión que se usa en todos los certificados de tarjeta inteligente.
-
La directiva "Inicio de sesión interactivo: Requerir tarjeta inteligente" no está habilitada en las estaciones de trabajo. Por lo tanto, los usuarios pueden iniciar sesión con otras credenciales, como el nombre de usuario y la contraseña.
-
El acceso a recursos locales y de red requiere el grupo de seguridad universal de tarjeta inteligente.
En este escenario, espera que solo un usuario que inicie sesión con tarjetas inteligentes pueda acceder a los recursos locales y de red. Sin embargo, como el token de acceso para el escritorio del usuario se crea durante el inicio de sesión, no cambia.
Ejemplos de escenarios
-
Ejemplo 1Si el token de acceso para el escritorio tiene el grupo de seguridad universal de tarjeta inteligente proporcionado por AMA, se produce uno de los siguientes resultados:
-
El usuario se desbloquea con la tarjeta inteligente: el usuario aún puede acceder a los recursos confidenciales de seguridad local. El usuario intenta acceder a los recursos de red que requieren el grupo de seguridad universal de tarjeta inteligente. Estos intentos tienen éxito.
-
El usuario se desbloquea con el nombre de usuario y la contraseña: el usuario aún puede acceder a los recursos confidenciales de seguridad local. Este resultado no es el esperado. El usuario intenta acceder a los recursos de red que requieren el grupo de seguridad universal de tarjeta inteligente. Estos intentos fallan.
-
-
Ejemplo 2Si el token de acceso para el escritorio no tiene el grupo de seguridad universal de tarjeta inteligente proporcionado por AMA, se produce uno de los siguientes resultados:
-
El usuario se desbloquea con el nombre de usuario y la contraseña: el usuario no puede acceder a los recursos confidenciales de seguridad local. El usuario intenta acceder a recursos de red que requieren el grupo de seguridad universal de tarjeta inteligente. Estos intentos fallan.
-
El usuario se desbloquea con la tarjeta inteligente: el usuario no puede acceder a los recursos confidenciales de seguridad local. Este resultado no es el esperado. El usuario intenta acceder a los recursos de red. Estos intentos se completan correctamente según lo esperado.
-
Más información
Debido al diseño de AMA y subsistema de seguridad que se describe en la sección "Síntomas", los usuarios experimentan los siguientes escenarios en los que AMA no puede identificar confiablemente el tipo de inicio de sesión interactivo.
Inicio o cierre de sesión
Si la optimización del inicio de sesión rápido está activa, el subsistema de seguridad local (lsass) usa la caché local para generar la pertenencia a grupos en el token de inicio de sesión. Al hacerlo, no es necesaria la comunicación con el controlador de dominio (DC). Por lo tanto, se reduce el tiempo de inicio de sesión. Esta es una característica muy deseable.Sin embargo, esta situación provoca el siguiente problema: Después del inicio de sesión sc y sc cierre de sesión, el grupo AMA almacenado localmente en caché está, incorrectamente, todavía presente en el token de usuario después del nombre de usuario/contraseña de inicio de sesión interactivo.Notas
-
Esta situación solo se aplica a los inicios de sesión interactivos.
-
Un grupo AMA se almacena en caché de la misma manera y mediante la misma lógica que otros grupos.
En esta situación, si el usuario intenta obtener acceso a los recursos de red, no se usa la pertenencia a grupos almacenados en caché en el lado del recurso y la sesión de inicio de sesión del usuario en el lado del recurso no contendrá un grupo AMA.Este problema se puede solucionar desactivando la Optimización de inicio de sesión rápido ("Plantillas administrativas > configuración del equipo > > de inicio de sesión de > del sistema > Esperar siempre a que la red se inicie y se inicie sesión en el equipo"). Importante Este comportamiento solo es relevante en el escenario de inicio de sesión interactivo. El acceso a los recursos de red funcionará según lo esperado, ya que no es necesario optimizar el inicio de sesión. Por lo tanto, no se usa la pertenencia a grupos almacenados en caché. El DC se pone en contacto para crear el nuevo vale con la información más reciente sobre la pertenencia a grupos AMA.
Bloquear o desbloquear
Tenga en cuenta el siguiente escenario:
-
Un usuario inicia sesión de forma interactiva con la tarjeta inteligente y, a continuación, abre los recursos de red protegidos por AMA.Nota: Solo se puede acceder a los recursos de red protegidos por AMA 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 por AMA abierto anteriormente.
-
El usuario desbloquea el equipo con el nombre de usuario y la contraseña del mismo usuario que inició sesión anteriormente con una tarjeta inteligente).
En este escenario, el usuario aún puede acceder a los recursos protegidos por AMA después de desbloquear el equipo. Este comportamiento es una característica del diseño de la aplicación. Cuando se desbloquea el equipo, Windows no vuelve a crear todas las sesiones abiertas que tenían recursos de red. Windows tampoco vuelve a comprobar la pertenencia a grupos. Esto se debe a que estas acciones causarían sanciones de rendimiento inaceptables.No hay ninguna solución predefinida para este escenario. Una solución sería crear un filtro de Proveedor de credenciales que filtre el nombre de usuario y el proveedor de contraseñas después de que se produzcan los pasos de inicio de sesión y bloqueo de SC. Para obtener más información sobre el Proveedor de credenciales, vea los recursos siguientes:
ICredentialProviderFilter interfaz Ejemplos de proveedores de credenciales de Windows VistaNota No podemos confirmar si este enfoque se ha implementado correctamente.
Más información sobre AMA
AMA no puede identificar ni exigir el tipo de inicio de sesión interactivo (tarjeta inteligente o nombre de usuario/contraseña). Este comportamiento es una característica del diseño de la aplicación.AMA está pensada para escenarios en los que los recursos de red requieren una tarjeta inteligente. No está pensado para usarse para el acceso local.Cualquier intento de corregir este problema introduciendo nuevas características, como la capacidad de usar la pertenencia a grupos dinámicos o de controlar los grupos AMA como un grupo dinámico, podría causar problemas importantes. Por este motivo, los tokens nt no admiten la pertenencia a grupos dinámicos. Si el sistema permitió recortar los grupos de forma real, es posible que se impida a los usuarios interactuar con sus propias aplicaciones y escritorios. Por lo tanto, las pertenencias a grupos se bloquean en el momento en que se crea la sesión y se mantienen durante toda la sesión.Los inicios de sesión en caché también son problemáticos. Si se habilita el inicio de sesión optimizado, lsass primero prueba una caché local antes de invocar un recorrido de ida y vuelta de red. Si el nombre de usuario y la contraseña son idénticos a lo que lsass veía para el inicio de sesión anterior (esto es así para la mayoría de los inicios de sesión), lsass crea un token que tiene las mismas pertenencias a grupos que tenía el usuario anteriormente. Si se desactiva el inicio de sesión optimizado, se requeriría una ida y vuelta de red. Esto garantizará que la pertenencia a grupos funcione al iniciar sesión según lo esperado.En un inicio de sesión almacenado en caché, lsass mantiene una entrada por usuario. Esta entrada incluye la pertenencia a grupos anterior del usuario. Esto está protegido por la última contraseña o credencial de tarjeta inteligente que vio Lsass. Desenvolver el mismo token y la misma clave de credencial. Si los usuarios intentaran iniciar sesión con una clave de credencial obsoleta, perderían los datos de DPAPI, el contenido protegido por EFS, etc. Por lo tanto, los inicios de sesión almacenados en caché siempre generan las pertenencias a grupos locales más recientes, independientemente del mecanismo que se usa para iniciar sesión.
