Procédures de dépannage des erreurs de traitement des stratégies de groupe dans un domaine Active Directory

Lors de l’application d’une stratégie de groupe, les membres d’un domaine Active Directory (AD) peuvent rencontrer des problèmes, pour diverses raisons. Cet article présente certaines des raisons les plus courantes et fournit des instructions pour le dépannage des problèmes sous-jacents.
 
Dépannage de base
La première étape pour résoudre ces problèmes est de déterminer leur étendue. S’il n’existe qu’une seule machine ne parvenant pas à traiter la stratégie de groupe, le problème provient probablement d’un dysfonctionnement ou d’une mauvaise configuration de cette machine. Si le problème est plus répandu, il se peut qu’il provienne d’un contrôleur de domaine (DC) ou d’AD lui-même.

Si une seule machine est touchée, exécutez gpupdate /force sur la machine concernée avant de poursuivre le dépannage. Cela permet de vous assurer que la panne ne résulte pas d’un problème réseau temporaire qui aurait été résolu depuis.

Lorsqu’une machine ne parvient pas à traiter la stratégie de groupe, elle génère typiquement une ou plusieurs erreurs Userenv dans son journal d’application. Les numéros d’ID d’événement les plus courants sont les suivants : 1030, 1053, 1054 et 1058. Les descriptions des erreurs spécifiques se produisant sur une machine affectée donnent généralement une idée du problème sous-jacent.

Problèmes de DNS
La cause qui revient sans doute le plus souvent lors d’échecs des stratégies de groupe, comme dans nombre d’autres problèmes en lien avec AD, est liée à un problème de résolution de noms. Si les erreurs Userenv sur une machine affectée comprennent une expression telle que « chemin réseau introuvable » ou « impossible de trouver un contrôleur de domaine », le DNS peut être en cause. Voici quelques conseils pour résoudre ce type de problème :

• Ouvrez une invite de commandes sur une machine affectée et exécutez nslookup domain (nslookup mydomain.local, par exemple). Cette commande doit renvoyer les adresses IP de tous les contrôleurs de domaine du domaine. Si d’autres adresses sont renvoyées, il y a probablement des enregistrements non valides dans le DNS. Vous pouvez également utiliser la commande nslookup pour convertir les noms de chaque contrôleur de domaine en adresses IP.
• Exécuter ipconfig /all sur une machine affectée et assurez-vous qu’elle est configurée pour utiliser uniquement des serveurs DNS internes. L’utilisation de serveurs DNS erronés est la cause principale de problèmes DNS dans un domaine, et elle peut être facilement résolue. Toutes les machines jointes au domaine doivent utiliser uniquement des serveurs DNS internes, qui servent généralement de contrôleurs de domaines.
• Si la machine affectée semble utiliser les serveurs DNS corrects, vérifiez la console DNS sur le contrôleur de domaine pour vous assurer que les enregistrements appropriés existent. Assurez-vous que chaque contrôleur de domaine a deux enregistrements de l’hôte (A) dans la zone de recherche directe du domaine : l’un avec le nom d’hôte du contrôleur de domaine et l’autre avec un nom « (identique à celui du dossier parent) ». Les deux enregistrements doivent comprendre l’adresse IP du contrôleur de domaine.
• Une fois qu’un problème de DNS a été résolu, exécutez ipconfig /flushdns sur toutes les machines affectées. Cela aura pour effet de purger toutes les données non valides du cache du résolveur sur ces machines.

Problèmes de canal sécurisé
Ce type de problème se produit lorsque le mot de passe de compte d’ordinateur stocké localement d’une machine jointe à un domaine ne correspond pas à son mot de passe dans AD. Les problèmes de canal sécurisé empêchent une machine de s’authentifier auprès d’un contrôleur de domaine. Ils prennent souvent la forme d’une erreur de type « Accès refusé » chaque fois que cette machine tente d’accéder aux ressources du domaine, y compris aux mises à jour des stratégies de groupe. Naturellement, les événements d’« accès refusé » ne sont pas tous provoqués par des problèmes de canal sécurisé, mais si une machine affectée présente des erreurs Userenv dans son journal d’application, avec l’expression « accès refusé » dans sa description, le canal sécurisé doit être considéré comme une cause possible.

• La commande nltest peut être utilisée pour tester (et réinitialiser, si nécessaire) le canal sécurisé sur un membre du domaine.
• Le raccourci clavier netdom permet également de tester et de réinitialiser le canal sécurisé.
• La cmdlet PowerShell Test-ComputerSecureChannel offre un autre moyen de tester ou de réinitialiser le canal sécurisé.
• Supprimer la machine affectée du domaine, réinitialiser le compte d’ordinateur AD puis joindre à nouveau la machine au domaine permet de réinitialiser son canal sécurisé. Ce n’est toutefois pas toujours possible.

Problèmes avec SYSVOL
Sur chaque contrôleur de domaine d’un domaine, les fichiers de modèle de stratégie de groupe sont stockés dans le partage SYSVOL. Les données SYSVOL sont répliquées d’un contrôleur de domaine à l’autre via le système de réplication de fichiers (FRS) ou la réplication de système de fichiers distribués (DFSR). Si un contrôleur de domaine ne possède pas de partage SYSVOL, c’est généralement le signe d’un problème avec la réplication SYSVOL.

Décalage de l’horloge
Par défaut, l’authentification Kerberos exige que les horloges des machines jointes à un domaine présentent moins de cinq minutes d’écart. Le dépassement de ce seuil entraîne un échec d’authentification, lequel empêche à son tour le traitement de la stratégie de groupe. Chaque élément du domaine devrait être configuré de telle sorte que son horloge soit synchronisée avec AD, à une exception près. Le contrôleur de domaine détenant le rôle FSMO d’émulateur PDC est la source de temps faisant autorité pour le domaine. Elle est par conséquent la seule machine d’un domaine à devoir se synchroniser avec une source externe, telle qu’un serveur NTP public.

Plus d’informations sur la configuration du service de temps Windows sont disponibles ici.

Fichiers de stratégie de groupe manquants
Un ou plusieurs fichiers de stratégie de groupe ont peut-être été supprimés de leur emplacement de stockage dans SYSVOL. Vous pouvez le vérifier en accédant à SYSVOL\domain\Policies dans l’Explorateur de fichiers et en recherchant les fichiers spécifiques mentionnés dans les erreurs Userenv. Les fichiers de chaque stratégie de groupe (GPO) se trouvent dans un sous-dossier du dossier Policies. Chaque sous-dossier est nommé d’après l’identificateur global unique (GUID) hexadécimal de la GPO dont il contient les fichiers.

Si des fichiers de stratégie sont manquants dans tous les contrôleurs de domaine, ils peuvent être restaurés grâce à une sauvegarde. Si la stratégie de domaine par défaut ou des fichiers de stratégie du contrôleur de domaine par défaut sont manquants et qu’aucune sauvegarde n’est disponible, la commande dcgpofix permet de restaurer les paramètres par défaut de ces deux stratégies.

Plus d’informations sur dcgpofix sont disponibles ici.