Sécuriser les comptes de service Active Directory : gMSA, SPN et délégation

Une identité technique mérite un périmètre précis

Un compte de service oublié peut conserver des accès sensibles pendant des années. Un mot de passe partagé entre plusieurs applications rend sa rotation difficile; des privilèges excessifs augmentent l’impact d’un serveur compromis. Le premier objectif est de rattacher chaque identité à un usage, un responsable et un ensemble minimal de ressources.

Ce guide porte sur les services Windows intégrés à Active Directory. Les exemples utilisent le domaine fictif corp.contoso.com. Ils constituent un parcours de configuration ciblé; la validation des applications et des droits reste propre à chaque environnement.

• Microsoft — Comptes de service Active Directory ↗

Choisir le bon type de compte

Un gMSA laisse Windows gérer le mot de passe. Il ne retire aucun privilège existant et ne corrige pas les droits applicatifs. Utilisez une identité distincte par application et frontière de sécurité; évitez un gMSA universel partagé entre production, développement et outils d’administration.

Validez le support du produit et de sa version : service Windows, pool IIS et tâche planifiée n’ont pas tous la même procédure de configuration. Le service de cluster lui-même et les applications hébergées sur le cluster sont aussi des cas distincts.

• Microsoft — Vue d’ensemble des gMSA ↗

1. Repérer les usages réels avant de changer l’identité

Le nom svc_* ne constitue pas un inventaire. Partez des applications et de leurs propriétaires, puis relevez services, tâches, pools IIS, connexions SQL, partages, scripts, coffres et outils tiers. Un compte sans SPN peut quand même être utilisé par une tâche ou un connecteur.

Pour chaque usage, notez les hôtes, droits locaux et distants, dépendances, fréquence d’exécution et test de réussite. Une tâche mensuelle absente des derniers journaux ne prouve pas que son compte est inutilisé.

• Exécuter avec les droits de lecture appropriés au serveur; les résultats peuvent être incomplets sans élévation.
• Conserver les résultats dans un emplacement restreint : ils décrivent les identités et l’architecture.
• Ne pas exporter de mots de passe, de clés privées ou de l’attribut msDS-ManagedPassword.

Get-CimInstance Win32_Service |
  Select-Object Name,State,StartMode,StartName

Get-ScheduledTask | Select-Object TaskPath,TaskName,
  @{Name='RunAs';Expression={$_.Principal.UserId}},
  @{Name='LogonType';Expression={$_.Principal.LogonType}}

# Sur un serveur IIS, avec le module WebAdministration disponible
Import-Module WebAdministration
Get-ChildItem IIS:\AppPools | Select-Object Name,
  @{Name='IdentityType';Expression={$_.processModel.identityType}},
  @{Name='UserName';Expression={$_.processModel.userName}}

2. Vérifier les prérequis AD et KDS

Validez les niveaux fonctionnels et systèmes pris en charge, la réplication AD, DNS, l’heure et l’accès aux contrôleurs de domaine. Installez les outils RSAT nécessaires sur le poste d’administration; un service applicatif n’exige pas que son hôte devienne contrôleur de domaine.

KDS fournit la base de génération des secrets gMSA. Vérifiez la présence d’une clé avant d’en créer une. Microsoft prévoit jusqu’à dix heures avant l’utilisation d’une nouvelle clé pour permettre sa convergence entre contrôleurs. Ne transposez pas en production le raccourci de rétrodatation destiné à un laboratoire à un seul DC.

Import-Module ActiveDirectory
Get-ADDomain | Select-Object DNSRoot,DomainMode
Get-ADForest | Select-Object RootDomain,ForestMode

# Dans une session d’administration disposant du module Kds
Get-KdsRootKey

# CHANGEMENT de forêt : seulement après validation et si nécessaire
# Add-KdsRootKey -EffectiveImmediately
# Attendre la période de convergence avant le pilote.

• Microsoft — Créer une clé racine KDS ↗

3. Créer un gMSA limité aux hôtes nécessaires

L’exemple crée un groupe dédié contenant seulement APP01 et un gMSA pour une application de rapports. Il modifie AD et doit être exécuté par un administrateur disposant des droits délégués nécessaires. Adaptez les noms et l’emplacement des objets avant de l’utiliser.

