13/10/2024

Active Directory

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.

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".

gMSA tâche planifiée

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.

author avatar
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.
Partagez cet article Partager sur Twitter Partager sur Facebook Partager sur Linkedin Envoyer par mail

10 commentaires sur “Active Directory : utiliser un gMSA dans une tâche planifiée

  • Bonjour,
    En ajoutant, un gMSA au groupe « Admins du domaine » est-ce que cela n’ajoute pas une vulnérabilité à l’AD ?

    Répondre
    • Bonjour,
      Pour ma part j’aurais tendance à dire oui ça ajoute une vulnérabilité à l’AD.
      Un administrateur local du serveur SRV-APPS pourrait créer une tâche planifiée, à exécuter avec le compte gMSA, qui ajouterai un Administrateur du domaine à l’AD.

      Répondre
  • Je ne suis pas spécialiste, mais c’est un compte de service, on ne peut donc pas se loguer avec.

    Répondre
  • Bonjour,
    Effectivement c’est une vulnérabilité à l’AD.
    Ex : une tache planifié avec ce compte de service (droit admin du domaine) exécutant un script sur l’ensemble des serveurs !

    Pour corriger affecter le compte de service gMSA au groupe Administrateurs local. Ce qui limitera le périmètre d’action au serveur uniquement.

    Bien à vous,

    Répondre
  • Bonjour,
    Je viens de créer un compte gMSA pour test, et la tache derrière, mais la tache ne se lance pas.
    Le Planificateur de tâches n’a pas pu démarrer la tâche « \Powershell_Mail Redemarrage » pour l’utilisateur « (NONE) ». Données supplémentaires : Valeur de l’erreur : 2147944189.
    Je soupçonne un problème au niveau de l’authentification
    Si je teste avec un compte qui a des droits de lancer une tache pas de souci

    Répondre
  • Bonjour, J’essais de configurer google sync depuis mon ad et exécuter un script de lancement. Problème, la console de configuration google rend la config créé utilisable seulement par le créateur. Dans ce cas, impossible de se logger avec un compte de service pour créer la config si ?

    Répondre
  • Bonjour, merci pour ce tuto !
    Question pratique : est-il possible de stocker un certificat autosigné dans le magasin personnel de certificats de ce compte (certmgr.msc) svp ?

    Répondre
  • Bonjour,
    j’ai plusieurs tâches qui tournent avec gMSA sans soucis. Mais j’ai voulu en reconfigurer une et a l’enregistrement il me demande le mot de passe du compte gMSA. Vu que c’est impossible comment faire pour modifier ma tache ?

    Répondre
    • pour cela il faut retourner sur le choix du compte et simplement re choisir tout l’annuaire / compte de securité et remettre le nom du compte (sans le $ a la fin).

      en validant il prends la modification

      Répondre
  • Bonjour,
    Bonne documentation qui m’a permis de mettre en place des gMSA dans mon infra.

    Cependant, je me suis heurté à un problème de production suite à la mise en place de compte pour des services. J’ai donc ajouté les gMSA pour les tâches à ouvrir des sessions en tant que tâches seulement, et les gMSA pour les services en tant que services uniquement.

    Or, suite à cela toutes mes tâches planifiés ont cessé de fonctionner ! J’avais la même erreur que @buisson avec le même code erreur. En regardant dans les logs de sécurité, l’authentification s’effectué en tant que service (LogonType: 5). J’ai donc dû ajouter tous les comptes gMSA de tâches dans l’authentification en tant que service en plus de l’authentification en tant que tâche.

    Si quelqu’un à une explication à pourquoi ce fonctionnement, je suis preneur. Nul part il est indiqué que les gMSA pour les tâches doivent avoir les deux droits. A savoir, que par sécurité, je n’ai pas ajouté les comptes dans le groupe « Admins du domaine » qui pour moi reste une faille de sécurité conséquente.

    Répondre

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.