Compartir a través de

Los cambios de pertenencia a grupos no se actualizan a través de algunas conexiones VPN

En este artículo se describe una situación en la que los usuarios vpn pueden experimentar problemas de acceso a recursos o configuración después de que cambie la pertenencia a grupos.

Se aplica a: Todas las versiones compatibles del cliente de Windows

Síntomas

En respuesta a la pandemia de covid-19, un número creciente de usuarios trabaja, aprende y socializa desde casa. Se conectan al área de trabajo mediante conexiones VPN. Estos usuarios vpn informan de que, cuando se agregan o quitan de grupos de seguridad, es posible que los cambios no surtan efecto según lo previsto. Notifican síntomas como los siguientes:

  • Los cambios en el acceso a recursos de red no surten efecto.
  • Los objetos de directiva de grupo (GPO) que tienen como destino grupos de seguridad específicos no se aplican correctamente.
  • La directiva de redirección de carpetas no se aplica correctamente.
  • Las reglas de AppLocker que tienen como destino grupos de seguridad específicos no funcionan.
  • Los scripts de inicio de sesión que crean unidades asignadas, incluida la carpeta principal del usuario o los mapas de unidades de GPP, no funcionan.
  • El whoami /groups comando (ejecute en un símbolo del sistema) notifica una lista obsoleta de pertenencias a grupos para el contexto de seguridad local del usuario.
  • El gpresult /r comando (ejecute en un símbolo del sistema) notifica una lista obsoleta de pertenencias a grupos.

Si el usuario bloquea y, a continuación, desbloquea Windows mientras el cliente permanece conectado a la VPN, algunos de estos síntomas se resuelven a sí mismos. Por ejemplo, algunos cambios de acceso a recursos surten efecto. Posteriormente, si el usuario cierra la sesión de Windows y vuelve a iniciar sesión (cerrando todas las sesiones que usan recursos de red), más de los síntomas se resuelven. Sin embargo, es posible que los scripts de inicio de sesión no funcionen correctamente y es posible que el gpresult /r comando todavía no refleje los cambios de pertenencia a grupos. El usuario no puede solucionar el problema mediante el runas comando para iniciar una nueva sesión de Windows en el cliente. Este comando solo usa la misma información de credenciales para iniciar la nueva sesión.

El ámbito de este artículo incluye entornos que han implementado authentication Mechanism Assurance (AMA) en el dominio y en los que los usuarios tienen que autenticarse mediante una tarjeta inteligente para acceder a los recursos de red. Para obtener más información, vea Descripción del uso de AMA en escenarios de inicio de sesión interactivos en Windows.

Causa

En un entorno de office, es habitual que un usuario cierre la sesión de Windows al final del día laboral. Cuando el usuario inicia sesión el día siguiente, el cliente ya está conectado a la red y tiene acceso directo a un controlador de dominio. En estas condiciones, los cambios en la pertenencia a grupos surten efecto rápidamente. El usuario tiene los niveles de acceso correctos el día siguiente (la próxima vez que el usuario inicie sesión). Del mismo modo, los cambios en la directiva de grupo parecen surtir efecto en un día o dos (después de que el usuario inicie sesión una o dos veces, dependiendo de las directivas programadas para aplicar).

En un entorno doméstico, el usuario podría desconectarse de la VPN al final del día laboral y bloquear Windows. Es posible que no cierren la sesión. Cuando el usuario desbloquea Windows (o inicia sesión) la mañana siguiente, el cliente no se conecta a la VPN (y no tiene acceso a un controlador de dominio) hasta después de que el usuario haya desbloqueado Windows o haya iniciado sesión. El cliente inicia la sesión del usuario en Windows mediante credenciales almacenadas en caché en lugar de ponerse en contacto con el controlador de dominio para obtener credenciales nuevas. Windows crea un contexto de seguridad para el usuario que se basa en la información almacenada en caché. Windows también aplica la directiva de grupo de forma asincrónica, en función de la caché de directivas de grupo local. Este uso de la información almacenada en caché puede provocar el siguiente comportamiento:

  • Es posible que el usuario tenga acceso a los recursos que no deben tener y que no tenga acceso a los recursos que deben tener.
  • Es posible que la configuración de directiva de grupo no se aplique según lo previsto o que la configuración de directiva de grupo no esté actualizada.

