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

« Un service interne que nous faisions tourner sous LocalSystem “pour l’instant” a été signalé à l’audit de sécurité comme “privilège excessif”. Vers quoi le changer ? » « Le service n’arrivait pas à accéder à un dossier partagé, alors nous le faisons tourner sous un utilisateur de domaine. Quand le mot de passe expire le service s’arrête, donc nous l’avons rendu sans expiration et l’avons écrit en clair dans le runbook. » — Parmi les consultations autour des services Windows des clients, ces deux-là sont des classiques.

Ce que les deux sites ont en commun, c’est que le compte d’ouverture de session du service est figé comme « le paramètre qui a fini par marcher », et non comme une décision de conception. Un service Windows tourne toujours dans le contexte de sécurité d’un compte, et ce compte décide de tout : ce qu’il peut faire en local, qui il est du point de vue de l’autre côté du réseau, et qui gère le mot de passe. Laisser cela à la valeur par défaut, et une vulnérabilité d’un seul service mène directement à la prise de la machine entière, et les mots de passe en clair se dispersent dans les runbooks et les scripts.

flowchart TB
    accTitle: Trois choses que le compte d'ouverture de session décide
    accDescr: Un service tourne toujours dans le contexte de sécurité d'un compte, et ce compte décide de tout ce qu'il peut faire en local, qui il est de l'autre côté du réseau, et qui gère le mot de passe
    acct["Le compte d'ouverture de session du service"] --> local["Ce qu'il peut faire en local"]
    acct --> net["Qui il est de l'autre côté du réseau"]
    acct --> pwd["Qui gère le mot de passe"]

Figure 1 : Choisir le compte d’ouverture de session est une décision de conception qui fixe à la fois les privilèges locaux, l’identité réseau et la gestion du mot de passe.

Il y a effectivement six choix — LocalSystem, LocalService, NetworkService, un compte virtuel (NT SERVICE\), un utilisateur de domaine, et un gMSA (compte de service administré de groupe). Destiné aux informaticiens de PME et aux développeurs d'applications Windows, cet article organise les privilèges, l'identité réseau et la gestion des mots de passe de ces six options en une seule table et résume un flux de décision, à partir des sources primaires Microsoft Learn d'août 2026.

Comment construire le service lui-même (choix entre le Planificateur de tâches et un service, implémentation avec un .NET Worker Service) est traité dans « Comment créer et exploiter un service Windows ». Cet article se concentre sur le « compte d’ouverture de session », là où arrivent le plus d’accidents.

1. La conclusion d’abord

• Dans le doute, un compte virtuel est le premier candidat pour un service qui se termine à l’intérieur d’une seule machine, et un gMSA est le premier candidat pour un service qui accède à une ressource du domaine avec une identité propre au service. Microsoft donne aussi pour consigne d’utiliser un compte administré (MSA / compte virtuel) partout où c’est possible.¹²
• Ne choisissez pas LocalSystem parce que « ça marche ». Le jeton inclut SYSTEM et BUILTIN\Administrators et détient des privilèges forts comme SeDebugPrivilege, donc une prise de contrôle perd presque tout sur cette machine. Le fait que sc.exe create soit LocalSystem par défaut est le terreau de cet accident.³⁴
• La différence entre LocalService et NetworkService est l’identité réseau. Les privilèges locaux sont minimaux pour les deux, mais du côté distant LocalService paraît anonyme et NetworkService paraît le compte ordinateur.⁵
• **Un compte virtuel (NT SERVICE\) est le défaut moderne qui sépare l'identité par service sans imposer de gestion de mot de passe.** On peut indiquer « NT SERVICE\\nom-du-service » directement sur une ACL, et le compte de service par défaut de SQL Server est celui-là aussi.[^understand-service-accounts][^sql-service-accounts]
• Quand LocalSystem, NetworkService ou un compte virtuel sort sur le réseau, il devient le compte ordinateur (DOMAIN\nom-ordinateur$). Accorder PC$ sur l’ACL d’un dossier partagé ou de SQL Server permet souvent de se passer d’un utilisateur de domaine.³⁶
• Une configuration qui utilise un utilisateur de domaine pour un service devient une dette à la fois sur l’exploitation des mots de passe et face au Kerberoasting. Le SCM ouvre une session avec le mot de passe stocké, donc l’expiration devient un échec de démarrage, et le « jamais d’expiration + note en clair » qui l’évite devient un cadeau pour l’attaquant.⁷⁸
• Un gMSA fait générer et faire tourner le mot de passe automatiquement par Active Directory. Les exigences sont un domaine et une clé racine KDS, et on configure le service en « DOMAIN\nom-de-compte$ » avec le champ mot de passe vide. Certaines applications ne le prennent pas en charge : il faut valider à l’avance.⁹¹⁰
• Changer le compte change les hypothèses du profil, de %TEMP% et de DPAPI. Les données protégées avec le DPAPI de l’ancien compte ne peuvent pas être déchiffrées par le nouveau.
• Un inventaire de l’état actuel se confirme à partir des comptes d’ouverture de session de la liste des services et de l’ID d’événement 4624 (type d’ouverture de session 5).¹¹

En une phrase, la conclusion de cet article est : faites d’une configuration qui « ne donne pas à un service un mot de passe humain » (comptes intégrés, compte virtuel, gMSA) le défaut, et traitez l’utilisateur de domaine comme un dernier recours.

2. Le tableau d’ensemble des choix — six comptes d’ouverture de session en une table

Un cran de rappel d’abord. Au démarrage du service, le Gestionnaire de contrôle des services (SCM) ouvre une session avec le compte configuré et, en cas de succès, crée un jeton d’accès et l’assigne au processus du service. Ensuite, chaque accès à une ressource — fichiers, canaux nommés, etc. — se décide en confrontant ce jeton à l’ACL.⁷ Choisir le compte d’ouverture de session est donc une conception qui décide du contenu du jeton passé au processus du service. Voici les six choix.

flowchart TB
    accTitle: Ce que fait le SCM au démarrage d'un service
    accDescr: Le SCM ouvre une session avec le compte configuré, en cas de succès crée un jeton d'accès et l'assigne au processus du service, et ensuite l'accès aux ressources se décide en confrontant le jeton à l'ACL
    scm["SCM"] --> logon["Ouvrir une session avec le compte configuré"]
    logon --> token["Créer un jeton d'accès"]
    token --> proc["L'assigner au processus du service"]
    proc --> access["Accès à un fichier ou un canal"]
    access --> check{"L'ACL l'autorise-t-elle ?"}
    check -->|Oui| ok["Accès réussi"]
    check -->|Non| deny["Accès refusé"]

