Choisir le compte d'un service Windows ── LocalSystem, comptes virtuels et gMSA

« Un service qui tourne sous LocalSystem a été signalé à l’audit comme ayant des privilèges excessifs. Vers quoi le changer ? » « Nous utilisons un utilisateur de domaine pour que le service se connecte à un dossier partagé, mais le service s’arrête quand le mot de passe expire. » ── Ces deux cas sont les consultations typiques qui surviennent lorsque le compte d’exécution d’un service n’est pas une décision de conception, mais est figé comme « le paramètre qui a fini par marcher ».

Quand on choisit le compte d’exécution, on sépare ce que le service peut faire dans le PC, qui il est du point de vue de la destination, et qui gère le mot de passe. Renforcer les privilèges locaux et pouvoir s’authentifier pour se connecter à un dossier partagé ne sont pas la même chose.¹²

La conclusion de cet article est de faire d’un compte virtuel le premier candidat pour un service métier qui reste dans une seule machine, et d’un gMSA le premier candidat lorsqu’une identité propre au service est nécessaire dans le domaine. On part d’une configuration où « le service ne détient pas un mot de passe humain », et on traite l’utilisateur de domaine comme un dernier recours. Cela dit, on ne change pas tous les services existants tout de suite ; on vérifie les privilèges nécessaires et l’impact de la migration.³⁴

Cet article s’adresse aux responsables informatiques des PME et aux développeurs d’applications Windows. L’explication, fondée sur Microsoft Learn d’août 2026 au moment de l’article d’origine, est organisée dans l’ordre choix → privilèges locaux → identité réseau → déploiement d’un gMSA → bascule et audit. Pour la construction du service lui-même, voir « Comment créer et exploiter un service Windows ».

1. D’abord choisir : six comptes et quatre questions

1.1 Les axes de comparaison sont les privilèges, l’identité et la gestion du mot de passe

Au démarrage d’un service, le Gestionnaire de contrôle des services (SCM) ouvre une session avec le compte configuré. En cas de succès, il attribue un jeton d’accès au processus du service, et ensuite chaque accès aux fichiers et aux tubes se décide en rapprochant ce jeton de la liste de contrôle d’accès (ACL). Choisir le compte d’exécution, c’est décider le contenu du jeton remis au service.¹

L’authentification réseau par PC$ dans le tableau suppose un environnement de domaine. La même méthode n’est pas disponible dans un groupe de travail. LocalSystem a aussi des limites, comme les zones protégées par WRP. Ne prenez pas « quasi illimités » au pied de la lettre comme « sans aucune limite ».⁵⁶²⁷

Avec LocalSystem, LocalService, NetworkService et les comptes virtuels, l’utilisateur n’a pas à définir ni à gérer un mot de passe pour le service. En revanche, dans une configuration qui utilise un utilisateur de domaine ou un utilisateur local, une personne gère l’expiration et les changements du mot de passe stocké dans le SCM. Un gMSA a bien un mot de passe, mais sa gestion est déléguée à AD.¹⁸

1.2 Avancer le choix avec quatre questions

On confirme d’abord si le service se connecte à d’autres machines avec l’authentification Windows, et si oui, on décide dans l’ordre si la machine est jointe au domaine, si une identité par machine suffit, et si l’application prend en charge gMSA.

flowchart TB
    accTitle: Flux de décision du compte d'exécution
    accDescr: Décider le compte d'exécution en répondant dans l'ordre à quatre questions, présence d'accès réseau, adhésion au domaine, suffisance d'une identité par machine, et prise en charge de gMSA
    q1{"Connexion à d'autres machines avec l'authentification Windows ?"} -->|Non| va["Compte virtuel"]
    va -.-> sys["LocalSystem si des privilèges sont requis"]
    q1 -->|Oui| q2{"Jointe au domaine ?"}
    q2 -->|Non| cred["Protéger et stocker les informations d'identification"]
    q2 -->|Oui| q3{"Identité par machine suffisante ?"}
    q3 -->|Oui| pcacl["Compte virtuel + autorisation PC$"]
    q3 -->|Non| q4{"L'application prend-elle en charge gMSA ?"}
    q4 -->|Oui| gmsa["gMSA"]
    q4 -->|Non| du["Utilisateur dédié + mesures d'atténuation"]

