Mise en place de compte de service dans un domaine AD (GMSA).
Avant-propos
Il est parfois nécessaire d’avoir des comptes de services dans un domaine, que ce soit pour l’exécution de certains services, des tâches planifiées, etc.
Comme on ne veut pas risquer d’interrompre ces tâches, on met un compte dont le mot de passe n’expire jamais, comme ça aucun risque de panne dût à un changement. Puis comme on veut pouvoir utiliser ce compte pour tout, on ne met aucune restriction de connexion sur des postes ou plage horaire.
Il n’est pas rare de voir ces comptes de service n’être que de simple compte utilisateurs, avec des droits (parfois administrateur) sous forme svc-matache@domain.local.
Dans le meilleur des cas, l’administrateur a mesuré un risque et a mis un mot de passe conforme de justesse à la PSSI avec 12 caractères.
En conclusion, on créé un compte, potentiellement administrateur, avec un mot de passe ridicule, qui n’expire jamais et avec accès sur tous les postes. Si vous receviez une demande de création de compte de ce type-là, vous refuseriez, mais pour un compte de service, visiblement ça choque moins.
Heureusement, Microsoft permet la mise en place de compte de service administré de groupe (gmsa) depuis Windows Serveur 2012.
gMSA ? sMSA ?
gMSA apporte plusieurs avantages
– un vrai mot de passe aléatoire fort rendant le brute-force ou l’attaque par dictionnaire peu probable
– gestion automatique de ce mot de passe, avec changement automatique tous les 30 jours, sans nécessité de le fournir (que ce soit aux utilisateurs, aux programmes, etc.)
– possibilité de déploiement sur plusieurs serveurs
– gestion du SPN
gMSA apporte plusieurs contraintes:
– tout n’est pas compatible avec gMSA (SQL Server par exemple). Dans ce cas, il faudra utiliser un sMSA (qui est la même chose, mais en standalone, disponible que sur un serveur).
– gMSA est un groupe à privilèges
– gMSA a accès en lecture/écriture à des ressources critiques.
Heureusement, ces contraintes et leurs moyens d’atténuation sont documentés par Microsoft (voir la partie aide en fin de page).
Prérequis
- Une délégation sur l’OU cible
- Accès à Powershell et à l’installation du module AD
- Un Windows Server 2012 minimum (et forêt équivalente)
- Un groupe d’ordinateurs sur lequel appliquer le gMSA
L’OU existe déjà nativement
Le plus beau dans tout ça, c’est que l’OU existe nativement depuis des années, mais que peu l’utilise.
Mise en contexte
Dans le reste de l’article on partira du principe qu’il nous faut un compte de service pour une tâche planifiée de redémarrage des postes dans le groupe DS_DomainController.
Ce compte devra changer son mot de passe tous les mois.
Mise en place
Exécuter Powershell en administrateur puis saisir la commande :
Add-KdsRootKey -EffectiveImmediately
Maintenant… patientez… longtemps. Il faut attendre que les AD se synchronisent afin de pouvoir utiliser le compte qu’importe l’AD recevant la demande. Sinon, voici le message que vous aurez :
Si besoin, on peux la retrouver ici :
Il reste maintenant à créer le gMSA. Pour ce faire, toujours via le terminal Powershell :
New-ADServiceAccount -Name "svc-reboot" -Description "gMSA pour tache de reboot DS_DomainController" -DNSHostName "gmsa-svc-reboot.geekmunity.local" -ManagedPasswordIntervalInDays 30 -PrincipalsAllowedToRetrieveManagedPassword "DS_DomainController" -Enabled $True
Confirmation dans l’AD :
Le gMSA est créé, on lui a dit qui avait le droit de lire le mot de passe, il faut maintenant ajouter ce compte aux postes cibles (dans mon cas, uniquement le serveur GEEK-AD1).
Pour ce faire :
Add-ADComputerServiceAccount -Identity GEEK-AD1 -ServiceAccount svc-reboot
Si l’on se rend dans l’AD, dans les attributs du serveur on constate une nouvelle ligne :
Déploiement du compte
Le compte de service est créé, les droits de lecture du mot de passe sont mis en place, il reste maintenant à déployer ce compte sur le poste via Powershell.
Install-ADServiceAccount svc-reboot
Bien sûr, lorsque le compte ne sera plus utile il y faudra faire la commande inverse :
Uninstall-ADServiceAccount svc-reboot
Utilisation du compte
Maintenant que tout est prêt, il est temps d’utiliser le compte.
Je créer donc une tâche planifiée de test, via Powershell car la GUI ne semble pas être capable de gérer les comptes gMSA.
On remarque que pour utiliser un compte gMSA il faut ajouter :
– renseigner le nom complet (domain\account)
– un « $ » après le nom de compte
Ma tâche fait un simple reboot avec un message pour confirmer que le gMSA est fonctionnel :
Pièges
Attention, pour utiliser un compte gMSA afin d’exécuter un batch ou un service, il faut configurer la GPO :
Computer Configuration > Windows Settings > Security Settings > User Right Assigment > Log on as a service
Computer Configuration > Windows Settings > Security Settings > User Right Assigment > Log on as batch job
Aide graphique
Si vous n’êtes pas à l’aise avec le Powershell, il existe un utilitaire en interface graphique : MSA GUI (lien plus bas).
Sources :
SPN : https://docs.microsoft.com/fr-fr/windows/win32/ad/service-principal-names
gMSA : https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/service-accounts-group-managed
Kds Root Key : https://docs.microsoft.com/fr-fr/windows-server/security/group-managed-service-accounts/create-the-key-distribution-services-kds-root-key && https://docs.microsoft.com/en-us/powershell/module/kds/?view=windowsserver2019-ps
Add-ADComputerServiceAccount : https://docs.microsoft.com/en-us/powershell/module/activedirectory/add-adcomputerserviceaccount?view=windowsserver2019-ps
MSA GUI : http://cjwdev.co.uk/Software/MSAGUI/Info.html
.){kind=link}