Résoudre les erreurs de traitement des objets de stratégie de groupe qui se produisent dans plusieurs forêts

Cet article explique comment faire pour résoudre les problèmes de traitement des objets de stratégie de groupe qui se produisent dans plusieurs forêts.

Version du produit d’origine :   Windows 10-toutes les éditions, Windows Server 2012 R2
Numéro de la base de connaissances initiale :   910206

Résumé

Cet article traite des trois scénarios suivants :

Symptômes pour le scénario 1

Ce problème se produit même si le paramètre de stratégie de groupe autoriser les utilisateurs et les profils utilisateur itinérants est activé. Une approbation externe existe entre le domaine dans lequel l’utilisateur se connecte et le domaine de l’utilisateur.

Par exemple, ce problème se produit dans le scénario suivant :

  • Un serveur Microsoft Windows Server 2003 Terminal Server appartient à l’unité d’organisation (UO) de Terminal Server dans un domaine Windows Server 2003.

  • Un utilisateur qui appartient à un domaine Microsoft Windows 2000 Server Service Pack 4 (SP4) ouvre une session sur le serveur Terminal Server de Windows Server 2003.

  • Le domaine Windows Server 2003 et le domaine Windows 2000 sont dans des forêts distinctes.

  • Il existe deux approbations externes entre le domaine Windows Server 2000 SP4 de la forêt 1 et le domaine Windows Server 2003 de la forêt 2.

  • Un objet GPO lié à l’unité d’organisation Terminal Server possède les paramètres suivants :

Ce scénario est spécifique aux approbations externes entre les domaines dans des forêts distinctes. Ce scénario ne s’applique pas aux approbations de forêt. Les approbations de forêt et les approbations externes diffèrent comme suit :

  • Les approbations externes sont utilisées dans Windows 2000 pour activer les relations d’approbation entre deux domaines qui se trouvent dans des forêts différentes.

  • Les approbations de forêt ressemblent à des approbations externes entre les domaines racines de deux forêts. Toutefois, une approbation de forêt englobe tous les domaines de chaque forêt. Les approbations de forêt exigent que tous les contrôleurs de domaine des deux forêts exécutent Windows Server 2003.

Cause du scénario 1

Le problème se produit car le contexte de sécurité du compte d’ordinateur est utilisé. Par conséquent, NTLM ne peut pas être utilisé. L’authentification Kerberos est requise.

Étapes de dépannage pour le scénario 1

Pour résoudre ce problème, procédez comme suit :

  1. Utilisez le moniteur réseau pour effectuer des suivis simultanés à partir de l’ordinateur client dans la forêt 1 et du contrôleur de domaine de connexion dans la forêt 2.
  2. Activez la journalisation USERENV. Pour plus d’informations sur la façon de procéder, voir Comment activer l’enregistrement de débogage de l’environnement utilisateur dans les versions commerciales de Windows.

Le suivi du moniteur réseau indique que l’authentification Kerberos échoue et que l’authentification NTLM n’est pas utilisée.

Les informations suivantes sont enregistrées dans le fichier Userenv. log :

USERENV (EC 0.86 c) 13:36:18:156 ProcessGPO : report de la recherche pour <LDAP://CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=nils,DC=com>
USERENV (EC 0.86 c) 13:36:18:484 GetMachineDomainDS : ldap_bind_s a échoué avec 82
USERENV (EC 0.86 c) 13:36:18:500 GetGPOInfo : départ 0

Résolution pour le scénario 1

Pour résoudre ce problème, appliquez le correctif 896683 au contrôleur de domaine Windows Server 2003 dans la forêt 2.

Un utilisateur dans un domaine externe approuvé ne peut pas se connecter à un domaine Windows Server 2003, même si le paramètre de stratégie de groupe autoriser les utilisateurs et les profils utilisateur itinérants est activé.

Ce correctif active l’objet de stratégie de groupe sans nécessiter l’authentification Kerberos.

Notes

Ce problème ne s’applique pas aux approbations de forêt entre deux forêts Windows 2003 qui fournissent une prise en charge Kerberos complète.

Symptômes pour le scénario 2

Les objets de stratégie de groupe entre forêts ne sont pas appliqués si ICMP n’est pas activé. Le traitement de la stratégie de groupe s’arrête si de nombreux paquets ICMP fragmentés ne sont pas autorisés sur le réseau en raison d’une détection de liaison lente. Dans ce cas, Microsoft Windows XP ne détecte pas de liaison rapide ou de liaison lente. Windows XP ne parvient pas à sortir du traitement de la stratégie de groupe. Seul un événement USERENV 1054 générique est enregistré dans le journal des événements d’application. Ce problème affecte les stratégies d’ordinateur et d’utilisateur.

