Sécuriser vos comptes de service gérés par groupe

Présentation des comptes de service gérés par groupe

La pratique traditionnelle consistant à utiliser des comptes d'utilisateurs réguliers comme comptes de service impose aux utilisateurs la gestion des mots de passe. En conséquence, les mots de passe des comptes restent souvent les mêmes pendant des années — ce qui les rend très vulnérables aux attaques par force brute et à une utilisation abusive. Les comptes de service gérés par groupe (gMSAs) offrent une manière plus sécurisée d'exécuter des tâches automatisées, des services et des applications.

Les gMSA ont été introduits dans Windows Server 2016 et peuvent être utilisés sur Windows Server 2012 et versions ultérieures. Les mots de passe gMSA sont entièrement gérés par Windows : ils sont générés aléatoirement et tournent automatiquement. De plus, les mots de passe n'ont pas besoin d'être connus par un utilisateur, puisque les comptes de service sont ‘installés’ sur le serveur qui doit interroger les informations de mot de passe depuis Active Directory au moment de l'exécution. En conséquence, les gMSA sont beaucoup moins susceptibles d'être mal utilisés et compromis que les comptes d'utilisateurs utilisés comme comptes de service.

Sécurité des comptes de service gérés par groupe

Les gMSA sont un type d'objet spécifique dans Active Directory: msDS-GroupManagedServiceAccount. Ces objets ont des attributs spéciaux associés à eux liés à leur mot de passe et à sa rotation. De manière similaire à LAPS, vous voudrez vous assurer que les attributs gMSA sont verrouillés pour n'être accessibles qu'aux objets Active Directory qui en ont besoin.

Attributs et permissions gMSA

Les gMSAs possèdent les attributs suivants :

• msDS-ManagedPassword— Un BLOB avec le mot de passe du gMSA
• msDS-ManagedPasswordID— L'ID clé utilisé pour générer le mot de passe gMSA actuel
• msDS-ManagedPasswordPreviousID— L'ID clé utilisé pour générer le mot de passe gMSA précédent
• msDS-GroupMSAMembership— Une liste des objets qui ont la permission de requérir le mot de passe pour le gMSA
• msDS-ManagedPasswordInterval— L'intervalle (en jours) auquel le mot de passe est renouvelé

Étant donné que les informations de mot de passe sont stockées dans l'attribut msDS-ManagedPassword, vous voudrez certainement savoir qui dans votre environnement est capable de consulter le mot de passe. Cette information est définie dans l'attribut msDS-GroupMSAMembership.

Cependant, c'est un peu plus compliqué que juste cet attribut, car les permissions de Active Directory entrent en jeu. Si pour une raison quelconque un utilisateur ou un objet est configuré pour avoir des permissions pour interroger le mot de passe via le compte msDS-GroupMSAMembership, il doit toujours avoir des permissions de 'Lecture' pour l'attribut msDS-ManagedPassword du gMSA.

Cela signifie qu'il y a deux moyens de sécuriser les mots de passe gMSA :

• Assurez-vous que seuls les objets nécessaires ont la permission de requêter le mot de passe et qu'ils existent dans le msDS-GroupMSAMembership
• Assurez-vous que seuls les utilisateurs administratifs qui ont besoin d'accès et les comptes d'ordinateurs où les gMSAs sont installés ont la permission de lire l'attribut. De plus, assurez-vous que seuls les administrateurs ont la capacité de modifier le gMSA et ses attributs, afin que personne ne puisse s'ajouter à l'attribut msDS-GroupMSAMembership.

Idéalement, vous verrouilleriez les gMSAs par les deux voies pour empêcher un attaquant d'avoir la possibilité d'exploiter l'un des scénarios ci-dessus. Ci-dessous, nous allons montrer comment des permissions ou des configurations mal gérées sur un gMSA peuvent conduire à la compromission du compte et à privilege escalation ou à un mouvement latéral.

Abus du mot de passe gMSA

Abuser d'un gMSA est un concept relativement simple. Tout d'abord, obtenez son mot de passe en utilisant un outil comme Mimikatz ou en l'interrogeant directement en raison de configurations non sécurisées dans Active Directory. Puisque les gMSAs sont des comptes de service, ils sont généralement assez privilégiés, vous pourrez donc généralement vous déplacer latéralement ou escalader.

Prenons un exemple de scénario.

1. D'abord, nous compromettons le compte utilisateur Windows ordinaire ‘notadmin’ par une technique telle que le phishing. Ce compte dispose de privilèges minimaux dans Active Directory, mais est un administrateur local sur la machine sur laquelle nous avons atterri.

2. Ensuite, nous allons essayer de déterminer si des gMSA existent. C'est très simple à réaliser si vous avez accès au cmdlet Windows PowerShell. L'exécution d'un script simple nous permet d'obtenir tous les comptes de service gérés dans Active Directory :

      Get-ADServiceAccount -Filter *
      