Este comportamiento se produce porque Windows usa información almacenada en caché para mejorar el rendimiento cuando los usuarios inician sesión. Windows también usa información almacenada en caché para iniciar sesión de usuarios en clientes unidos a un dominio que no están conectados a la red. Se producen consecuencias inesperadas si el cliente usa exclusivamente una VPN para conectarse a la red y el cliente no puede establecer la conexión VPN hasta después de que el usuario inicie sesión.

Importante

Este comportamiento solo es relevante en el escenario de inicio de sesión interactivo. El acceso a los recursos de red funciona según lo previsto porque el inicio de sesión de red no usa información almacenada en caché. En su lugar, la información del grupo procede de una consulta del controlador de dominio.

Efectos en el contexto de seguridad del usuario y el control de acceso

Si el cliente no puede conectarse a un controlador de dominio cuando el usuario inicia sesión, Windows basa el contexto de seguridad del usuario en la información almacenada en caché. Después de que Windows cree el contexto de seguridad del usuario, no actualiza el contexto hasta la próxima vez que el usuario inicie sesión.

Por ejemplo, supongamos que un usuario está asignado a un grupo de Active Directory mientras el usuario está sin conexión. El usuario inicia sesión en Windows y, a continuación, se conecta a la VPN. Si el usuario abre una ventana del símbolo del sistema y, a continuación, ejecuta el whoami /groups comando, la lista de grupos no incluye el nuevo grupo. El usuario bloquea y, a continuación, desbloquea el escritorio mientras sigue conectado a la VPN. El whoami /groups comando sigue produciendo el mismo resultado. Por último, el usuario cierra la sesión de Windows. Después de que el usuario vuelva a iniciar sesión, el whoami /groups comando genera el resultado correcto.

El efecto de la información almacenada en caché sobre el acceso del usuario a los recursos depende de los siguientes factores:

  • Si los recursos están en el cliente o en la red
    Los recursos de la red requieren un paso de autenticación adicional (un inicio de sesión de red en lugar de un inicio de sesión interactivo). Este paso significa que la información de grupo que usa el recurso para determinar el acceso siempre procede de un controlador de dominio, no de la memoria caché del cliente.
  • Si los recursos usan vales kerberos u otras tecnologías (como tokens de acceso NTLM) para autenticar y autorizar a los usuarios
    • Para obtener más información sobre cómo afecta la información almacenada en caché al acceso de los usuarios a los recursos protegidos por NTLM, consulte Recursos que dependen de la autenticación NTLM.
    • Para más información sobre cómo afecta la información almacenada en caché al acceso de los usuarios a los recursos protegidos por Kerberos, consulte Recursos que dependen de vales kerberos.
  • Si el usuario reanuda una sesión de recursos existente o inicia una nueva sesión de recursos.
  • Si el usuario bloquea y desbloquea el cliente mientras está conectado a la VPN
    Si el usuario bloquea el cliente mientras está conectado a la VPN y, a continuación, lo desbloquea, el cliente actualiza su caché de grupos de usuarios. Sin embargo, este cambio no afecta al contexto de seguridad de usuario existente ni a las sesiones que se estaban ejecutando cuando el usuario bloqueó el cliente.
  • Si el usuario cierra la sesión del cliente mientras está conectado a la VPN y, a continuación, inicia sesión de nuevo.
    Los efectos de cerrar sesión y, a continuación, iniciar sesión difieren en función de si el usuario ha bloqueado y desbloqueado el cliente primero mientras está conectado a la VPN. Al bloquear el cliente y desbloquearlo, se actualiza la memoria caché de la información de usuario que el cliente usa en el siguiente inicio de sesión.

