Le Cloud de Romain LOIZEAU

Avant Windows Server 2008R2, lorsque nous voulions utiliser un compte de service pour piloter un service, ce dernier, en règle générale était un compte utilisateur du domaine auquel on affectait les paramètres suivants :

-          Interdiction d’ouvrir une session interactive (Deny Logon Locally)

-          Un Mot de passe fixe qui n’expire jamais (Password Never Expires)

-          L’utilisateur ne peut pas changer le mot de passe (User cannot changed password)


Depuis Windows Server 2008R2, un nouveau type de compte de domaine est apparu, le MSA : Managed Service Account.

Ce type de compte, hérite de certaines propriétés des classes utilisateurs et ordinateurs et permet donc plus de souplesse au niveau de la gestion des comptes de services.

Ce MSA est capable de changer son mot de passe tout seul (comme les comptes machines, dont il hérite), au bout d’un certain laps de temps, auprès du contrôleur de domaine, sans aucune intervention d’un administrateur. Il n’est même pas nécessaire de connaitre le mot de passe, ce qui enlève un niveau de complexité administrative où, auparavant, il fallait gérer tous les mots de passes de tous les comptes de services

Un exemple d'utilisation d'un serveur SQL (SQL Server 1) utilisant un MSA (Managed Service Account 1):

Ce mécanisme très pratique est en revanche, très limité, par exemple lorsque nous voulions utiliser ce même MSA pour deux services sur deux serveurs différents SQL Server 1 et SQL Server 2 .

En effet, imaginons que le mot de passe atteint sa date d'expiration et que SQL Server 1 se mette à négocier le nouveau mot de passe avec le contrôleur de domaine, et qu'ils se mettent d’accord pour utiliser le mot de passe Password1.

SQLServer2 de son côté se rend compte que le mot de passe à expiré et à son tour tente de négocier le changement de mot de passe en proposant Password2. Puisqu’il n’y a pas de mécanisme de synchronisation, le mot de passe est accepté par le contrôleur de domaine.

SQL Server 1 n’ayant jamais reçu l’information comme quoi le mot de passe a été changé de nouveau, l’authentification du MSA échoue et le service n’est plus fonctionnel.

Cette limitation pouvait se contourner et pour que nos deux serveurs SQL puissent bénéficier de la souplesse de gestion des MSA, il fallait créer un compte par service :

Bien que les mot de passes des MSA ne soient plus gérés par l'admnistrateur, il fallait cependant gérer un MSA par service... 

C'est pourquoi Windows Server 2012 introduit les Group Managed Service Account (gMSA).

Le fonctionnement des gMSA est très similaire à celui des MSA à l’exception que ceux-ci peuvent s’affecter à des groupes de sécurités Active Directory.

Ce groupe permet de définir a quels comptes d’ordinateurs le gMSA peut être attribué. Arrivé à expiration, le nouveau mot de passe sera publié à tous les membres du groupe, permettant à toutes les machines membres de se synchroniser :

Pour finir, ces comptes ont eux aussi leurs limitations car il faut que le service soit compatible avec les MSA/gMSA (ex: SQL Server 2012, IIS, etc)...

Edit: Petite précision, les gMSA ne fonctionnent que si le système hôte du service est Windows Server 2012..

Facebook Like
Anonymous
  • Merci   pour cette excellente synthese sur ces groupes et comptes managés qui ont empoisonné notre installation de system center.par  écrasement silencieux  des comptes de service locaux que nous créions par une GPO de domaine 2008R2 et pas d'utilisation des opmptes de service de niveau domaine !!)