Figure 1 : Si tout reste local, un compte virtuel. Dans le domaine, quand PC$ n’est pas assez fin, on passe à un gMSA. Dans un groupe de travail, on conçoit les informations d’identification à part.

Il n’est pas nécessaire de remplacer sans raison tous les traitements locaux existants sous LocalService, ni tous les accès par machine sous NetworkService. Pour un choix nouveau, on prend pour base le compte virtuel, qui combine faible privilège et isolement par service.

Dans le diagramme, un trait continu marque une relation qui vaut toujours et un trait pointillé une relation conditionnelle (les conditions figurent dans l’explication de chaque relation sur la page de détail). La liste complète des relations (19 au total, avec preuve et niveau de certitude) et les définitions des concepts principaux sont rassemblées sur la page de détail de la carte des connaissances (en japonais). Données : JSON-LD / Turtle

2. Décider les privilèges dans le PC : partir du compte virtuel

2.1 LocalService et NetworkService diffèrent par l’identité réseau

LocalService et NetworkService sont des comptes intégrés pour les services à faible privilège. En local, les deux tournent avec, grosso modo, les privilèges minimaux d’un membre du groupe Users. Ce qui change, ce sont les informations d’identification présentées au distant.⁶³

Le partage est : LocalService si le service ne sort pas sur le réseau ou n’est jamais interrogé sur son identité, et NetworkService s’il a besoin de l’identité de la machine dans le domaine.

Il faut toutefois noter que, dans les deux cas, plusieurs services partagent le même compte. Tant que les ACL sont octroyées à ce compte partagé, on ne peut pas distinguer les services. Si cinq services tournent sous LocalService, les cinq peuvent atteindre toute ressource autorisée à ce compte. La raison pour laquelle SQL Server ne prend pas en charge Local Service est la même : un compte partagé ne peut pas être isolé des autres services.³

2.2 Avec un compte virtuel, on peut octroyer des ACL par service

Un compte virtuel est un compte local géré, disponible à partir de Windows Server 2008 R2 / Windows 7. Son nom est NT SERVICE\<nom du service>. Il n’y a ni création de compte ni définition de mot de passe, et chaque service a une identité propre. Pour l’accès réseau dans un environnement de domaine, il utilise les informations d’identification du compte ordinateur.²

On conserve l’avantage « pas de gestion de mot de passe » de LocalService et NetworkService, tout en supprimant le point faible du partage de compte. Le fait que l’installation de SQL Server utilise par défaut NT SERVICE\MSSQLSERVER et assimilés suit le même raisonnement.³

L’avantage pratique est que l’on peut indiquer ce service directement dans une ACL. Sans ajouter de création de groupe ni de gestion de mot de passe, on peut configurer « octroyer le droit de modification sur ce dossier de données à ce service ».

L’exemple suivant bascule un MyAppService existant vers un compte virtuel. Avant de l’exécuter, vérifiez le droit d’ouverture de session, le placement des données et DPAPI du chapitre 7, et confirmez le démarrage et les fonctions principales dans un environnement de test.

# Changer le compte d'ouverture de session du service vers un compte virtuel
# La valeur de obj= est « NT SERVICE\nom-du-service ». Ne pas spécifier de mot de passe
sc.exe config MyAppService obj= "NT SERVICE\MyAppService"

# Vérifier la configuration (contrôler SERVICE_START_NAME)
sc.exe qc MyAppService

# Octroyer le droit de modification sur le dossier de données à ce service seulement
icacls "C:\ProgramData\MyApp" /grant "NT SERVICE\MyAppService:(OI)(CI)M"

Dans l’interface graphique, ouvrez les propriétés du service dans services.msc, onglet « Ouvrir une session », mettez le nom de compte à NT SERVICE\nom-du-service, et laissez les champs mot de passe vides. On ne spécifie pas de mot de passe pour un compte virtuel ou un MSA. Le changement prend effet au redémarrage du service.³

Avoir une identité propre en local ne garantit pas que l’on puisse distinguer les services de l’autre côté du réseau. Cette limite est expliquée au chapitre 3.

2.3 Juger LocalSystem d’après les privilèges nécessaires, pas d’après « ça marche »

LocalSystem (NT AUTHORITY\SYSTEM, nom affiché Système local) est un compte prédéfini utilisé par le SCM. Le jeton contient les SID NT AUTHORITY\SYSTEM et BUILTIN\Administrators, et il détient des privilèges locaux étendus. Des privilèges forts comme SeDebugPrivilege et SeTcbPrivilege sont aussi activés par défaut.⁵

