Active Directory : utiliser un gMSA dans une tâche planifiée

I. Présentation

Dans ce tutoriel, nous allons apprendre à créer un compte gMSA et à l'utiliser au sein d'une tâche planifiée sur Windows Server afin d'exécuter un script PowerShell (ou autre chose) de façon sécurisée.

Exécuter un script PowerShell au sein d'une tâche planifiée, c'est quelque chose de très courant, y compris avec un compte ayant des privilèges élevés sur le domaine Active Directory afin de pouvoir effectuer les tâches qui vont bien. Lors de la configuration de la tâche planifiée, vous allez devoir associer un compte utilisateur qui sera utilisé par Windows pour exécuter la tâche. Pour ce compte, vous avez plusieurs options, dont :

• Associer le compte Administrateur du domaine (ou un équivalent), ce qui est vraiment mal ;
• Associer un compte utilisateur avec une convention de nommage spécifique pour lui donner des allures de comptes de service, par exemple "CDS-Srv-01", disons que ce n'est pas l'idéal non plus, car en général, le mot de passe de ce compte ne sera jamais changé
• Associer un gMSA, c'est-à-dire un véritable compte de service stocké dans l'Active Directory et qui aura un mot de passe renouvelé automatiquement à intervalle régulier (sans aucune configuration de votre part) : là, on est bien !

Bien sûr, dans ce tutoriel je vais vous présenter la dernière option : l'utilisation d'un compte gMSA pour exécuter une tâche planifiée sur Windows. Si vous découvrez la notion de gMSA, je vous recommande de lire l'article ci-dessous, publié il y a quelque temps. Je vous rappelle que les comptes gMSA sont disponibles depuis Windows Server 2012.

• Tutoriel - Active Directory et les comptes gMSA

II. Création du compte gMSA

Dans le but de pouvoir créer un compte gMSA sur notre annuaire Active Directory, il faut générer une clé KDS racine : c'est un prérequis. Sans m'attarder sur le sujet, car je l'ai déjà fait précédemment, voici la commande à exécuter pour créer cette fameuse clé KDS (la commande Get-KdsRootKey permettra de voir si vous en avez déjà une) sur un environnement de production (active sous 10h, le temps de permettre à la clé de se répliquer sur tous les DC) :

Add-KdsRootKey -EffectiveImmediately

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))

Le cmdlet New-ADServiceAccount va nous permettre de créer un gMSA nommé "gMSA-SRV-APPS" que le serveur "SRV-APPS" va pouvoir utiliser. Le mot de passe de ce compte gMSA sera régénéré tous les 30 jours, automatiquement. Voici la commande correspondante :