Recursos que se basan en la autenticación NTLM

Esta categoría de recursos incluye lo siguiente:

  • Sesión de usuario en el cliente

  • Todas las sesiones de recursos del cliente que se basan en la autenticación NTLM

  • Todas las sesiones de recursos de la red que se basan en la autenticación NTLM

    Importante

    Cuando el usuario accede a un recurso en la red que requiere autenticación NTLM, el cliente presenta las credenciales almacenadas en caché desde el contexto de seguridad del usuario. Sin embargo, el servidor de recursos consulta el controlador de dominio para obtener la información de usuario más reciente.

Estas sesiones de recursos, incluida la sesión de usuario en el cliente, no expiran. Continúan ejecutándose hasta que el usuario finaliza la sesión, como cuando el usuario cierra la sesión de Windows. El bloqueo y, a continuación, el desbloqueo del cliente no finaliza las sesiones existentes.

Recursos que se basan en vales kerberos

Cuando el usuario se conecta a la VPN e intenta acceder a un recurso de red que se basa en vales kerberos, el Centro de distribución de claves (KDC) de Kerberos obtiene la información del usuario de Active Directory. El KDC usa información de Active Directory para autenticar al usuario y crear un vale de concesión de vales (TGT). La información de pertenencia a grupos del TGT está actualizada en el momento en que se crea el TGT.

A continuación, Windows usa el TGT para obtener un vale de sesión para el recurso solicitado. A su vez, el vale de sesión usa la información de grupo del TGT.

El cliente almacena en caché el TGT y continúa utilizándolo cada vez que el usuario inicia una nueva sesión de recursos, ya sea local o en la red. El cliente también almacena en caché el vale de sesión para que pueda continuar con la conexión al recurso (por ejemplo, cuando expire la sesión de recursos). Cuando expire el vale de sesión, el cliente vuelve a enviar el TGT para un vale de sesión nuevo.

Importante

Si la pertenencia al grupo del usuario cambia después de que el usuario haya iniciado sesiones de recursos, los siguientes factores controlan cuándo el cambio afecta realmente al acceso a los recursos del usuario:

  • Un cambio en la pertenencia a grupos no afecta a las sesiones existentes.
    Las sesiones existentes continúan hasta que el usuario cierra la sesión o finaliza la sesión, o hasta que expire la sesión. Cuando una sesión expira, se produce una de las siguientes acciones:
    • El cliente vuelve a enviar el vale de sesión o envía un nuevo vale de sesión. Esta operación renueva la sesión.
    • El cliente no intenta conectarse de nuevo. La sesión no se renueva.
  • Un cambio en la pertenencia a grupos no afecta al TGT actual ni a los vales de sesión creados mediante ese TGT.
    El servicio de concesión de vales (TGS) usa la información de grupo del TGT para crear un vale de sesión en lugar de consultar Active Directory. El TGT no se renueva hasta que el usuario bloquea el cliente o cierra la sesión, o hasta que el TGT expire (normalmente 10 horas). Un TGT se puede renovar durante 10 días.

Puede usar el comando klist para purgar manualmente la caché de vales de un cliente.

Nota:

La caché de vales almacena vales para todas las sesiones de usuario en el equipo. Puede usar las klist opciones de línea de comandos para dirigir el comando a usuarios o vales específicos.

Efectos en los procesos de inicio e inicio de sesión

