Group Managed Service Accounts

Introduction

Windows Server 2012 est arrivé avec de nombreuses nouvelles fonctionnalités. Parmi elles, la possibilité de créer des « gMSA ». Sous Windows Server 2008R2, nous pouvions seulement créer des MSA (Managed Service account) utilisable sur une seule machine et inutilisable pour les tâches planifiées. Nous bénéficions dorénavant de plusieurs nouveautés, dont :

L’utilisation de gMSA sur plusieurs machines.
L’utilisation des gMSA pour des tâches planifiées.
L’utilisation de gMSA pour des pools d’application IIS par exemple ou d’autres application. Cependant, il faut vérifier avant cela si notre application supporte l’utilisation des gMSA.

Prérequis

Afin d’utiliser les gMSA nous devons respecter les prérequis suivants :

Un niveau de schéma AD au moins en 2012 (version 56).
Au moins un DC en 2012 ou ultérieur avec le service « Microsoft Key Distribution Service ».
Le module Powershell Active Directory.
Les clients qui vont utiliser les gMSA devront au moins disposer d’un OS Windows Server 2012/2012 R2 ou Windows 8/8.1 et les versions ultérieures.
Vous devez au minimum appartenir au groupe Admins du domaine ou Opérateurs de compte, ou avoir la capacité de créer des objets msDS-GroupManagedServiceAccount

Gestion du mot de passe

Contrairement au MSA (Manage Service Account), le mot de passe pour le gMSA et généré et maintenue par le service (KDC) sur les DC ayant pour OS une version de Windows Server 2012 ou ultérieurs. Ce qui autorise plusieurs machines à utiliser le mot de passe. Les serveurs membres qui souhaite utiliser le gMSA envoient une requête au DC pour obtenir le mot de passe. L’utilisation du mot de passe sera alors autorisé seulement pour les objets qui auront au préalable été déclaré dans l’attribut « msDS-GroupMSAMembership ».

L’intervalle de changement de mot de passe est par défaut de 30 jours. Cette valeur est modifiable. L’attribut permettant de changer l’intervalle d’actualisation de mot de passe accepte en paramètre une variable de type <int 32>.

Lorsqu’une machine va tenter de récupérer le mot de passe pour le gMSA, le contrôleur de domaine va alors vérifier si un changement de mot de passe est nécessaire en fonction de la valeur de l’attribut « msDS-ManagedPasswordInterval ». Si un changement de mot de passe est nécessaire, le DC va alors utiliser un algorithme prédéterminé pour générer un mot de passe de 120 caractères. Cet algorithme dépend du « root key ID » (pré-généré par l’administrateur) qui est partagé par l’ensemble des instances KDS (Windows Server 2012 ou ultérieurs), mais aussi le temps à l’instant <T> et enfin le S.I.D du gMSA. N’importe quel serveur KDS (Windows 2012 ou ultérieurs) peut dont générer un mot de passe. Toutes les instances KDS utilisent le même algorithme et peuvent donc générer le même mot de passe.

Démonstration

Pour la création du gMSA il y a globalement 4 étapes :

Vérification des prérequis.
Créer la clé racine pour le KDS (Une par forêt).
Créer et configurer le gMSA.
Configurer le gMSA sur les machines.

Nous allons d’abord commencer par vérifier la version de notre schéma AD :

L’attribut objectVersion est à 69 (2012R2).

En explorant notre schéma AD nous pouvons voir que nous disposons de la classe « msDS-GroupManagedServiceAccount » qui hérite des classes :

Les nouveaux attributs qui apparaissent avec la classe « msDS-GroupManagedServiceAccount » sont :

msDS-GroupMSAMembership – attribut permettant d’identifier (groupe ou machine) qui pourra obtenir le mot de passe et utiliser le gMSA.
msDS-ManagedPassword – attribut contenant le mot de passe courant, l’ancien mot de passe mais aussi l’intervalle de changement de mot de passe.
msDS-ManagedPasswordInterval – attribut configuré au moment de la creation du compte (ne peut pas être change par la suite !), qui va permettre de déterminé au bout de combien de jours le mot de passe doit être changé.
msDS-ManagedPasswordID – ID utilisé par le service (KDS) pour générer le mot de passe courant.
msDS-ManagedPasswordPreviousID – ID pour l’ancien mot de passe.

Nous allons maintenant créer la clé racine. Pour cela, nous allons nous connecter sur un contrôleur de domaine (2012 ou ultérieur) disposant du module powershell AD et entrer la commande suivante en tant qu’administrateur :

Une fois la commande validée, il faut attendre au moins 10 heures pour pouvoir utiliser la clé. En effet, c’est une mesure de sécurité pour s’assurer que l’ensemble des contrôleurs de domaine ont bien répliqués l’information.

Cependant, dans un environnement de lab uniquement il est possible d’utiliser la clé KDS immédiatement grâce à la commande :

Nous pouvons vérifier la génération de la clé :

Il nous faut maintenant créer le gMSA. Mais avant cela, nous allons un créer un groupe de sécurité de type Global qui contiendra l’ensemble des machines qui seront autorisés à utiliser le gMSA :

Nous pouvons maintenant créer notre gMSA en Powershell grâce à la commande :

Si à ce niveau vous rencontrez une erreur de type « key not exist » ou « la clé n’existe pas » c’est que vous n’avez pas forcément attendue le temps nécessaire lors de la création de la clé racine KDS.

Pour pouvoir utiliser le gMSA précédemment crée, il va nous falloir le configurer sur les machines qui doivent l’utiliser. Pour cela, nous devons utiliser les commandes :

Si vous rencontrez des erreurs. Vous pouvez vérifier que votre serveur est bien membre du groupe que vous avez ajouté pour le gMSA. Si c’est le cas il faut redémarrer votre serveur afin de prendre en compte l’appartenance au groupe.

Nous allons maintenant utiliser le gMSA dans une tâche planifiée. Pour notre exemple, nous prendrons un simple script permettant de récupérer la liste de l’ensemble des distinguishedName pour les comptes utilisateurs AD.

Nous allons configurer une tâche planifiée en utilisant le gMSA précédemment créer pour lancer le script de manière quotidienne. Malheureusement, pour pouvoir utiliser le gMSA nous devons créer la tâche planifiée en Powershell. En effet, cela n’est pas encore possible via la console « taskschd.msc »

Il est important de rappeler de spécifier la chaîne de caractère « Password » dans le script pour l’utilisation du gMSA. En effet, ne disposant pas de mot de passe cela permet d’indiquer à la tâche planifiée qu’elle doit récupérer le mot de passe auprès d’un contrôleur de domaine.