Partager via

Les modifications d’appartenance au groupe ne sont pas mises à jour sur certaines connexions VPN

Cet article décrit une situation dans laquelle les utilisateurs VPN peuvent rencontrer des problèmes d’accès aux ressources ou de configuration après leur modification de l’appartenance au groupe.

S’applique à : toutes les versions prises en charge du client Windows

Symptômes

En réponse à la pandémie de Covid-19, un nombre croissant d’utilisateurs travaillent maintenant, apprennent et socialisent à domicile. Ils se connectent au lieu de travail à l’aide de connexions VPN. Ces utilisateurs VPN signalent que lorsqu’ils sont ajoutés ou supprimés des groupes de sécurité, les modifications peuvent ne pas prendre effet comme prévu. Ils signalent des symptômes tels que les suivants :

  • Les modifications apportées à l’accès aux ressources réseau ne prennent pas effet.
  • Les objets de stratégie de groupe qui ciblent des groupes de sécurité spécifiques ne s’appliquent pas correctement.
  • La stratégie de redirection de dossiers n’est pas appliquée correctement.
  • Les règles AppLocker qui ciblent des groupes de sécurité spécifiques ne fonctionnent pas.
  • Les scripts d’ouverture de session qui créent des lecteurs mappés, y compris le dossier d’accueil de l’utilisateur ou les mappages de lecteurs GPP, ne fonctionnent pas.
  • La whoami /groups commande (exécutée à une invite de commandes) signale une liste obsolète d’appartenances de groupe pour le contexte de sécurité local de l’utilisateur.
  • La gpresult /r commande (exécutée à une invite de commandes) signale une liste obsolète des appartenances aux groupes.

Si l’utilisateur verrouille et déverrouille Windows pendant que le client reste connecté au VPN, certains de ces symptômes se résolvent eux-mêmes. Par exemple, certaines modifications d’accès aux ressources prennent effet. Par la suite, si l’utilisateur se déconnecte de Windows, puis se reconnecte (fermant toutes les sessions qui utilisent des ressources réseau), plus les symptômes se résolvent. Toutefois, les scripts d’ouverture de session peuvent ne pas fonctionner correctement, et la commande peut ne pas refléter les modifications apportées à l’appartenance gpresult /r au groupe. L’utilisateur ne peut pas contourner le problème en utilisant la runas commande pour démarrer une nouvelle session Windows sur le client. Cette commande utilise simplement les mêmes informations d’identification pour démarrer la nouvelle session.

L’étendue de cet article inclut des environnements qui ont implémenté Authentication Mechanism Assurance (AMA) dans le domaine et dans lesquels les utilisateurs doivent s’authentifier à l’aide d’une carte à puce pour accéder aux ressources réseau. Pour plus d’informations, consultez Description de l’utilisation d’AMA dans les scénarios d’ouverture de session interactive dans Windows.

Cause

Dans un environnement de bureau, il est courant qu’un utilisateur se déconnecte de Windows à la fin du travail. Lorsque l’utilisateur se connecte le lendemain, le client est déjà connecté au réseau et a un accès direct à un contrôleur de domaine. Dans ces conditions, les modifications apportées à l’appartenance au groupe prennent effet rapidement. L’utilisateur a les niveaux d’accès corrects le lendemain (la prochaine fois que l’utilisateur se connecte). De même, les modifications apportées à la stratégie de groupe semblent prendre effet dans un jour ou deux (après que l’utilisateur se connecte une ou deux fois, selon les stratégies qui sont planifiées pour s’appliquer).

