Les GPO ne s'appliquent pas; raison: inaccessible, vide ou désactivé; Server 2012 R2 et Windows 10


16

J'ai un domaine Windows Server 2012 R2.

Hier, le lecteur réseau d'un ordinateur (exécutant Windows 10 Pro) a cessé de fonctionner.

Après une enquête plus approfondie ( gpresult /h), il apparaît que TOUS les objets de stratégie de groupe échouent avec la raison Inaccessible, Empty, or Disabled.

J'ai confirmé que tous les GPO existent toujours et sont activés sur les deux contrôleurs de domaine (redondants et locaux). De plus, il y a 20 autres machines sur le même domaine et LAN sans aucun problème.

Cependant, il y a un autre ordinateur que j'ai testé qui a présenté le même problème! Est-ce à dire que le problème vient des serveurs?

gpresult /rsignale qu'un client obtient des objets de stratégie de groupe du DC1 local et l'autre du DC2. Ce n'est donc pas un problème lié à un DC spécifique.

gpupdate /force n'a rien corrigé (même s'il affirmait que des politiques étaient appliquées)

J'ai essayé de supprimer les entrées de registre pour les politiques locales (en suivant ce guide /superuser/379908/how-to-clear-or-remove-domain-applied-group-policy-settings-after-leaving-the -do ) et redémarrage - même problème.

J'ai trouvé cette page de support de Microsoft ( https://support.microsoft.com/en-us/kb/2976965 ), mais elle prétend qu'elle ne s'applique qu'à Windows 7 ou aux clients antérieurs.

Toutes mes machines (serveur et client) exécutent des versions 64 bits et sont entièrement mises à jour. Je les ai tous redémarrés juste pour être sûr.



Merci. Votre commentaire a fourni la clé de la solution. Voir ci-dessous.
Daniel

Réponses:


19

Vérifiez le patch lien joeqwerty aussi .

Il y a le détail important:

Problèmes connus

MS16-072 modifie le contexte de sécurité avec lequel les stratégies de groupe d'utilisateurs sont récupérées. Ce changement de comportement par conception protège les ordinateurs des clients contre une vulnérabilité de sécurité. Avant l'installation de MS16-072, les stratégies de groupe d'utilisateurs ont été récupérées à l'aide du contexte de sécurité de l'utilisateur. Une fois MS16-072 installé, les stratégies de groupe d'utilisateurs sont récupérées à l'aide du contexte de sécurité des machines. Ce problème s'applique aux articles de la base de connaissances suivants:

  • 3159398 MS16-072: Description de la mise à jour de sécurité pour la stratégie de groupe: 14 juin 2016
  • 3163017 Mise à jour cumulative pour Windows 10: 14 juin 2016
  • 3163018 Mise à jour cumulative pour Windows 10 version 1511 et Windows Server 2016 Technical Preview 4: 14 juin 2016
  • 3163016 Mise à jour cumulative pour Windows Server 2016 Technical Preview 5: 14 juin 2016

Symptômes

Toutes les stratégies de groupe d'utilisateurs, y compris celles dont la sécurité a été filtrée sur les comptes d'utilisateurs ou les groupes de sécurité, ou les deux, peuvent ne pas s'appliquer sur les ordinateurs joints au domaine.

Cause

Ce problème peut se produire si l'objet de stratégie de groupe ne dispose pas des autorisations de lecture pour le groupe d'utilisateurs authentifiés ou si vous utilisez le filtrage de sécurité et qu'il manque des autorisations de lecture pour le groupe d'ordinateurs de domaine.

Résolution

Pour résoudre ce problème, utilisez la console de gestion des stratégies de groupe (GPMC.MSC) et suivez l'une des étapes suivantes:

- Ajoutez le groupe Utilisateurs authentifiés avec des autorisations de lecture sur l'objet de stratégie de groupe (GPO).
- Si vous utilisez le filtrage de sécurité, ajoutez le groupe Ordinateurs du domaine avec une autorisation de lecture.

Voir ce lien Déployer MS16-072 qui explique tout et propose un script pour réparer les GPO affectés. Le script ajoute des autorisations de lecture d'utilisateurs authentifiés à tous les objets de stratégie de groupe qui n'ont aucune autorisation pour les utilisateurs authentifiés.

# Copyright (C) Microsoft Corporation. All rights reserved.

$osver = [System.Environment]::OSVersion.Version
$win7 = New-Object System.Version 6, 1, 7601, 0

if($osver -lt $win7)
{
    Write-Error "OS Version is not compatible for this script. Please run on Windows 7 or above"
    return
}

