Tutos, news et aides informatiques

Publié le par Publié dans WINDOWS

Description : Les comptes de services sont des comptes d’utilisateurs spécifiquement créés et utilisés pour faire fonctionner des services Windows, une application, un script, ou autres au lieu d’utiliser un compte nominatif d’un utilisateur existant. Hors, ces comptes peuvent parfois poser des soucis de sécurité, car ils sont généralement configurés avec un mot de passe qui n’expire jamais. Si le mot de passe d’un compte de service vient à être compromis, cela peut générer de gros incidents de sécurité, surtout si le compte de service possède des privilèges élevés au sein du domaine Active Directory. Même si le compte de service ne possède que des droits d’administration locaux sur un serveur, vous n’êtes pas à l’abris que le compte piraté puisse servir à faire des attaques par mouvements horizontaux en volant les crédentials d’un autre compte d’administration qui se serait connecté à ce serveur.

Pour limiter l’usage de comptes de services avec des mots de passe éternels, Microsoft a introduit la notion de comptes de service gérés et autonomes, afin qu’un mécanisme puisse réaliser une rotation des mots de passe à intervalle régulier en toute autonomie. Les comptes de service managés autonomes (sMSA – Standalone Managed Service Account), ont vu le jour avec Windows Server 2008 R2 et Windows 7. Ces comptes de service managés (sMSA), ne peuvent être utilisés que pour une seule machine dans le domaine, car c’est la machine qui gérait la rotation du mot de passe du compte de service sMSA.

A partir de Windows Server 2012, Microsoft a introduit les comptes de services managés de groupe (gMSA – Group Managed Service Account). Ces comptes de services autonomes, fonctionnent comme les comptes de services sMSA, mais ont la particularité de pouvoir être utilisés sur plusieurs machines du domaine AD… Ce qui rend plus pratique l’usage d’un même compte de service managé de groupe (gMSA) sur plusieurs machines d’un même cluster. Pour fonctionner sur plusieurs machines, c’est l’Active Directory qui prend désormais en charge la rotation des mots de passes des comptes gMSA.


Cette procédure explique comment créer des comptes de services managés de groupe (gMSA) au sein d’un domaine Active Directory.

Pour que les mots de passe puisse être gérés par rotation automatique, Microsoft a introduit le service KDS (Key Distribution Service) sur les contrôleurs de domaine. Le service de distribution des clés utilise la dll « kdssvc.dll » afin de générer des clés à intervalle régulier. Le contrôleur de domaine gère la rotation des mots de passe et les hôtes sur lesquels on a configuré des comptes de service gMSA pourront alors contacter les contrôleurs de domaine pour récupérer la valeur des nouveaux mots de passe.

Attention : Les comptes de service managés de groupe (gMSA) ne sont pas compatibles pour faire fonctionner des clusters de basculement Microsoft (Failover Clustering). Ils peuvent être utilisés que sur des services applicatifs (Exemple IIS), scripts ou autres que ceux dédiés à faire tourner le cluster Windows.

Prérequis :

  • Architecture x64
  • OS du contrôleur de domaine hébergeant le compte gMSA : Windows Server 2012 minimum (Version de schéma 52 minimum)
  • Module PowerShell pour Active Directory
  • Authentification Kerberos avec AES
  • Client Kerberos conforme aux RFC
  • Une clé racine pour le domaine AD doit être créée
  • Avoir un compte Admin du domaine ou Enterprise Admin pour créer des objet de type « msDS-GroupManagedServiceAcount » ou être membre du groupe « Opérateur de compte ».

Les gMSA ne peuvent pas être créés via l’interface graphique des consoles d’administration Active Directory. Il faut les créer via PowerShell ou un outils tiers avec GUI. La nouvelle commande Powershell « New-ADServiceAccount » peut prendre en charge plusieurs paramètres pour la création de gMSA :

NB : Sur un point de vue purement technique, un compte de service gMSA est considéré comme un compte d’ordinateur. Ce qui veut dire que le SamAccountName du compte gMSA aura un « $ » à la fin, comme un compte d’ordinateur.
Exemple deSamAccountName d’un compte gMSA : « svctestgmsa$ ».