Figure 2 : Chaque accès aux ressources du service se décide en confrontant le jeton créé par le SCM au démarrage à l’ACL.

LocalSystem, LocalService, NetworkService et un compte virtuel n’ont aucun concept de mot de passe. Les seuls qui ouvrent une session avec un mot de passe stocké dans le SCM (= expiration et fuite possibles) sont un utilisateur de domaine et un utilisateur local.⁷³

Ci-dessous nous creusons cette table une ligne à la fois.

3. Ce qui ne va pas avec LocalSystem

3.1. Plus fort encore que « Exécuter en tant qu’administrateur »

LocalSystem (nom d’affichage Local System, NT AUTHORITY\SYSTEM) est un compte prédéfini que le SCM utilise, et il détient des privilèges étendus sur l’ordinateur local. Le jeton inclut les SID de NT AUTHORITY\SYSTEM et de BUILTIN\Administrators, et il peut accéder à la plupart des objets du système. De plus, SeDebugPrivilege, qui peut déboguer d’autres processus, et SeTcbPrivilege, qui agit comme une partie de l’OS, sont activés par défaut.³

Cette force est synonyme de l’ampleur des dégâts en cas de prise de contrôle. Si un service qui tourne sous LocalSystem a une vulnérabilité d’exécution de code arbitraire, un attaquant atteint, d’un souffle, la lecture et l’altération des fichiers de chaque utilisateur sur cette machine (SYSTEM a le Contrôle total par défaut sur NTFS⁵), la lecture de la mémoire d’autres processus via SeDebugPrivilege, et le vol d’informations d’identification puis le déplacement latéral (un point de départ pour Pass-the-Hash et assimilés). La chaîne du vol d’informations d’identification et du déplacement latéral est traitée dans « NTLM et Kerberos expliqués en images » et « Guide pratique de Windows LAPS ».

flowchart TB
    accTitle: Les dégâts quand un service LocalSystem est pris
    accDescr: Si un service qui tourne sous LocalSystem a une vulnérabilité d'exécution de code arbitraire, un attaquant atteint la lecture et l'altération des fichiers de chaque utilisateur, la lecture de la mémoire d'autres processus, et le vol d'informations d'identification puis le déplacement latéral
    vuln["Une vulnérabilité d'exécution de code"] --> sys["L'attaquant obtient les privilèges SYSTEM"]
    sys --> files["Lecture et altération des fichiers"]
    sys --> mem["Lecture de la mémoire d'autres processus"]
    sys --> cred["Vol d'informations d'identification"]
    cred --> lateral["Déplacement latéral vers une autre machine"]

Figure 3 : Une vulnérabilité dans un service LocalSystem laisse un attaquant atteindre, d’un souffle, la prise de la machine entière et un point de départ pour le déplacement latéral.

3.2. Pourquoi on le choisit encore

La raison est simple : c’est le défaut, et un accès refusé n’apparaît jamais. Le défaut quand on omet obj= sur sc.exe create est LocalSystem,⁴ et beaucoup d’anciens exemples et modèles d’installeur supposent encore LocalSystem. Parce que l’on peut rester libre d’erreurs de privilège pendant le développement, la structure qui produit en masse « ça a marché, donc on laisse » est là. La documentation de Microsoft elle-même indique que la plupart des services n’ont pas besoin d’un niveau de privilège aussi élevé, et que si on n’en a pas besoin on devrait envisager LocalService ou NetworkService.³

flowchart TB
    accTitle: La structure qui fait encore choisir LocalSystem
    accDescr: Le défaut de sc.exe create est LocalSystem, et les anciens exemples et modèles supposent aussi LocalSystem, donc aucun accès refusé n'apparaît pendant le développement et une configuration ça a marché donc on laisse est produite en masse
    def["Le défaut de sc.exe create"] --> lsys["Créé comme LocalSystem"]
    old["Anciens exemples et modèles"] --> lsys
    lsys --> noerr["Pas d'accès refusé pendant le développement"]
    noerr --> asis["Ça a marché, donc on laisse"]
    asis --> mass["Des services à privilège excessif sont produits en masse"]

Figure 4 : Le défaut et une expérience de développement « sans accès refusé » produisent en masse des services figés sous LocalSystem.

3.3. La différence avec TrustedInstaller — LocalSystem n’est pas illimité non plus

Appeler LocalSystem « le compte le plus fort de Windows » n’est pas exact. La Protection des ressources Windows (WRP) depuis Windows Vista n’autorise les modifications des fichiers, dossiers et clés de registre importants du système qu’à TrustedInstaller (le service Programme d’installation des modules Windows), et même SYSTEM ou un administrateur reçoit un accès refusé sur une réécriture.¹² Le « Vous avez besoin d’une autorisation de TrustedInstaller » d’Explorer est ce mécanisme. À l’inverse, LocalSystem peut atteindre presque tout hors de la zone protégée par WRP, et il n’y a d’ordinaire aucune raison de donner cela à un service métier.

flowchart TB
    accTitle: La relation entre la zone protégée par WRP et TrustedInstaller
    accDescr: Les modifications des fichiers système et clés de registre importants que WRP protège ne sont autorisées qu'à TrustedInstaller, et même SYSTEM ou un administrateur reçoit un accès refusé
    ti["TrustedInstaller"] -->|Peut modifier| wrp["Fichiers système protégés par WRP"]
    sysadm["SYSTEM et administrateurs"] -->|Accès refusé| wrp
    sysadm -->|Presque tout est autorisé| other["Hors de la zone protégée par WRP"]

Figure 5 : LocalSystem n’est pas illimité non plus ; les modifications de la zone protégée par WRP ne sont autorisées qu’à TrustedInstaller.

3.4. Cas où LocalSystem est raisonnable