Dans un environnement domestique, l’utilisateur peut se déconnecter du VPN à la fin du travailday et verrouiller Windows. Ils ne se déconnectent peut-être pas. Lorsque l’utilisateur déverrouille Windows (ou se connecte) le lendemain matin, le client ne se connecte pas au VPN (et n’a pas accès à un contrôleur de domaine) tant que l’utilisateur n’a pas déverrouillé Windows ou connecté. Le client connecte l’utilisateur à Windows à l’aide d’informations d’identification mises en cache au lieu de contacter le contrôleur de domaine pour obtenir de nouvelles informations d’identification. Windows crée un contexte de sécurité pour l’utilisateur basé sur les informations mises en cache. Windows applique également la stratégie de groupe de manière asynchrone, en fonction du cache de stratégie de groupe local. Cette utilisation des informations mises en cache peut entraîner le comportement suivant :

  • L’utilisateur peut avoir accès aux ressources qu’il ne doit pas avoir et n’a peut-être pas accès aux ressources qu’il doit avoir.
  • Les paramètres de stratégie de groupe peuvent ne pas être appliqués comme prévu, ou les paramètres de stratégie de groupe peuvent être obsolètes.

Ce comportement se produit parce que Windows utilise des informations mises en cache pour améliorer les performances lorsque les utilisateurs se connectent. Windows utilise également des informations mises en cache pour connecter des utilisateurs sur des clients joints à un domaine qui ne sont pas connectés au réseau. Des conséquences inattendues se produisent si le client utilise exclusivement un VPN pour se connecter au réseau, et que le client ne peut pas établir la connexion VPN tant qu’après la connexion de l’utilisateur.

Important

Ce comportement est pertinent uniquement dans le scénario d’ouverture de session interactive. L’accès aux ressources réseau fonctionne comme prévu, car l’ouverture de session réseau n’utilise pas d’informations mises en cache. Au lieu de cela, les informations de groupe proviennent d’une requête de contrôleur de domaine.

Effets sur le contexte de sécurité utilisateur et le contrôle d’accès

Si le client ne peut pas se connecter à un contrôleur de domaine lorsque l’utilisateur se connecte, Windows base le contexte de sécurité utilisateur sur les informations mises en cache. Une fois que Windows a créé le contexte de sécurité utilisateur, il ne met pas à jour le contexte avant la prochaine connexion de l’utilisateur.

Par exemple, supposons qu’un utilisateur est affecté à un groupe dans Active Directory pendant que l’utilisateur est hors connexion. L’utilisateur se connecte à Windows, puis se connecte au VPN. Si l’utilisateur ouvre une fenêtre d’invite de commandes, puis exécute la whoami /groups commande, la liste des groupes n’inclut pas le nouveau groupe. L’utilisateur verrouille, puis déverrouille le bureau tout en restant connecté au VPN. La whoami /groups commande produit toujours le même résultat. Enfin, l’utilisateur se déconnecte de Windows. Une fois que l’utilisateur se reconnecte, la whoami /groups commande produit le résultat correct.

L’effet des informations mises en cache sur l’accès de l’utilisateur aux ressources dépend des facteurs suivants :

  • Indique si les ressources se trouvent sur le client ou sur le réseau
    Les ressources sur le réseau nécessitent une étape d’authentification supplémentaire (une ouverture de session réseau au lieu d’une ouverture de session interactive). Cette étape signifie que les informations de groupe que la ressource utilise pour déterminer l’accès proviennent toujours d’un contrôleur de domaine, et non du cache client.
  • Indique si les ressources utilisent des tickets Kerberos ou d’autres technologies (telles que des jetons d’accès NTLM) pour authentifier et autoriser les utilisateurs
  • Indique si l’utilisateur reprend une session de ressource existante ou démarre une nouvelle session de ressources
  • Indique si l’utilisateur verrouille et déverrouille le client lors de la connexion au VPN
    Si l’utilisateur verrouille le client lors de sa connexion au VPN, puis le déverrouille, le client met à jour son cache des groupes d’utilisateurs. Toutefois, cette modification n’affecte pas le contexte de sécurité utilisateur existant ou les sessions qui s’exécutaient lorsque l’utilisateur a verrouillé le client.
  • Indique si l’utilisateur se déconnecte du client lors de la connexion au VPN, puis se reconnecte
    Les effets de la déconnexion, puis de la connexion diffèrent selon que l’utilisateur a verrouillé et déverrouillé le client en premier lors de la connexion au VPN. Verrouillez le client, puis déverrouillez-le met à jour le cache des informations utilisateur que le client utilise lors de la prochaine connexion.