Cette force est aussi l’ampleur des dégâts en cas de compromission. Si un service LocalSystem a une vulnérabilité d’exécution de code arbitraire, il peut devenir le point de départ de la lecture et de l’altération des fichiers de tous les utilisateurs, de la lecture de la mémoire d’autres processus, du vol d’informations d’identification et d’un mouvement latéral. Sur NTFS, SYSTEM a le contrôle total par défaut.⁶ Le lien entre vol d’informations d’identification et mouvement latéral est aussi traité dans « NTLM et Kerberos expliqués en images » et « Guide pratique de Windows LAPS ».

LocalSystem continue pourtant d’être choisi parce que c’est la valeur par défaut quand on omet obj= dans sc.exe create, et parce qu’il reste dans beaucoup d’anciens exemples et modèles d’installateur. Les erreurs d’autorisation apparaissent rarement pendant le développement, donc le réflexe est de le laisser tel quel « parce que ça a marché ». Microsoft explique toutefois que la plupart des services n’ont pas besoin de ce niveau de privilège, et qu’il faut envisager LocalService ou NetworkService quand ce n’est pas nécessaire.⁹⁵

Même LocalSystem ne peut pas tout modifier sans condition. Depuis Windows Vista, la Protection des ressources Windows (WRP) restreint la modification des fichiers, dossiers et clés de registre importants du système à TrustedInstaller (le service Programme d’installation des modules Windows). Même SYSTEM et les administrateurs reçoivent un accès refusé sur une écriture ordinaire. Le message « Vous avez besoin d’une autorisation de TrustedInstaller » vient de ce mécanisme.⁷

Cette restriction n’enlève rien au fait que LocalSystem reste un privilège excessif pour un service métier. Les exceptions légitimes sont les traitements dont les privilèges exigés dépassent déjà le niveau administrateur : intégration étroite avec des pilotes de périphérique, manipulation des fondations de sécurité de l’OS, gestion d’autres services et sessions, etc. Pour un agent de sauvegarde, un EDR et assimilés, c’est cette nécessité qui est en question.

Même dans un cas d’exception, on vérifie s’il existe vraiment un chemin de code qui utilise le privilège, et si l’on peut isoler seulement cette partie. Pour la façon de le discerner, voir « Quand Windows exige-t-il réellement des privilèges administrateur ».

3. Décider l’identité vue par la destination : PC$ suffit-il ?

3.1 Si l’on veut seulement se connecter à un dossier partagé, un utilisateur de domaine est souvent inutile

Sur une machine jointe au domaine, un service qui utilise LocalSystem, NetworkService ou un compte virtuel s’authentifie auprès du distant comme DOMAIN\nom-ordinateur$. Parfois, la seule raison pour laquelle un service ne peut pas accéder à un dossier partagé est que ce PC$ n’est pas autorisé dans l’ACL de la destination.⁵²

Ce qu’il faut ici n’est pas renforcer les privilèges locaux du service, mais autoriser la bonne identité sur la destination. Pour un dossier partagé, on configure à la fois les autorisations de partage et les autorisations NTFS.

L’exemple suivant, exécuté côté serveur de fichiers, donne le droit de modification au service sur APPSV01. Quand on choisit le compte dans l’interface graphique, on inclut « Ordinateurs » dans les types d’objets.

# Côté serveur de fichiers : donner au service sur APPSV01 le droit de
# modification sur le dossier partagé. Il faut l'octroyer à la fois
# aux autorisations de partage et aux autorisations NTFS
Grant-SmbShareAccess -Name "AppData" -AccountName "CORP\APPSV01$" -AccessRight Change -Force
icacls "D:\Shares\AppData" /grant "CORP\APPSV01$:(OI)(CI)M"

Pour SQL Server, l’idée d’enregistrer le compte ordinateur comme une ouverture de session Windows est la même. On utilise Integrated Security=true dans la chaîne de connexion, et le service se connecte sans détenir le mot de passe d’un utilisateur de domaine.

-- Côté serveur de base : autoriser l'authentification Windows intégrée
-- depuis le service sur APPSV01
CREATE LOGIN [CORP\APPSV01$] FROM WINDOWS;

Ceci est la partie où l’on crée l’ouverture de session Windows côté serveur de base. Le principe d’octroyer les autorisations nécessaires sur la destination ne change pas par rapport au dossier partagé.

