Utilisation des comptes gMSA dans l’Active Directory (group Managed Service Account)

Petit article que je repousse depuis très longtemps mais les congés de Noël m’offre un peu de temps pour m’y atteler… 😁 Aujourd’hui, nous allons parler comptes de service.

Si vous utilisez Active Directory, vous créez probablement des comptes utilisateurs, des groupes, des OU, … et toutes sortes d’objets dedans. Comme beaucoup d’entreprises j’imagine que pour vos applications métiers et services, vous créez des comptes de service. Le souci, c’est que la plupart du temps ces « comptes de service » ne sont que des comptes utilisateurs standards à qui vous avez attribué une convention de nommage spécifique visant à en faire des comptes de services (svc_, service_, etc.). Evidemment, rien de mal à ça – je vous rassure toutes les entreprises le font.

Sachez que depuis Windows Server 2008 R2, il existe ce que l’on appelle des Managed Service Accounts. Il s’agit de comptes spécifiques que vous pouvez utiliser pour vos applications, tâches planifiées, scripts, serveur base de données, etc. Le principe de ces comptes de service et que vous n’aurez pas besoin de connaître le mot de passe et surtout il y aura une rotation automatique du mot de passe effectuée par l’AD. C’est donc un outil inestimable pour sécuriser votre Active Directory (lui-même à la base de toute votre infrastructure).

Pour les détails sur le fonctionnement de ces comptes, je vous encourage à consulter la documentation officielle sur le site de Microsoft. Malheureusement, même si c’était une excellente avancée technique pour gérer ces types de comptes, les MSA avaient un problème majeur : un compte comme celui-ci ne pouvait être utilisé/consommé que par 1 seul serveur. Ce qui excluait donc tout usage au sein d’un Cluster ou infrastructure plus conséquente.

Avec l’arrivée de Windows Server 2012, il est désormais possible de créer des comptes appelés gMSA – group Managed Service Accounts. Vous l’aurez deviné, c’est exactement le même principe que les MSA sauf que là le compte de service va pouvoir être utilisé sur plusieurs machines. D’une manière générale, je vous encourage à utiliser systématiquement les gMSA plutôt que les MSA – et c’est ce que je vous propose de voir dans cet article ! 🤓

Prérequis pour l’utilisation d’un compte gMSA

Avant de pouvoir créer et utiliser un compte gMSA, nous allons devoir générer une racine KDS. Pour ce faire, nous allons utiliser la commande suivante :

Add-KdsRootKey -EffectiveImmediately

Dans mon exemple ci-dessus, j’ai choisi d’utiliser la paramètre –EffectiveImmediately qui permet en effet de pouvoir activer et utiliser cette racine KDS immédiatement. Si c’est acceptable dans un environnement de Pré-Production / Test, cela ne l’est en revanche PAS recommandé dans votre Production. Sans ce paramètre, vous devrez attendre au moins 10 h (durée de validité maximum des tickets Kerberos – configuré dans la Domain Controllers policy).

Si vraiment vous ne pouvez pas attendre, utilisez la commande ci-dessous :

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

Une fois que c’est bon, vous pouvez vérifier en démarrant l’outil Active Directory Sites and Services. Vous pourrez alors voir que votre racine a bien été générée.