Ressources qui s’appuient sur l’authentification NTLM

Cette catégorie de ressources comprend les éléments suivants :

  • Session utilisateur sur le client

  • Toutes les sessions de ressources sur le client qui s’appuient sur l’authentification NTLM

  • Toutes les sessions de ressources sur le réseau qui s’appuient sur l’authentification NTLM

    Important

    Lorsque l’utilisateur accède à une ressource sur le réseau qui nécessite l’authentification NTLM, le client présente des informations d’identification mises en cache à partir du contexte de sécurité utilisateur. Toutefois, le serveur de ressources interroge le contrôleur de domaine pour obtenir les informations utilisateur les plus récentes.

Ces sessions de ressources, y compris la session utilisateur sur le client, n’expirent pas. Ils continuent à s’exécuter jusqu’à ce que l’utilisateur termine la session, par exemple lorsque l’utilisateur se déconnecte de Windows. Le verrouillage, puis le déverrouillage du client ne termine pas les sessions existantes.

Ressources qui s’appuient sur des tickets Kerberos

Lorsque l’utilisateur se connecte au VPN, puis tente d’accéder à une ressource réseau qui s’appuie sur des tickets Kerberos, le Centre de distribution de clés Kerberos (KDC) obtient les informations de l’utilisateur à partir d’Active Directory. Le KDC utilise des informations d’Active Directory pour authentifier l’utilisateur et créer un ticket d’octroi de ticket (TGT). Les informations d’appartenance au groupe dans le TGT sont à jour au moment de la création du TGT.

Windows utilise ensuite le TGT pour obtenir un ticket de session pour la ressource demandée. Le ticket de session utilise à son tour les informations de groupe du TGT.

Le client met en cache le TGT et continue à l’utiliser chaque fois que l’utilisateur démarre une nouvelle session de ressources, qu’elle soit locale ou sur le réseau. Le client met également en cache le ticket de session afin qu’il puisse continuer à se connecter à la ressource (par exemple, lorsque la session de ressource expire). Lorsque le ticket de session expire, le client resoumet le TGT pour un nouveau ticket de session.

Important

Si l’appartenance au groupe de l’utilisateur change une fois que l’utilisateur a démarré des sessions de ressources, les facteurs suivants contrôlent quand la modification affecte réellement l’accès aux ressources de l’utilisateur :

  • Une modification de l’appartenance au groupe n’affecte pas les sessions existantes.
    Les sessions existantes continuent jusqu’à ce que l’utilisateur se déconnecte ou termine la session, ou jusqu’à l’expiration de la session. Lorsqu’une session expire, l’une des opérations suivantes se produit :
    • Le client soumet à nouveau le ticket de session ou envoie un nouveau ticket de session. Cette opération renouvelle la session.
    • Le client n’essaie pas de se connecter à nouveau. La session ne se renouvelle pas.
  • Une modification de l’appartenance au groupe n’affecte pas le TGT actuel, ni les tickets de session créés à l’aide de ce TGT.
    Le service d’octroi de tickets (TGS) utilise les informations de groupe du TGT pour créer un ticket de session au lieu d’interroger Active Directory lui-même. Le TGT n’est pas renouvelé tant que l’utilisateur ne verrouille pas le client ou se déconnecte, ou jusqu’à ce que le TGT expire (généralement 10 heures). Un TGT peut être renouvelé pendant 10 jours.

Vous pouvez utiliser la commande klist pour vider manuellement le cache de tickets d’un client.

Note

Le cache de tickets stocke les tickets pour toutes les sessions utilisateur sur l’ordinateur. Vous pouvez utiliser les options de klist ligne de commande pour cibler la commande à des utilisateurs ou des tickets spécifiques.

Effets sur les processus de démarrage et de connexion