Ce qui est exceptionnellement raisonnable, c’est un service dont les privilèges requis dépassent dès le départ la classe administrateur — travailler étroitement avec un pilote de périphérique, opérer le fondement de sécurité de l’OS, gérer d’autres services ou sessions, etc. Des logiciels comme un agent de sauvegarde ou un EDR s’appliquent. Même alors, il vaut la peine de confirmer qu’il existe un chemin de code qui utilise vraiment ce privilège, et d’envisager si le travail qui a besoin du privilège peut être séparé (pour savoir le dire, voir « Quand Windows exige-t-il réellement des privilèges administrateur »).

4. LocalService et NetworkService — comptes intégrés au moindre privilège

LocalService (NT AUTHORITY\LOCAL SERVICE, SID : S-1-5-19) et NetworkService (NT AUTHORITY\NETWORK SERVICE, SID : S-1-5-20) sont des comptes intégrés préparés pour les services à faible privilège. Tous deux ne détiennent que des privilèges minimaux en local, et ne peuvent guère plus qu’un membre du groupe Users.⁵¹

La différence entre les deux tient à un point : qui ils sont du point de vue de l’autre côté du réseau.⁵

• LocalService : se connecte au distant avec des informations d’identification anonymes. Il ne peut pas accéder à une ressource qui exige une authentification.
• NetworkService : présente les informations d’identification de l’ordinateur au distant (dans un environnement de domaine, DOMAIN\nom-ordinateur$).

La coupure est LocalService si « il ne sort pas sur le réseau, ou s’il le fait il n’a pas besoin d’identité », et NetworkService si « vous voulez accéder à une ressource du domaine avec l’identité de la machine ».

flowchart TB
    accTitle: La différence entre LocalService et NetworkService
    accDescr: Les privilèges locaux sont minimaux pour les deux, mais du côté distant LocalService se connecte avec des informations d'identification anonymes et NetworkService présente celles de l'ordinateur
    ls["LocalService"] --> anon["Se connecte avec des informations anonymes"]
    anon -.-> ng["Une ressource qui exige une authentification est impossible"]
    ns["NetworkService"] --> comp["Présente les informations de l'ordinateur"]
    comp -.-> pc["Dans un domaine il apparaît comme PC$"]

Figure 6 : Les privilèges locaux sont le même minimum, mais l’identité visible de l’autre côté du réseau se coupe entre anonyme et compte ordinateur.

Ces deux-là ont toutefois une faiblesse d’un point de vue moderne. Le même compte est partagé par beaucoup de services. Si cinq services tournent sous LocalService, tant que l’ACL est par compte, les cinq peuvent accéder aux ressources les uns des autres. SQL Server ne prend pas en charge le compte Local Service pour la même raison : c’est un compte partagé et on ne peut pas le séparer des autres services.¹

flowchart TB
    accTitle: Un compte partagé ne peut pas être séparé
    accDescr: Si plusieurs services partagent le même LocalService, tant que l'ACL est par compte ils peuvent accéder aux ressources les uns des autres
    sva["Service A"] --> acct["Le même LocalService"]
    svb["Service B"] --> acct
    svc["Service C"] --> acct
    acct --> mutual["Peuvent accéder aux ressources les uns des autres"]
    mutual -.-> reason["Parce que l'ACL est par compte"]

Figure 7 : Les services qui partagent le même compte ne peuvent pas être séparés des ressources les uns des autres par une ACL.

Résoudre ce « rester à faible privilège, mais séparer par service » est le sujet suivant, le compte virtuel.

5. Comptes virtuels (NT SERVICE\) — le défaut moderne

5.1. On peut avoir une identité par service sans mot de passe

Un compte virtuel est un « compte local administré » disponible à partir de Windows Server 2008 R2 / Windows 7. Il a trois caractéristiques.⁶

• Le compte est géré automatiquement ; ni création ni définition de mot de passe n’est nécessaire
• Le nom est NT SERVICE\<nom-du-service>, et il devient une identité unique à chaque service
• Dans un environnement de domaine, il peut accéder au réseau avec les informations d’identification du compte ordinateur (DOMAIN\nom-ordinateur$)

Autrement dit, il conserve le mérite « pas de gestion de mot de passe » de LocalService/NetworkService et retire le défaut « on ne peut pas séparer parce que le compte est partagé ». C’est aussi pourquoi l’installation de SQL Server utilise par défaut un compte virtuel tel que NT SERVICE\MSSQLSERVER.¹

flowchart TB
    accTitle: Ce qu'un compte virtuel rend compatible
    accDescr: Un compte virtuel conserve le mérite absence de gestion de mot de passe de LocalService et NetworkService, retire le défaut on ne peut pas séparer parce que partagé, et a une identité unique à chaque service
    merit["Mérite (pas de gestion de mot de passe)"] -->|Conserver| va["Compte virtuel"]
    demerit["Défaut (on ne peut pas séparer car partagé)"] -->|Retirer| va
    va --> ident["Une identité unique à chaque service"]
    va --> auto["Ni création ni mot de passe n'est nécessaire"]

Figure 8 : Un compte virtuel conserve les mérites des comptes intégrés et ne retire que le défaut on ne peut pas séparer parce que partagé.

5.2. On peut écrire « NT SERVICE\nom-du-service » directement sur une ACL

La commodité pratique est que on peut ajouter seulement ce service à une ACL par nom. « Seul ce service peut écrire dans ce dossier de données » se réalise sans créer de groupe ni gérer de mot de passe.

# Change the service's logon account to a virtual account
# The value of obj= is "NT SERVICE\service-name". Do not specify a password
sc.exe config MyAppService obj= "NT SERVICE\MyAppService"

# Confirm the configuration (check SERVICE_START_NAME)
sc.exe qc MyAppService

# Grant modify rights on the data folder to this service only
icacls "C:\ProgramData\MyApp" /grant "NT SERVICE\MyAppService:(OI)(CI)M"

Dans l’interface graphique, dans services.msc ouvrez les propriétés du service → l’onglet « Connexion » → saisissez NT SERVICE\nom-du-service dans « Ce compte », et laissez les champs mot de passe vides (pour un compte virtuel ou un MSA, ne pas spécifier de mot de passe est la spécification du SCM). Après le changement, un redémarrage du service l’applique.

5.3. La contrainte — hors de la machine ce n’est pas « ce service »

L’identité d’un compte virtuel est locale à la machine et n’est pas reconnue depuis le domaine. Sur le réseau elle s’effondre vers le compte ordinateur comme décrit plus loin, donc le distant ne peut pas dire « de quel service il s’agit », et on ne peut pas non plus partager la même identité sur plusieurs serveurs.¹⁰