Dans ce scénario, les informations suivantes sont enregistrées dans le fichier Userenv. log :

USERENV (22C. 91C) 15:58:22:322 ProcessGPOs :
USERENV (22C. 91C) 15:58:22:322 ProcessGPOs :
USERENV (22C. 91C) 15:58:22:332 ProcessGPOs : Starting User Group Policy (Background) Processing...
USERENV (22C. 91C) 15:58:22:332 ProcessGPOs :
USERENV (22C. 91C) 15:58:22:341 ProcessGPOs :
USERENV (22C. 91C) 15:58:22:341 EnterCriticalPolicySectionEx : saisie avec le délai 600000 et les indicateurs 0x0
USERENV (22C. 91C) 15:58:22:341 EnterCriticalPolicySectionEx : la section critique de l’utilisateur a été réclamée. Handle = 0x734
USERENV (22C. 91C) 15:58:22:351 EnterCriticalPolicySectionEx : quitter.
USERENV (22C. 91C) 15:58:22:351 ProcessGPOs : le rôle d’ordinateur est 2.
USERENV (22C. 91C) 15:58:22:370 PingComputer : vitesse de carte 10 millions BPS
USERENV (22C. 91C) 15:58:22:446 PingComputer : première fois : 76
USERENV (22C. 91C) 15:58:27:247 PingComputer : second échec de l’envoi avec 11010
USERENV (22C. 91C) 15:58:27:314 PingComputer : première fois : 73
USERENV (22C. 91C) 15:58:32:496 PingComputer : second échec de l’envoi avec 11010
USERENV (22C. 91C) 15:58:32:563 PingComputer : première fois : 73
USERENV (22C. 91C) 15:58:37:745 PingComputer : second échec de l’envoi avec 11010
USERENV (22C. 91C) 15:58:37:745 PingComputer : aucune donnée disponible
USERENV (22C. 91C) 15:58:37:926 PingComputer : vitesse de carte 10 millions BPS
USERENV (22C. 91C) 15:58:38:003 PingComputer : première fois : 75
USERENV (958.95 c) 15:58:42:517 LibMain : nom du processus : C:\WINDOWS\system32\userinit.exe
USERENV (22C. 91C) 15:58:42:994 PingComputer : second échec de l’envoi avec 11010
USERENV (22C. 91C) 15:58:43:070 PingComputer : première fois : 77
USERENV (22C. 91C) 15:58:48:243 PingComputer : second échec de l’envoi avec 11010
USERENV (22C. 91C) 15:58:48:396 PingComputer : première fois : 159
USERENV (22C. 91C) 15:58:53:492 PingComputer : second échec de l’envoi avec 11010
USERENV (22C. 91C) 15:58:53:492 PingComputer : aucune donnée disponible
USERENV (22C. 91C) 15:58:53:492 ProcessGPOs : DSGetDCName a échoué avec 59.
USERENV (22C. 91C) 15:58:53:502 ProcessGPOs : aucune journalisation WMI n’a été réalisée dans ce cycle de stratégie.
USERENV (22C. 91C) 15:58:53:502 ProcessGPOs : le traitement a échoué avec l’erreur 59.
USERENV (22C. 91C) 15:58:53:502 LeaveCriticalPolicySection : Critical section 0x734 a été publié.
USERENV (22C. 91C) 15:58:53:512 ProcessGPOs : la stratégie de groupe utilisateur a été appliquée.

Cause du scénario 2

Ce problème peut se produire lorsque les clients authentifient et extraient des paramètres de stratégie de groupe sur un lien de réseau étendu (WAN). Le processus utilisé pour détecter la vitesse de liaison implique l’envoi d’une demande ping ICMP de grande taille. Par exemple, une demande ping est envoyée dont la taille est supérieure à 2 Ko. La demande d’écho ICMP est fragmentée en paquets IP distincts par l’interface réseau du client, par un routeur WAN ou par l’interface et le routeur. Étant donné que certaines attaques IP impliquent des paquets ICMP mal formés, de nombreux routeurs sont configurés pour éliminer les paquets ICMP fragmentés.

Résolution pour le scénario 2

Important

Cette section, méthode ou tâche contient des étapes vous indiquant comment modifier le Registre. Toutefois, des problèmes graves peuvent se produire si vous modifiez le Registre de façon incorrecte. Par conséquent, veillez à suivre ces étapes scrupuleusement. Pour une meilleure protection, sauvegardez le registre avant de le modifier. Vous pouvez alors le restaurer en cas de problème. Pour plus d’informations sur la sauvegarde et la restauration du Registre, reportez-vous à la rubrique How to back up and Restore the registry in Windows.