Note : Si ça ne vous parle pas, vérifiez avec votre admin car en général c’est quelque chose qui a été créé en amont ou pour d’autres besoins (attention à bien utiliser la vue avancée « service node » dans Active Directory Sites and Services.

Créer un compte group Managed Service Account

L’un des principaux points de blocage à l’utilisation intensive des comptes gMSA dans toutes les infrastructures du monde est principalement : le manque de connaissance. Même si tout a commencé avec 2008 R2, c’est encore très courant pour des entreprises de découvrir cet outil.

L’autre aspect qui peut être bloquant pour certains admins est qu’il n’existe aucune console graphique (officielle) pour créer un compte gMSA. Cela passe nécessairement par du PowerShell. Cela dit, vous allez voir que ce n’est pas compliqué ! 😉

Commencez avec la commande suivante :

New-ADServiceAccount -Name "gMSA-applitoto" -Description "gMSA pour mon appli toto" -DNSHostName "VM-APP-TOTO.akril.local" -ManagedPasswordIntervalInDays 30 -PrincipalsAllowedToRetrieveManagedPassword "VM-APP-TOTO$" -Enabled $True

Evidemment, je vous laisse le soin d’adapter la convention de nommage en fonction de vos besoins.

Comme vous le voyez dans les paramètres, on peut spécifier le nombre de jours pour la rotation du mot de passe et surtout le serveur sur lequel nous allons utiliser ce compte gMSA (dans mon cas j’ai créé une VM et j’ai également imaginé une application « toto » mais c’est pour tester).

Si le compte a bien été créé, vous pourrez le voir dans le container par défaut de votre Active Directory à la racine : « Managed Service Accounts« .

Afin de pouvoir utiliser de compte de service, nous allons maintenant l’associer à notre VM / serveur sur lequel notre application imaginaire « toto » va consommer ce gMSA.

Exécutez la commande suivante :

Add-ADComputerServiceAccount -Identity VM-APP-TOTO -ServiceAccount gMSA-applitoto

Si tout s’est bien passé et que vous n’avez pas eu d’erreur – dans ce cas, au niveau de l’objet Computer, vous verrez que l’attribut : msDS-HostServiceAccount a changé (n’oubliez pas d’utiliser le mode avancé). Vous devriez voir que votre compte gMSA a été ajouté. C’est ce qui va autoriser notre VM à utiliser notre compte gMSA.

Installation du compte group Managed Service Account

Cette utilisation du terme « Installation » est un peu étrange mais c’est pour faire référence à la CmdLet que nous allons utiliser.

Cette dernière va nous permettre « d’installer » le compte gMSA sur notre serveur. Evidemment, tout est toujours en PowerShell donc si vous n’avez pas accès aux CmdLet Active Directory sur la machine cible : vous allez devoir installer préalablement la feature RSAT-AD-PowerShell.

Si besoin exécutez d’abord la commande suivante :

Add-WindowsFeature RSAT-AD-PowerShell

Une fois que c’est bon, utilisez la commande suivante :

Install-ADServiceAccount gMSA-applitoto

PowerShell ne sera pas très bavard donc si vous n’avez aucun retour et aucune erreur – c’est que c’est tout bon ! 😁

Si vous voulez toutefois vérifier que la VM est prêt à utiliser votre compte de service gMSA, vous pouvez exécuter la commande suivante :

Test-AdServiceAccount -Identity gMSA-applitoto

Si vous avez comme réponse « True » alors c’est que tout est bon ! 🤓

Il ne reste donc plus qu’a utiliser ce compte gMSA dans votre application.

Utilisation du compte gMSA dans notre application

Donc là, vous avez tout fait. Le compte gMSA est prêt à être utilisé. Ce qu’il vous reste à savoir désormais c’est que pour pouvoir utiliser un compte gMSA, votre application ou middleware doit être compatible – c’est-à-dire que l’éditeur doit avoir modifié son application pour qu’elle soit compatible avec les gMSA.

C’est le cas aujourd’hui sur la plupart des outils Microsoft mais les éditeurs tiers traînent encore un peu des pieds pour prendre en charge cette fonctionnalité. Par exemple ci-dessous vous avez le cas de l’AAD Connect qui peut désormais fonctionner avec un gMSA (au moment de l’installation).

Donc pour l’utilisation, je vous invite à vérifier la compatibilité avec votre application. Plus il y aura d’infrastructures qui utiliseront massivement les comptes gMSA, plus les éditeurs seront forcés de faire les changements dans leur code.

Dans mon prochain article, je vous montrerai comment utiliser un compte gMSA dans l’utilitaire des tâches planifiées de Microsoft. Donc si vous avez des scripts cmd ou PowerShell qui ont besoin de droits spécifiques – cela devrait forcément vous intéresser. 🙂

Lecture(s) additionnelle(s) :

• Managed Service Accounts: Understanding, Implementing, Best Practices, and Troubleshooting
• Group Managed Service Accounts Overview

Crédits image bannière – madartzgraphics