flowchart TB
    accTitle: L'identité d'un compte virtuel s'effondre hors de la machine
    accDescr: Un compte virtuel unique par service à l'intérieur de la machine s'effondre aussi vers le compte ordinateur sur le réseau, et 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["L'identité visible du côté distant"]
    remote -.-> nodist["On ne peut pas dire de quel service il s'agit"]

Figure 9 : Même avec une identité unique à l’intérieur de la machine, de l’autre côté du réseau chaque service ressemble au même PC$.

Le moment où cette contrainte — besoin d’une identité propre au service de l’autre côté du réseau, besoin de la même identité sur plusieurs serveurs — devient un problème est celui où un gMSA (chapitre 8) est appelé.

6. Identité en sortant sur le réseau — la pratique du compte ordinateur (PC$)

6.1. « Un service ne peut pas accéder à un dossier partagé » est un malentendu

Sur une machine jointe au domaine, quand un service qui tourne sous LocalSystem, NetworkService ou un compte virtuel accède à une ressource distante, il s’authentifie comme le compte ordinateur (DOMAIN\nom-ordinateur$).³⁶ Beaucoup des consultations d’ouverture « il n’arrivait pas à accéder à un dossier partagé, donc nous en avons fait un utilisateur de domaine » se résolvent en fait ainsi. L’ACL de destination n’autorisait simplement pas PC$.

flowchart TB
    accTitle: Accès distant en tant que compte ordinateur
    accDescr: Un service LocalSystem, NetworkService ou compte virtuel sur une machine jointe au domaine s'authentifie auprès du distant comme le compte ordinateur, et si l'ACL de destination autorise PC$ il peut accéder
    svc["Service (LocalSystem, un compte virtuel, etc.)"] --> auth["S'authentifier comme PC$"]
    auth --> acl{"L'ACL de destination autorise-t-elle PC$ ?"}
    acl -->|Oui| ok["L'accès à un dossier partagé ou une BD réussit"]
    acl -->|Non| ng["Accès refusé"]

Figure 10 : Dans un environnement de domaine, accorder PC$ sur l’ACL de destination suffit à établir l’accès distant sans utilisateur de domaine.

L’octroi côté serveur de fichiers est le même qu’une opération d’ACL ordinaire ; indiquez nom-ordinateur$ comme nom de compte (dans la boîte de dialogue de sélection d’objet de l’interface, incluez « Ordinateurs » dans les types d’objets).

# On the file-server side: grant a service on APPSV01 modify rights on the shared folder
# You need to grant both share permissions and NTFS permissions
Grant-SmbShareAccess -Name "AppData" -AccountName "CORP\APPSV01$" -AccessRight Change -Force
icacls "D:\Shares\AppData" /grant "CORP\APPSV01$:(OI)(CI)M"

SQL Server est le même : créez le compte ordinateur comme une connexion et la chaîne de connexion passe avec Integrated Security=true et sans mot de passe.

-- On the DB-server side: permit Windows integrated authentication from a service on APPSV01
CREATE LOGIN [CORP\APPSV01$] FROM WINDOWS;

6.2. Connaître les limites de l’approche PC$

Cette approche a deux limites.

1. La granularité est par machine. LocalSystem, NetworkService et chaque service à compte virtuel qui tourne sur la même machine ressemblent tous au même PC$ depuis le distant. On ne peut pas « n’autoriser que ce service » sur la destination, et on ne peut pas non plus auditer quel service a utilisé ce compte.²
2. Elle ne peut pas être utilisée dans un environnement de groupe de travail. Un compte ordinateur est un objet Active Directory, donc une machine non jointe au domaine n’en a pas. Il faut une conception qui traite explicitement les informations d’identification du compte de destination.

Quand on veut dépasser la limite 1, la réponse 2026 n’est pas l’utilisateur de domaine du chapitre suivant… mais de sauter ce problème et de passer à un gMSA.

flowchart TB
    accTitle: Deux limites de l'approche PC$
    accDescr: L'authentification comme PC$ a une granularité de niveau machine donc ni autorisation ni audit par service n'est possible, et dans un groupe de travail le compte ordinateur lui-même n'existe pas donc on ne peut pas l'utiliser
    pcs["L'approche PC$"] --> lim1["Limite 1 : par machine"]
    pcs --> lim2["Limite 2 : pas de groupe de travail"]
    lim1 -.-> noaudit["Ni autorisation ni audit par service"]
    lim2 -.-> nocred["Utiliser des informations explicites"]
    lim1 --> gmsa["Au-delà : un gMSA"]

Figure 11 : Quand on veut dépasser les deux limites de granularité machine et de prérequis de domaine, on saute l’utilisateur de domaine et on passe à un gMSA.

7. Le problème d’utiliser un utilisateur de domaine pour un service

7.1. Le problème structurel du mot de passe

Si vous assignez un utilisateur de domaine (ou un utilisateur local) à un service, le SCM stocke ce mot de passe et l’utilise pour ouvrir une session à chaque démarrage. Le SCM ne gère pas l’expiration, donc quand le mot de passe expire l’ouverture de session échoue et le service ne démarre pas.⁷

De là commence la spirale négative que l’on voit souvent sur le terrain.

1. Un accident d’arrêt du service à cause de l’expiration se produit
2. En prévention de récidive, « mot de passe n’expire jamais » est défini
3. Une procédure de changement n’est jamais établie, et le même mot de passe est écrit en clair dans les runbooks, scripts et Planificateur de tâches de plusieurs serveurs
4. Même quand quelqu’un part, le mot de passe ne change pas (si on le change, on ne sait pas ce qui s’arrêtera)

flowchart TB
    accTitle: La spirale négative d'exploiter avec un utilisateur de domaine
    accDescr: Le mot de passe expire et le service s'arrête, jamais d'expiration est défini en prévention de récidive, un mot de passe en clair se répand dans les runbooks et scripts, et même quand quelqu'un part on ne peut pas le changer
    expire["1. L'expiration arrête le service"] --> forever["2. Jamais d'expiration est défini en prévention"]
    forever --> spread["3. Un mot de passe en clair se répand"]
    spread -.-> where["Runbooks, scripts, tâches"]
    spread --> stuck["4. Même quand quelqu'un part, on ne peut pas le changer"]

