Dans un précédent article, je vous ai montré comment créer et utiliser un compte gMSA. Je ne vais pas reprendre dans ce deuxième l’article l’ensemble des explications – je vous invite donc à consulter mon précédent post. 🤓 En revanche, nous allons voir un scénario classique et simple d’utilisation d’un compte gMSA.
Imaginez que vous ayez besoin (je suis sûr que c’est le cas) de créer et exécuter des scripts PowerShell avec d’important privilèges comme par exemple Domain Admin, Enterprise Admin, … et ce de manière régulière ! Utiliser une compte de service classique donc vous ne changez jamais le mot de passe… pas ouf en termes de sécurité ! 😒
Nous allons donc voir comment nous pouvons utiliser un compte gMSA qui utiliserait de grands privilèges pour exécuter un script PowerShell de manière régulière avec le planificateur de tâches intégré dans Windows Server (c’est un exemple assez classique d’utilisation).
Créer le compte gMSA et l’affecter à votre serveur
Pour ce faire, je vous invite à exécuter les quelques CmdLet PowerShell que je vous présente dans mon ancien article. Une fois que le compte gMSA est créé nous allons l’utiliser sur la machine qui doit exécuter la tâche planifiée. Je considère toute cette partie comme effectuée. 😉
Script de test
Pour tester notre scénario, je vous propose de faire un script tout simple. On va créer un script PowerShell qui va ajouter un groupe Active Directory de sécurité dans le container par défaut « Users ». Vous serez d’accord avec moi que notre compte de service, s’il souhaite pouvoir réaliser cette tâche, doit être membre du groupe « Domain Admins » au minimum.
Je créée donc un fichier PowerShell dans lequel je mets la ligne de commande suivante :
New-ADGroup -Name "PwetGroup" -SamAccountName PwetGroup -GroupCategory Security -GroupScope Global -DisplayName "PwetGroup" -Path "CN=Users,DC=akril,DC=local" -Description "Coucou"
Pensez à remplacer le Path en fonction du nom de votre domaine Active Directory.
J’ai positionné le script dans un dossier de test : C:\Temps\Scripts\PowerShell.
Mon script s’appelle : CreateGroup.ps1.
Je reprends donc le script gMSA que j’ai créé précédemment (encore une fois, reportez-vous à mon précédent article si votre compte gMSA n’est pas déjà créé). Je donne les privilèges « Domain Admins » à mon gMSA (oui c’est possible comme avec n’importe quel compte d’utilisateur et/ou computer). 😉
Création de la tâche planifiée
Nous allons maintenant nous connecter sur le serveur qui doit exécuter la tâche planifiée.
Démarrez le Task Scheduler et créez une nouvelle tâche planifiée. Je vais pas mettre une capture d’écran pour tout. Donc s’il y a quelque chose qui vous semble manquer, c’est que j’ai pris les réglages par défaut – tout simplement. 😉
Pour exécuter un script PowerShell, configurez votre tâche planifiée comme sur le screenshot ci-dessous. Dans Program/script, mettez powershell.exe tandis que dans Add Argument ajoutez -File « chemin-vers-votre-script ».
Il ne nous reste alors plus qu’à sélectionner notre compte gMSA pour exécuter la tâche planifiée.
Utilisez le bouton « Change User or Group » et sélectionnez votre compte gMSA. Pour ce faire, vous devrez :
- Modifiez la localisation pour chercher dans l’AD et pas en local sur le serveur ;
- Modifiez les types d’objets et ne gardez que Service Account ;
- Saisissez ensuite quelques lettres de votre compte gMSA pour le retrouver ;
- Validez.
Petite spécificité qu’il ne faut pas oublier mais pour que votre de service gMSA puisse exécute un script PowerShell vous devez l’autoriser à le faire en l’ajoutant également dans les User Right Assignment et lui donner la permission Log on as a batch job. Vous pouvez le faire en GPO ou directement via une local policy dans gpedit.msc (j’ai choisi la seconde option pour aller plus vite car ce n’est pas l’objet du test).
Voilà, on est tout bon pour notre test final ! 🤓
Evidemment, on ne va pas attendre que la tâche planifiée passe à un créneau horaire spécifique. Cliquez simplement du bouton droit sur la tâche et exécutez la manuellement. Pour que notre test soit considéré comme un succès, vous l’aurez compris nous devons voir apparaître notre nouveau groupe PwetGroup dans l’AD.
Vous vous en doutez, ça fonctionne ! 😎
Vous pouvez également retirer la permission Domain Admins et re tenter l’expérience pour vérifier que sans cette permission cela ne fonctionne pas bien sûr !
Voici un petit scénario qui vous évitera de créer un compte utilisateur classique qui disposerait de plein de permissions et dont vous n’effectueriez pas une rotation de mot de passe de manière régulière. Mieux encore, le mot de passe n’est pas mis en charge lors de l’exécution de la tâche planifiée. Bref, d’un point de vue sécurité c’est que du bonheur !
Un article supplémentaire – en anglais qui ajoute un complément d’informations.
Crédits image bannière – madartzgraphics