Try
{
    Import-Module GroupPolicy
}
Catch
{
    Write-Error "GP Management tools may not be installed on this machine. Script cannot run"
    return
}

$arrgpo = New-Object System.Collections.ArrayList

foreach ($loopGPO in Get-GPO -All)
{
    if ($loopGPO.User.Enabled)
    {
        $AuthPermissionsExists = Get-GPPermissions -Guid $loopGPO.Id -All | Select-Object -ExpandProperty Trustee | ? {$_.Name -eq "Authenticated Users"}
        If (!$AuthPermissionsExists)
        {
            $arrgpo.Add($loopGPO) | Out-Null
        }
    }
}

if($arrgpo.Count -eq 0)
{
    echo "All Group Policy Objects grant access to 'Authenticated Users'"
    return
}
else
{
    Write-Warning  "The following Group Policy Objects do not grant any permissions to the 'Authenticated Users' group:"
    foreach ($loopGPO in $arrgpo)
    {
        write-host "'$($loopgpo.DisplayName)'"
    }
}

$title = "Adjust GPO Permissions"
$message = "The Group Policy Objects (GPOs) listed above do not have the Authenticated Users group added with any permissions. Group policies may fail to apply if the computer attempting to list the GPOs required to download does not have Read Permissions. Would you like to adjust the GPO permissions by adding Authenticated Users group Read permissions?"

$yes = New-Object System.Management.Automation.Host.ChoiceDescription "&Yes", `
    "Adds Authenticated Users group to all user GPOs which don't have 'Read' permissions"
$no = New-Object System.Management.Automation.Host.ChoiceDescription "&No", `
    "No Action will be taken. Some Group Policies may fail to apply"
$options = [System.Management.Automation.Host.ChoiceDescription[]]($yes, $no)
$result = $host.ui.PromptForChoice($title, $message, $options, 0)  
$appliedgroup = $null
switch ($result)
{
    0 {$appliedgroup = "Authenticated Users"}
    1 {$appliedgroup = $null}
}
If($appliedgroup)
{
    foreach($loopgpo in $arrgpo)
    {
        write-host "Adding 'Read' permissions for '$appliedgroup' to the GPO '$($loopgpo.DisplayName)'."
        Set-GPPermissions -Guid $loopgpo.Id -TargetName $appliedgroup -TargetType group -PermissionLevel GpoRead | Out-Null
    }
}

Si vous préférez définir l'autorisation de lecture pour les ordinateurs du domaine (comme je le fais) plutôt que pour les utilisateurs authentifiés, remplacez simplement cela 0 {$appliedgroup = "Authenticated Users"}par celui0 {$appliedgroup = "Domain Computers"}


On dirait que je vais provisoirement marquer cela comme la réponse. J'ai ajouté «Ordinateurs du domaine» avec un accès en lecture à mon filtrage de sécurité et maintenant au moins un des ordinateurs avec le problème fonctionne. Je suppose donc qu'un correctif s'est automatiquement appliqué au serveur via Windows Update et a causé ce problème. Maintenant, je me demande également quelle est la différence entre l'onglet Délégation pour un objet de stratégie de groupe et la section Filtrage de sécurité ... il est temps de lire
Daniel

2
Pour ajouter un peu à la confusion, pour moi, il fallait ajouter le groupe de sécurité contenant l'utilisateur ET le groupe contenant l'ordinateur pour que la politique s'applique. L'ajout d'un seul (utilisateur ou ordinateur) entraînerait la non-application de la stratégie. Il ne doit pas nécessairement être le groupe Ordinateurs du domaine, seule la combinaison de l'utilisateur et de l'ordinateur doit être valide dans le filtrage de sécurité si la stratégie s'applique.
Adwaenyth

Cela l'a corrigé pour notre entreprise -> Ajouter le groupe d'utilisateurs authentifiés avec des autorisations de lecture sur l'objet de stratégie de groupe (GPO). Big thx
Brain Foo Long

Cela ne semble pas être une solution réelle car je ne veux pas que tout le monde applique cet objet de stratégie de groupe, juste des personnes spécifiques dans le groupe. Pourquoi MS déploie-t-il toujours cela dans Windows Update? Ça casse tout.
Sephethus

@Sephethus Utilisez l'onglet de délégation pour ajouter le bon ordinateur de domaine, le GPO fonctionnera comme d'habitude de cette façon. Si votre objet de stratégie de groupe n'a pas de paramètres d'ordinateur, l'ajout de l'ordinateur du domaine au filtre de sécurité ne fera rien non plus, mais l'onglet de délégation est meilleur à mon avis.
yagmoth555
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.