Figure 12 : En partant d’un accident d’expiration, jamais d’expiration et la diffusion d’un mot de passe en clair se figent.

Microsoft souligne aussi qu’une configuration qui utilise un compte de domaine pour un service coûte un effort opérationnel considérable dans la gestion manuelle du mot de passe et du SPN, et que la maintenance peut mener à un arrêt de service.¹

7.2. Kerberoasting — un compte de service est visé

Une autre attaque spécifique à un compte de service utilisateur de domaine est le Kerberoasting. Un service qui reçoit une authentification Kerberos inscrit un SPN (nom de principal de service) sur le compte d’ouverture de session. Tout utilisateur authentifié du domaine peut demander un ticket de service à un compte qui a un SPN inscrit, donc un attaquant obtient le ticket et tente un brute-force hors ligne du mot de passe. Un mot de passe de 10 à 16 caractères décidé par un humain ne résistera pas à cette attaque.

flowchart TB
    accTitle: Le flux du Kerberoasting
    accDescr: Un ticket de service vers un compte de service qui a un SPN inscrit peut être demandé par tout utilisateur authentifié, donc un attaquant obtient le ticket et tente un brute-force hors ligne du mot de passe
    atk["Un utilisateur authentifié du domaine"] --> req["Demander un ticket pour le SPN"]
    req --> tkt["Obtenir un ticket de service"]
    tkt --> brute["Brute-force hors ligne"]
    brute --> weak["10 à 16 caractères environ seront cassés"]

Figure 13 : Tout utilisateur authentifié peut demander un ticket, et un mot de passe d’une longueur décidée par un humain ne résistera pas à un brute-force hors ligne.

La réponse efficace est de rendre le mot de passe d’une force qu’un humain ne peut ni deviner ni casser. Microsoft liste aussi le forçage d’un mot de passe long, et l’utilisation d’un gMSA dont le mot de passe devient une longue valeur aléatoire générée par machine.⁸ Le même document mentionne aussi le blindage Kerberos (FAST), mais FAST 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 à un SPN, donc ce n’est pas un substitut à la force du mot de passe d’un compte de service. La relation entre SPN et Kerberos, et les conditions sous lesquelles l’authentification retombe sur NTLM, sont diagrammées dans « NTLM et Kerberos expliqués en images ».

7.3. Si vous utilisez quand même un utilisateur de domaine

Si vous n’avez pas le choix que d’utiliser un utilisateur de domaine, pour des raisons telles que l’application ne prenant pas en charge un gMSA, traitez ce qui suit comme l’atténuation minimale.

• Faites du mot de passe 25 caractères ou plus générés aléatoirement, et ne l’écrivez nulle part ailleurs que dans un outil de gestion de mots de passe (runbooks, scripts, Excel partagé)
• Faites-en un compte dédié au service et scindez-le par service (ne le partagez pas avec un compte humain²)
• Refusez l’ouverture de session interactive et le Bureau à distance, et n’autorisez que « Ouvrir une session en tant que service »
• Minimisez les groupes auxquels il appartient (l’ajouter à Domain Admins est hors de question)
• Établissez une procédure de rotation périodique et mettez les endroits qu’un changement affectera dans un registre

Faire tout cela est moins sûr et moins facile que de migrer vers un gMSA — c’est le chapitre suivant.

8. gMSA — laisser la gestion du mot de passe à Active Directory

8.1. Le mécanisme et l’effet

Un gMSA (compte de service administré de groupe) est un compte de domaine qui laisse la gestion du mot de passe au contrôleur de domaine. Le mot de passe est calculé par le contrôleur de domaine à partir de la clé racine KDS (Key Distribution Service), et seuls les hôtes autorisés l’obtiennent.¹³

flowchart TB
    accTitle: Comment un gMSA gère le mot de passe
    accDescr: Le contrôleur de domaine calcule le mot de passe à partir de la clé racine KDS, seuls les hôtes autorisés l'obtiennent et l'utilisent pour faire tourner le service, et le mot de passe est renouvelé automatiquement tous les 30 jours par défaut
    kds["Clé racine KDS"] --> dc["Le DC calcule le mot de passe"]
    dc --> host["Un hôte autorisé l'obtient"]
    host --> svc["Utilisé pour faire tourner le service"]
    dc -.-> rot["Rotation automatique tous les 30 jours par défaut"]

Figure 14 : Le contrôleur de domaine prend en charge la génération, la distribution et la mise à jour du mot de passe, et les humains peuvent opérer sans connaître le mot de passe.

Les effets sont clairs.⁹

• Un mot de passe de 240 octets généré aléatoirement : brute-force et attaques par dictionnaire deviennent irréalistes, et la résistance au Kerberoasting monte substantiellement
• Rotation automatique tous les 30 jours par défaut : un humain n’a pas besoin de planifier un changement, et le service n’a pas besoin d’être arrêté
• La même identité peut être partagée sur plusieurs serveurs : une ferme de serveurs sous équilibrage de charge peut s’authentifier mutuellement comme le même principal
• Gestion des SPN plus simple : l’inscription et la gestion des SPN peuvent aussi être déléguées et simplifiées

Les humains peuvent opérer sans connaître le mot de passe — si on le prend comme le mécanisme qui fait pour un compte de service ce que Windows LAPS fait pour un mot de passe d’administrateur local, le placement est plus facile à saisir.

8.2. Exigences

Un gMSA a des prérequis.¹⁰

• Un environnement de domaine Active Directory (impossible dans un groupe de travail)
• Niveaux fonctionnels de domaine et de forêt Windows Server 2012 ou supérieur
• Une clé racine KDS a déjà été créée
• Le nom du gMSA est unique dans la forêt, pas seulement dans le domaine
• L’intervalle de changement de mot de passe ne peut être défini qu’à la création

Créer la clé racine KDS est une tâche unique, mais pendant jusqu’à 10 heures après la création on ne peut pas créer de gMSA, parce qu’on attend la réplication vers chaque contrôleur de domaine. C’est un dispositif de sécurité pour empêcher l’accident d’un échec de récupération du mot de passe avant que la réplication soit terminée.¹⁴