Pour désactiver la détection des liaisons lentes sur l’ordinateur client Windows XP, définissez les valeurs de Registre suivantes :

  • Registre 1 :

    • Sous-clé de Registre : HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System
    • Nom de la valeur : GroupPolicyMinTransferRate
    • Type de valeur : DWORD
    • Données de la valeur : 0
  • Registre 2 :

    • Sous-clé de Registre : HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System
    • Nom de la valeur : GroupPolicyMinTransferRate
    • Type de valeur : DWORD
    • Données de la valeur : 0

Ces paramètres de Registre doivent être configurés manuellement, car la stratégie de groupe n’est pas appliquée dans ce scénario. Ces paramètres de Registre sont définis par ailleurs par les paramètres de stratégie de groupe suivants :

  • Paramètre de stratégie de groupe 1 :

    • Emplacement de la stratégie : configuration de l’ordinateur \ modèles d’assurance
    • Nom de la stratégie : détection de liaison lente de stratégie de groupe
    • Paramètre de stratégie : activé avec une valeur de 0
  • Paramètre de stratégie de groupe 2 :

    • Emplacement de la stratégie : Configuration utilisateur \ modèles d’assurance
    • Nom de la stratégie : détection de liaison lente de stratégie de groupe
    • Paramètre de stratégie : activé avec une valeur de 0

Ces modifications de Registre peuvent être scriptées avec le fichier Reg.ini si vous devez appliquer les modifications à de nombreux ordinateurs. Vous pouvez ensuite créer un objet de stratégie de groupe qui applique ces paramètres pour vous assurer que les paramètres sont conservés une fois le problème résolu.

Vous pouvez également modifier le profil utilisateur par défaut de sorte qu’il contienne les paramètres côté utilisateur. Par conséquent, tous les nouveaux profils appliquent les paramètres de stratégie de groupe. Une fois ces paramètres implémentés, le fichier Userenv. log indique un traitement correct de la stratégie de groupe. Les informations suivantes sont enregistrées dans le fichier Userenv. log :

USERENV (21C. 6F4) 17:09:54:872 ProcessGPOs :
USERENV (21C. 6F4) 17:09:54:872 ProcessGPOs :
USERENV (21C. 6F4) 17:09:54:872 ProcessGPOs : Starting Computer Group Policy (Background) Processing...
USERENV (21C. 944) 17:09:54:872 ProcessGPOs :
USERENV (21C. 944) 17:09:54:882 ProcessGPOs :
USERENV (21C. 944) 17:09:54:882 EnterCriticalPolicySectionEx : entrée avec le délai 600000 et les indicateurs 0x0
USERENV (21C. 944) 17:09:54:882 EnterCriticalPolicySectionEx : la section critique de l’utilisateur a été réclamée. Handle = 0xa4c
USERENV (21C. 6F4) 17:09:54:882 EnterCriticalPolicySectionEx : saisie avec le délai 600000 et les indicateurs 0x0
USERENV (21C. 6F4) 17:09:54:892 EnterCriticalPolicySectionEx : la section critique de l’ordinateur a été revendiquée. Handle = 0xa44
USERENV (21C. 944) 17:09:54:892 EnterCriticalPolicySectionEx : quitter.
USERENV (21C. 944) 17:09:54:902 ProcessGPOs : le rôle d’ordinateur est 2.
USERENV (21C. 6F4) 17:09:54:892 EnterCriticalPolicySectionEx : quitter.
USERENV (21C. 6F4) 17:09:54:912 ProcessGPOs : le rôle d’ordinateur est 2.
USERENV (21C. 944) 17:09:54:902 IsSlowLink : le taux de transfert de liaison lente est égal à 0. Toujours télécharger la stratégie.

Symptômes pour le scénario 3

Les administrateurs ne peuvent pas utiliser le mode de planification RSoP pour planifier les scénarios qui s’étendent sur plusieurs forêts dans Windows Server 2003. Par exemple, vous ne pouvez pas planifier un scénario dans lequel un utilisateur se connecte à une station de travail dans la forêt 1 à partir de la forêt 2. Lorsque vous essayez d’exécuter le mode de planification RSoP dans un environnement entre forêts, vous pouvez recevoir le message d’erreur de stratégie de groupe suivant :

Les scénarios en mode de planification entre forêts ne sont actuellement pas pris en charge.

Cause du scénario 3

Ce problème se produit parce que le mode de planification RSoP ne prend pas en charge les scénarios entre forêts. Dans de nombreux scénarios, RSoP ne peut pas valider les informations renvoyées par un contrôleur de domaine se trouvant dans une autre forêt. Le groupe utilisateurs authentifiés doit disposer d’autorisations de lecture pour les stratégies appropriées pour pouvoir lire une stratégie particulière dans un environnement entre forêts.