{"id":10382,"date":"2023-11-30T10:56:30","date_gmt":"2023-11-30T09:56:30","guid":{"rendered":"https:\/\/blog.capdata.fr\/?p=10382"},"modified":"2023-12-13T10:53:06","modified_gmt":"2023-12-13T09:53:06","slug":"les-managed-service-account-msa-et-gmsa-se-simplifier-la-vie-pour-gerer-ses-comptes-de-service-sql-server","status":"publish","type":"post","link":"https:\/\/blog.capdata.fr\/index.php\/les-managed-service-account-msa-et-gmsa-se-simplifier-la-vie-pour-gerer-ses-comptes-de-service-sql-server\/","title":{"rendered":"Les Managed Service Account (MSA et gMSA) : se simplifier la vie pour g\u00e9rer ses comptes de service SQL Server"},"content":{"rendered":"\"twitter\"<\/a>\"linkedin\"<\/a>\"mail\"<\/a>

Pour faire tourner son service SQL Server sous Windows, il y a diff\u00e9rentes \u00e9coles. Certains veulent un compte de service cr\u00e9\u00e9 dans l’Active Directory, afin d’y appliquer des GPO et bien les identifier avec un nom explicite. D’autres pr\u00e9f\u00e8rent garder les choses simples et laissent les Virtual Service Account (NT Service\\MSSQLSERVER<\/em>).<\/p>\n

Le probl\u00e8me avec le passage sur un compte de service d\u00e9di\u00e9 est le risque de mauvaise administration et de s’en servir pour ouvrir une session interactive, combin\u00e9 avec l’\u00e9ventualit\u00e9 que le mot de passe soit r\u00e9cup\u00e9r\u00e9 par un utilisateur malicieux. On peut donc mettre en place une strat\u00e9gie d’expiration de mot de passe, mais alors la rotation des mots de passe dans le parc peut vite devenir infernale !<\/p>\n

C’est l\u00e0 qu’intervient une solution assez m\u00e9connue : les Managed Service Account. L’une des principales raisons pour laquelle cette solution est m\u00e9connue est qu’elle n\u00e9cessite que le niveau fonctionnel de la for\u00eat Active Directory soit au minimum au niveau fonctionnel de Windows 2012.<\/a><\/p>\n

Maintenant que nous sommes en 2023, on peut supposer que la plupart des infrastructures Active Directory sont dans des niveaux sup\u00e9rieurs.<\/p>\n

Les MSA \u00e9taient le premier nom donn\u00e9 \u00e0 ce type de compte, et ne fonctionnait que pour les service qui tournaient sur une seule machine. Peu de temps apr\u00e8s a \u00e9t\u00e9 ajout\u00e9 la possibilit\u00e9 de fonctionner sur un cluster avec la notion de Group Managed Service Account. Mais les commandes restent les m\u00eames.<\/p>\n

Pr\u00e9-requis \u00e0 l’utilisation d’un Managed Service Account pour SQL Server (MSA\/gMSA) :<\/h2>\n

Comme indiqu\u00e9, le premier pr\u00e9-requis est au niveau de l’Active Directory qui doit \u00eatre au niveau fonctionnel 2012 ou sup\u00e9rieur.<\/p>\n

Pour SQL Server, si c’est pour travailler avec une instance “standalone” , il faudra un SQL Server 2014. Pour de l’AlwaysOn et du Failover Cluster Instance (FCI), cela n\u00e9cessitant la couche cluster, et donc un gMSA, il faudra un SQL Server 2016.<\/p>\n

Pour cr\u00e9er un (g)MSA, il faudra soit \u00eatre administrateur du domaine ou bien disposer du privil\u00e8ge de cr\u00e9ation des objets de type “msDS-GroupManagedServiceAccount”.<\/p>\n

Un acc\u00e8s PowerShell avec l’extension Active Directory (disponible par exemple en installant le feature Windows “Remote Management”) doit \u00eatre pr\u00e9sent sur les machines SQL Server.<\/p>\n

Afin de faire fonctionnaire les MSA, ils est \u00e9galement n\u00e9cessaire qu’une infrastructure KDS soit pr\u00e9sente sur le domaine. Si vous ne savez pas si vous en avez une, vous pouvez interrogez votre domaine avec la commande PowerShell Get-KDSRootKey :<\/p>\n

\"\"<\/p>\n

On voit ici qu’une cl\u00e9 a \u00e9t\u00e9 cr\u00e9\u00e9e le 29\/11\/2023.<\/p>\n

Si jamais vous n’en avez pas, il faut la cr\u00e9er avec la commande :<\/p>\n

\r\nAdd-KdsRootKey -EffectiveImmediately\r\n<\/pre>\n
Bien que le param\u00e8tre EffectiveImmediately<\/em> permette son usage imm\u00e9diatement, j’ai rencontr\u00e9 des d\u00e9lais avant que mes machines SQL Server puissent utiliser les MSA, il se peut donc qu’il faille attendre \u00e9galement chez vous. Par ailleurs, si vous avez plusieurs contr\u00f4leurs de domaine, le temps de r\u00e9plication peut atteindre 10 heures.<\/p>\n
Cr\u00e9ation d’un gMSA pour SQL Server :<\/h2>\n
Notre but ici est de cr\u00e9er un compte de service manag\u00e9 pour un SQL Server 2022 avec un groupe de disponibilit\u00e9. Nous sommes dans le sc\u00e9nario le plus compliqu\u00e9, o\u00f9 SQL Server a d\u00e9j\u00e0 \u00e9t\u00e9 install\u00e9 et le groupe de disponibilit\u00e9 est d\u00e9j\u00e0 pr\u00e9sent.<\/p>\n
Notre configuration est telle que nous avons deux serveurs LAB1SQL1 et LAB1SQL2 avec un listener pour le groupe de disponibilit\u00e9 LAB1_LSTN. Nous voulons un compte de service commun pour nos deux serveurs SQL que l’on appellera LAB1_gMSA. Nous voulons \u00e9galement que les SPN soient enregistr\u00e9s correctement sans intervention suppl\u00e9mentaire.<\/p>\n
Cr\u00e9ation d’un groupe AD pour les machines autoris\u00e9es \u00e0 utiliser le gMSA :<\/h2>\n
Dans la console Active Directory Users and Computers, on va cr\u00e9er un groupe de s\u00e9curit\u00e9 et y ajouter les deux comptes ordinateurs de notre groupe de disponibilit\u00e9 :<\/p>\n
\"\"\"\"<\/p>\n
Cr\u00e9ation du gMSA :<\/h2>\n
La cr\u00e9ation du gMSA se fait avec la commande PowerShell “New-ADServiceAccount”. Elle n’est pas possible par l’interface graphique “Active Directory Users and Computers”.<\/p>\n
 \r\nNew-ADServiceAccount -Name LAB1_gMSA -DNSHostName LAB1SQL1.LAB1.local -ManagedPasswordIntervalInDays 90 -PrincipalsAllowedToRetrieveManagedPassword LAB1_SQL_Group -ServicePrincipalNames MSSQLSvc\/LAB1SQL1.lab1.local, MSSQLSvc\/LAB1SQL1.lab1.local:1433, MSSQLSvc\/LAB1_LSTN.lab1.local, MSSQLSvc\/LAB1_LSTN.lab1.local:1434 -Enabled $true\r\n<\/pre>\n
On aura donc un groupe de disponibilit\u00e9 avec les param\u00e8tres suivants:<\/p>\n