Auditer les autorisations des GPO et les droits gPLink

Une GPO, c'est de l'exécution de code sur chaque ordinateur auquel elle s'applique. Une tâche planifiée, un script de démarrage ou une entrée de groupes restreints déployés via une GPO liée à l'UO Domain Controllers s'exécutent en tant que SYSTEM sur chaque DC au cycle d'actualisation suivant. Trois autorisations relèvent donc du Tier 0 dès qu'elles touchent des systèmes Tier 0 : le droit de modifier une GPO, le droit de lier une GPO à une UO, un site ou un domaine, et le droit de créer des GPO. Les outils d'analyse des chemins d'attaque comme BloodHound font régulièrement apparaître des droits GpoEdit ou d'écriture sur gPLink détenus par des groupes de support, et ils figurent parmi les chemins vers la compromission du domaine les plus souvent relevés lors des audits.

Le pilier Stratégie de groupe et SYSVOL introduit la distinction entre modification et liaison avec un contrôle rapide de la racine du domaine et de l'UO des DC. Ce guide va plus loin : chaque GPO, chaque UO et site, la propriété des GPO, le groupe de créateurs, les filtres WMI, et le croisement de ces éléments qui vous indique quels constats relèvent réellement du Tier 0.

Comment les autorisations des GPO sont stockées

Une GPO comporte deux moitiés. Le Group Policy Container (GPC) est un objet AD situé à CN={GUID},CN=Policies,CN=System,<domain DN> ; le Group Policy Template (GPT) est le dossier \\<domain>\SYSVOL\<domain>\Policies\{GUID}. La console de gestion des stratégies de groupe (GPMC) et le module PowerShell GroupPolicy écrivent des autorisations cohérentes dans les deux, exprimées sous forme de cinq niveaux : GpoRead, GpoApply, GpoEdit, GpoEditDeleteModifySecurity et GpoCustom. Quiconque dispose d'un accès en écriture à l'une ou l'autre moitié peut modifier ce que fait la stratégie.

Les droits de liaison sont distincts et se trouvent sur la cible : l'accès en écriture à l'attribut gPLink (GUID de schéma f30e3bbe-9ff0-11d1-b603-0000f80367c1) sur un objet UO, domaine ou site détermine quelles GPO s'y appliquent. gPOptions (f30e3bbf-9ff0-11d1-b603-0000f80367c1) contrôle le blocage de l'héritage. GenericAll, GenericWrite, WriteDacl et WriteOwner sur l'UO impliquent les deux.

Mesurer : associer les GPO à ce qu'elles atteignent

Commencez par le croisement qui détermine la gravité : quelles GPO s'appliquent aux systèmes Tier 0. Incluez au minimum l'UO Domain Controllers, la racine du domaine et toute UO contenant des serveurs Tier 0 (AD CS, Entra Connect, sauvegarde, PAM) issus de votre inventaire Tier 0.

Import-Module GroupPolicy, ActiveDirectory
$domain = Get-ADDomain
$tier0Targets = @(
    $domain.DomainControllersContainer
    $domain.DistinguishedName
    'OU=Tier0 Servers,OU=Admin,DC=corp,DC=example'   # à adapter à votre arborescence
)

$tier0Gpos = foreach ($t in $tier0Targets) {
    (Get-GPInheritance -Target $t).InheritedGpoLinks |
        Select-Object @{n='Target';e={$t}}, DisplayName, GpoId, Enforced
}
$tier0Gpos | Sort-Object DisplayName -Unique | Format-Table -AutoSize

InheritedGpoLinks inclut les GPO liées plus haut et les liaisons appliquées (enforced) : il reflète donc ce qui s'applique réellement. Les GPO liées à un site s'appliquent aussi aux DC de ce site ; listez-les via l'attribut gPLink des objets CN=Sites,CN=Configuration,... (voir plus bas).

Auditer : droits de modification et propriété des GPO

Listez chaque mandataire non standard disposant d'un accès en modification ou de la propriété, et signalez les GPO qui atteignent le Tier 0 :

