Windows 10: la stratégie de groupe ne s'applique pas directement après le démarrage, réussit plus tard
Mon problème est que la stratégie de groupe n'est pas appliquée lorsqu'un client est fraîchement démarré. Directement après le démarrage, le client publie un message d'erreur dans le journal des événements avec la source "GroupPolicy (Microsoft-Windows-GroupPolicy)" et l'ID d'événement 1058: "Le traitement de la stratégie de groupe a échoué. [...]". Dans l'onglet Détails, le ErrorCode est 50, ce qui signifie ERROR_NOT_SUPPORTED. Ce n'est pas seulement un problème esthétique: les politiques ne sont vraiment pas appliquées correctement: les lecteurs réseau mappés ne sont pas là, par exemple. Après un certain temps, l'exécution de "gpupdate" fonctionne et les stratégies sont appliquées normalement: les lecteurs réseau mappés apparaissent.
Le scénario le plus simple dans lequel j'ai pu reproduire le problème: domaine nouvellement créé sur Windows Server 2012R2 fraîchement installé, le client est une machine Windows 10 64 bits fraîchement installée. Le domaine se compose d'un seul contrôleur de domaine et n'a aucune relation avec d'autres domaines.
Étant donné que le message d'erreur indique que Windows ne peut pas lire un fichier .GPT à partir du partage Sysvol du domaine, j'ai essayé d'accéder au même fichier à partir d'une invite de commandes. Et en effet, lorsque j'ouvre une invite de commande juste après le démarrage, j'obtiens ceci:
C:\Users\username>dir \\domain.example.com\sysvol
The request is not supported.
Après avoir attendu une minute ou deux, l'exécution de la même commande donnera une liste de répertoires. Exécuter gpupdate à ce stade fonctionnera très bien.
J'ai défini le paramètre de stratégie de groupe "Toujours attendre le réseau au démarrage et à l'ouverture de session de l'ordinateur" sur "Activé" et je sais que cette stratégie est appliquée: dans le même objet de stratégie, un paramètre de Registre est spécifié et lorsque je vérifie le Registre sur le client, le paramètre spécifié est là.
Autres facteurs pouvant être pertinents:
- NTLM est restreint dans le domaine, mais cela ne semble pas avoir d'importance: même après l'avoir activé, mis à jour les politiques et redémarré toutes les machines, les symptômes restent les mêmes.
- Peu importe que le serveur soit configuré à l'aide de DHCP ou avec une configuration statique.
- Le serveur DNS du domaine ne prend pas en charge les mises à jour dynamiques. Les enregistrements nécessaires ont été ajoutés manuellement (depuis C:\Windows\System32\config\netlogon.dns)
- L'hibernation est désactivée sur le client (à l'aide de
powercfg /h off) donc chaque démarrage est un démarrage complet, pas un démarrage rapide - Le délai d'attente de traitement de la stratégie de démarrage de la stratégie est défini sur 120 secondes
- La connectivité au DC fonctionne bien. Les pings fonctionneront. La désactivation du client, la désactivation de mon compte dans AD, l'activation du client empêchera le client de me connecter: il remarque immédiatement que le le compte est désactivé.
- En dehors de ce problème, je ne remarque rien d'extraordinaire.
Cela semble être davantage un problème SMB qu'un problème de stratégie de groupe. Renifler la connexion côté serveur montre quelque chose d'intéressant: la première fois que j'exécute la commande dir \\domain.example.com\sysvol, ce qui suit s'affiche dans Microsoft Message Analyzer sur le contrôleur de domaine:
- Le client configure une connexion TCP au port 445 du contrôleur de domaine et une comNégociation est effectuée avec succès (DialectRevision: 0x02FF).
- Immédiatement après cela, une négociation est effectuée avec succès. Le DialectRevision est 0x0302.
- Immédiatement après cela, le client ferme la connexion TCP avec un TCP RST (??)
Chaque fois que j'exécute la commande et que j'obtiens l'erreur, les étapes 2 et 3 se produisent.
Lorsque la commande commence à fonctionner, les étapes 1 et 2 se produisent, mais au lieu que le client envoie un TCP RST, un SessionSetup est effectué, puis un TreeConnect, puis beaucoup de (apparemment normal) SMB bavardage se produit.
Ainsi, il semble que le client ne parlera pas correctement SMB to the DC jusqu'à une minute ou deux après le démarrage, ce qui entraîne l'échec du traitement de la stratégie de groupe) .
Quelqu'un sait comment je peux déboguer et résoudre ce problème?
J'ai réussi à résoudre ce problème moi-même. Pour référence voici ce qui a résolu mon problème:
Tout d'abord, je me trompais en ce que la désactivation de tout blocage de NTLM entraînait les mêmes symptômes. Il en est résulté un symptôme différent, qui a eu le même effet. Sans aucune stratégie de blocage NTLM en vigueur, la commande dir a maintenant entraîné une erreur d'accès refusé. La stratégie de groupe ne s'appliquerait toujours pas, ce qui est logique: SYSVOL n'était toujours pas accessible.
Un peu de recherche sur le Web m'a dit que je savais qu'il y avait un problème plus courant. bien que. Apparemment, les clients Windows 10 peuvent avoir des problèmes d'accès au partage SYSVOL des contrôleurs de domaine (et peut-être aussi au partage NETLOGON). Soi-disant Windows 10 a changé quelque chose dans la façon dont il accède à ces partages, ce qui peut entraîner des problèmes. La solution de contournement consiste à désactiver le renforcement du chemin UNC sur le client pour ces partages, en définissant la stratégie de groupe "Chemins UNC renforcés" pour les clients Windows 10 comme suit:
\\*\SYSVOL RequireMutualAuthentication=0,RequireIntegrity=0,RequirePrivacy=0
\\*\NETLOGON RequireMutualAuthentication=1,RequireIntegrity=1
(Si vous rencontrez des problèmes pour accéder au partage Netlogon à partir des clients Windows 10, cela pourrait également aider à définir les trois paramètres à zéro pour ce partage.)
Voir article de Microsoft sur MS15-011 pour plus d'informations. Il contient une bonne description des implications de sécurité de la modification de ce paramètre, ainsi que des étapes détaillées sur la façon de modifier la stratégie.
Avertissement : Notez que les paramètres ci-dessus désactivent certaines ou toutes les protections contre le problème de sécurité MS15-011 a été créé pour! Ne pas simplement les copier/coller à l'aveugle, mais prendre une décision éclairée en fonction des risques encourus. En outre, ce problème est susceptible d'être résolu dans le futur. Dans ce cas, n'oubliez pas de définir cette stratégie sur les valeurs recommandées, comme décrit dans MS15-011.
À partir de Windows 8, Microsoft a introduit cette notion de "démarrage rapide", où, lorsque vous arrêtez le système d'exploitation, ils mettent en veille l'empreinte mémoire du système d'exploitation tout comme Hibernate fonctionne dans les scénarios d'hibernation normaux. Cela se traduit par un OS plus rapide, mais cela a également pour effet secondaire de désactiver le traitement GP par ordinateur au démarrage. C'est probablement ce que vous voyez et cela peut être désactivé en désactivant la stratégie sous Configuration ordinateur\Stratégies\Modèles d'administration\Système\Arrêt\Nécessite l'utilisation d'un démarrage rapide
Si cela ne résout pas le problème, il s'agit très probablement d'un problème de synchronisation de la pile réseau, où le traitement GP pour l'ordinateur démarre avant que la pile réseau ne soit complètement initialisée. Cela existe depuis XP et à partir de Windows 7, Microsoft a ajouté une stratégie sous Configuration ordinateur\Stratégies\Modèles d'administration\Système\Stratégie de groupe\Traitement des stratégies de démarrage Temps d'attente où vous pouvez augmenter le temps que le GP attend avant de commencer. Essayez de le régler sur 60 secondes et voyez si cela aide.
Darren
J'ai essayé plusieurs suggestions, y compris des modifications de registre et des modifications de stratégie de groupe locale, dont aucune n'a résolu le problème - les lecteurs mappés étaient toujours X'ed au démarrage. Un gpupdate le corrigerait à chaque fois, mais c'était une étape supplémentaire pour l'utilisateur.
Ce qui a fini par le réparer était de mapper manuellement les lecteurs réseau, en remplaçant les entrées GPO sur chacun d'eux. Pas besoin de se déconnecter et de remplacer, je les ai mappés de la même manière qu'ils ont été mappés, juste manuellement.
Juste pour info pour toute autre personne qui trouve ce fil, désactiver le durcissement UNC en définissant l'authentification mutuelle sur 0 désactive une partie de votre sécurité. Nous rencontrons le même problème avec les clients win7, et j'essayais de travailler avec Microsoft dessus. Ils m'ont dit que c'était un bogue, mais jusqu'à présent, ils ne m'ont pas donné de moyen de savoir quand le bogue sera résolu.
Voir cet autre fil pour plus d'informations https://social.technet.Microsoft.com/Forums/en-US/6a20e3f6-728a-4aa9-831a-6133f446ea08/gpos-do-not-apply-on-windows -10-entreprise-x64