flowchart TB
    accTitle: De la création de la clé racine KDS à la création d'un gMSA
    accDescr: Après la création de la clé racine KDS on attend la réplication vers chaque contrôleur de domaine, donc pendant jusqu'à 10 heures on ne peut pas créer de gMSA ; après la fin de la réplication on peut en créer un
    add["Créer la clé racine KDS"] --> wait["Jusqu'à 10 heures d'attente de réplication"]
    wait -.-> why["Un dispositif de sécurité pour empêcher un accident d'échec de récupération"]
    wait --> done["La réplication vers chaque DC est terminée"]
    done --> ok["On peut créer un gMSA"]

Figure 15 : L’attente jusqu’à 10 heures après la création de la clé racine est un temps d’attente pour empêcher un échec de récupération tant que la réplication n’est pas finie.

# Run as a domain administrator, on a domain controller (or an administrative
# workstation with the AD PowerShell module)

# Confirm whether a KDS root key exists, and create one if not (once per forest)
Get-KdsRootKey
Add-KdsRootKey -EffectiveImmediately   # Actually usable after up to 10 hours

8.3. La procédure de la création à la configuration

La procédure est en quatre étapes : « ① créer un groupe autorisé à récupérer → ② créer le gMSA → ③ l’installer sur les serveurs → ④ le définir sur le service ».¹⁰

flowchart TB
    accTitle: Les quatre étapes d'introduction d'un gMSA
    accDescr: L'introduire en quatre étapes : créer un groupe autorisé à récupérer le mot de passe, créer le gMSA, l'installer sur chaque serveur, et le définir comme compte d'ouverture de session du service
    st1["① Créer un groupe autorisé à récupérer"] --> st2["② Créer le gMSA"]
    st1 -.-> add["Ajouter les PC$ des serveurs"]
    st2 --> st3["③ Installer sur chaque serveur"]
    st3 -.-> test["Valider la récupération avec la commande Test"]
    st3 --> st4["④ Le définir sur le service"]

Figure 16 : De la création du groupe à la définition du service, l’introduction d’un gMSA avance en quatre étapes.

# ① Create a security group permitted to retrieve the password,
#    and add the computer accounts of the servers that will run the service
New-ADGroup -Name "GG-SvcBatchHosts" -GroupScope Global
Add-ADGroupMember -Identity "GG-SvcBatchHosts" -Members "APPSV01$", "APPSV02$"
# Group membership is evaluated at computer logon, so
# restarting the target servers after adding is the reliable approach

# ② Create the gMSA
New-ADServiceAccount -Name "svc-batch" `
    -DNSHostName "svc-batch.corp.example.com" `
    -PrincipalsAllowedToRetrieveManagedPassword "GG-SvcBatchHosts"

# ③ On each server that will run the service, install the gMSA and validate
Install-ADServiceAccount -Identity "svc-batch"
Test-ADServiceAccount -Identity "svc-batch"   # True means retrieval is working

# ④ Set it as the service's logon account. Append $ to the name, and do not specify a password
sc.exe config MyBatchService obj= "CORP\svc-batch$"
Restart-Service MyBatchService

Lors de la définition depuis services.msc aussi, le nom de compte est du type CORP\svc-batch$ — ajoutez $ à la fin, et laissez les champs mot de passe vides. Un compte de la famille MSA ne peut pas être utilisé pour une ouverture de session interactive.¹ Ensuite, accordez CORP\svc-batch$ sur l’ACL d’un dossier partagé ou de SQL Server à la place de PC$, et l’accès réseau avec une identité propre au service est complet, sans mot de passe.

8.4. Certaines applications ne le prennent pas en charge

En garde, tout logiciel ne tournera pas sous un gMSA. Les choses qui configurent l’identité d’ouverture de session par un mécanisme standard — un service Windows, un pool d’applications IIS, une tâche du Planificateur de tâches — sont largement prises en charge, mais il y a des contraintes telles que le clustering de basculement lui-même ne prenant pas en charge un gMSA, et une application dont l’intérieur exige un mot de passe ne peut pas l’utiliser.¹⁰ Microsoft indique aussi clairement qu’il faut confirmer le comportement en tant que gMSA dans un environnement de test avant la production.⁹

flowchart TB
    accTitle: Distinguer si quelque chose prend en charge un gMSA
    accDescr: Une application qui configure l'identité d'ouverture de session par un mécanisme standard prend largement en charge un gMSA, mais le clustering de basculement et une application dont l'intérieur exige un mot de passe ne peuvent pas l'utiliser, donc confirmez dans un environnement de test avant la production
    app["L'application cible"] --> how{"Comment l'ouverture de session est-elle définie ?"}
    how -->|Mécanisme standard| okapp["gMSA pris en charge"]
    okapp -.-> ex1["Service, IIS, une tâche"]
    how -->|Mot de passe exigé| ngapp["gMSA impossible"]
    ngapp -.-> ex2["Clustering de basculement"]
    okapp --> test["Tester avant la production"]

Figure 17 : Une application qui configure l’ouverture de session par un mécanisme standard est largement prise en charge, mais certaines conceptions ne le sont pas, donc une validation avant la production est indispensable.

Il y a aussi des frères : le sMSA (compte de service administré autonome) pour un seul serveur, et le dMSA (compte de service administré délégué, introduit dans Windows Server 2025, qui se lie à l’identité de l’appareil pour contrer le vol d’informations d’identification). Pour une construction nouvelle, prenez un gMSA comme base et considérez selon les exigences.⁶

9. Conception d’accompagnement — droits d’ouverture de session, profil, DPAPI et audit

Quatre autres choses qui changent avec le compte, à retenir.

9.1. Le droit « Ouvrir une session en tant que service » (SeServiceLogonRight)

Pour démarrer en tant que service, le compte a besoin du droit utilisateur « Ouvrir une session en tant que service ». LocalSystem, LocalService et NetworkService l’ont intégré, mais tout autre compte (un utilisateur de domaine, un gMSA, etc.) a besoin d’une assignation explicite.¹⁵