$defaultTrustees = 'Domain Admins','Enterprise Admins','SYSTEM','ENTERPRISE DOMAIN CONTROLLERS','Authenticated Users'
$tier0Ids = $tier0Gpos.GpoId | ForEach-Object { $_.ToString() }

Get-GPO -All | ForEach-Object {
    $gpo = $_
    $perms = Get-GPPermission -Guid $gpo.Id -All |
        Where-Object { $_.Permission -in 'GpoEdit','GpoEditDeleteModifySecurity','GpoCustom' -and
                       $_.Trustee.Name -notin $defaultTrustees }
    foreach ($p in $perms) {
        [pscustomobject]@{
            GPO        = $gpo.DisplayName
            Tier0      = $tier0Ids -contains $gpo.Id.ToString()
            Trustee    = "$($p.Trustee.Domain)\$($p.Trustee.Name)"
            Permission = $p.Permission
            Owner      = $gpo.Owner
        }
    }
} | Sort-Object Tier0, GPO -Descending | Format-Table -AutoSize

GpoCustom nécessite un examen manuel de l'ACE sous-jacente, car il peut masquer un simple WriteProperty ou WriteDacl. Examinez aussi la colonne Owner séparément : le propriétaire du GPC dispose de droits implicites pour modifier ses autorisations. Les GPO créées par des membres de Group Policy Creator Owners appartiennent à ce membre, et non aux Domain Admins.

La GPMC signale aussi lorsque les autorisations AD et SYSVOL divergent (« The permissions for this GPO in the SYSVOL folder are inconsistent »). Une incohérence signifie généralement que quelqu'un a modifié directement l'ACL NTFS ou l'ACL AD ; vérifiez le dossier GPT lorsque le GPC semble sain :

$gpoPath = "\\$($domain.DNSRoot)\SYSVOL\$($domain.DNSRoot)\Policies"
foreach ($id in $tier0Ids) {
    (Get-Acl "$gpoPath\{$id}").Access |
        Where-Object { $_.FileSystemRights -match 'Write|Modify|FullControl|ChangePermissions|TakeOwnership' } |
        Select-Object @{n='GPO';e={$id}}, IdentityReference, FileSystemRights, IsInherited
}

Auditer : droits de liaison sur les UO, le domaine et les sites

Identifiez ensuite chaque principal non administrateur capable d'écrire gPLink où que ce soit. Filtrez les SID d'administration connus par leur suffixe plutôt que par leur nom, afin que les noms de groupes localisés ne passent pas au travers.

$gpLink  = [guid]'f30e3bbe-9ff0-11d1-b603-0000f80367c1'
$adminRx = '-(512|518|519)$|^S-1-5-18$|^S-1-5-32-544$|^S-1-5-9$'   # DA, Schema Admins, EA, SYSTEM, Administrators, EDCs
$configNC = (Get-ADRootDSE).configurationNamingContext

$targets = @($domain.DistinguishedName) +
           (Get-ADOrganizationalUnit -Filter * | Select-Object -ExpandProperty DistinguishedName) +
           (Get-ADObject -SearchBase "CN=Sites,$configNC" -LDAPFilter '(objectClass=site)' |
                Select-Object -ExpandProperty DistinguishedName)

foreach ($t in $targets) {
    (Get-Acl "AD:\$t").Access | Where-Object {
        $_.AccessControlType -eq 'Allow' -and (
            ($_.ActiveDirectoryRights -match 'WriteProperty' -and $_.ObjectType -in $gpLink, [guid]::Empty) -or
            $_.ActiveDirectoryRights -match 'GenericAll|GenericWrite|WriteDacl|WriteOwner')
    } | ForEach-Object {
        $sid = try { $_.IdentityReference.Translate([Security.Principal.SecurityIdentifier]).Value } catch { $_.IdentityReference.Value }
        if ($sid -notmatch $adminRx) {
            [pscustomobject]@{
                Target    = $t
                Trustee   = $_.IdentityReference.Value
                Rights    = $_.ActiveDirectoryRights
                Inherited = $_.IsInherited
            }
        }
    }
} | Sort-Object Target | Format-Table -AutoSize