3. Avec quelques légères modifications du script, nous pouvons identifier qui a accès pour interroger les mots de passe gMSA :

      Get-ADServiceAccount -Filter * -Properties PrincipalsAllowedToRetrieveManagedPassword
      

Comme nous pouvons le voir, seul le compte de Kevin Joyce est capable de consulter les mots de passe pour ces comptes de service :

4. Nous pouvons réduire le champ des cibles que nous voulons en vérifiant si ces comptes de service sont membres de groupes privilégiés, et à partir de là, nous pouvons approfondir les permissions définies sur l'un des objets :

      Get-ADServiceAccount -Filter * -Properties memberof
      

En examinant les résultats ici, nous pouvons voir que le compte de service gMSA est membre des Domain Admins, donc ce sera celui que nous allons essayer d'exploiter.

5. En modifiant un script fourni dans un article sur Microsoft LAPS, nous avons pu obtenir une liste de tous les objets disposant de permissions sur un compte de services gérés incluant le Contrôle total, l'Écriture de toutes les propriétés ou l'Écriture de propriété pour l'attribut gMSA spécifique. Le résultat est ci-dessous, et le script est lié en bas de page.

6. Comme vous pouvez le voir, le compte notadmin dispose d'un Contrôle total sur le compte gMSA. Cela nous donne la capacité de modifier l'attribut msDS-GroupMSAMembership, ce qui nous permettra de récupérer le mot de passe pour le compte de service géré :

      Set-ADServiceAccount -Identity gmsa -PrincipalsAllowedToRetrieveManagedPassword notadmin
      

7. Maintenant que nous sommes réellement capables d'interroger le mot de passe, voyons ce que nous pouvons faire avec :

      Get-ADServiceAccount -Identity gmsa -properties msds-ManagedPassword
      

      $pwd = Get-ADServiceAccount -identity gMSA -Properties msds-ManagedPassword
      

8. La valeur stockée dans l'attribut est un BLOB qui contient les données pour le mot de passe, et non le mot de passe lui-même, donc nous devrons décoder le mot de passe à l'aide d'un outil tel que DSInternals :

      $pw = ConvertFrom-ADManagedPasswordBlob $pwd.’msds-managedpassword’
ConvertTo-NTHash $pw.securecurrentpassword
      

Cela nous donne le SecureCurrentPassword et le CurrentPassword. Le CurrentPassword semble inutile mais c’est parce que tous les caractères sont en UTF-16. Le SecureCurrentPassword peut être converti en un hash NTLM et utilisé dans une attaque pass the hash avec mimikatz pour élever nos privilèges.

9. Pour pass the hash, il suffit d'exécuter mimikatz et d'utiliser cette commande :

      sekurlsa::pth /user:gmsa /domain:sbpmlab.net /ntlm:a99afa608b79a3c539a969212c505ea9
      

10. Maintenant que nous avons un shell exécuté en tant que compte de service gMSA qui était membre des Domain Admins, nous pouvons faire tout ce que nous voulons pour compromettre Active Directory. L'une des méthodes les plus rapides, mais probablement les plus bruyantes, est d'exécuter une DCSync attack et de voler le hash du compte krbtgt :

      lsadump::dcsync /user:krbtgt /domain:sbpmlab.net
      

Protection & Surveillance des gMSA

Il existe des stratégies que vous pouvez utiliser pour prévenir et détecter l'abus de gMSA.

Permissions

La protection la plus évidente et sans doute la plus importante que vous pouvez mettre en place est de vous assurer que les permissions appropriées sont définies sur vos comptes de service gérés par groupe. Comprendre qui a un accès en écriture à ces objets est pertinent pour les protéger ; quelqu'un qui peut s'ajouter à l'attribut qui contrôle qui peut interroger le mot de passe a théoriquement déjà accès pour prendre le contrôle de ce compte et abuser de ses privilèges.

La prochaine étape serait de comprendre qui a la capacité d'interroger les mots de passe de ces comptes et qui a réellement besoin d'un tel accès. En réalité, le seul compte qui devrait pouvoir obtenir le mot de passe d'un gMSA est le compte de l'ordinateur sur lequel le gMSA est installé.

Journaux d'événements

Il existe un événement que vous pouvez rechercher dans les journaux d'événements natifs qui vous aidera à identifier qui interroge les mots de passe des comptes gMSA. Si vous activez la politique ‘Audit directory service access’ pour votre domaine et configurez une SACL sur les gMSA que vous souhaitez surveiller, vous pouvez générer des journaux d'événements lorsque des personnes interrogent l'attribut msDS-ManagedPassword :

Activer ce paramètre et créer un nouveau SACL générera un journal d'événements avec l'ID d'événement 4662; cela ressemble à ceci :