Le service de stratégie de groupe est optimisé pour accélérer l’application de la stratégie de groupe et réduire les effets néfastes sur les performances du client. Pour plus d’informations, consultez Comprendre l’effet de l’optimisation rapide de l’ouverture de session rapide et du démarrage rapide sur la stratégie de groupe. Cet article fournit une explication détaillée de la façon dont la stratégie de groupe interagit avec les processus de démarrage et de connexion. Le service de stratégie de groupe peut s’exécuter au premier plan (au démarrage ou à la connexion) ou en arrière-plan (pendant la session de l’utilisateur). Le service traite la stratégie de groupe de la manière suivante :

  • Le traitement asynchrone fait référence aux processus qui ne dépendent pas du résultat d’autres processus.
  • Le traitement synchrone fait référence aux processus qui dépendent des résultats des uns des autres. Par conséquent, dans le cadre de processus synchrones, un processus doit se terminer pour que le processus suivant puisse commencer.

Le tableau suivant récapitule les événements qui déclenchent le traitement au premier plan ou en arrière-plan, et indique si le traitement est synchrone ou asynchrone.

Déclencheur Synchrone ou asynchrone Premier plan ou arrière-plan
Démarrage ou arrêt de l’ordinateur Synchrone ou asynchrone Premier plan
Connexion ou déconnexion de l’utilisateur Synchrone ou asynchrone Premier plan
Planifié (pendant la session de l’utilisateur) Asynchrone Background
Action de l’utilisateur (gpupdate /force) Asynchrone Background

Pour appliquer les modifications de configuration, certaines extensions côté client (CSE) nécessitent un traitement synchrone (au démarrage de l’utilisateur ou de l’ordinateur). Dans ce cas, le CSE identifie la nécessité d’une modification pendant le traitement en arrière-plan. La prochaine fois que l’utilisateur se connecte ou que l’ordinateur démarre, le CSE termine la modification dans le cadre de la phase de traitement synchrone.

Certaines de ces CSE ont une complication supplémentaire : elles doivent se connecter aux contrôleurs de domaine ou à d’autres serveurs réseau pendant que le traitement synchrone s’exécute. Les CSE de redirection de dossiers et scripts sont deux des CSE de cette catégorie.

Cette conception fonctionne efficacement dans un environnement de bureau. Toutefois, dans un environnement de travail à domicile, l’utilisateur peut ne pas se déconnecter et se reconnecter lors de la connexion au domaine. Le traitement synchrone doit se terminer avant que le client contacte un contrôleur de domaine ou un autre serveur. Par conséquent, certaines stratégies ne peuvent pas être appliquées ou mises à jour correctement.

Par exemple, une modification de la redirection de dossiers nécessite tous les éléments suivants :

  • Traitement synchrone au premier plan (lors de la connexion de l’utilisateur).
  • Connexion à un contrôleur de domaine. La connexion doit être disponible pendant l’exécution du traitement.
  • Connexion au serveur de fichiers qui héberge les dossiers cibles de redirection. La connexion doit être disponible pendant l’exécution du traitement.

En fait, cette modification peut impliquer deux connexions. Lors de la première connexion, le CSE de redirection de dossiers sur le client détecte la nécessité d’une modification et demande l’exécution du traitement synchrone au premier plan. Lors de la connexion suivante, le CSE implémente la modification de la stratégie.

Effets sur les rapports de stratégie de groupe

Le service stratégie de groupe gère les informations d’appartenance au groupe sur le client, dans WMI (Windows Management Instrumentation) et dans le Registre. Le magasin WMI est utilisé dans l’ensemble de stratégies résultant (généré par l’exécution gpresult /r). Il n’est pas utilisé pour prendre des décisions sur les objets de stratégie de groupe appliqués.

Note

Vous pouvez désactiver la fonction De création de rapports de stratégie résultante en activant la stratégie de journalisation de stratégie Désactiver le jeu de journalisation des stratégies.

Dans les circonstances suivantes, le service de stratégie de groupe ne met pas à jour les informations de groupe dans WMI :

  • La stratégie de groupe s’exécute en arrière-plan. Par exemple, pendant les actualisations périodiques une fois l’ordinateur démarré ou un utilisateur connecté, ou lorsqu’un utilisateur exécute la commande pour actualiser la gpupdate /force stratégie de groupe.
  • La stratégie de groupe est en cours d’exécution à partir du cache de stratégie de groupe. Par exemple, lorsque l’utilisateur se connecte pendant que le client n’a pas accès à un contrôleur de domaine.