3.2 PC$ ne permet pas d’autoriser ni d’auditer par service

L’identité d’un compte virtuel est locale à la machine et n’est pas reconnue par le domaine. Une fois sur le réseau, elle se ramène à PC$, donc on ne peut pas distinguer, par le seul compte, de quel service de la même machine vient la requête.¹⁰⁴

flowchart TB
    accTitle: L'identité d'un compte virtuel se ramène hors de la machine
    accDescr: Les comptes virtuels propres à chaque service dans la machine se ramènent au compte ordinateur sur le réseau, donc le distant ne peut pas dire de quel service il s'agit
    vaa["Compte virtuel A"] --> pc["Compte ordinateur PC$"]
    vab["Compte virtuel B"] --> pc
    pc --> remote["Identité vue par le distant"]
    remote -.-> nodist["On ne peut pas dire de quel service"]

Figure 2 : Même si les services sont isolés dans le PC, la destination voit le même PC$. L’isolement local et l’isolement réseau sont des décisions distinctes.

Cette approche a deux limites.

Partager la même identité entre plusieurs serveurs dépasse aussi ce qu’un PC$ ou un compte virtuel par machine peut faire. Dès qu’une identité propre au service, ou commune à plusieurs serveurs, est nécessaire dans le domaine, on envisage un gMSA avant un utilisateur de domaine : c’est la ligne de cet article. Un gMSA ne s’utilise pas non plus dans un groupe de travail.

4. Le rôle du gMSA : une identité propre, la gestion du mot de passe confiée à AD

4.1 Séparer des humains la génération, la distribution et le renouvellement du mot de passe

Un gMSA (group Managed Service Account, compte de service administré de groupe) est un compte de domaine dont la gestion du mot de passe est déléguée aux contrôleurs de domaine. Le contrôleur de domaine calcule le mot de passe à partir de la clé racine du Key Distribution Service (KDS), et seuls les hôtes autorisés le récupèrent pour l’utiliser dans le service.⁸

flowchart TB
    accTitle: Fonctionnement de la gestion du mot de passe gMSA
    accDescr: Le contrôleur de domaine calcule le mot de passe à partir de la clé racine KDS, seuls les hôtes autorisés le récupèrent et l'utilisent pour exécuter le service, et le mot de passe tourne automatiquement tous les 30 jours par défaut
    kds["Clé racine KDS"] --> dc["Le DC calcule le mot de passe"]
    dc --> host["L'hôte autorisé le récupère"]
    host --> svc["Utilisé pour exécuter le service"]
    dc -.-> rot["Rotation automatique tous les 30 jours par défaut"]

Figure 3 : Sans qu’aucun humain ne connaisse le mot de passe, les hôtes autorisés le récupèrent et le service tourne avec des informations d’identification renouvelées automatiquement.

Ce sont les raisons de préférer un gMSA à un utilisateur de domaine géré à la main.¹¹ Là où Windows LAPS automatise la gestion des mots de passe administrateur locaux, le gMSA prend en charge la gestion des mots de passe des comptes de service ; le voir ainsi aide à comprendre sa place. Les deux mécanismes visent des cibles différentes.

4.2 Ne pas omettre de vérifier la prise en charge par l’application

Le gMSA est largement pris en charge par ce qui configure l’identité d’ouverture de session par les mécanismes standard : services Windows, pools d’applications IIS, Planificateur de tâches, etc. Mais toutes les applications ne peuvent pas l’utiliser. Une conception qui demande en interne la saisie d’un mot de passe ne le peut pas, et il existe aussi des contraintes comme le clustering de basculement lui-même qui ne prend pas en charge gMSA.¹⁰

Une fois le gMSA retenu comme candidat, on confirme en environnement de test, avant la production, que le service démarre sous le gMSA et qu’il peut accéder aux ressources nécessaires. Microsoft demande aussi cette étape.¹¹

Parmi les options liées, il y a le sMSA (standalone Managed Service Account, compte de service administré autonome) pour un seul serveur, et le dMSA (delegated Managed Service Account, compte de service administré délégué) introduit dans Windows Server 2025. Un dMSA lie l’authentification à l’identité de l’appareil pour contrer le vol d’informations d’identification. Pour une nouvelle configuration, on part du gMSA et on envisage aussi ceux-ci selon les exigences.²