Autre différence avec un compte d’utilisateur classique ?

– Valeur de l’attribut « PrimaryGroupID » gMSA : 515 (GROUP_RID_COMPUTER)
– Valeur de l’attribut « PrimaryGroupID » compte user : 513 (GROUP_RID_USERS)

– Valeur de l’attribut « SamAccountType » gMSA : (MACHINE_ACCOUNT)
– Valeur de l’attribut « SamAccountType » compteuser : (NORMAL_USER_ACCOUNT)

Il faudra donc respecter une longueur de nom de compte inférieur ou égale à 15 caractères à l’identique d’un nom Netbios d’une compte d’ordinateur.

Clé racine pour le service KDS

Pour générer des clés ou mot de passe gMSA, le service de distribution de clés (KDS, Key Distribution Service) a besoin d’avoir une clé racine stockée dans l’Active Directory. Cette clé sera ensuite répliquée sur l’ensemble des contrôleurs de domaine. Lorsqu’on créé une nouvelle clé racine pour KDS, la clé est par défaut utilisable que 10h après sa création. Ce mécanisme permet de laisser le temps a tous les contrôleurs de domaine de répliquer la clé.

NB : Si vous devez supprimer et recréer la clé racine, il faudra alors redémarrer tous les contrôleurs de domaine, afin de rafraichir le contenu de la clé mis en cache sur chaque DC.

Les clés racines KDS sont stockées dans l’AD à l’emplacement suivant :

« CN=Master Root Keys,CN=Service de distribution de clés de groupe,CN=Services,CN=Configuration,DC=<forest name> »

Pour voir la clé racine KDS via une interface graphique, il suffit de réaliser les actions suivantes :

  • Lancez la console « Active Directory Sites et Services » (%SystemRoot%\system32\dssite.msc)
  • Sélectionnez la racine de la console, cliquez sur le menu « View » / « Affichage » et cochez la case « Show services node » / « Affichez le nœud des services »
  • Développez l’arborescence de la console « Services\Group Key Distribution Sevice\Master Root Keys » et la clé créée apparaitra à droite :
  • La clé racine possède un type d’objet « msKds-ProvRootKey« .
  • Dans la clé racine Kds, l’attribut « msKds-DomainID » contient en valeur, l’identité du contrôleur de domaine qui a créé la clé racine (Le nom netbios du contrôleur de domaine). Si ce contrôleur de domaine est rétrogradé, on peut modifier la valeur de cet attribut et indiquer un autre contrôleur de domaine.

Créez une clé racine KDS

Pour créer une clé racine KDS dans votre domaine AD, suivez les étapes suivantes :

  • A partir d’un contrôleur de domaine en Windows serveur 2012 minimum, lancez une invite de commande PowerShell ou le client PowerShell_ISE en tant qu’administrateur.
  • Tapez la commande PowerShell suivante pour créer la clé KDS :
    • Add-KdsRootKey -Effective Immédiatement
  • La clé racine KDS sera opérationnelle après 10h (Mécanisme par défaut).

Si vous êtes sur votre infra de test avec qu’un seul contrôleur de domaine et que vous souhaitez que votre clé racine KDS soit opérationnelle tout de suite, sans avoir à attendre 10h, il faudra plutôt suivre cette procédure :

  • Tapez la commande PowerShell suivante pour créer une clé KDS active de suite :
    • Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10))

Pour vérifier si la clé racine a bien été créé, vous pouvez taper la commande suivante :

  • Afficher la clé Kds racine :
    • Get-KdsRootKey
  • Tester la clé Kds racine (La valeur « True » doit être retournée si la clée Kds est valide) :
    • Test-KdsRootKey -KeyId (Get-KdsRootKey).KeyId

Créez un gMSA

Avant de créer un compte gMSA, je vous recommande de créer un groupe de sécurité dédié à cet usage afin de regrouper l’ensemble des machines autorisées à utiliser ce gMSA.

  • A partir d’un contrôleur de domaine en Windows serveur 2012 minimum sur votre domaine Active Directory, lancez une invite de commande PowerShell ou le client PowerShell_ISE en tant qu’administrateur.
  • Si le compte gMSA ne nécessite pas de délégation Kerberos, vous pouvez le créer avec la ligne de command PowerShell suivante :