Ce comportement signifie que la liste des groupes sur un client VPN uniquement peut toujours être obsolète, car le service stratégie de groupe ne peut pas se connecter au réseau pendant la connexion de l’utilisateur. Lorsque la stratégie de groupe s’exécute et ne met pas à jour les informations de groupe dans WMI, le service de stratégie de groupe peut enregistrer un événement semblable à ce qui suit :

GPSVC(231c.2d14) 11:56:10:651 CSessionLogger ::Log : restauration d’anciens grps de sécurité

Vous pouvez être certain que WMI et la sortie d’une gpresult /r instance sont mises à jour uniquement lorsque la ligne suivante apparaît dans le journal du service de stratégie de groupe pour le compte que vous examinez :

GPSVC(231c.2d14) 11:56:10:651 CSessionLogger ::Log : journalisation de nouveaux grps de sécurité

Résolution

Pour résoudre les problèmes décrits par cet article, utilisez une solution VPN capable d’établir une connexion VPN à un client avant la connexion de l’utilisateur.

Solutions de contournement

Si vous ne pouvez pas utiliser un VPN qui établit une connexion cliente avant la connexion de l’utilisateur, ces solutions de contournement peuvent atténuer les problèmes décrits par cet article.

Solution de contournement pour le contexte de sécurité utilisateur et le contrôle d’accès

Après avoir ajouté un utilisateur à un groupe ou supprimé un utilisateur d’un groupe, fournissez les étapes suivantes à l’utilisateur. Cette procédure fournit la seule solution de contournement prise en charge qui actualise le contexte de sécurité utilisateur sur les clients qui ne se connectent pas au VPN avant la connexion de l’utilisateur.

Important

Laissez suffisamment de temps pour que la modification de l’appartenance soit répliquée entre les contrôleurs de domaine avant que l’utilisateur démarre cette procédure.

  1. Connectez-vous à l’ordinateur client, puis connectez-vous au VPN comme vous le faites généralement.
  2. Lorsque vous êtes sûr que l’ordinateur client est connecté au VPN, verrouillez Windows.
  3. Déverrouillez l’ordinateur client, puis déconnectez-vous de Windows.
  4. Connectez-vous à Nouveau à Windows.

Les informations d’appartenance au groupe (et l’accès aux ressources) sont désormais à jour.

Vous pouvez vérifier les informations d’appartenance au groupe en ouvrant une fenêtre d’invite de commandes, puis en exécutant whoami /all.

Note

Vous pouvez utiliser le script Windows PowerShell suivant pour automatiser les étapes de verrouillage et de déverrouillage de cette procédure. Dans ce processus, l’utilisateur doit se connecter à Windows, puis se déconnecter de Windows après l’exécution du 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

Solution de contournement pour les processus de connexion, y compris la stratégie de groupe

Vous pouvez atténuer certains problèmes en effectuant manuellement des modifications de configuration, en apportant des modifications de script afin que les scripts puissent s’exécuter une fois que l’utilisateur se connecte ou que l’utilisateur se connecte au VPN, puis déconnectez-vous de Windows. Vous devrez peut-être combiner ces approches. Pour la stratégie de groupe, en particulier, la clé consiste à comprendre quand et comment la stratégie de groupe peut fonctionner.

Note

Les connexions de lecteur mappées et les scripts d’ouverture de session n’ont pas les mêmes exigences de traitement synchrone au premier plan que les redirections de dossiers, mais elles nécessitent une connectivité de contrôleur de domaine et de serveur de ressources.

Pour obtenir la liste détaillée des exigences de traitement des CSE de stratégie de groupe, consultez Comprendre l’effet de l’optimisation rapide de l’ouverture de session rapide et du démarrage rapide sur la stratégie de groupe.