5. Déployer un gMSA : de la vérification des prérequis à la configuration du service

5.1 Exigences à confirmer d’abord

Le nom du gMSA et l’intervalle de changement se décident aussi avant le déploiement. Y penser après la création du compte impose de le recréer.¹⁰

5.2 Vérifier la clé racine KDS et en créer une si elle manque

La création de la clé racine KDS est un travail unique par forêt. On vérifie d’abord s’il existe déjà une clé, et on n’en ajoute une que si elle n’existe pas.

# Exécuter en tant qu'administrateur de domaine, sur un contrôleur de domaine
# (ou un poste d'administration avec le module PowerShell AD)

# Vérifier la présence d'une clé racine KDS et en créer une si elle manque
# (une seule fois par forêt)
Get-KdsRootKey
Add-KdsRootKey -EffectiveImmediately   # Utilisable réellement jusqu'à 10 heures plus tard

Même avec -EffectiveImmediately, la clé n’est pas forcément utilisable juste après la création. Pour attendre la réplication vers tous les contrôleurs de domaine, il y a jusqu’à 10 heures d’attente après la création, pendant lesquelles on ne peut pas créer de gMSA. C’est pour éviter l’accident d’aller récupérer le mot de passe alors que la réplication est encore incomplète, et d’échouer. Incluez ce délai dans le plan de déploiement.¹²

5.3 Restreindre les hôtes autorisés à récupérer le mot de passe, puis configurer le gMSA

La procédure a quatre étapes. La première moitié est la configuration côté AD ; la seconde, le travail sur chaque serveur qui fait tourner le service.¹⁰

Avant d’exécuter l’exemple suivant, configurez aussi le droit « Ouvrir une session en tant que service » de 7.1. Le succès de sc.exe config et la capacité du service à ouvrir une session sont deux choses distinctes.

# (1) Créer un groupe de sécurité autorisé à récupérer le mot de passe,
#     et y ajouter les comptes ordinateur des serveurs qui font tourner le service
New-ADGroup -Name "GG-SvcBatchHosts" -GroupScope Global
Add-ADGroupMember -Identity "GG-SvcBatchHosts" -Members "APPSV01$", "APPSV02$"
# L'appartenance au groupe est évaluée à l'ouverture de session de l'ordinateur,
# donc redémarrer les serveurs cibles après l'ajout est la méthode fiable

# (2) Créer le gMSA
New-ADServiceAccount -Name "svc-batch" `
    -DNSHostName "svc-batch.corp.example.com" `
    -PrincipalsAllowedToRetrieveManagedPassword "GG-SvcBatchHosts"

# (3) Sur chaque serveur qui fait tourner le service, installer et vérifier le gMSA
Install-ADServiceAccount -Identity "svc-batch"
Test-ADServiceAccount -Identity "svc-batch"   # True signifie que le mot de passe peut être récupéré

# (4) Le définir comme compte d'exécution du service. Ajouter $ à la fin du nom
#     et ne pas spécifier de mot de passe
sc.exe config MyBatchService obj= "CORP\svc-batch$"
Restart-Service MyBatchService

Dans services.msc aussi, saisissez le nom de compte avec un $ final, par exemple CORP\svc-batch$, et laissez les champs mot de passe vides. Les comptes de type MSA ne peuvent pas servir à une ouverture de session interactive.³

Sur le dossier partagé ou SQL Server de destination, on octroie les autorisations nécessaires à CORP\svc-batch$ à la place de PC$. On obtient ainsi une configuration où personne ne gère de mot de passe, et où le service accède au réseau avec une identité qui lui est propre. Ne vous arrêtez pas à la vérification de récupération par Test-ADServiceAccount ; validez aussi les fonctions principales du service pour de bon.

6. L’utilisateur de domaine est un dernier recours : si on l’utilise, réunir les mesures d’atténuation

6.1 Éviter l’expiration fige un autre risque

Quand on affecte un utilisateur de domaine ou un utilisateur local à un service, le SCM stocke le mot de passe et s’en sert pour ouvrir une session à chaque démarrage. Mais le SCM ne gère pas l’expiration. Si le mot de passe stocké expire, l’ouverture de session échoue et le service ne démarre plus.¹

De là naît un cercle vicieux : pour éviter les arrêts par expiration, on passe le mot de passe en sans expiration, on laisse le même mot de passe en clair dans les procédures, scripts et tâches de plusieurs serveurs, et enfin personne ne peut plus le changer même après un départ, parce que « on ne sait pas ce qui s’arrêtera si on le change ».