Si vous le définissez depuis l’onglet « Connexion » de l’interface services.msc, le composant logiciel enfichable accorde ce droit automatiquement. En revanche, CreateService / ChangeServiceConfig (les API que sc.exe config appelle) ne vérifient pas que le compte spécifié a ce droit. La cause typique d’un service configuré par un script qui s’arrête au démarrage avec « le service n’a pas pu démarrer en raison d’un échec d’ouverture de session » est celle-ci. Ne vous fiez pas à un effet de bord d’un outil ; incluez dans la procédure de déploiement, explicitement, l’ajout à « Ouvrir une session en tant que service » dans la Stratégie de sécurité locale (secpol.msc), ou une configuration via GPO/Intune (dans un environnement qui configure ce droit avec une stratégie de groupe, un octroi local est écrasé quand la stratégie s’applique, donc cela aussi demande de l’attention). Inversement, le geste standard pour un compte dédié au service est de définir « Refuser l’ouverture de session locale » en même temps.

flowchart TB
    accTitle: La différence selon le chemin de configuration du droit Ouvrir une session en tant que service
    accDescr: L'interface services.msc accorde le droit automatiquement, mais l'API que sc.exe config appelle ne vérifie pas le droit, donc un compte sans le droit arrête le service avec un échec d'ouverture de session au démarrage
    gui["Définir dans services.msc"] --> auto["Le droit est accordé automatiquement"]
    auto --> okgui["Le service peut démarrer"]
    cli["Définir avec sc.exe config"] --> noval["Le droit n'est pas vérifié"]
    noval --> has{"A-t-il le droit ?"}
    has -->|Oui| okcli["Le service peut démarrer"]
    has -->|Non| stop["S'arrête avec un échec d'ouverture de session"]
    stop -.-> fix["Accorder explicitement avec secpol.msc ou une GPO"]

Figure 18 : L’interface accorde le droit automatiquement, mais une configuration par script ne le vérifie pas, donc il faut inclure un octroi explicite dans la procédure.

9.2. Le profil, %TEMP% et HKEY_CURRENT_USER changent

Le SCM charge le profil utilisateur de ce compte au démarrage du service.⁷ Donc les vrais %TEMP%, %APPDATA% et HKEY_CURRENT_USER sont une chose différente par compte d’ouverture de session, et quand on change de compte, les paramètres et caches enregistrés dans le profil de l’ancien compte ont l’air d’« avoir disparu ».

La réponse de conception est simple : mettez les données du service non pas sous le profil mais sur un chemin explicite tel que C:\ProgramData\<nom-d-application>, et accordez cette ACL au compte d’ouverture de session. Ainsi un changement de compte n’entraîne pas une migration de données.

flowchart TB
    accTitle: Dépendance au profil et réponse de placement des données
    accDescr: Le vrai profil est une chose différente par compte d'ouverture de session, donc changer de compte fait paraître les données de l'ancien profil comme disparues, mais les placer sur un chemin explicite et accorder l'ACL rend la migration inutile
    sw["Changer le compte d'ouverture de session"] --> newprof["Un profil différent est chargé"]
    newprof --> lost["Les anciennes données ont l'air d'avoir disparu"]
    lost -.->|Réponse| fix["Les placer sous ProgramData"]
    fix --> acl["Accorder l'ACL au compte d'ouverture de session"]
    acl --> nomig["Pas de migration même quand le compte change"]

Figure 19 : Évitez le profil et mettez les données sur un chemin explicite, et un changement de compte n’entraîne plus de migration de données.

9.3. Les données protégées avec DPAPI sont liées au compte

Plus facile encore à manquer est DPAPI. Les données chiffrées avec DPAPI de portée utilisateur (CryptProtectData ou ProtectedData de .NET) ne peuvent, en principe, être déchiffrées que par le même compte qui les a protégées. Au moment où vous changez le compte, une chaîne de connexion ou une clé d’API stockée ne peut plus être lue — c’est DPAPI qui fait correctement son travail, mais si ce n’est pas dans la procédure de migration cela devient un incident.

flowchart TB
    accTitle: La relation entre les données protégées par DPAPI et un changement de compte
    accDescr: Les données protégées avec DPAPI de portée utilisateur ne peuvent être déchiffrées que par le même compte qui les a protégées, donc après avoir changé le compte d'ouverture de session il faut ressaisir les secrets
    protect["Protéger par DPAPI avec l'ancien compte"] --> data["Une chaîne de connexion protégée et assimilés"]
    data --> who{"Quel compte déchiffre ?"}
    who -->|Le même ancien compte| okdec["Peut déchiffrer"]
    who -->|Le nouveau compte| ngdec["Ne peut pas déchiffrer"]
    ngdec --> re["Ressaisir les secrets"]

Figure 20 : Les données protégées par DPAPI sont liées au compte qui les a protégées, et après un changement de compte il faut ressaisir.

La réponse est d’inclure dans le plan de migration la procédure « ressaisir les secrets après le changement de compte » (pour la conception de l’endroit où les stocker, voir « Stocker les secrets des applications Windows »). Aussi, une configuration qui peut se terminer avec l’authentification intégrée Windows en tant que gMSA ou PC$ peut éliminer le stockage du secret lui-même. L’ordre correct est de considérer « peut-on s’en passer » avant « où le stocke-t-on ».

Et si le service veut traiter « avec les privilèges de l’utilisateur appelant », on utilise l’emprunt d’identité plutôt que de rendre le compte plus fort. Pour cela, voir « Bien gérer les jetons d’emprunt d’identité Windows ».

9.4. Audit — regarder 4624 type d’ouverture de session 5

Un démarrage de service est enregistré dans le journal des événements de sécurité comme ID d’événement 4624 (Un compte a ouvert une session) avec le type d’ouverture de session 5 (Service : le SCM a démarré un service). Le champ « Virtual Account » de l’événement indique si l’ouverture de session était par un MSA / compte virtuel, donc on peut aussi l’utiliser pour surveiller l’usage des comptes administrés.¹¹

flowchart TB
    accTitle: Le flux d'audit d'un démarrage de service
    accDescr: Le SCM qui démarre un service est enregistré comme ID d'événement 4624 type d'ouverture de session 5, et le champ Virtual Account peut identifier si l'ouverture de session était par un compte administré
    start["Le SCM démarre un service"] --> ev["Enregistrer l'ID d'événement 4624"]
    ev --> type5["Type d'ouverture de session 5 (Service)"]
    type5 --> vafield["Champ Virtual Account"]
    vafield --> watch["Surveillance des comptes administrés"]

Figure 21 : Un démarrage de service est enregistré comme un 4624 de type d’ouverture de session 5, et on peut même suivre l’usage des comptes administrés.

