Active Directory : utilisation des gMSA (group Managed Service Accounts)

I. Présentation

Dans ce tutoriel, nous allons voir comment préparer son infrastructure à l'utilisation des comptes de service gMSA, ainsi que l'utilisation et la gestion des comptes gMSA sur des serveurs sous Windows Server.

Windows Server 2008 a apporté les comptes de type MSA (Managed Services Accounts) appelé également sMSA (standalone Managed Service Account) et Windows Server 2012 quant à lui a apporté dans son sac de nouveautés les gMSA (group Managed Service Accounts) qui sont une version améliorée des MSA.

Ce qu'il faut savoir au sujet des gMSA :

- Un même gMSA est utilisable sur plusieurs serveurs

- Les gMSA sont stockés dans le container "Managed Service Account" dans l'Active Directory

- Un gMSA est utilisable uniquement sur Windows Server 2012 et ultérieur

- Nécessite l'utilisation de Microsoft Key Distribution Service (kdssvc.dll) pour la gestion automatique des mots de passe et la création des comptes

- un gMSA s'apparente à un groupe de sécurité dans lequel on va associer des objets ordinateurs qui seront autorisés à utiliser ce compte de service sécurisé

- Le niveau fonctionnel de votre forêt Active Directory doit être Windows Server 2012 au minimum

- Le mot de passe est géré par l'Active Directory, il est très très complexe et personne ne le connaît

Avec un compte MSA ou gMSA, la gestion du mot de passe est automatique par l'Active Directory lui-même, contrairement à l'utilisation d'un compte utilisateur classique, que l'on peut utiliser pour un service mais pour lequel vous devez gérer vous même le renouvellement du mot de passe. Bien souvent, comme c'est contraignant et chronophage, les mots de passe de ces comptes ne sont pas renouvelés par les administrateurs. D'où l'utilité de s'appuyer sur la solution gMSA, qui en plus offre une sécurité accrue au niveau des credentials.

Un compte MSA peut-être associé à seulement un serveur, contrairement au gMSA, ce qui est contraignant lorsque vous avez besoin d'utiliser un compte de service sur un service qui est redondé entre plusieurs serveurs.

Au niveau de la compatibilité, les comptes gMSA fonctionnent avec différents types d'applications et de fonctionnalités, notamment :