Le paramètre DNSHostName décrit le compte; il ne crée pas un enregistrement DNS pour l’application. Le SPN applicatif sera traité séparément. L’intervalle de mot de passe est choisi à la création; ne supposez pas qu’il est modifiable ensuite.

Import-Module ActiveDirectory
New-ADGroup -Name 'GG-gMSA-Reports-Hosts' -GroupScope Global `
  -GroupCategory Security
Add-ADGroupMember -Identity 'GG-gMSA-Reports-Hosts' `
  -Members (Get-ADComputer 'APP01')

$params = @{
  Name = 'gmsaReports'
  DNSHostName = 'gmsaReports.corp.contoso.com'
  PrincipalsAllowedToRetrieveManagedPassword = 'GG-gMSA-Reports-Hosts'
  KerberosEncryptionType = @('AES128','AES256')
  ManagedPasswordIntervalInDays = 30
}
New-ADServiceAccount @params

• Microsoft — New-ADServiceAccount et paramètres ↗

4. Protéger la récupération du secret et valider l’hôte

Contrôlez aussi qui peut modifier le groupe d’hôtes, les ACL du gMSA et les serveurs membres. Un administrateur d’un hôte autorisé peut compromettre une identité utilisable par ce serveur. N’accordez pas la récupération à Domain Computers ou à un groupe d’administration général.

Après ajout du compte ordinateur au groupe, planifiez un redémarrage de l’hôte pilote pour renouveler son contexte de sécurité. Installez ensuite le compte et testez sa disponibilité. True confirme cette étape, pas le bon fonctionnement de l’application.

Install-ADServiceAccount -Identity 'gmsaReports'
Test-ADServiceAccount -Identity 'gmsaReports'