El servicio de directiva de grupo está optimizado para acelerar la aplicación de la directiva de grupo y reducir los efectos adversos en el rendimiento del cliente. Para obtener más información, consulte Descripción del efecto de la optimización rápida del inicio de sesión y inicio rápido en la directiva de grupo. En este artículo se proporciona una explicación detallada de cómo interactúa la directiva de grupo con los procesos de inicio e inicio de sesión. El servicio de directiva de grupo se puede ejecutar en primer plano (al iniciar o iniciar sesión) o en segundo plano (durante la sesión del usuario). El servicio procesa la directiva de grupo de la siguiente manera:

  • El procesamiento asincrónico hace referencia a procesos que no dependen del resultado de otros procesos.
  • El procesamiento sincrónico hace referencia a los procesos que dependen del resultado del otro. Por lo tanto, los procesos sincrónicos deben esperar que el proceso anterior finalice antes de que pueda comenzar el siguiente.

En la tabla siguiente se resumen los eventos que desencadenan el procesamiento en primer plano o en segundo plano, y si el procesamiento es sincrónico o asincrónico.

Desencadenador Sincrónico o asincrónico Primer plano o fondo
Inicio o apagado del equipo Sincrónico o asincrónico Primer plano
Inicio de sesión de usuario o cierre de sesión Sincrónico o asincrónico Primer plano
Programado (durante la sesión de usuario) Asincrónico Fondo
Acción de usuario (gpupdate /force) Asincrónico Fondo

Para aplicar cambios de configuración, algunas extensiones del lado cliente (CSE) requieren procesamiento sincrónico (en el inicio de sesión del usuario o en el inicio del equipo). En tales casos, el CSE identifica la necesidad de un cambio durante el procesamiento en segundo plano. La próxima vez que el usuario inicie sesión o se inicie el equipo, el CSE completa el cambio como parte de la fase de procesamiento sincrónica.

Algunos de estos CSE tienen una complicación adicional: tienen que conectarse a controladores de dominio u otros servidores de red mientras se ejecuta el procesamiento sincrónico. El redireccionamiento de carpetas y los CSE de scripts son dos de los CSE de esta categoría.

Este diseño funciona eficazmente en un entorno de oficina. Sin embargo, en un entorno de trabajo en casa, es posible que el usuario no cierre la sesión y vuelva a iniciarla mientras está conectada al dominio. El procesamiento sincrónico debe finalizar antes de que el cliente se pone en contacto con un controlador de dominio o cualquier otro servidor. Por lo tanto, algunas directivas no se pueden aplicar o actualizar correctamente.

Por ejemplo, un cambio en el redireccionamiento de carpetas requiere lo siguiente:

  • Procesamiento sincrónico en primer plano (durante el inicio de sesión del usuario).
  • Conexión a un controlador de dominio. La conexión debe estar disponible mientras se ejecuta el procesamiento.
  • Conexión al servidor de archivos que hospeda las carpetas de destino de redirección. La conexión debe estar disponible mientras se ejecuta el procesamiento.

De hecho, este cambio puede implicar dos inicios de sesión. Durante el primer inicio de sesión, el CSE de redirección de carpetas en el cliente detecta la necesidad de un cambio y solicita la ejecución de procesamiento sincrónico en primer plano. Durante el siguiente inicio de sesión, el CSE implementa el cambio de directiva.

Efectos en los informes de directivas de grupo

El servicio de directiva de grupo mantiene información de pertenencia a grupos en el cliente, en Instrumental de administración de Windows (WMI) y en el Registro. El almacén WMI se usa en el informe Conjunto resultante de directivas (generado mediante la ejecución gpresult /rde ). No se usa para tomar decisiones sobre qué GPO se aplican.

Nota:

Puede desactivar el conjunto resultante de la función de informes de directivas habilitando la directiva Desactivar conjunto resultante de la directiva de registro de directivas.

En las circunstancias siguientes, el servicio de directiva de grupo no actualiza la información de grupo en WMI:

  • La directiva de grupo se ejecuta en segundo plano. Por ejemplo, durante las actualizaciones periódicas después de iniciar el equipo o de que un usuario haya iniciado sesión, o cuando un usuario ejecute el comando para actualizar la gpupdate /force directiva de grupo.
  • La directiva de grupo se ejecuta desde la caché de directivas de grupo. Por ejemplo, cuando el usuario inicia sesión mientras el cliente no tiene acceso a un controlador de dominio.