New-ADServiceAccount -Name "gMSA-SRV-APPS" `
                     -Description "gMSA pour tâches planifiées SRV-APPS" `
                     -DNSHostName "gmsa-srv-apps.it-connect.local" `
                     -ManagedPasswordIntervalInDays 30 `
                     -PrincipalsAllowedToRetrieveManagedPassword "SRV-APPS$" `
                     -Enabled $True

- Microsoft Docs - New-ADServiceAccount

Le compte gMSA nommé "gMSA-SRV-APPS" est créé sur mon annuaire Active Directory. Il nous reste deux choses à effectuer :

• L'associer au serveur SRV-APPS dans l'Active Directory

Add-ADComputerServiceAccount -Identity "SRV-APPS" -ServiceAccount "gMSA-SRV-APPS"

• L'ajouter au groupe "Admins du domaine", car il doit pouvoir effectuer des tâches nécessitant des privilèges élevés

Add-ADGroupMember -Identity "Admins du domaine" -Members "gMSA-SRV-APPS$"

Bien sûr, l'ajout dans le groupe "Admins du domaine" peut être fait via la console graphique de gestion de l'Active Directory, comme n'importe quel autre objet. D'ailleurs, on peut vérifier que le gMSA est bien dans le groupe :

Passons sur le serveur SRV-APPS afin de l'utiliser dans une tâche planifiée.

III. Ajouter le gMSA sur le serveur

Le gMSA doit être "installé" sur le serveur pour reprendre le terme de la commande "Install-ADServiceAccount" que nous allons utiliser. Pour utiliser ce cmdlet, il faut disposer du module Active Directory de PowerShell sur l'hôte local (Add-WindowsFeature RSAT-AD-PowerShell). Ensuite, on l'installe en l'appelant par son nom :

Install-ADServiceAccount "gMSA-SRV-APPS"

Il ne reste plus qu'à créer la tâche planifiée et à utiliser le gMSA.

IV. Créer une tâche planifiée avec un gMSA

Pour créer la tâche planifiée, vous allez voir que c'est, à un détail près, une procédure de création classique d'une tâche planifiée sur une machine Windows. Ouvrez la console "Gestion de l'ordinateur", puis "Planificateur de tâches" dans le menu à gauche. Effectuez un clic droit et cliquez sur "Créer une nouvelle tâche". Nous pourrions créer la tâche planifiée avec PowerShell, mais ce n'est pas ce qu'il y a de plus intuitif.

L'assistant va démarrer, nous allons pouvoir configurer la tâche planifiée. Pour ma part, je nomme la tâche "Script PowerShell - Copier un fichier sur tous les ordinateurs", mais cela vous importe peu ! 🙂

Cette tâche planifiée va exécuter le script "C:\Scripting\Copier-Fichier-PC.ps1" qui a un objectif très simple : copier un fichier sur chaque machine de l'AD contenue sous l'OU "PC". Voici le code, à titre indicatif :

$PCList = (Get-ADComputer -Filter * -SearchBase "OU=PC,DC=it-connect,DC=local").name

Foreach($PC in $PCList){
    Copy-Item -Path "C:\Partage\IT-Connect.txt" -Destination "\\$PC\Partage\"
}

Ce qui est important, ce sont les options de sécurité. Cliquez sur le bouton "Utilisateur ou groupe" afin que l'on puisse sélectionner le gMSA afin que ce soit le compte utilisé par la tâche planifiée. Une fenêtre va s'ouvrir... Cliquez sur "Emplacements" et sélectionnez "Tout l'annuaire" (et non votre domaine) puis "Types d'objets" afin de sélectionner "Des comptes de service".

Une fois que c'est fait, saisissez le nom de votre gMSA (ou le début de son nom) et cliquez sur "Vérifiez les noms". Le gMSA doit être trouvé : il ne reste plus qu'à cliquer sur "OK".

Voilà, la tâche planifiée s'exécutera avec notre compte gMSA ! 🙂

Au sein de cet onglet "Général", cochez également "Exécuter même si l'utilisateur n'est pas connecté" et "Configurer pour :", choisissez la version la plus élevée de Windows proposée dans la liste.

Pour le reste, il faut définir un déclencheur, puis une action. Pour l'action, ce sera notre script PowerShell : cliquez sur l'onglet "Actions" puis sur "Nouveau". Indiquez :

• Programme/script : powershell.exe
• Ajouter des arguments : -File "<chemin vers le script>" (pour ma part : -File "C:\Scripting\Copier-Fichier-PC.ps1")

Ce qui donne :

Vous n'avez plus qu'à valider, car la tâche planifiée est prête. Enfin, je vous laisse le soin d'ajuster les autres paramètres propres à vos besoins, si vous le souhaitez.

V. Autoriser le gMSA à se connecter en tant que tâche

Afin que le compte gMSA soit en mesure d'exécuter le script via la tâche planifiée, il faut l'autoriser à ouvrir une session en tant que tâche. Sinon, le script ne pourra pas s'exécuter en principe (mais j'ai déjà rencontré des cas où cela fonctionne sans ce paramètre). Pour cela, il faut créer une GPO et l'appliquer sur le(s) serveur(s) qui vont utiliser le gMSA, ou modifier la stratégie locale (gpedit.msc).

Si l'on fait une GPO, ce qui sera le cas en production, il faudra modifier ce paramètre :

Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Attribution des droits utilisateurs > Ouvrir une session en tant que tâche

Ce paramètre doit être définit et le gMSA sélectionné, sur le même principe que pour le sélectionner au sein de la tâche planifiée.

Grâce à ce changement additionnel, le script PowerShell va s'exécuter en tâche planifiée sans difficultés ! 🙂

Je vous encourage fortement à exécuter vos tâches planifiées (et les autres services) avec des comptes gMSA afin de renforcer la sécurité de votre infrastructure basée sur un Active Directory.