Stratégie de groupe absente sur le VPN ? Vérifiez l’étendue avant le tunnel

Un réglage qui s’appliquait sur le réseau du bureau cesse de s’appliquer la semaine où un utilisateur commence à travailler par VPN, et le tunnel est mis en cause avant même que quiconque ouvre un rapport. La stratégie de groupe décide quels paramètres arrivent sur l’utilisateur et l’ordinateur Windows, récupère la matière auprès du domaine et exécute le traitement côté client, et ces trois étapes échouent de trois façons différentes. Le tunnel ne change que le chemin dont dispose le client. Dérouler les vérifications dans l’ordre évite de courir après un problème de permissions de fichier comme s’il s’agissait d’un problème de routage.

Commencer par le paramètre, pas par le tunnel

Notez une GPO attendue et un paramètre précis qu’elle contient, puis déterminez si ce paramètre relève de la configuration utilisateur ou de la configuration ordinateur. Cela suppose un client Windows autorisé et joint au domaine sur un VPN approuvé, et non un appareil non géré ou uniquement cloud que l’on transforme en membre du domaine. La réponse sur l’étendue détermine qui peut lire le résultat et si une élévation est nécessaire, réglez-la donc avant d’exécuter quoi que ce soit.

Demandez à l’administrateur du domaine quels liens, emplacements d’objet, filtres de sécurité et filtres WMI sont censés être en jeu. Modifier ces contrôles pour faire passer un test est un autre projet avec un autre responsable.

Lire le rapport avec le compte qui possède le paramètre

Dans la session de l’utilisateur concerné, exécutez whoami /user puis gpresult /scope user /r. Le compte qui a authentifié le VPN n’est pas automatiquement le compte Windows dont vous lisez la stratégie, et une vérification lancée depuis un compte administrateur répond à une autre question. Enregistrez la référence sous un nouveau nom de fichier, par exemple %TEMP%\vpn-policy-user-before.html. La référence de gpresult documente les commutateurs d’étendue et de sortie, et il vaut la peine de savoir que générer un rapport n’actualise rien.

La stratégie ordinateur a sa propre étendue et son propre contexte de permissions, inspectez-la donc séparément avec l’élévation requise. Réunir les deux étendues dans un seul rapport, c’est ainsi qu’un paramètre utilisateur est déclaré manquant alors qu’il n’a jamais relevé de cette étendue.

La découverte n’est pas l’accès : d’abord les enregistrements SRV, puis SMB

Une fois le VPN approuvé connecté, confirmez que le client résout les contrôleurs de domaine par le chemin DNS prévu ; un site web public qui se charge ne dit rien de la découverte des contrôleurs. Pour le domaine illustratif corp.example, nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example répond à la question que vous vous posez vraiment. Un enregistrement de service renvoyé n’est qu’une preuve de découverte, car l’adresse du contrôleur sélectionné doit encore être joignable avec l’authentification requise et les services d’annuaire autorisés. La matière de stratégie arrive ensuite depuis SYSVOL, ce qui est une lecture SMB sur ce contrôleur précis et non un test ICMP.

Une preuve plus faible est facile à confondre avec une preuve. Une réponse ICMP d’un contrôleur, à côté d’une lecture refusée d’un modèle de stratégie, produit un rapport qui semble vide pour une raison que personne n’a encore reliée.

Gardez cohérentes les permissions de service AD, les chemins de retour et la synchronisation horaire du déploiement, plutôt que de les remplacer par une ouverture de pare-feu générale ou un serveur DNS public. Des données de stratégie qui diffèrent entre contrôleurs sont une question de réplication pour le propriétaire de l’annuaire.

Une actualisation, deux rapports, une comparaison

Le chemin étant prouvé, demandez l’actualisation pertinente avec gpupdate /target:user et lisez le résultat au lieu de le supposer. L’actualisation par défaut applique la stratégie modifiée tandis que /force demande une réapplication ; ni l’une ni l’autre ne répare le DNS, les permissions de fichier ou le filtrage. Certaines extensions ne se terminent qu’à une connexion ultérieure ou à un autre événement au premier plan, une seule exécution n’est donc pas un verdict. Ajouter des commutateurs d’arrêt de session ou de redémarrage à la session d’un utilisateur distant comme diagnostic de routine jette ce qu’il avait ouvert.

Générez un second rapport sous un autre nom de fichier et comparez le temps de traitement, la GPO attendue, son statut appliqué ou refusé et le paramètre lui-même. Un rapport d’une session réussie antérieure ne prouve rien pour cette actualisation. Une stratégie filtrée pointe vers l’applicabilité plutôt que vers le transport, ce qui change qui possède l’étape suivante.

Rattacher l’échec à une seule activité

Dans l’Observateur d’événements, commencez par l’avertissement ou l’erreur de stratégie de groupe dans le journal Système, puis passez au journal opérationnel GroupPolicy sous Journaux des applications et des services. Filtrez ce journal opérationnel par l’identifiant d’activité de l’actualisation que vous venez d’exécuter, car une nouvelle actualisation obtient un nouvel identifiant et le mélanger aux événements de la veille produit une conclusion assurée et fausse. Notez l’heure, le contexte utilisateur ou ordinateur, le contrôleur sélectionné, la GPO, le code d’erreur et la dépendance en échec.

Cette note est ce sur quoi le propriétaire du réseau ou de l’annuaire peut agir. Être connecté au VPN et avoir lancé gpupdate plusieurs fois ne sont pas des preuves, et ni l’un ni l’autre ne survit à une passation.

Gardez les rapports HTML privés, car ils exposent des noms internes, des appartenances de groupe et la configuration de sécurité. Une fois le paramètre confirmé, supprimez les permissions temporaires que vous avez ajoutées au lieu de les laisser en place.