### Exemple de création d'un compte de service gMSA :
### Chiffrement Kerberos utilisant AES256 et rotation du mot de passe tous les 30 jours 
### Seul les ordinateurs membres du groupe de sécurité GL-SRV-TEST seront autorisé à lire le mot de passe

New-ADServiceAccount -Name "SVCTestgMSA" `
                     -Description "Compte de test gMSA pour le site infonovice.fr" `
                     -DNSHostName "SVCTestgMSA.infonovice.priv" `
                     -KerberosEncryptionType AES256 `
                     -ManagedPasswordIntervalInDays 30 `
                     -PrincipalsAllowedToRetrieveManagedPassword "GL-SRV-TEST" `
                     -Enabled $True
  • Si le compte gMSA nécessite d’être créé avec une délégation Kerberos contrainte, vous pouvez le créer avec la ligne de commande PowerShell suivante :
### Exemple de création d'un compte de service gMSA pour un cluster SQL avec délégation Kerberos : 
### Chiffrement Kerberos utilisant AES256 et rotation du mot de passe tous les 30 jours 
### Seul les ordinateurs membres du groupe de sécurité GL-SRV-SQL-TEST seront autorisés à lire le mot de passe

New-ADServiceAccount -Name "SVCSQLGMSA" `
                     -Description "Compte de test gMSA pour le site infonovice.fr - Cluster SQL" `
                     -DNSHostName "SVCSQLGMSA.infonovice.priv" `
                     -KerberosEncryptionType AES256 `
                     -ManagedPasswordIntervalInDays 30 `
                     -PrincipalsAllowedToRetrieveManagedPassword "GL-SRV-SQL-TEST" `
                     -Enabled $True

### Donner la permission au compte de service d'enregistrer lui-même ses SPNs :

dsacls "CN=SVCSQLGMSA,CN=Managed Service Accounts,DC=infonovice,DC=priv" /G "\SELF:RPWP;servicePrincipalName"

### Configurer la délégation Kerberos contrainte :

Set-ADAccountControl -Identity SVCSQLGMSA$ -TrustedForDelegation $false -TrustedToAuthForDelegation $false

Set-ADServiceAccount -Identity SVCSQLGMSA$ -Add @{'msDS-AllowedToDelegateTo'='MSSQLSvc/srvsqla.infonovice.priv:SQL_01','MSSQLSvc/srvsqla.infonovice.priv:1433','MSSQLSvc/srvsqlb.infonovice.priv:1433','MSSQLSvc/srvsqlb.infonovice.priv:SQL_01','MSSQLSvc/vipsql.infonovice.priv:SQL_01','MSSQLSvc/vipsql.infoovice.priv:1433'}

Installez un compte gMSA sur un serveur

Avant d’installer un compte gMSA sur un serveur, il faut s’assurer que le module PowerShell pour AD est présent.
Vous pouvez l’installer via une invite de commande PowerShell, exécutée en tant qu’administrateur :

Add-WinowsFeature RSAT-AD-PowerShell

Une fois ce prérequis réalisé, vous devez vous assurer que la machine sur laquelle vous souhaitez configurer le compte de service gMSA est bien membre du groupe AD que vous avez créé pour ce tutorial, ou si ce n’est pas le cas, assurez-vous que le compte d’ordinateur de votre machine figure bien dans l’attribut « PrincipalsAllowedToRetrievedManagedPassword » du compte de service, sinon le compte d’ordinateur ne pourra pas avoir accès au mot de passe du compet gMSA.

Si tous les pré requis sont respectez, vous pourrez ensuite installer le compte de service sur votre serveur avec la commande PowerShell suivante executé en tant qu’administrateur :

Install-ADServiceAccount -Identity "SVCSQLGMSA"

Pour vérifier que le compte de service est bien actif sur votre serveur, vous pouvez taper ligne de commande PowerShell suivante en tant qu’administrateur :

Test-ADServiceAccount "SVCSQLGMSA"

Pour vérifier la date de dernier changement du mot de passe, il suffira de taper la commande suivante :

Get-ADServiceAccount "SVCSQLGMSA" -Property PasswordLastSet

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.