Attendez-vous à quelques délégations légitimes sur les UO départementales. Tout ce qui concerne la racine du domaine, l'UO Domain Controllers, un site contenant des DC ou une UO hébergeant des serveurs Tier 0 constitue un constat. N'oubliez pas que les GPO liées à un site s'appliquent à chaque ordinateur du site, DC compris : l'accès en écriture à un objet site est donc aussi sensible que la racine du domaine. Pour la question plus large des autres ACE qui comptent sur ces UO, voir auditer les ACL AD.

Auditer : création de GPO et filtres WMI

Get-ADGroupMember 'Group Policy Creator Owners' -Recursive | Select-Object Name, objectClass

# Qui peut créer des GPO directement dans le conteneur Policies
$policies = "CN=Policies,CN=System,$($domain.DistinguishedName)"
(Get-Acl "AD:\$policies").Access |
    Where-Object { $_.ActiveDirectoryRights -match 'CreateChild|GenericAll' } |
    Select-Object IdentityReference, ActiveDirectoryRights

# Filtres WMI : l'accès en écriture modifie le ciblage de chaque GPO qui les utilise
$som = "CN=SOM,CN=WMIPolicy,CN=System,$($domain.DistinguishedName)"
Get-ADObject -SearchBase $som -LDAPFilter '(objectClass=msWMI-Som)' -Properties msWMI-Name |
    ForEach-Object {
        $f = $_
        (Get-Acl "AD:\$($f.DistinguishedName)").Access |
            Where-Object { $_.ActiveDirectoryRights -match 'Write|GenericAll' } |
            Select-Object @{n='Filter';e={$f.'msWMI-Name'}}, IdentityReference, ActiveDirectoryRights
    }

Group Policy Creator Owners doit être vide. Un filtre WMI modifiable permet à son éditeur d'élargir la portée d'une GPO, par exemple pour qu'une GPO de postes de travail gérée par le support s'applique aussi aux serveurs.

Interpréter les résultats : constats fréquents

Une poignée de schémas récurrents expliquent la plupart des constats dans les domaines réels. Les connaître accélère le tri.

• Équipe de support ou équipe serveurs avec GpoEdit sur la Default Domain Policy ou la Default Domain Controllers Policy. Généralement accordé il y a des années pour qu'une équipe puisse modifier un seul paramètre. Ces deux GPO atteignent le Tier 0 : c'est donc l'équivalent d'un Domain Admin. Déplacez le paramètre dont elle a besoin dans une GPO limitée à sa propre UO et retirez le droit.
• Un ancien administrateur propriétaire d'une GPO. La propriété survit aux changements d'appartenance aux groupes et même aux renommages de comptes. Si ce compte est désactivé, le risque est faible, mais la propriété empêche toujours un audit propre ; s'il est encore actif, il détient des droits implicites sur les autorisations de la GPO.
• Authenticated Users ou Domain Users avec GpoEdit. Presque toujours une erreur commise lors de la configuration du filtrage de sécurité, où quelqu'un a choisi le mauvais niveau d'autorisation. C'est un constat critique si la GPO est liée où que ce soit.
• Comptes de service disposant de droits de liaison. Les outils de déploiement et de provisionnement reçoivent parfois un large accès en écriture aux UO pour pouvoir déplacer des ordinateurs, ce qui inclut silencieusement gPLink. Limitez leur délégation aux types d'objets et aux attributs précis dont ils ont besoin.
• GenericAll hérité sur une arborescence d'UO. Une délégation faite sur une UO parente se propage à chaque enfant, y compris toute UO Tier 0 créée ultérieurement en dessous. Les UO Tier 0 doivent bloquer l'héritage des ACE déléguées ou se trouver entièrement en dehors des arborescences déléguées.

Traitez chaque constat portant sur une GPO qui apparaît dans le croisement Tier 0 de l'étape Mesurer comme un constat Tier 0, quoi que suggère le nom de la GPO.