Microsoft souligne aussi que, dans une configuration qui utilise un compte de domaine pour un service, la gestion manuelle du mot de passe et des SPN coûte de l’effort d’exploitation, et que la maintenance peut entraîner un arrêt de service. Passer le mot de passe en sans expiration ne résout pas à lui seul le problème de gestion.³

6.2 Un compte qui a un SPN est aussi une cible de Kerberoasting

Un service qui accepte l’authentification Kerberos enregistre un SPN (service principal name, nom de principal de service) sur le compte d’exécution. Un utilisateur authentifié du domaine peut demander un ticket de service pour ce compte, donc un attaquant récupère le ticket et tente une force brute hors ligne sur le mot de passe : c’est le Kerberoasting.

La contre-mesure n’est pas de s’appuyer sur un mot de passe humain d’environ 10 à 16 caractères, mais d’utiliser un long mot de passe généré aléatoirement. Microsoft cite aussi le forçage de mots de passe longs et le gMSA, qui utilise une longue valeur aléatoire générée par machine.¹³

Le blindage Kerberos (FAST), mentionné dans le même document, protège les données de préauthentification et la résistance à l’usurpation de KDC. Il n’empêche pas un utilisateur authentifié de demander un ticket de service pour un SPN, et il ne remplace pas la force du mot de passe du compte de service. Pour les SPN, Kerberos, et les conditions de bascule vers NTLM, voir « NTLM et Kerberos expliqués en images ».

6.3 Pour une application non prise en charge, associer un compte dédié et l’exploitation

Quand on est forcé d’utiliser un utilisateur de domaine dédié, par exemple parce que l’application ne prend pas en charge gMSA, on met en œuvre toutes les mesures d’atténuation suivantes.

Séparer l’identité du service des comptes humains est aussi un principe important.⁴ Déplacer vers un gMSA les services qui le prennent en charge est plus sûr et plus léger à exploiter que de faire continuer cette gestion par des personnes : c’est la raison de préférer le gMSA.

7. Bascule et audit : ne pas s’arrêter au changement du nom de compte

7.1 Vérifier le droit « Ouvrir une session en tant que service »

Pour démarrer en tant que service, le compte a besoin de SeServiceLogonRight (Ouvrir une session en tant que service). LocalSystem, LocalService et NetworkService l’ont de façon intégrée, mais pour tout autre compte, on vérifie l’attribution de ce droit.¹⁴

On inscrit explicitement dans la procédure de déploiement comment le droit est configuré, que ce soit par la stratégie de sécurité locale (secpol.msc) ou par GPO ou Intune. Ne pas s’appuyer sur un effet de bord de l’outil est important. Pour un compte dédié au service, on combine aussi le refus de l’ouverture de session interactive.

7.2 Vérifier les données sous le profil, et les ACL

Au démarrage du service, le SCM charge le profil utilisateur de ce compte. Par conséquent, les emplacements réels de %TEMP%, %APPDATA% et HKEY_CURRENT_USER diffèrent selon le compte. Quand les paramètres ou le cache semblent « disparus » après la bascule, c’est parce que le service consulte un profil différent de celui de l’ancien compte.¹

La parade est de placer les données du service dans un chemin explicite tel que C:\ProgramData\<nom de l'application> et d’octroyer une ACL au compte d’exécution. Une fois les données détachées du profil par compte, le prochain changement de compte n’impose plus de déplacer le stockage. Pour les données déjà enregistrées sous un profil, incluez leur migration dans le plan de bascule.

Vérifiez les autorisations non seulement sur les dossiers nécessaires, mais aussi sur le registre et ailleurs. Après le passage à un compte à faible privilège, validez que les traitements qui supposaient les anciens privilèges LocalSystem n’échouent pas.

7.3 Les données protégées par DPAPI ne se transmettent pas en déplaçant seulement les fichiers

Les données protégées avec DPAPI de portée utilisateur (CryptProtectData, ProtectedData de .NET, etc.) ne peuvent, en principe, être déchiffrées que par le même compte qui les a protégées. Changer le compte d’exécution rend illisibles les chaînes de connexion et clés d’API déjà enregistrées.

