Sécurité des GPO : permissions, délégation et mots de passe oubliés dans SYSVOL

Une GPO est un chemin d'administration

Une GPO peut déployer une tâche planifiée exécutée en SYSTEM, ajouter un compte au groupe Administrateurs local, lancer un script de démarrage ou modifier une clé de registre. Quiconque peut écrire dans une GPO obtient donc les droits des machines qu'elle cible. Pour une GPO liée à la racine du domaine ou à l'OU Domain Controllers, cela signifie la compromission complète du domaine.

Le risque ne se limite pas à la GPO elle-même. Le droit d'écrire l'attribut gPLink d'une OU permet d'y lier une GPO que l'on contrôle déjà. Et les fichiers de la GPO dans SYSVOL ont leurs propres ACL, qui doivent rester cohérentes avec celles de l'objet dans l'annuaire.

Les permissions à passer en revue

Pour chaque GPO liée à un périmètre sensible, la question est simple : qui, en dehors des administrateurs du domaine, peut la modifier ? Les situations rencontrées le plus souvent :

• un groupe « Support » ou « Helpdesk » délégué en Edit settings sur des GPO de postes, puis sur une GPO également liée à la racine ;
• un compte nominatif d'ancien administrateur resté propriétaire de GPO qu'il a créées ;
• des membres de Group Policy Creator Owners qui ne devraient plus y être ;
• des droits d'écriture sur gPLink accordés sur des OU contenant des serveurs sensibles ;
• des ACL NTFS élargies sur le dossier Policies de SYSVOL.

Get-GPO -All | ForEach-Object {
  Get-GPPermission -Guid $_.Id -All |
    Where-Object { $_.Permission -match 'Edit' } |
    Select-Object @{n='GPO';e={$_.DisplayName}}, Trustee, Permission
}

Le résultat doit être comparé à un modèle de délégation écrit : les GPO des contrôleurs et de la racine ne devraient être modifiables que par le premier cercle d'administration.

Les cpassword des préférences (MS14-025)

Les préférences de stratégie de groupe permettaient de définir un mot de passe pour un compte local, un service, une tâche planifiée ou un lecteur mappé. Ce mot de passe était stocké dans un fichier XML de SYSVOL, dans un attribut cpassword, chiffré avec une clé AES publiée par Microsoft. N'importe quel utilisateur authentifié peut donc le lire et le déchiffrer.

Le correctif MS14-025 a retiré la possibilité de saisir ces mots de passe dans la console, mais il ne supprime pas les fichiers existants. Des domaines anciens en contiennent encore, parfois avec le mot de passe de l'administrateur local de tout le parc.

findstr /S /I cpassword \\contoso.local\SYSVOL\contoso.local\Policies\*.xml

Scripts et fichiers dans SYSVOL

SYSVOL est lisible par tous les utilisateurs authentifiés. On y trouve pourtant régulièrement des scripts d'ouverture de session contenant un compte de service en clair, des fichiers .bat qui mappent un partage avec net use /user:, ou des exports de configuration oubliés. Une recherche de mots-clés (password, pwd, /user:, ConvertTo-SecureString) sur l'ensemble du partage prend quelques minutes et révèle souvent des surprises. Pour chaque secret trouvé : rotation du mot de passe, puis retrait du fichier.

Ce qu'un audit vérifie

• Les délégations d'écriture sur les GPO liées à la racine et aux contrôleurs de domaine.
• Les droits de liaison (gPLink) sur les OU sensibles.
• La présence de cpassword dans les fichiers XML de SYSVOL.
• Les identifiants en clair dans les scripts et fichiers partagés.
• La cohérence entre ACL de l'annuaire et ACL NTFS de SYSVOL.