Imposer : retirer et redéléguer

Retirez les droits de modification des non-administrateurs sur les GPO Tier 0 avec le module GroupPolicy, qui met à jour à la fois le GPC et le GPT :

Set-GPPermission -Name 'Default Domain Controllers Policy' -TargetName 'CORP\Helpdesk' `
    -TargetType Group -PermissionLevel None -Replace

Retirez une délégation gPLink d'une UO en supprimant l'ACE précise plutôt que toutes les ACE du mandataire :

$ou  = 'OU=Tier0 Servers,OU=Admin,DC=corp,DC=example'
$acl = Get-Acl "AD:\$ou"
$acl.Access | Where-Object { $_.IdentityReference -eq 'CORP\Helpdesk' -and $_.ObjectType -eq $gpLink -and -not $_.IsInherited } |
    ForEach-Object { [void]$acl.RemoveAccessRule($_) }
Set-Acl -Path "AD:\$ou" -AclObject $acl

Si l'ACE est héritée, corrigez-la sur le parent où elle est définie. Redéléguez ensuite correctement : les administrateurs départementaux reçoivent GpoEdit sur leurs propres GPO et des droits de liaison sur leur propre UO uniquement (GPMC > l'UO > onglet Delegation > Link GPOs), et les GPO Tier 0 ne sont modifiées que depuis un poste d'administration privilégié par des administrateurs Tier 0. Prenez possession des GPO appartenant à d'anciens créateurs et attribuez-en la propriété aux Domain Admins.

Vérifier

Relancez les trois blocs d'audit ; les lignes Tier 0 ne doivent plus lister que les mandataires d'administration par défaut. Confirmez avec Get-GPPermission -Name '<GPO>' -All sur chaque GPO Tier 0 et vérifiez que la GPMC n'affiche aucun avertissement d'incohérence SYSVOL. Rendez ensuite la dérive visible : activez « Audit Directory Service Changes » sur les DC et ajoutez des SACL d'écriture sur les objets groupPolicyContainer et sur gPLink pour les UO. Les événements 5136 (attribut modifié, y compris gPLink et versionNumber), 5137 (GPO créée) et 5141 (GPO supprimée) enregistreront alors chaque changement ; la référence des ID d'événements AD explique comment les lire.

Ce qui casse

• Retirer les droits de modification du support ou des administrateurs de site sur les GPO partagées les empêche d'effectuer les changements qu'ils géraient eux-mêmes. Donnez-leur leurs propres GPO, limitées à leurs UO.
• Retirer les droits gPLink signifie que les administrateurs délégués ne peuvent plus attacher de GPO à des UO hors de leur périmètre, et tout ce qu'ils avaient lié plus haut continue de fonctionner jusqu'à ce que quelqu'un le délie ; examinez aussi les liaisons existantes.
• Vider Group Policy Creator Owners bloque la création de GPO pour ces membres ; la création doit passer par le groupe mandaté.
• Prendre possession des GPO retire le WriteDacl implicite dont disposait l'ancien propriétaire, ce qui peut casser une automatisation qui s'exécutait sous ce compte et modifiait des autorisations.
• Modifier le filtrage de sécurité pendant le nettoyage : depuis MS16-072 (juin 2016), les ordinateurs lisent les GPO dans leur propre contexte de sécurité ; si vous retirez Authenticated Users de l'ACL d'une GPO, vous devez conserver le droit Read pour Domain Computers (ou les ordinateurs cibles), sinon la GPO cesse silencieusement de s'appliquer.
• Resserrer les ACL des filtres WMI empêche les non-administrateurs d'ajuster le ciblage, ce que certaines équipes utilisent pour les déploiements par version de système d'exploitation.

Pour aller plus loin : le thème Stratégie de groupe & SYSVOL, la gestion des chemins d'attaque pour prioriser les arêtes liées aux GPO dans le graphe global, et supprimer les mots de passe GPP pour l'autre constat historique lié aux GPO.