C’est pourquoi, séparément de la migration des fichiers de profil, on prépare une procédure pour réinjecter les secrets après la bascule. Même si DPAPI protège correctement les données, cela devient un incident de service si personne n’a prévu cette étape. Pour la conception du stockage, voir « Stocker les secrets des applications Windows ».

Si la connexion peut se faire par authentification Windows intégrée avec un gMSA ou PC$, on peut supprimer le stockage de secrets lui-même. L’ordre est de se demander « peut-on éviter de stocker ? » avant « où stocker ? ».

De plus, si l’on veut « traiter avec les privilèges de l’utilisateur appelant », on envisage l’emprunt d’identité plutôt que de renforcer le compte d’exécution du service. C’est expliqué dans « Bien gérer les jetons d’emprunt d’identité Windows ».

7.4 Faire l’inventaire à partir de la liste des services, et confirmer l’identité au démarrage dans le journal

Pour le premier inventaire, on agrège les comptes d’exécution de la liste des services. L’exemple suivant donne le nombre par compte, et les services LocalSystem dont le chemin est hors du dossier Windows.

# Agréger quels services tournent sous quel compte
Get-CimInstance Win32_Service |
    Group-Object StartName |
    Sort-Object Count -Descending |
    Select-Object Count, Name

# Repérer les services non standard qui tournent sous LocalSystem
# (distinguer les services internes / tiers d'après le chemin)
Get-CimInstance Win32_Service |
    Where-Object { $_.StartName -eq 'LocalSystem' -and $_.PathName -notlike '*\Windows\*' } |
    Select-Object Name, DisplayName, PathName

Si un service métier tourne sous LocalSystem ou un utilisateur de domaine, on revient au jugement du chapitre 1 et on confirme les privilèges nécessaires et l’identité requise côté destination. On utilise le filtre par chemin comme indice pour trouver des candidats, et on décide d’après l’usage réel du service et le contenu du traitement.

Le démarrage d’un service se confirme dans le journal des événements de sécurité avec l’ID d’événement 4624, type d’ouverture de session 5 (Service). Cela représente l’ouverture de session effectuée par le SCM pour démarrer un service. Le champ « Virtual Account » indique si l’ouverture de session a été faite par un MSA ou un compte virtuel, donc on peut aussi s’en servir pour surveiller l’usage des comptes gérés.¹⁵

7.5 Récapitulatif des vérifications avant la bascule en production

Que l’on quitte LocalSystem ou que l’on déploie un gMSA, on termine ces vérifications avant de basculer la production. Le point de la migration est de confirmer ensemble le moindre privilège et le maintien des fonctions nécessaires.

8. Résumé

Pour choisir un compte de service, on sépare les privilèges locaux, l’identité réseau et la gestion du mot de passe. Que LocalSystem soit la valeur par défaut n’est pas une raison de l’utiliser. Pour un service métier ordinaire, on part du compte virtuel et on octroie les ACL nécessaires. On n’envisage LocalSystem que lorsque des privilèges forts sont vraiment nécessaires.⁵³

Si une identité par machine suffit pour les destinations dans le domaine, un compte virtuel ou assimilé plus une autorisation PC$ peut suffire. Si une identité propre au service, ou commune à plusieurs serveurs, est nécessaire, on choisit un gMSA et on confie la gestion du mot de passe à AD. Dans un groupe de travail, ni PC$ ni gMSA n’est disponible, et une autre conception qui traite des informations d’identification est nécessaire.²¹⁰

Quand un utilisateur de domaine est nécessaire, on réunit un compte dédié, un long mot de passe aléatoire, des restrictions d’ouverture de session, le moindre privilège, la rotation et un registre. Lors de la bascule, on vérifie non seulement le nom de compte, mais aussi le droit d’ouverture de session, le profil et DPAPI.

La question à se poser la prochaine fois que l’on configure un service est « en tant que qui, et jusqu’où, ce service devrait-il pouvoir accéder ? ». On choisit le compte d’après cette réponse, et on ne le laisse pas figé comme « le paramètre qui a fini par marcher ».

Articles connexes

• Comment créer et exploiter un service Windows ── du choix entre Planificateur de tâches et service à la transformation d’un BackgroundService en service Windows
• Quand Windows exige-t-il réellement des privilèges administrateur - UAC, zones protégées et comment le déterminer par conception
• Bien gérer les jetons d’emprunt d’identité Windows — emprunt des privilèges par thread et retour sécurisé au contexte d’origine
• NTLM et Kerberos expliqués en images — Pourquoi l’authentification « retombe »-t-elle sur NTLM ?
• Guide pratique de Windows LAPS ── En finir avec le mot de passe administrateur local commun à tous les PC
• Stocker les secrets des applications Windows - Éviter les configurations en clair avec DPAPI