Este comportamiento significa que la lista de grupos de un cliente de solo VPN siempre puede estar obsoleta porque el servicio de directiva de grupo no se puede conectar a la red durante el inicio de sesión del usuario. Cuando se ejecuta la directiva de grupo y no actualiza la información de grupo en WMI, el servicio de directiva de grupo podría registrar un evento similar al siguiente:

GPSVC(231c.2d14) 11:56:10:651 CSessionLogger::Log: restaurar grps de seguridad antiguas

Puede estar seguro de que WMI y la salida de gpresult /r solo se actualizan cuando aparece la siguiente línea en el registro de servicio de directiva de grupo de la cuenta que está examinando:

GPSVC(231c.2d14) 11:56:10:651 CSessionLogger::Log: registro de nuevas grps de seguridad

Solución

Para resolver los problemas descritos en este artículo, use una solución VPN que pueda establecer una conexión VPN a un cliente antes de que el usuario inicie sesión.

Soluciones alternativas

Si no puede usar una VPN que establezca una conexión de cliente antes de que el usuario inicie sesión, estas soluciones alternativas pueden mitigar los problemas que describe este artículo.

Solución alternativa para el contexto de seguridad del usuario y el control de acceso

Después de agregar un usuario a un grupo o quitar un usuario de un grupo, proporcione los pasos siguientes al usuario. Este procedimiento proporciona la única solución alternativa admitida que actualiza el contexto de seguridad del usuario en los clientes que no se conectan a la VPN antes de que el usuario inicie sesión.

Importante

Permita tiempo suficiente para que el cambio de pertenencia se replique entre los controladores de dominio antes de que el usuario inicie este procedimiento.

  1. Inicie sesión en el equipo cliente y, a continuación, conéctese a la VPN como lo hace normalmente.
  2. Cuando esté seguro de que el equipo cliente está conectado a la VPN, bloquee Windows.
  3. Desbloquee el equipo cliente y cierre la sesión de Windows.
  4. Vuelva a iniciar sesión en Windows.

La información de pertenencia a grupos (y el acceso a recursos) ahora está actualizada.

Para comprobar la información de pertenencia a grupos, abra una ventana del símbolo del sistema y, a continuación, ejecute whoami /all.

Nota:

Puede usar el siguiente script de Windows PowerShell para automatizar los pasos de bloqueo y desbloqueo de este procedimiento. En este proceso, el usuario tiene que iniciar sesión en Windows y, a continuación, tiene que cerrar sesión en Windows después de que se ejecute el script.

$fullname = $env:userdnsdomain + "\" + "$env:username" 
$MyCred = Get-Credential -Username $fullname -Message "Update Logon Credentials"
Start-Process C:\Windows\System32\cmd.exe -ArgumentList ("/C", "exit 0") -Credential $MyCred -WindowStyle Hidden -PassThru -Wait

Solución alternativa para los procesos de inicio de sesión, incluida la directiva de grupo

Puede mitigar algunos problemas realizando cambios de configuración manualmente, realizando cambios de script para que los scripts puedan ejecutarse después de que el usuario inicie sesión o haciendo que el usuario se conecte a la VPN y, a continuación, cierre la sesión de Windows. Es posible que tenga que combinar estos enfoques. En el caso de la directiva de grupo, en particular, la clave es comprender cuándo y cómo puede funcionar la directiva de grupo.

Nota:

Las conexiones de unidad asignadas y los scripts de inicio de sesión no tienen los mismos requisitos de procesamiento sincrónico en primer plano que las redirecciones de carpetas, pero requieren conectividad de controlador de dominio y servidor de recursos.

Para obtener una lista detallada de los requisitos de procesamiento de los CSE de directiva de grupo, consulte Descripción del efecto de la optimización de inicio de sesión rápido y inicio rápido en la directiva de grupo.