- Des services Windows
- Des tâches planifiées
- Des serveurs IIS (Pool d'applications), SQL Server, ADFS, etc.

II. Prérequis - générer une clé KDS racine

Pour être en mesure de créer des comptes gMSA sur notre infrastructure Active Directory, le service Key Distribution Service doit être en cours d'exécution et une clé racine doit être générée. Pour créer une clé à partir du contrôleur de domaine, nous allons utiliser PowerShell et le cmdlet Add-KdsRootKey.

Il est possible de différer l'activation de la clé générée grâce à l'utilisation du paramètre -EffectiveTime suivi d'une date. Si l'on utilise le paramètre -EffectiveImmediately la clé sera utilisable 10 heures après sa création (comportement par défaut) afin de s'assurer qu'elle soit répliquée entre les différents DC.

Voici la commande à exécuter :

Add-KdsRootKey -EffectiveImmediately

Dans le cadre d'un lab, si vous souhaitez pouvoir utiliser la clé KDS dès maintenant sans devoir attendre 10 heures, il est possible de tricher en utilisant cette commande :

Add-KdsRootKey –EffectiveTime ((Get-Date).AddHours(-10))

La clé créée est identifiable avec un Guid.

- Add-KdsRootKey

La clé peut-être affichée simplement en exécutant la commande ci-dessous :

Get-KdsRootKey

Ce qui retourne un résultat sous cette forme :

AttributeOfWrongFormat :
KeyValue : {174, 194, 208, 151...}
EffectiveTime : 16/04/2020 18:43:58
CreationTime : 16/04/2020 18:43:58
IsFormatValid : True
DomainController : CN=SRV-ADDS-01,OU=Domain Controllers,DC=IT-CONNECT,DC=LOCAL
ServerConfiguration : Microsoft.KeyDistributionService.Cmdlets.KdsServerConfiguration
KeyId : 907a7443-1e9e-4026-b06b-03ae9adf9ce6
VersionNumber : 1

Si vous souhaitez vérifier la validité d'une clé racine, le cmdlet Test-KdsRootKey est utilisable. Il suffit de préciser le Guid de la clé à vérifier. Par exemple :

Test-KdsRootKey -KeyId 907a7443-1e9e-4026-b06b-03ae9adf9ce6

Si la clé est valide, la valeur true sera retournée dans la console.

Les clés Kds sont visibles dans la console "Sites et services Active Directory", en activant l'option "Afficher le nœud des services" dans le menu "Affichage".

Ensuite, parcourez de cette façon : Services > Group Key Distribution Service > Master Root Keys

Maintenant que ce prérequis est réalisé, nous pouvons passer à la suite.

III. Créer un gMSA

Pour créer un gMSA sur notre infrastructure Active Directory, nous allons utiliser le cmdlet New-ADServiceAccount et différents paramètres. Voici la commande à exécuter pour créer et activer un gMSA nommé "gMSA-01" avec un mot de passe qui se renouvelle tous les 30 jours. Le compte d'ordinateur "SRV-MGMT-01$" sera autorisé à utiliser ce gMSA.

New-ADServiceAccount -Name "gMSA-01" `
                     -Description "gMSA pour IIS - www.it-connect.fr" `
                     -DNSHostName "gmsa-01.it-connect.local" `
                     -ManagedPasswordIntervalInDays 30 `
                     -PrincipalsAllowedToRetrieveManagedPassword "SRV-MGMT-01$" `
                     -Enabled $True

Quelques explications supplémentaires sur les paramètres :

• ManagedPasswordIntervalInDays : sert à indiquer que le mot de passe doit être réinitialisé tous les X jours. Cette action est automatique et ne nécessite aucune action de maintenance. Cet attribut est à définir lors de la création du gMSA, ensuite il est en lecture seule (read only).
• PrincipalsAllowedToRetrieveManagedPassword : sert à indiquer l'objet qui pourra utiliser ce gMSA et va écrire l'attribut msDS-GroupMSAMembership au niveau de l'objet gMSA. Bien entendu, il est possible d'autoriser d'autres objets par la suite puisqu'un gMSA est utilisable par plusieurs hôtes.
• DNSHostName : nom DNS de cet objet gMSA

- New-ADServiceAccount

Lorsque le gMSA est créé, nous pouvons le retrouver dans l'annuaire Active Directory au sein du container "Managed Service Account".

L'objet gMSA étant créé, il faut que l'on ajoute ce compte de service à notre objet ordinateur SRV-MGMT-01 pour l'associer. Pour cette action, le cmdlet à utiliser est Add-ADComputerServiceAccount, avec deux paramètres : -Identity pour le nom du serveur et -ServiceAccount pour le nom ou des services à lier.

Ce qui donne :

Add-ADComputerServiceAccount -Identity SRV-MGMT-01 -ServiceAccount gMSA-01

Si l'on regarde notre objet ordinateur dans l'AD, à savoir l'objet "SRV-MGMT-01", on peut voir qu'il y a eu une modification de l'attribut msDS-HostServiceAccount. Cet attribut contient désormais une valeur correspondante à notre gMSA "gMSA-01".

La création du gMSA est terminée, passons à la suite.

IV. Ajouter le gMSA sur le serveur

Pour être utilisé sur un serveur, le gMSA doit être installé sur ce serveur à l'aide d'un cmdlet qui est intégré au module PowerShell "ActiveDirectory". Si vous intervenez sur un serveur qui n'est pas contrôleur de domaine, vous devez installer ce module. Cela s'effectue tout simplement avec la commande suivante :

Add-WindowsFeature RSAT-AD-PowerShell

L'installation prendra seulement quelques secondes et ne nécessite pas de redémarrer le serveur.

Dès lors que le module PowerShell cité précédemment est installé, le compte gMSA peut être installé sur le serveur. Il suffit d'appeler le cmdlelt Install-ADServiceAccount et de préciser le nom du gMSA à installer, comme ceci :

Install-ADServiceAccount gMSA-01

Une fois installé, vous pouvez tester que c'est OK grâce à la commande suivante :

Test-AdServiceAccount -Identity gMSA-01

Cette commande doit retourner "true" dans la console si tout est opérationnel.

Note: pour utiliser un compte gMSA sur un serveur, ce dernier doit être membre du domaine.

Tout est prêt, j'entends par là que le gMSA est correctement associé à notre serveur et qu'il est intégré sur le serveur.

V. Utiliser le gMSA

Comme je vous le disais, pour utiliser un gMSA sur un serveur, celui-ci doit être membre du domaine Active Directory, mais aussi et c'est important, il doit exécuter au minimum Windows Server 2012.

La dernière étape consiste à l'associer à votre tâche planifiée, votre service, etc... Par exemple, on peut l'utiliser sur un pool d'application IIS. Ce qui est important, c'est de bien laisser le champ mot de passe vide quand vous utilisez un gMSA. Autre chose importante, quand vous indiquez le nom du compte gMSA, pensez à ajouter un "$" à la fin et en préfixe le nom NETBIOS du domaine. Pour le compte gMSA "gMSA-01", cela donne :

IT-CONNECT\gMSA-01$

VI. Désinstaller un gMSA

Si le gMSA que vous avez installé sur votre serveur n'a plus d'utilité, le mieux c'est de le désinstaller de votre serveur. Pour cela, depuis le serveur sur lequel il est installé, exécutez la commande suivante (exemple avec le gMSA "gMSA-01") :

Uninstall-ADServiceAccount "gMSA-01"

Cette fois-ci, la commande de test doit retourner "false".

Test-AdServiceAccount -Identity gMSA-01

Ce tutoriel est terminé, à vous de jouer... Si vous recherchez des informations supplémentaires, vous pouvez utiliser la documentation Microsoft : gMSA

Sur le même sujet : utiliser un gMSA dans une tâche planifiée.

Florian BURNEL Co-founder of IT-Connect

Ingénieur système et réseau, cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture.

See Full Bio