Comme vous pouvez le voir, cela a enregistré que le compte ‘notadmin’ a lu une propriété sur le compte gMSA. Les propriétés lues sont les GUID stockés dans le schéma pour Active Directory, mais en utilisant ADSI edit, nous pouvons voir que le GUID mis en évidence correspond à l'attribut msDS-ManagedPassword.

En supposant que vous ayez une sorte de transfert de journaux d'événements ou une solution SIEM, ces journaux seraient inestimables pour déterminer qui accède à ces attributs.

Netwrix StealthDEFEND

Une autre option est un outil comme Netwrix StealthDEFEND. Netwrix StealthDEFEND ne dépend pas des journaux d'événements natifs et peut détecter l'accès au mot de passe gMSA et les attributions de permissions à haut risque directement après installation. Par exemple, le scénario présenté ci-dessus générerait la menace suivante lorsque le compte 'notadmin' interroge le mot de passe :

De plus, avec Netwrix StealthDEFEND, vous pouvez facilement construire un playbook pour exécuter lorsqu'une utilisation abusive de gMSA est détectée. Le playbook peut impliquer plusieurs étapes, telles que demander au compte utilisateur fautif de répondre à une demande MFA, désactiver le compte ou créer un incident ServiceNow.

Annexe

code des permissions gMSA :

      <#
Author: Kevin Joyce
Requirements: Active Directory PowerShell module, Domain Administrator privileges (to ensure the capability to get attribute GUIDs and view all permissions on all gMSA objects)
Description: Looks up permissions within Active Directory on a gMSA to determine access to modify the gMSA attribute (ms-ds-GroupMSAMembership).
Usage: populate the $target variable with the samaccountname of a gMSA.
To output the results to a text file run the following .gMSA_Permissions_Collection.ps1 > output.txt
#>
Import-Module ActiveDirectory
##Get the GUID of the extended attribute ms-ds-GroupMSAMembership from Schema
$schemaIDGUID = @{}
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -LDAPFilter '(name=ms-ds-GroupMSAMembership)' -Properties name, schemaIDGUID |
ForEach-Object {$schemaIDGUID.add([System.GUID]$_.schemaIDGUID,$_.name)}

<# **REPLACE DN VARIABLE BELOW**
Declare the samaccountname of the gMSA to search for#>
$target = 'gmsa'

##Get distinguished name of all gMSAs objects from the OU
$gMSAs = Get-ADServiceAccount -identity $target