Get-ADServiceAccount 'gmsaReports' -Properties `
  PrincipalsAllowedToRetrieveManagedPassword,ServicePrincipalNames |
  Select-Object Name,PrincipalsAllowedToRetrieveManagedPassword,
                ServicePrincipalNames

• Microsoft — Gestion des gMSA ↗
• Microsoft — Test-ADServiceAccount ↗

5. Réduire les droits et configurer le service

Configurez l’identité CORP\gmsaReports$ avec l’outil pris en charge par l’éditeur. Aucun mot de passe gMSA ne doit être copié dans un script. Pour SQL Server, privilégiez SQL Server Configuration Manager; pour IIS, vérifiez aussi les paramètres d’authentification de l’application.

Dans Configuration ordinateur > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Attribution des droits utilisateur, accordez Ouvrir une session en tant que service au périmètre nécessaire. Une tâche peut nécessiter Ouvrir une session en tant que tâche. Les droits de refus priment sur les autorisations; vérifiez la stratégie résultante avant de redémarrer.

Bloquez les usages interactifs inutiles après essais. Ne refusez pas indistinctement l’accès réseau à une identité qui doit joindre SQL ou un partage. Accordez les ACL NTFS, permissions de partage et droits SQL requis seulement; le compte n’a normalement pas à être administrateur local ou du domaine.

• Tester lecture et écriture attendues, mais aussi refus sur une ressource hors périmètre.
• Rechercher les fichiers chiffrés, secrets DPAPI et profils liés à l’ancienne identité : un changement de compte peut rendre ces données illisibles.
• Vérifier les effets d’une GPO qui remplace une liste de droits utilisateur déjà utilisée par d’autres services.

6. Gérer les SPN sans créer de doublons

Un SPN associe un nom de service à son identité Kerberos. Le nom utilisé par le client, y compris un alias, doit correspondre à la configuration effective. Recherchez l’existant avant toute modification. L’enregistrement HTTP ci-dessous est un exemple, pas une recette universelle pour IIS.

Pendant une migration, arrêtez l’ancien usage, retirez le SPN de son ancien propriétaire et affectez-le au nouveau dans une fenêtre contrôlée. Conservez les commandes inverses. N’utilisez pas setspn -A lorsque -S peut vérifier un doublon.

REM Lecture seule; la recherche globale peut coûter du temps dans une grande forêt
setspn -F -Q HTTP/reports.corp.contoso.com
setspn -L CORP\svcReports
setspn -L CORP\gmsaReports$

REM CHANGEMENTS : uniquement après validation du propriétaire et arrêt du service
REM setspn -D HTTP/reports.corp.contoso.com CORP\svcReports
REM setspn -S HTTP/reports.corp.contoso.com CORP\gmsaReports$

REM Sur un client de test, dans le contexte utilisateur concerné
klist get HTTP/reports.corp.contoso.com
klist

• Microsoft — setspn ↗

7. Distinguer SPN et délégation Kerberos

Exécuter un service sous gMSA n’impose pas de délégation. Elle devient pertinente lorsqu’un service doit accéder à un autre au nom de l’utilisateur. Si l’application accède à SQL sous sa propre identité technique, ce n’est pas le même scénario.

La délégation non contrainte ouvre un périmètre trop large pour un nouveau déploiement applicatif. Une délégation contrainte classique limite les services cibles sur l’identité amont; la délégation contrainte basée sur la ressource, ou RBCD, contrôle les identités autorisées depuis la cible. Dans les deux cas, limitez les destinations et protégez les droits de modification.

La transition de protocole et les comptes non délégables peuvent changer le comportement. Faites valider le double saut complet avant d’ajouter une autorisation. Ne modifiez jamais la délégation seulement pour faire disparaître une erreur d’authentification.

Get-ADUser 'svcReports' -Properties TrustedForDelegation,
  TrustedToAuthForDelegation,AccountNotDelegated,'msDS-AllowedToDelegateTo' |
  Select-Object SamAccountName,TrustedForDelegation,
    TrustedToAuthForDelegation,AccountNotDelegated,'msDS-AllowedToDelegateTo'

# Exemple de cible ordinateur pour RBCD; adapter au principal cible réel
Get-ADComputer 'SQL01' -Properties PrincipalsAllowedToDelegateToAccount |
  Select-Object Name,PrincipalsAllowedToDelegateToAccount

• Microsoft — Délégation Kerberos contrainte ↗

8. Préparer AES et la rotation des comptes hérités

Configurer AES est utile, mais il faut aussi que les clés existent et que tous les composants le prennent en charge. Pour un ancien compte utilisateur de service, une rotation peut être nécessaire pour générer les clés; coordonnez-la avec tous les consommateurs. Ne modifiez pas en masse msDS-SupportedEncryptionTypes sans analyser les tickets réellement émis.

Pour une application incompatible gMSA, conservez un compte unique à privilèges minimaux et un secret aléatoire dans un coffre. Documentez qui le récupère, comment les services sont mis à jour et comment un échec de rotation est détecté. Évitez les secrets dans les lignes de commande, fichiers de configuration partagés ou journaux.

Le retour arrière d’une migration d’identité peut réutiliser temporairement l’ancien compte si son secret demeure valide et protégé. Après une rotation de secret, remettre simplement une ancienne configuration ne suffit pas. En cas de compromission, ne rétablissez pas un secret exposé.

• Microsoft — Détecter et corriger RC4 ↗
• Guide — Kerberos RC4 vers AES →

9. Migrer une application et observer un cycle complet

Définissez les critères d’arrêt avant le basculement : traitement métier impossible, erreurs d’accès ou authentification inattendue. Restaurez alors identité, SPN et permissions documentées. Ne supprimez pas immédiatement l’ancien compte; ne le laissez pas non plus actif sans échéance.

Surveillez les tickets de service 4769 sur les DC avec l’audit approprié, les connexions 4624/4625 sur les systèmes concernés et les journaux applicatifs. Un volume élevé de tickets n’est pas à lui seul une preuve d’attaque; comparez hôtes, horaires et services attendus. Les champs disponibles dépendent de la version et des correctifs.

• Microsoft — Événement de ticket Kerberos 4769 ↗

Un contrôle à maintenir dans le temps

Lorsqu’un serveur est retiré, retirez aussi son droit de récupérer le secret. Lorsqu’une application change de propriétaire, mettez à jour sa procédure de rotation et ses tests. Revoyez périodiquement les membres des groupes d’hôtes, les SPN, les délégations et les accès aux ressources.

Le bon résultat est une identité dont on connaît l’usage et dont on peut changer les accès sans interruption imprévue. Un accompagnement ciblé est particulièrement utile lorsque plusieurs applications partagent un compte, que le double saut Kerberos est mal documenté ou que des services critiques reposent sur des secrets historiques.

• Service — Audit de sécurité Active Directory →
• Guide — Récupération de forêt après cyberattaque →