Comment gérer les services et les tâches planifiées avec les comptes de services gérés (MSA et gMSA)
Si vous en avez assez de jongler avec les mots de passe de vos services et tâches planifiées, les comptes de service gérés (MSA) et les comptes de service gérés de groupe (gMSA) sont une solution idéale. Ils gèrent automatiquement les changements de mot de passe et, surtout, fini la gestion fastidieuse des mots de passe ! Bien sûr, ils sont principalement destinés aux environnements joints à un domaine, mais si vous utilisez Active Directory et que vous avez besoin d’exécuter des applications en toute sécurité sans vous soucier des identifiants, c’est la solution qu’il vous faut. Leur fonctionnement est un peu particulier, mais croyez-moi, une fois configurés, c’est un vrai soulagement. De plus, avec les gMSA, vous pouvez les utiliser sur plusieurs serveurs, ce qui simplifie grandement la mise à l’échelle ou le clustering d’applications. Voici un guide complet pour créer, installer et utiliser ces comptes pour les services et les tâches planifiées sur les serveurs ou PC Windows connectés à Active Directory.
- Comment créer un compte géré (MSA) dans Active Directory
- Créer un compte de service géré par groupe (gMSA) dans Active Directory
- Installer un compte de service géré sous Windows
- Comment exécuter un service Windows en tant que compte de service géré
- Exécuter une tâche planifiée Windows avec un compte de service géré (gMSA)
Tout d’abord, AD se décline en deux saveurs principales :
- MSA : Convient à une utilisation sur un seul serveur (
msDS-ManagedServiceAccount), mais ne peut pas être utilisé pour le clustering ou plusieurs serveurs. Généralement, il est destiné aux services exécutés sur une seule machine. - gMSA : Introduit dans Windows Server 2012, destiné à plusieurs serveurs, parfait pour les applications ou services en cluster nécessitant une identité commune (
msDS-GroupManagedServiceAccount).
Comment créer un compte géré (MSA) dans Active Directory
Avant de créer des comptes de service gérés (MSA), vous devez générer la clé racine KDS. Sans cela, Active Directory ne pourra pas générer de mots de passe pour vos MSA. La commande est simple, mais à exécuter une seule fois : `powershell Add-KdsRootKey –EffectiveImmediately`.Cette commande lance la création de la clé. Attention : sur la plupart des configurations, la réplication Active Directory peut prendre environ 10 heures pour synchroniser la clé. Ne vous attendez donc pas à un résultat instantané. Si vous effectuez des tests ou êtes pressé, vous pouvez l’appliquer immédiatement avec : `powershell Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))`.Pour confirmer la présence de la clé, exécutez : `powershell Get-KdsRootKey` puis vérifiez-la avec : `powershell Test-KdsRootKey -KeyId (Get-KdsRootKey).KeyId`.Une fois cette étape terminée, la création d’un compte de service géré (MSA) est simple : `powershell New-ADServiceAccount -Name msaAppService -RestrictToSingleComputer`.Il est conseillé d’associer ce MSA à un serveur spécifique afin qu’il puisse exécuter des services en toute sécurité. Pour ce faire, récupérez l’objet ordinateur dans Active Directory et ajoutez le compte de service : `powershell $identity = Get-ADComputer -Identity « Server01 » Add-ADComputerServiceAccount -Identity $identity -ServiceAccount msaAppService`.Il est conseillé de vérifier que le compte apparaît bien sous CN=Managed Service Accounts dans ADUC, mais ce conteneur est masqué par défaut (sauf si vous activez les *Fonctionnalités avancées* dans le menu Affichage d’ADUC).Personne n’apprécie les éléments cachés.
Créer un compte de service géré par groupe (gMSA) dans Active Directory
Les GMSA sont un peu plus complexes, mais extrêmement pratiques lorsque plusieurs serveurs ont besoin de la même identité. Il vous faut d’abord un groupe de sécurité Active Directory auquel vous ajouterez les serveurs qui exécuteront ce GMSA. Créez le groupe : `powershell New-ADGroup -Name grWebServers -Path « OU=Servers, DC=domain, DC=com » -GroupScope Global`.Ajoutez ensuite les serveurs : `powershell Add-ADGroupMember -Identity grWebServers -Members server01$, server02$, server03$`.Une fois cette opération terminée, créez le compte de service géré (gMSA) et spécifiez le groupe de serveurs comme principal autorisé : `powershell New-ADServiceAccount -Name gmsaWebApp -DNSHostName gmsaWebApp.domain.com -PrincipalsAllowedToRetrieveManagedPassword grWebServers -Verbose`.Si vous venez d’ajouter des serveurs au groupe, redémarrez-les ou actualisez le cache du groupe Active Directory : `cmd klist.exe -lh 0 -li 0x3e7 purge` (cela actualise le cache des tickets Kerberos).Le compte de service géré apparaît automatiquement dans l’unité d’organisation « Comptes de service gérés » et Active Directory gère la rotation des mots de passe de manière transparente. Pour les services nécessitant un enregistrement SPN Kerberos, vous devrez configurer les SPN : cmd setspn -s MSSQLSvc/mssql01 domain\gmsaWebApp$ setspn -s MSSQLSvc/mssql01.domain.com domain\gmsaWebApp$ Cette étape peut parfois poser problème, mais elle est essentielle pour SQL Server ou d’autres applications dépendant de Kerberos.
Installer un compte de service géré sous Windows
Pour utiliser des comptes de service gérés (MSA) ou des comptes de service gérés par Active Directory (gMSA) sous Windows, assurez-vous que le module Active Directory est prêt : `powershell Add-WindowsFeature RSAT-AD-PowerShell`.Ensuite, installez le compte sur votre serveur : `powershell Install-ADServiceAccount -Identity gmsaWebApp`.Pour les MSA, vous devez les installer afin que Windows les reconnaisse. Les gMSA, quant à eux, sont automatiquement disponibles une fois qu’Active Directory les reconnaît et que le serveur dispose des autorisations nécessaires. Vérifiez leur bon fonctionnement : `powershell Test-ADServiceAccount gmsaWebApp`.Si la commande renvoie `True`, tout est en ordre. Si elle renvoie `False`, le compte est peut-être mal installé ou les autorisations sont manquantes.Remarque importante : Vous ne pouvez pas exécuter des services avec des MSA via la commande `RunAs` classique ; vous devez spécifier le compte dans la configuration du service ou via PowerShell. Pour effectuer un test, vous pouvez utiliser *PsExec* : cmd PsExec64.exe -i -u domain\gmsaWebApp$ -p ~ cmd.exe. Le tilde (~) est un espace réservé qui permet à Windows de récupérer automatiquement le mot de passe depuis Active Directory (en théorie).Ensuite, exécutez la commande `whoami` dans le répertoire courant pour vérifier.
Comment exécuter un service Windows en tant que compte de service géré
Voici la procédure à suivre. Pour configurer un service afin qu’il s’exécute sous un compte MSA ou gMSA : – Ouvrez `services.msc` – Trouvez le service souhaité – Faites un clic droit, choisissez Propriétés, puis accédez à l’onglet Connexion – Sélectionnez Ce compte et saisissez le nom du compte, se terminant par `$` (par exemple, `domain\gmsaWebApp$`) – Aucun mot de passe n’est requis ; Windows accorde automatiquement les autorisations – Cliquez sur OK et redémarrez le service. Même procédure pour les pools d’applications IIS : vous pouvez définir l’identité sur un compte personnalisé. Accédez simplement à IIS, sélectionnez le pool d’applications, puis *Paramètres avancés*.Remplacez *Identité* par *Compte personnalisé*, puis saisissez `
Exécuter une tâche planifiée avec un compte de service géré (gMSA)
L’exécution de tâches planifiées en tant qu’administrateur système de gestion de la gestion (gMSA) est assez fastidieuse avec une interface graphique ; Microsoft encourage fortement l’utilisation de PowerShell pour cela. Créez une tâche via PowerShell : `powershell $action = New-ScheduledTaskAction -Execute powershell.exe -Argument « -file C:\Scripts\Backup.ps1 -executionpolicy bypass » $trigger = New-ScheduledTaskTrigger -At 23:00 -Daily $principal = New-ScheduledTaskPrincipal -UserID domain\gmsaWebApp$ -LogonType Password -RunLevel Highest Register-ScheduledTask -TaskName « DailyBackup » -Action $action -Trigger $trigger -Principal $principal` Remarque : Vous devez spécifier l’identifiant utilisateur (`-UserID`) avec le compte gMSA. Sur certaines configurations, les tâches créées via l’interface graphique n’acceptent pas gMSA, sauf si elles sont créées avec PowerShell ou schtasks.exe : `cmd schtasks /Create /TN « Backup » /TR « powershell.exe -file C:\Scripts\Backup.ps1 » /SC DAILY /ST 23:00 /RU « domain\gmsaWebApp$ »`.Pour les autorisations, vous devrez ajouter gMSA au groupe Opérateurs de sauvegarde pour les autorisations de lecture/écriture, et vous assurer de lui accorder le droit Ouvrir une session en tant que tâche planifiée dans la stratégie de groupe locale (`gpedit.msc`).L’avantage de gMSA ? Lorsque Windows actualise automatiquement le mot de passe, les tâches planifiées ne sont pas interrompues. Aucune mise à jour ni reconfiguration n’est nécessaire.
En résumé, les comptes de service gérés (et notamment les comptes de service gérés gMSA) simplifient la sécurité et réduisent les tracas. Leur configuration initiale demande un peu de travail, mais une fois en place, les services et les planifications fonctionnent sans problème, sans alerte de mot de passe. Si cela ne suffit pas, vérifiez les autorisations, les GPO, ou redémarrez simplement les services Active Directory et attendez la réplication. En espérant que cela puisse éviter bien des soucis à certains.
Résumé
- Création d’une clé racine KDS pour la génération de mots de passe gMSA.
- Configurer les comptes MSA et gMSA dans AD, liés aux ordinateurs ou aux groupes.
- Installation de MSA/gMSA sur des serveurs Windows.
- Services configurés et IIS s’exécutent sous des comptes gérés.
- Configurez des tâches planifiées avec des comptes gMSA à l’aide de PowerShell ou de schtasks.
Conclure
Configurer ces comptes gérés pour qu’ils fonctionnent correctement demande un peu de patience, mais une fois en place, la vie est bien plus simple. Fini les mots de passe qui traînent, fini les mises à jour manuelles : un service sécurisé et automatisé qui fonctionne sans problème. Si cela permet à ne serait-ce qu’un seul service de plus de fonctionner sans interruption tous les deux mois, mission accomplie. J’espère que ce sera aussi efficace pour tous les autres.