Domaines de conseil associés

KomuraSoft LLC prend en charge la conception du compte d’exécution et le passage au moindre privilège pour les services Windows et les applications résidentes, la migration vers un compte virtuel ou un gMSA de services existants construits sur l’hypothèse de LocalSystem, et l’investigation des pannes causées par un accès refusé, DPAPI et le profil après un changement de compte. Commencer au stade « on nous a signalés à un audit, mais nous ne savons pas par où commencer » convient tout à fait.

• Développement d’applications Windows
• Analyse des bugs et des causes
• Conseil technique et revue de conception
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Faut-il changer tout de suite un service que l'on fait tourner « pour l'instant » sous LocalSystem ?

Un changement immédiat n'est pas toujours la bonne réponse. Vérifiez d'abord si ce service a vraiment besoin de privilèges locaux de classe LocalSystem (des privilèges forts, au-delà d'un administrateur). S'il s'agit seulement de lecture et d'écriture de fichiers et de communication réseau, le premier candidat est un compte virtuel (NT SERVICE\nom-du-service). Lors de la migration, confirmez l'octroi d'accès aux dossiers et clés de registre nécessaires, le traitement des données qui dépendent du profil ou de DPAPI, et la présence du droit « Ouvrir une session en tant que service ». Validez le démarrage et les fonctions principales dans un environnement de test, puis basculez la production.

Faut-il choisir un compte virtuel ou NetworkService ?

Pour un choix nouveau, un compte virtuel est recommandé. Sur le réseau, les deux apparaissent comme le compte ordinateur (DOMAIN\nom-ordinateur$), et les deux ont de petits privilèges locaux. NetworkService est toutefois partagé par plusieurs services, donc une ACL ne peut pas exprimer « n'autoriser que ce service ». Un compte virtuel a une identité propre à chaque service, et on peut indiquer NT SERVICE\nom-du-service directement dans une ACL. Les produits Microsoft récents comme SQL Server utilisent aussi un compte virtuel par défaut.

Peut-on utiliser un gMSA dans un environnement de groupe de travail (sans domaine) ?

Non. Un gMSA est un mécanisme dans lequel les contrôleurs de domaine Active Directory génèrent et gèrent le mot de passe ; un domaine et la création d'une clé racine KDS sont des prérequis. Dans un groupe de travail, la base est de terminer le traitement local avec un compte virtuel ou LocalService/NetworkService. S'il faut accéder à une autre machine, il faut une autre conception, par exemple utiliser explicitement les informations d'identification d'un compte préparé sur la destination. L'accès réseau en tant que compte ordinateur (PC$) n'est aussi valable que dans un environnement de domaine.

Après avoir changé le compte d'exécution du service, je ne peux plus lire les paramètres et informations d'identification enregistrés. Pourquoi ?

Parce que chaque compte d'exécution est lié à son propre profil utilisateur, %TEMP%, HKEY_CURRENT_USER et clé DPAPI. En particulier, les données protégées avec DPAPI de portée utilisateur (CryptProtectData et assimilés) ne peuvent, en principe, être déchiffrées que par le même compte qui les a protégées. Les fichiers enregistrés sous le profil (AppData et assimilés) sont aussi un autre chemin depuis le nouveau compte. Avant de changer de compte, planifiez la procédure de recréation des données protégées par DPAPI (nouvelle saisie des clés d'API, etc.) et la migration des fichiers sous le profil.

Si je veux seulement que le service accède à un dossier partagé, faut-il un utilisateur de domaine ?

Dans beaucoup de cas, non. Dans un environnement de domaine, un service qui tourne sous LocalSystem, NetworkService ou un compte virtuel s'authentifie auprès du distant comme le compte ordinateur (DOMAIN\nom-ordinateur$). Ajoutez ce PC$ aux autorisations de partage et aux autorisations NTFS du dossier partagé et il peut lire et écrire. Si vous voulez un contrôle d'accès avec une identité propre au service, ou la même identité sur plusieurs serveurs, envisagez un gMSA plutôt qu'un utilisateur de domaine.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.