<#Get objects that have specific permissions on the target(s): 
Full Control(GenericAll) 
Write all Properties (WriteProperty where ObjectType = 00000000-0000-0000-0000-000000000000 
#>
Set-Location ad:
foreach ($gmsa in $gMSAs){
(Get-Acl $gmsa.distinguishedname).access | 
Where-Object { (($_.AccessControlType -eq 'Allow') -and ($_.activedirectoryrights -in ('GenericAll') -and $_.inheritancetype -in ('All', 'None')) -or (($_.activedirectoryrights -like '*WriteProperty*') -and ($_.objecttype -eq '00000000-0000-0000-0000-000000000000')))} |
ft ([string]$gmsa.name),identityreference, activedirectoryrights, objecttype, isinherited -autosize 
}
<#Get objects that have specific permissions on the target(s) and specifically the gMSA attribute:
WriteProperty 
#>
Set-Location ad:
foreach ($gmsa in $gMSAs){
(Get-Acl $gmsa.distinguishedname).access | 
Where-Object {(($_.AccessControlType -eq 'Allow') -and (($_.activedirectoryrights -like '*WriteProperty*') -and ($_.objecttype -in $schemaIDGUID.Keys)))} |
ft ([string]$gmsa.name),identityreference, activedirectoryrights, objecttype, isinherited -AutoSize
}
      

voir brutgMSA_Permissions_Collection.ps1 hébergé avec par GitHub

FAQ

Qu'est-ce qu'un gMSA ?

Semblable aux comptes de service gérés (MSA), les comptes de service gérés de groupe (gMSAs) sont des comptes de domaine gérés qui sont utilisés pour aider à sécuriser les services et la gestion des accès. La fonctionnalité gMSA offre une gestion automatique des mots de passe par le contrôleur de domaine (DC), une gestion simplifiée du nom principal du service (SPN) et la possibilité de déléguer la gestion à d'autres administrateurs, ce qui améliore la sécurité Active Directory et réduit le nombre de comptes avec un accès privilégié.

Quelle est la différence entre les MSAs et les gMSAs ?

Contrairement à un MSA, un gMSA peut être associé à plusieurs ordinateurs.

Comment trouver un compte de service géré par un groupe ?

Pour obtenir une liste des gMSAs sur votre contrôleur de domaine, ouvrez Gestionnaire de serveur > Outils > Active Directory Users and Computers > Comptes de service gérés.

Un gMSA peut-il être un administrateur de domaine ?

Oui, un compte gMSA peut être membre des Domain Admins, bien que cette pratique puisse être dangereuse pour la sécurité de l'information.

Comment puis-je créer un gMSA ?

Les comptes de service gérés par groupe sont créés avec la cmdlet New-ADServiceAccount.

Les autorisations d'objet d'un gMSA déterminent si cette automatisation reste sécurisée. Lorsqu'un compte ordinaire dispose d'un accès en écriture à l'attribut qui contrôle la récupération du mot de passe, il peut s'accorder la permission de lire les identifiants, puis agir avec les droits existants de l'identité du service, y compris toute appartenance à un groupe privilégié que le compte détient.

Cette permission unique est souvent la seule chose qui sépare un déploiement renforcé d'une compromission à l'échelle du domaine.

Les comptes de service sont des identités non humaines, et 76 % des organisations ne les gouvernent ni ne les surveillent complètement, selon le Netwrix 2026 Data and Identity Security Report. Un compte de service géré par groupe supprime le mot de passe des mains humaines, mais toute personne pouvant réécrire quels principaux peuvent le récupérer peut toujours prendre le contrôle de l'identité.

Qu'est-ce qu'un compte de service géré de groupe (gMSA) ?

Comment fonctionne un gMSA

Le mot de passe d’un gMSA suit la même séquence sur chaque hôte qui l’utilise.

1. Le Key Distribution Service (KDS) sur chaque contrôleur de domaine détient le secret utilisé pour calculer les mots de passe de chaque gMSA dans le domaine.

Un compte de service géré de groupe est un compte géré de Active Directory domain utilisé pour exécuter des services, des applications et des tâches planifiées. Windows génère un mot de passe aléatoire et le fait tourner automatiquement, et les hôtes autorisés récupèrent les identifiants depuis Active Directory à l'exécution, de sorte que les administrateurs n'ont jamais besoin de connaître le mot de passe ni de le stocker dans des fichiers.

1. L'hôte récupère également le mot de passe précédent, maintenant l'authentification active pendant la courte période de propagation de la rotation.

Les gMSA ne s'appliquent pas aux systèmes d'exploitation Windows antérieurs à Windows Server 2012, donc chaque hôte qui en utilise un nécessite Windows Server 2012 ou une version ultérieure. Un gMSA prend en charge une identité de service sur plusieurs ordinateurs, tandis qu'un compte de service géré autonome prend en charge un seul ordinateur, et un compte utilisateur classique laisse la gestion des mots de passe aux administrateurs.

1. Parce que chaque hôte autorisé s’authentifie en tant que même principal de domaine, un gMSA simplifie également la gestion du Service Principal Name (SPN) pour les services qui partagent une identité entre plusieurs hôtes.
2. Windows fait tourner le mot de passe automatiquement, tous les 30 jours par défaut, sans qu’aucun hôte ait besoin d’un préavis ou d’une intervention manuelle.
3. Un hôte autorisé contacte un contrôleur de domaine et récupère le mot de passe actuel à l'exécution, calculé à partir de ce secret, plutôt que de le stocker localement.

gMSA vs autres types de comptes de service

Ensemble, ces attributs indiquent à un hôte comment récupérer le mot de passe, et msDS-GroupMSAMembershipExpand est ce qu’un attaquant doit réécrire, la mauvaise configuration exploitée dans le tutoriel plus bas.

Active Directory représente un gMSA avec la classe d'objet msDS-GroupManagedServiceAccountExpand, et ces attributs de schéma stockent le mot de passe et les contrôles de récupération.

Windows propose plusieurs principaux pour exécuter des services, chacun prenant en charge différents services et gérant son mot de passe différemment. Choisissez le type de compte en fonction des exigences d'authentification et du modèle de déploiement de l'application.

Contrairement à un sMSA, un gMSA peut être partagé entre plusieurs ordinateurs, ce qui le rend adapté aux fermes de serveurs et aux services équilibrés. Ce sont tous deux des comptes de service gérés qui permettent à Windows et Active Directory de gérer les mots de passe.

Pourquoi les gMSA sont importantes

Microsoft note que les mots de passe gMSA sont générés par machine et automatiquement renouvelés, mais ne sont pas liés à la machine, ils peuvent donc toujours être lus depuis un hôte compromis, et une gMSA ne peut pas être migrée directement vers une dMSA.

Windows Server 2025 ajoute le delegated managed service account (dMSA), qui migre un compte de service traditionnel vers un compte machine avec des clés gérées et aléatoires, et lie l'authentification à l'identité de l'appareil.

Mots de passe forts que personne n’a à gérer

Utiliser un compte utilisateur classique comme compte de service confie la génération, la distribution et la rotation des mots de passe aux administrateurs, et le mot de passe reste inchangé jusqu'à ce que quelqu'un le fasse tourner. Un gMSA remplace ce cycle manuel par une génération et une récupération gérées par le domaine.

Le mot de passe doit toujours atteindre chaque hôte, donc l'autorisation et la sécurité de l'hôte font partie de la protection des identifiants.

Une identité unique sur une ferme de serveurs

Les protocoles d’authentification qui prennent en charge l’authentification mutuelle, comme Kerberos, exigent que chaque instance d’un service hébergé en ferme utilise le même principal. Un gMSA fournit à tous les hôtes membres un principal de domaine unique, et les administrateurs gèrent ses permissions de manière centralisée sans synchroniser de mot de passe entre les hôtes.

Moins d’exposition aux attaques par force brute et aux usages abusifs

Un gMSA utilise un mot de passe de 240 octets généré aléatoirement que Windows change tous les 30 jours, minimisant le risque de compromission par attaques par force brute ou dictionnaire. Les administrateurs configurent le compte et ses hôtes autorisés et ne manipulent jamais le mot de passe, ainsi les services obtiennent des identifiants solides sans que personne ne les copie dans des scripts, notes de déploiement ou fichiers de configuration.

Les services Windows, les pools d’applications IIS et les tâches planifiées peuvent s’exécuter en tant que gMSA, et les recommandations Kerberoasting de Microsoft mentionnent également SQL Server. Le support applicatif reste une exigence de déploiement, donc testez chaque service sous le gMSA avant sa mise en production.

Une valeur par défaut plus sûre contre le Kerberoasting

La génération automatique supprime la sélection des mots de passe par les humains, et la rotation automatique supprime la tâche récurrente de mise à jour d’un identifiant statique sur chaque hôte de service. Microsoft recommande les gMSA pour les services sur site, sauf si un service ne peut pas les utiliser.

La responsabilité restante est la gouvernance des accès, car une personne pouvant modifier l'autorisation de récupération du mot de passe peut obtenir les identifiants sans jamais participer à la génération du mot de passe.

Kerberoasting permet à un attaquant disposant de n'importe quel compte de domaine de demander des tickets de service et de casser le mot de passe d'un compte de service hors ligne, la force du mot de passe déterminant si l'attaque fonctionne.

Les recommandations Kerberoasting de Microsoft désignent les comptes avec des mots de passe faibles comme les plus vulnérables et recommandent l’utilisation de gMSA ou dMSA chaque fois que possible, car un mot de passe généré supprime la faiblesse choisie par l’humain sur laquelle la technique repose.

Comment configurer un gMSA en toute sécurité

Netwrix Threat Manager détecte le vol d’identifiants, les mouvements latéraux et l’escalade de privilèges dans les environnements hybrides. Demandez une démo.

1. Vérifiez les exigences

Confirmez les exigences de domaine, d’hôte, d’administration et d’application avant de déployer le gMSA.

Créez le compte avec une liste explicite d’hôtes autorisés, puis installez-le et validez-le sur chaque hôte.

• Niveaux fonctionnels de domaine et de forêt définis sur Windows Server 2012 ou ultérieur, que Microsoft indique prendre en charge les fonctionnalités gMSA pour tous les appareils.
• Hôtes exécutant Windows Server 2012 ou une version ultérieure.
• Le module PowerShell Active Directory sur le système d’administration, qui nécessite une architecture 64 bits pour exécuter les cmdlets gMSA.
• Une clé racine KDS disponible pour les contrôleurs de domaine.
• Appartenance à Domain Admins ou Enterprise Admins, ou permission déléguée pour créer des msDS-GroupManagedServiceAccountExpand objets.
• Un service qui prend en charge les gMSA, comme un service Windows, un pool d'applications IIS ou une tâche planifiée.

Déléguez la création de gMSA à un groupe administratif dédié et maintenez l’identité du service hors des groupes administratifs.

2. Créez la clé racine KDS

3. Créez le gMSA avec New-ADServiceAccount

Les clusters de basculement ne prennent pas en charge les gMSA, mais les services exécutés sur le service Cluster peuvent en utiliser un s'ils sont un service Windows, un pool d'applications ou une tâche planifiée, ou s'ils prennent en charge les gMSA nativement. Kerberos doit également fonctionner de bout en bout, donc enregistrez les SPN pour chaque service, maintenez les enregistrements DNS et les horloges à jour, et autorisez le trafic Kerberos entre les systèmes concernés.

Malgré le nom du paramètre, -EffectiveImmediatelyExpand ne saute pas la réplication. Les autres contrôleurs de domaine ne peuvent pas utiliser la clé tant qu'elle n'est pas répliquée, et la procédure de création de clés de Microsoft fait attendre les contrôleurs de domaine jusqu'à 10 heures avant d'autoriser la création d'un gMSA, donc prévoyez cette fenêtre en production.

4. Installer et tester le gMSA sur chaque hôte

Créez un groupe de sécurité dédié pour les comptes des ordinateurs hôtes du service, puis créez le gMSA avec New-ADServiceAccountExpand, en nommant son nom d’hôte DNS et le groupe de sécurité dans PrincipalsAllowedToRetrieveManagedPasswordExpand. Microsoft exige que les noms gMSA soient uniques dans toute la forêt, pas seulement dans le domaine.

Vérifiez si la forêt possède déjà une clé racine KDS avant d’en créer une, car la clé est une condition préalable unique au niveau de la forêt. Créez-la sur un contrôleur de domaine Windows Server 2012 ou ultérieur avec Add-KdsRootKey -EffectiveImmediatelyExpand, puis confirmez l’ID d’événement 4004Expand dans le journal des événements KDS.

5. Configurez le service pour qu’il s’exécute en tant que gMSA

Définissez un intervalle de mot de passe personnalisé avec -ManagedPasswordIntervalInDaysExpand lors de la création si le déploiement en nécessite un, car l'intervalle ne peut être défini qu'à la création. Enregistrez le propriétaire de l'application du compte et les hôtes prévus avec la configuration du déploiement, et excluez les groupes généraux d'administration des serveurs ainsi que les groupes contenant des utilisateurs ordinaires du paramètre de récupération, comme l'explique "Limit who can retrieve the password".

Testez chaque serveur membre individuellement, car un résultat réussi sur un serveur ne garantit rien concernant l'appartenance à un groupe ou la connectivité d'un autre serveur. Résolvez les validations échouées avant de modifier l'identité de connexion d'un service en production.

Définissez l'identité de connexion du service via Service Control Manager, les paramètres d'identité du pool d'applications IIS ou la configuration de la tâche planifiée, et laissez le mot de passe vide. Windows récupère les informations d'identification gérées.

Comment les attaquants abusent d’un mot de passe gMSA

Attribuez au compte les permissions applicatives nécessaires, puis confirmez à la fois le démarrage du service et l'accès aux ressources dépendantes. Un test de compte réussi prouve uniquement la disponibilité des identifiants, donc la charge de travail nécessite toujours ses propres permissions pour les fichiers, bases de données et autres ressources.

Ajoutez le compte ordinateur de chaque hôte au groupe de sécurité, puis exécutez Install-ADServiceAccountExpand suivi de Test-ADServiceAccountExpand sur chaque hôte autorisé. Test-ADServiceAccountExpand vérifie que l'hôte peut récupérer le mot de passe.

Le laboratoire ci-dessous utilise un compte ordinaire nommé notadminExpand et un gMSA privilégié mal configuré. Les noms de domaine et de compte appartiennent à cet environnement d'exemple.

Trouvez les gMSA et qui peut les lire

Un attaquant peut récupérer un mot de passe gMSA via un chemin autorisé ou par des permissions Active Directory non sécurisées, puis s’authentifier en tant que compte avec ses droits existants.Exploitation gMSA couvre une classe d’attaque plus large, y compris les attaques Golden gMSA, qui empruntent une voie différente vers les identifiants gérés.

1. Avec le module PowerShell Active Directory disponible, l'attaquant énumère les comptes de service gérés avec Get-ADServiceAccount -Filter *Expand.

Trouvez un gMSA privilégié et un moyen d’entrer

1. La demande de la propriété PrincipalsAllowedToRetrieveManagedPasswordExpand indique quels principaux peuvent lire le mot de passe de chaque compte.

Dans les résultats du laboratoire, un seul compte administratif peut interroger les mots de passe, donc notadminExpand ne peut pas encore les lire. Cette configuration est importante lorsque l'attaquant examine qui peut modifier l'objet gMSA.

1. L'attaquant vérifie si un compte de service appartient à des groupes privilégiés en interrogeant la propriété memberOfExpand.

Le gMSA du laboratoire appartient à Domain Admins, donc l'attaquant le sélectionne. Son appartenance existante fournit les privilèges nécessaires pour les étapes suivantes.

Récupérer et décoder le mot de passe

1. L’examen des autorisations d’objet identifie les principaux disposant d’un Contrôle total, Écrire toutes les propriétés ou Écrire la propriété sur l’attribut d’autorisation de récupération de mot de passe, en utilisant un script adapté d’une méthode décrite dans un article sur Microsoft LAPS. Le script d’autorisations dans « Find and audit every gMSA » ci-dessous effectue la même vérification.
2. Dans le laboratoire, notadminExpand a un Contrôle total sur l'objet gMSA, ce qui lui permet d'utiliser Set-ADServiceAccountExpand pour s'ajouter à PrincipalsAllowedToRetrieveManagedPasswordExpand.

Utilisez le mot de passe pour escalader

1. L'attribut contient un BLOB contenant les données du mot de passe plutôt que le mot de passe lui-même, donc l'attaquant le décode avec DSInternals, ce qui expose les valeurs du mot de passe actuel et précédent et peut convertir le mot de passe actuel en un hash NT.
2. L'attaquant compromet notadminExpand via une technique telle que le phishing. Le compte dispose de privilèges Active Directory minimaux mais détient local administrator rights sur la machine compromise.
3. Après la modification, notadminExpand peut interroger l'attribut msDS-ManagedPasswordExpand et stocker l'objet retourné.

Comment sécuriser vos gMSA

Une seule autorisation trop large, Full Control sur un objet gMSA, a permis à l’attaque de passer d’un compte compromis ordinaire à une falsification des identifiants à l’échelle du domaine.

Les attaques Golden gMSA atteignent le mot de passe d’un gMSA par une autre voie et sont expliquées sur la page exploitation gMSA.

Sécurisez ensemble l'autorisation de récupération d'un gMSA, les permissions d'objet et les privilèges de service.

1. Avec les identifiants récupérés, l'attaquant s'authentifie en tant que gMSA via pass-the-hash et lance un processus sous l'identité du service, héritant de tous les droits détenus par cette identité.

Limiter qui peut récupérer le mot de passe

Restreindre qui peut modifier le gMSA

1. Parce que le gMSA du laboratoire appartient à Domain Admins, l'attaquant peut utiliser ses droits de réplication pour lancer une attaque DCSync contre le compte krbtgtExpand. Le matériel d'identification de ce compte signe chaque ticket Kerberos dans le domaine, donc le récupérer permet à l'attaquant de falsifier des tickets pour n'importe quel utilisateur par la suite.

Gardez les gMSA hors des groupes privilégiés

Seuls les comptes ordinateurs exécutant le service devraient normalement récupérer son mot de passe gMSA. Pour un déploiement multi-serveurs, utilisez un groupe de sécurité dédié contenant ces comptes ordinateurs, configurez-le via PrincipalsAllowedToRetrieveManagedPasswordExpand, et vérifiez son appartenance chaque fois que la liste des hôtes du service change.

Accordez l'accès en écriture uniquement aux administrateurs qui doivent gérer le compte, et vérifiez les autorisations Contrôle total, Écriture de toutes les propriétés et Écriture de propriétés spécifiques pour chaque gMSA. Un principal ayant la permission de modifier msDS-GroupMSAMembershipExpand peut autoriser la récupération de son propre mot de passe, ce qui est précisément la mauvaise configuration exploitée dans le tutoriel ci-dessus.

Attribuez à chaque gMSA uniquement les droits nécessaires à son service. Un gMSA peut appartenir à Domain Admins, mais cette appartenance donne à quiconque obtient ses identifiants des privilèges administratifs sur tout le domaine, et les recommandations de mitigation de Microsoft conseillent de revoir les permissions des comptes de service et de supprimer les accès excessifs.

Appliquer le chiffrement AES

Protégez le compte via les deux chemins d'autorisation. Restreignez les principaux que l'attribut msDS-GroupMSAMembershipExpand représente, et limitez l'accès à l'annuaire à l'objet gMSA lui-même, en particulier le droit de modifier le compte ou son autorisation de récupération.

Vérifiez l'appartenance directe au groupe et les autorisations effectives conférées par les groupes imbriqués, et documentez l'accès requis par l'application avant de supprimer les autorisations afin que le propriétaire du service puisse valider la configuration révisée.

Les contrôleurs de domaine exécutant Windows Server 2025 n’émettent plus du tout de tickets d’octroi RC4, donc un appareil ancien qui dépend de RC4 ne peut pas s’authentifier auprès d’eux.

Trouvez et auditez chaque gMSA

Microsoft supprime progressivement le chiffrement RC4 Kerberos par défaut, et ne se contente pas de le déconseiller. Une mise à jour de 2022 a déjà changé le type de chiffrement par défaut en Advanced Encryption Standard (AES)-SHA1 pour tout compte sans type de chiffrement explicite configuré.

Vérifiez l'attribut msDS-SupportedEncryptionTypesExpand de chaque gMSA et confirmez qu'il inclut AES plutôt que de vous fier au paramètre par défaut de secours du domaine, car c'est précisément ce paramètre que Microsoft supprime.

Réinitialisez le mot de passe du compte après avoir activé la prise en charge AES pour générer de nouvelles clés, puis testez l'authentification, car un gMSA laissé uniquement sur RC4 peut perdre complètement l'authentification Kerberos au lieu de simplement fonctionner avec un chiffrement plus faible.

Surveiller les lectures de mots de passe

Script original : gMSA_Permissions_Collection.ps1.

L'événement résultant identifie le compte sujet, l'objet de répertoire cible et les propriétés consultées.

Le script d'autorisations ci-dessous indique quels comptes disposent d'un accès Contrôle total ou Écriture de propriété à l'attribut msDS-GroupMSAMembershipExpand d'un gMSA, la vérification que l'étape 5 du tutoriel ci-dessus effectue du côté de l'attaquant. Les administrateurs doivent toujours examiner l'héritage, l'appartenance au groupe et l'accès effectif lorsqu'ils décident qui doit conserver ces droits.

Énumérez les comptes de service gérés avec Get-ADServiceAccount -Filter *Expand, puis filtrez les objets dont le ObjectClassExpand est msDS-GroupManagedServiceAccountExpand pour distinguer les gMSA des comptes de service gérés autonomes.

Retirez les gMSA que vous n’utilisez plus

Activez la stratégie d'accès au service d'annuaire d'audit et configurez une liste de contrôle d'accès système (SACL) sur les gMSA pour surveiller, ce qui génère l'ID d'événement 4662Expand chaque fois qu'un principal lit msDS-ManagedPasswordExpand.

Les identifiants de propriété apparaissent sous forme de GUID de schéma dans l’événement, et ADSI Edit peut résoudre le GUID pertinent pour confirmer qu’il correspond à msDS-ManagedPasswordExpand.

Transférez les journaux du contrôleur de domaine vers un système de gestion des informations et des événements de sécurité (SIEM), comparez les lectures de mots de passe avec les hôtes de service approuvés du compte, et enquêtez sur les récupérations par des utilisateurs ou ordinateurs inattendus.

Comment Netwrix aide à sécuriser les gMSA

Protéger l'administration gMSA

L'examen manuel des autorisations de récupération et des journaux d'audit ne peut pas être étendu dès qu'un environnement compte plus de quelques gMSA. Ces trois produits Netwrix couvrent l'accès administratif au compte, détectent les usages abusifs des identifiants et offrent une visibilité continue sur les comptes détenant encore des permissions excessives.

Supprimez un gMSA inutilisé de ses anciens hôtes avec Uninstall-ADServiceAccountExpand. La désinstallation de l’hôte et la suppression du compte d’annuaire sont des actions de cycle de vie distinctes. Assurez-vous que toutes les charges de travail dépendantes ont été migrées ou retirées avant de supprimer l’objet AD, et supprimez les autorisations d’hôte obsolètes ainsi que les permissions de ressources associées dans le cadre de la même modification.

Détecter un comportement anormal des comptes de service

Avec Netwrix Privilege Secure, le district accorde un accès temporaire via des comptes temporaires supprimés une fois la tâche terminée, et a mis en place Privileged Access Management pour ses systèmes critiques en quelques jours au lieu de plusieurs mois.

Netwrix Privilege Secure remplace l'accès permanent aux objets privilégiés tels que les gMSA par des comptes temporaires limités à la tâche. Eastern Carver County Schools a vu des Red Teams accéder à plusieurs reprises à des systèmes critiques via un accès privilégié excessif et inutile.

Trouvez les comptes de service surautorisés et obsolètes

Netwrix Threat Manager détecte le vol d’identifiants, les mouvements latéraux et l’escalade de privilèges dans les environnements hybrides. Enquêtez sur ces détections pour les abus d’identités de service telles que les gMSA, où un attaquant s’authentifiant avec un mot de passe géré volé exerce les droits existants de l’identité.

Associez la rotation automatique à des autorisations strictes de récupération

Netwrix Access Analyzer résout l’appartenance aux groupes imbriqués et analyse les autorisations effectives sur les objets Active Directory, et ses rapports signalent également les comptes de fiduciaires obsolètes. Utilisez ces résultats pour examiner la récupération de gMSA et les autorisations des objets et identifier les candidats au nettoyage.

La rotation automatique des mots de passe et les permissions strictes de récupération sont deux contrôles distincts, et un gMSA reste sécurisé uniquement lorsque les deux sont en place. L'exemple ci-dessus montre ce qui se passe lorsqu'une seule permission est défaillante : un compte compromis ordinaire hérite d'un identifiant Domain Admin et forge des tickets pour tout le domaine, sans qu'aucun mot de passe ne soit jamais craqué ou deviné.

Considérez les revues de permissions comme un travail récurrent, et non comme une étape de configuration unique, car chaque nouvel hôte, chaque changement d’appartenance à un groupe et chaque migration de service peuvent rouvrir le même chemin.

Demandez une démo pour voir comment Netwrix Privilege Secure supprime l'accès permanent aux comptes privilégiés, Netwrix Threat Manager détecte les abus de comptes de service et Netwrix Access Analyzer identifie les comptes surautorisés.