Pour un inventaire de l’état actuel, agréger les comptes d’ouverture de session de la liste des services est la méthode rapide.

# Aggregate which services are running as which account
Get-CimInstance Win32_Service |
    Group-Object StartName |
    Sort-Object Count -Descending |
    Select-Object Count, Name

# Inventory non-standard services running as LocalSystem (tell in-house / third-party by the path)
Get-CimInstance Win32_Service |
    Where-Object { $_.StartName -eq 'LocalSystem' -and $_.PathName -notlike '*\Windows\*' } |
    Select-Object Name, DisplayName, PathName

Si cette sortie aligne « un service métier qui tourne sous LocalSystem » et « un service qui tourne sous un utilisateur de domaine », le flux de décision du chapitre suivant est appelé.

10. Flux de décision — décider avec quatre questions

Voici le contenu jusqu’ici, comme procédure de sélection. Répondez à quatre questions dans l’ordre.

flowchart TB
    accTitle: Le flux de décision pour le compte d'ouverture de session
    accDescr: Décider le compte d'ouverture de session en répondant dans l'ordre aux quatre questions de l'accès réseau, de l'adhésion au domaine, de la suffisance d'une identité de niveau machine, et de la prise en charge d'un gMSA
    q1{"Auth Windows vers un pair ?"} -->|Non| va["Compte virtuel"]
    va -.-> sys["LocalSystem si besoin"]
    q1 -->|Oui| q2{"Joint au domaine ?"}
    q2 -->|Non| cred["Protéger les infos stockées"]
    q2 -->|Oui| q3{"Niveau machine suffisant ?"}
    q3 -->|Oui| pcacl["Compte virtuel + PC$"]
    q3 -->|Non| q4{"L'appli prend en charge un gMSA ?"}
    q4 -->|Oui| gmsa["gMSA"]
    q4 -->|Non| du["Utilisateur + atténuations"]

Figure 22 : Répondez aux quatre questions dans l’ordre et lequel des six choix vous devez utiliser est décidé.

Question 1 : Ce service accède-t-il à une autre machine sur le réseau (un dossier partagé, une BD, une API, etc.) avec l’authentification Windows ?

Sinon, un compte virtuel est le défaut. Seulement si un privilège local spécial est nécessaire, confirmez ce besoin puis envisagez LocalSystem.

Question 2 : (S’il accède) La machine est-elle jointe au domaine ?

Dans un groupe de travail, ni PC$ ni un gMSA ne peuvent être utilisés. Utilisez une conception qui traite explicitement les informations d’identification du compte de destination (protégez le stockage avec DPAPI ou assimilé), ou envisagez de joindre le domaine.

Question 3 : (Dans un domaine) Une identité de niveau machine (PC$) suffit-elle ?

Si oui, un compte virtuel (ou NetworkService) + accorder PC$ sur l’ACL de destination est complet. Si vous avez besoin d’une identité propre au service, ou d’une identité commune sur plusieurs serveurs, passez à la question 4.

Question 4 : L’application prend-elle en charge un gMSA ?

Si oui (les choses qui configurent l’ouverture de session par un mécanisme standard — SCM, un pool d’applications IIS, le Planificateur de tâches — le font généralement), un gMSA. N’oubliez pas une vérification de comportement dans un environnement de validation. Si c’est non pris en charge quoi qu’il arrive, utilisez un utilisateur de domaine dédié après avoir appliqué chaque atténuation de la section 7.3.

En table c’est comme suit.

11. Résumé

• Le compte d’ouverture de session d’un service est une décision de conception qui décide à la fois des privilèges locaux, de l’identité réseau et de la gestion du mot de passe. Ne le laissez pas au défaut (LocalSystem).
• LocalSystem détient un jeton SYSTEM+Administrators et des privilèges forts, et les dégâts en cas de prise de contrôle sont maximisés. La plupart des services métier n’ont pas besoin de ce privilège.
• LocalService et NetworkService sont tous deux à faible privilège ; la différence est l’identité réseau (anonyme, ou le compte ordinateur). Parce que le compte est partagé par plusieurs services, toutefois, on ne peut pas les séparer.
• Un compte virtuel (NT SERVICE\) est le défaut moderne qui peut séparer par service tout en n'ayant pas besoin de gestion de mot de passe. On peut l'indiquer directement sur une ACL, et la configuration n'est que de changer le nom du compte d'ouverture de session.
• LocalSystem, NetworkService et un compte virtuel sortent sur le réseau comme DOMAIN\PC$ dans un environnement de domaine. Accorder PC$ sur l’ACL d’un dossier partagé ou de SQL Server permet souvent de se passer d’un utilisateur de domaine.
• Utiliser un utilisateur de domaine pour un service a les problèmes structurels d’un arrêt par expiration, de la diffusion d’un mot de passe en clair, et du Kerberoasting. Si vous en utilisez un, un compte dédié + un long mot de passe aléatoire + des restrictions d’ouverture de session sont requis.
• Un gMSA est un mécanisme dans lequel AD génère et fait tourner le mot de passe automatiquement ; les exigences sont un domaine, un niveau fonctionnel 2012 ou supérieur, et une clé racine KDS. Configurez le service en « DOMAIN\nom$ » avec le champ mot de passe vide.
• Quand vous changez le compte, incluez le droit « Ouvrir une session en tant que service », le déplacement du profil et de %TEMP%, et la resaisie des données protégées par DPAPI dans la procédure de migration. L’audit se confirme avec l’ID d’événement 4624 type d’ouverture de session 5.

La prochaine fois que vous installez un service, arrêtez-vous un instant sur l’écran des paramètres d’ouverture de session et reposez cette question. En tant que qui, et jusqu’où, ce service devrait-il pouvoir accéder ? La réponse devrait être une ligne de la table de décision de cet article.

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’ouverture de session et le durcissement 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/é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, nous recommandons un compte virtuel. 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 on ne peut pas séparer avec une ACL qui « n'autorise que ce service ». Un compte virtuel a une identité propre à chaque service, et on peut indiquer NT SERVICE\nom-du-service directement sur 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 un contrôleur de domaine Active Directory génère et gère 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 un 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'ouverture de session du service, je ne peux plus lire les paramètres et informations d'identification enregistrés. Pourquoi ?

Parce que chaque compte d'ouverture de session 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 (saisie à nouveau 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.