Créer des comptes locaux et des politiques de mot de passe avec PowerShell

Ce que vous gérez réellement (et pourquoi ça continue de vous mordre)

Un « compte local » semble simple : un nom d’utilisateur et un mot de passe stockés sur une machine Windows. Mais opérationnellement,
vous gérez trois systèmes qui se chevauchent :

• L’objet du compte (activé/désactivé, état du mot de passe, appartenance aux groupes, profil, droits).
• La surface de politique d’authentification (longueur du mot de passe, complexité, seuil de verrouillage, expiration).
• Le périmètre d’impact (où ce credential fonctionne et ce qu’il peut faire).

Les comptes locaux sont un risque de fiabilité parce qu’ils sont collants. Ils survivent aux projets.
Ils résistent aux migrations. Ils n’apparaissent pas dans votre tableau de bord IAM central. Et quand vous avez plus d’une poignée
de serveurs, « on pensera à faire tourner ce mot de passe » devient une histoire du soir que vous racontez aux auditeurs.

Le travail n’est pas « créer un utilisateur ». Le travail est : créer un utilisateur prévisible, détectable, gouverné et réversible.
Prévisible signifie nommage cohérent, appartenance aux groupes cohérente, règles de mot de passe cohérentes. Détectable signifie
que vous pouvez l’inventorier et expliquer pourquoi il existe. Gouverné signifie que les politiques sont appliquées (ou au moins mesurées). Réversible
signifie que vous pouvez le désactiver proprement sans casser le serveur.

Si vous pensez « c’est exagéré pour les comptes locaux », félicitations : vous n’avez jamais dû répondre à une enquête de mouvement latéral
où le credential préféré de l’attaquant était un mot de passe d’admin local partagé sur 700 machines.

Faits et contexte historique utiles pour les discussions

Les ingénieurs aiment les faits qu’ils peuvent déployer en réunion. En voici quelques-uns qui comptent quand la salle commence à débattre de « juste un compte local ».

1. Windows a des comptes locaux depuis NT — et beaucoup de paramètres de sécurité par défaut ont été conçus quand les réseaux étaient plus petits et plus plats.
   L’héritage façonne encore le comportement actuel.
2. Le snap-in MMC « Local Users and Groups » n’a pas toujours existé sur tous les SKUs (notamment absent sur certaines éditions), c’est pourquoi
   les scripts et net.exe sont devenus la lingua franca de l’automatisation admin.
3. La politique de mot de passe n’est pas par utilisateur par défaut. Sur les machines autonomes, c’est principalement une politique au niveau machine ; sur les systèmes joints au domaine,
   la politique de domaine l’emporte normalement, sauf si des politiques fines ou des dérogations locales sont en place.
4. Le module LocalAccounts de PowerShell (cmdlets comme New-LocalUser) est arrivé relativement tard par rapport à l’âge de l’administration Windows.
   Les anciens scripts utilisent ADSI ou net user parce qu’ils le devaient.
5. La politique de verrouillage de compte est un levier de fiabilité, pas seulement un levier de sécurité. Trop stricte et vous vous faites un DoS avec des services maladroits ;
   trop laxiste et la force brute devient un hobby.
6. « Password never expires » n’est pas juste une case à cocher ; c’est une déclaration que vous acceptez une durée de vie illimitée des credentials.
   Cela nécessite des contrôles compensatoires (système de rotation, LAPS, checkout de vault, etc.).
7. L’appartenance aux groupes est le véritable modèle d’autorisation pour la plupart des admins. L’objet utilisateur est ennuyeux ; ce sont les groupes qui font le feu.
8. Windows maintient plusieurs sources de vérité pour les paramètres de sécurité (politique de sécurité locale, politique basée sur le registre, politique de domaine, traitement GPO).
   Votre script peut « définir » quelque chose et quand même perdre lors du prochain rafraîchissement.
9. Les comptes intégrés se comportent différemment. « Administrator » et « Guest » ont un traitement spécial et un bagage historique ; renommer ne supprime pas l’identité.

Outils principaux : LocalAccounts, ADSI, net.exe, secedit

Il y a quatre manières pratiques de gérer les comptes locaux et la politique de mot de passe dans l’automatisation Windows. Vous utiliserez chacune d’elles
selon la version OS, les contraintes de remoting et le niveau d’accès dont vous avez besoin.

1) Module LocalAccounts de PowerShell

Des cmdlets comme Get-LocalUser, New-LocalUser, Add-LocalGroupMember sont lisibles et relativement sûres.
Elles sont excellentes pour les builds modernes de Windows Server et Windows 10/11. Elles rendent aussi les erreurs compréhensibles.

2) ADSI (fournisseur WinNT)

Vieux mais fiable. Fonctionne quand LocalAccounts n’est pas disponible. Utile aussi lorsque vous avez besoin de compatibilité dans des flottes mixtes.
Inconvénient : moins convivial ; vous pouvez vous faire mal avec des one-liners sans le remarquer avant que la production ne commence à boiter.

3) net.exe (net user, net localgroup, net accounts)

L’outil de survie des cafards : il est là, il fonctionne, et il est pris en charge à peu près partout.
Il est aussi basé sur du texte, ce qui rend l’analyse des sorties parfois pénible. Pourtant : pour l’inspection des politiques et les vérifications rapides,
il est brutalement efficace.

4) secedit (export/import de la politique de sécurité locale)

Quand vous devez voir ou appliquer des options de sécurité au niveau machine en masse, secedit peut exporter la politique dans un fichier de type INF.
Vous pouvez versionner ce fichier, le diff, et l’appliquer. Ce n’est pas joli, mais c’est honnête.

Une idée paraphrasée qui a guidé les opérations pendant des décennies : L’espoir n’est pas une stratégie — Ed Yourdon.
Les comptes locaux sont l’endroit où l’espoir vient prendre sa retraite. Traitez-les comme n’importe quelle autre surface de production.

Principes d’opérateur : décider d’abord, puis script

Les scripts qui gèrent des utilisateurs échouent pour des raisons ennuyeuses : le compte existe déjà, la machine est jointe au domaine, la politique de mot de passe
est imposée par GPO, WinRM est à moitié configuré, ou l’opérateur n’a pas d’admin local. Donc ne commencez pas par écrire du code. Commencez par décider :

• Intention : Pourquoi ce compte local existe-t-il ? Break-glass humain ? Service applicatif ? Support fournisseur ?
• Périmètre : Quelles machines ? Quelle OU ? Quels environnements ?
• Autorité : Qui possède le cycle de vie du credential ? Un coffre ? Une équipe ? Un service plateforme ?
• Contrôles : Expiration, verrouillage, audit, restrictions d’appartenance, interdire la connexion interactive quand c’est possible.
• Réversibilité : Quelle est la procédure de désactivation ? Quels alertes se déclenchent si elle disparaît ?

Et oui, vous pouvez tout automatiser. Le piège est d’automatiser les mauvaises hypothèses plus vite.

Blague #1 : Si votre « admin local temporaire » est plus vieux que votre machine à café, ce n’est pas temporaire — c’est un fossile avec des privilèges.

Tâches pratiques (commandes, sorties, décisions)

La façon la plus rapide de devenir bon est d’effectuer des opérations réelles et vérifiables et de lier chaque sortie à une décision.
Ci-dessous des tâches que vous exécuterez réellement en production. Les commandes sont montrées comme si elles étaient lancées depuis un shell sur une hôte.
Adaptez les noms d’hôte et les chemins à votre environnement.

Task 1: Confirm the OS and build (because cmdlet availability is not a vibe)

cr0x@server:~$ powershell -NoProfile -Command "Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber"
WindowsProductName WindowsVersion OsBuildNumber
----------------- -------------- -------------
Windows Server 2022 Datacenter 21H2           20348

Ce que cela signifie : Vous êtes sur une build serveur moderne ; le module LocalAccounts est généralement présent.
Décision : Préférez Get-LocalUser/New-LocalUser plutôt qu’ADSI/net parsing.

Task 2: Check whether the LocalAccounts module is available

cr0x@server:~$ powershell -NoProfile -Command "Get-Module -ListAvailable Microsoft.PowerShell.LocalAccounts | Select-Object Name, Version"
Name                               Version
----                               -------
Microsoft.PowerShell.LocalAccounts 1.0.0.0

Ce que cela signifie : Les cmdlets existent localement.
Décision : Utilisez-les pour les opérations CRUD des comptes ; retombez sur ADSI seulement pour les cas limites.

Task 3: Inventory existing local users and their password flags

cr0x@server:~$ powershell -NoProfile -Command "Get-LocalUser | Select-Object Name, Enabled, PasswordRequired, PasswordExpires, LastLogon | Format-Table -Auto"
Name               Enabled PasswordRequired PasswordExpires LastLogon
----               ------- ---------------- -------------- ---------
Administrator      False   True             False
DefaultAccount     False   False            False
Guest              False   False            False
svc_backup         True    True             True           1/21/2026 3:12:09 AM
vendor_support     True    True             False          12/11/2025 10:44:18 AM

Ce que cela signifie : Vous avez au moins deux comptes non intégrés ; l’un n’expire pas.
Décision : Décidez si vendor_support doit être limité dans le temps ou désactivé quand il n’est pas utilisé. « Never expires » nécessite un contrôle compensatoire.

Task 4: Create a new local user safely (no plaintext password in your history)

cr0x@server:~$ powershell -NoProfile -Command "$pw=Read-Host -AsSecureString 'Enter password'; New-LocalUser -Name 'svc_app' -Password $pw -Description 'App service account' -PasswordNeverExpires:$false -UserMayNotChangePassword:$true"
Enter password: ********

Ce que cela signifie : Le compte est créé ; le mot de passe est capturé en tant que SecureString.
Décision : Affectez immédiatement l’appartenance aux groupes et les droits ; ne laissez pas un compte de service sans permissions minimales.

Task 5: Verify the account properties you actually care about

cr0x@server:~$ powershell -NoProfile -Command "Get-LocalUser -Name 'svc_app' | Select-Object Name, Enabled, UserMayChangePassword, PasswordExpires, PasswordLastSet | Format-List"
Name                  : svc_app
Enabled               : True
UserMayChangePassword : False
PasswordExpires       : True
PasswordLastSet       : 2/5/2026 1:03:27 PM

Ce que cela signifie : Ce compte ne peut pas changer son propre mot de passe, et l’expiration est activée.
Décision : Placez la rotation des mots de passe sous un mécanisme contrôlé (coffre + rotation planifiée, ou solution de gestion locale), pas « quelqu’un s’en souviendra ».

Task 6: Add the account to a local group (and verify)

cr0x@server:~$ powershell -NoProfile -Command "Add-LocalGroupMember -Group 'Users' -Member 'svc_app'; Get-LocalGroupMember -Group 'Users' | Select-Object Name | Sort-Object Name | Select-Object -First 10"
Name
----
BUILTIN\Administrator
NT AUTHORITY\INTERACTIVE
NT AUTHORITY\Authenticated Users
SERVER01\svc_app

Ce que cela signifie : Le compte est un utilisateur standard, pas un admin.
Décision : Gardez-le ainsi à moins de pouvoir prouver que l’application a besoin des droits d’admin. « A besoin d’admin » est souvent synonyme de « personne n’a testé les permissions ».

Task 7: Audit local Administrators membership (the group that ruins your week)

cr0x@server:~$ powershell -NoProfile -Command "Get-LocalGroupMember -Group 'Administrators' | Select-Object ObjectClass, Name, PrincipalSource | Format-Table -Auto"
ObjectClass Name                          PrincipalSource
----------- ----                          ---------------
User        SERVER01\Administrator         Local
Group       CONTOSO\Domain Admins          ActiveDirectory
User        SERVER01\vendor_support        Local

Ce que cela signifie : Un utilisateur fournisseur local est administrateur local. C’est, par définition, un credential à haut risque.
Décision : Si l’accès fournisseur est nécessaire, passez à un accès limité dans le temps (activation/désactivation à la demande), faites tourner le mot de passe après usage, ou retirez-le des Administrators.

Task 8: Disable an account without deleting it (reversibility is a feature)

cr0x@server:~$ powershell -NoProfile -Command "Disable-LocalUser -Name 'vendor_support'; Get-LocalUser -Name 'vendor_support' | Select-Object Name, Enabled"
Name           Enabled
----           -------
vendor_support False

Ce que cela signifie : La connexion est bloquée, mais le compte et le SID restent.
Décision : Préférez désactiver plutôt que supprimer quand vous n’êtes pas sûr des dépendances ; la suppression peut orpheliner des ACL et casser silencieusement des tâches planifiées.

Task 9: Find where an account is referenced (scheduled tasks are repeat offenders)

cr0x@server:~$ powershell -NoProfile -Command "Get-ScheduledTask | Where-Object {$_.Principal.UserId -match 'svc_app|vendor_support'} | Select-Object TaskName, State, @{n='UserId';e={$_.Principal.UserId}} | Format-Table -Auto"
TaskName           State  UserId
--------           -----  ------
NightlyBackup      Ready  SERVER01\svc_app

Ce que cela signifie : svc_app est utilisé par une tâche planifiée ; le désactiver casserait ce job.
Décision : Traitez le compte comme faisant partie d’un graphe de dépendances applicatives. Faites la rotation avec précaution ; testez l’exécution des tâches après les changements.

Task 10: Inspect effective password and lockout policy quickly (net accounts)

cr0x@server:~$ powershell -NoProfile -Command "net accounts"
Force user logoff how long after time expires?:       Never
Minimum password age (days):                          1
Maximum password age (days):                          60
Minimum password length:                              14
Length of password history maintained:                24
Lockout threshold:                                    5
Lockout duration (minutes):                           15
Lockout observation window (minutes):                 15
Computer role:                                        WORKSTATION
The command completed successfully.

Ce que cela signifie : Cette machine exige des mots de passe de 14 caractères, expiration à 60 jours, verrouillage après 5 échecs.
Décision : Les comptes de service avec risque de connexion interactive doivent être restreints ; s’ils doivent exister, assurez-vous de ne pas déclencher des verrouillages avec des credentials obsolètes.

Task 11: Change password policy settings (where allowed) with net accounts

cr0x@server:~$ powershell -NoProfile -Command "net accounts /minpwlen:16 /maxpwage:45 /uniquepw:24 /lockoutthreshold:5 /lockoutduration:15 /lockoutwindow:15"
The command completed successfully.

Ce que cela signifie : La politique locale est mise à jour — sauf si un GPO la remplace.
Décision : Sur les machines jointes au domaine, traitez cela comme un outil de diagnostic, pas comme un mécanisme d’application de politique. Si un GPO l’écrase, votre « changement » s’évaporera.

Task 12: Verify domain join status (policy source matters)

cr0x@server:~$ powershell -NoProfile -Command "(Get-CimInstance Win32_ComputerSystem).PartOfDomain"
True

Ce que cela signifie : Les politiques de domaine s’appliquent probablement.
Décision : Ne supposez pas que les commandes de politique locales resteront ; vérifiez la politique résultante et la priorité des GPO.

Task 13: Export local security policy to a file for diffing

cr0x@server:~$ powershell -NoProfile -Command "secedit /export /cfg C:\Windows\Temp\secpol.cfg /areas SECURITYPOLICY"
The task has completed successfully.
See log %windir%\security\logs\scesrv.log for detail information.

Ce que cela signifie : Vous avez maintenant une représentation textuelle de nombreux paramètres de sécurité locaux.
Décision : Différenciez ce fichier entre serveurs pour trouver la dérive de configuration. La dérive est souvent le vrai bug.

Task 14: Extract password policy values from the exported config

cr0x@server:~$ powershell -NoProfile -Command "Select-String -Path C:\Windows\Temp\secpol.cfg -Pattern 'MinimumPasswordLength|MaximumPasswordAge|PasswordComplexity|LockoutBadCount' | ForEach-Object {$_.Line}"
MinimumPasswordLength = 14
MaximumPasswordAge = 60
PasswordComplexity = 1
LockoutBadCount = 5

Ce que cela signifie : La complexité est activée (1), longueur min 14, âge max 60, verrouillage à 5.
Décision : Si des scanners se plaignent, vous pouvez prouver ce qui est configuré. Si les configs diffèrent entre nœuds d’un cluster, corrigez la cohérence d’abord.

Task 15: Set “Password never expires” for a specific local user (with a reason, not a shrug)

cr0x@server:~$ powershell -NoProfile -Command "Set-LocalUser -Name 'svc_backup' -PasswordNeverExpires $true; Get-LocalUser -Name 'svc_backup' | Select-Object Name, PasswordExpires"
Name       PasswordExpires
----       --------------
svc_backup False

Ce que cela signifie : Le compte n’expirera plus.
Décision : Ne faites ceci que si vous disposez d’une rotation fiable ailleurs (coffre géré, mise à jour planifiée + plan de redémarrage de service, ou solution gérée). Sinon vous échangez des pannes contre des compromissions.

Task 16: Find stale local users (last logon older than N days)

cr0x@server:~$ powershell -NoProfile -Command "$cutoff=(Get-Date).AddDays(-90); Get-LocalUser | Where-Object {$_.Enabled -and $_.LastLogon -and $_.LastLogon -lt $cutoff} | Select-Object Name, LastLogon | Sort-Object LastLogon"
Name           LastLogon
----           ---------
svc_legacy     10/2/2025 11:18:44 AM
vendor_support 11/3/2025 8:20:01 AM

Ce que cela signifie : Des comptes activés n’ont pas ouvert de session depuis 90 jours.
Décision : Candidats à la désactivation, mais vérifiez d’abord les tâches planifiées, services et configurations « run as ». Stale n’est pas toujours inutilisé — mais souvent.

Task 17: Check Windows services for “Log On As” dependencies

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_Service | Where-Object {$_.StartName -match 'svc_app|svc_backup'} | Select-Object Name, State, StartName | Format-Table -Auto"
Name           State   StartName
----           -----   ---------
AppWorker      Running .\svc_app
BackupAgent    Running .\svc_backup

Ce que cela signifie : Ces comptes sont liés à des services en cours d’exécution.
Décision : Tout changement de mot de passe nécessite une mise à jour coordonnée des credentials des services (et idéalement une fenêtre de redémarrage). Sinon, préparez-vous à un incident auto-infligé.

Task 18: Export local users inventory to CSV for centralized review

cr0x@server:~$ powershell -NoProfile -Command "Get-LocalUser | Select-Object Name, Enabled, PasswordExpires, PasswordLastSet, LastLogon, Description | Export-Csv -NoTypeInformation C:\Windows\Temp\local-users.csv; Get-Item C:\Windows\Temp\local-users.csv | Select-Object Name, Length"
Name            Length
----            ------
local-users.csv 924

Ce que cela signifie : Vous avez maintenant un petit artefact que vous pouvez ingérer dans votre pipeline d’inventaire.
Décision : Établissez une base « connue bonne » et alertez sur les changements. La dérive des comptes est un signal, pas du bruit de fond.

Réalité des politiques de mot de passe sous Windows (local vs domaine)

La politique de mot de passe est l’endroit où les bonnes intentions meurent doucement. Le détail clé : sur un hôte autonome,
la « politique de mot de passe » est en grande partie une politique au niveau machine appliquée aux comptes locaux. Sur un hôte joint au domaine,
la politique de domaine contrôle typiquement ce qui est appliqué, et les réglages locaux peuvent ne pas compter.

Ce que vous pouvez contrôler de manière fiable localement

• Existence et état des comptes locaux : créer, désactiver, renommer (avec précaution), définir la description, définir les flags.
• Appartenance aux groupes locaux : qui est dans Administrators, Remote Desktop Users, etc.
• Certaines options machine-level de mot de passe/verrouillage sur les serveurs autonomes ou lorsque le GPO le permet.
• Le flag d’expiration par utilisateur (PasswordNeverExpires) sur les comptes locaux.

Ce qui vous surprendra si vous ne testez pas

• Écrasement par GPO de domaine : vous définissez la longueur min à 16 localement, le GPO dit 14, et après rafraîchissement de la politique vous êtes de nouveau à 14.
  Votre script « a marché » et a quand même perdu.
• Application différente selon le type d’authentifiant : connexions de service, tâches planifiées, connexions RDP et accès SMB peuvent échouer différemment.
  Le compte existe, mais le contexte d’authentification change le mode d’échec.
• Verrouillages causés par des mots de passe en cache : vous faites la rotation d’un mot de passe, mais un service continue d’essayer l’ancien toutes les minutes et vous verrouille.

Blague #2 : Les politiques de mot de passe sont comme les parapluies — tout le monde admet qu’ils sont nécessaires jusqu’à ce qu’on leur demande d’en porter un sous la pluie.

Opinion tranchée : arrêtez de gérer manuellement les mots de passe d’admin local

Si votre environnement est assez grand pour justifier un script, il est assez grand pour justifier une gestion centralisée.
Pour les comptes admin locaux, vous voulez des mots de passe uniques par hôte et une rotation automatique. Les humains sont incohérents,
et les attaquants aiment la cohérence.

Si vous devez absolument avoir des admins locaux pour break-glass, utilisez un runbook opérationnel : checkout contrôlé, validité courte, rotation après usage,
et surveillance des changements d’appartenance. Le but n’est pas la « perfection ». Le but est « pas embarrassant ».

Trois micro-histoires d’entreprise tirées du terrain

Incident causé par une mauvaise hypothèse : « La politique locale s’applique partout »

Une équipe plateforme a déployé un job PowerShell pour « durcir » des machines Windows autonomes utilisées sur une ligne de production.
Le script définissait la longueur minimale du mot de passe et le seuil de verrouillage via net accounts. Il passait en vert. Tout le monde a passé à autre chose.

Un mois plus tard, une autre équipe a joint au domaine la moitié de ces machines pour activer le patching centralisé et l’inventaire.
Personne n’a informé l’équipe plateforme parce que le join était « juste une amélioration rapide ».

Ensuite la ligne a commencé à échouer d’une nouvelle manière : un compte de service stable depuis des années a commencé à se verrouiller.
Le service tournait sous un utilisateur local dont le mot de passe avait été tourné manuellement sur une machine puis copié « par commodité » sur les autres.
Sur les nœuds récemment joints, une politique de verrouillage de domaine plus stricte s’est appliquée. Le service a réessayé avec l’ancien mot de passe, s’est verrouillé,
et la ligne s’est arrêtée.

Le post-mortem avait une phrase qui comptait : ils ont supposé que la politique locale était autoritaire.
La correction tenait aussi en une phrase : détecter le statut de jointure au domaine, mesurer la politique résultante, et traiter la rotation des mots de passe comme un système, pas un rituel.

Optimisation qui s’est retournée contre eux : « Rotons tout la nuit »

Une initiative sécurité a exigé une rotation fréquente des mots de passe. L’équipe en charge a voulu aider, alors elle a construit un job de rotation nocturne.
Il mettait à jour les mots de passe locaux des comptes de service et essayait de « réparer » les services affectés en appliquant les nouveaux credentials et en les redémarrant.

Une semaine durant, tout semblait brillant. Les graphiques d’âge des mots de passe baissaient. Les tableaux de bord de conformité montaient. L’équipe a été invitée à plus de réunions,
ce qui n’est jamais vraiment une récompense mais souvent pris pour telle.

Puis est venu le Patch Tuesday. Plusieurs serveurs ont redémarré plus lentement que d’habitude, et le job de rotation a chevauché le démarrage des services.
Des services partiellement démarrés ont vu leurs credentials mis à jour au milieu de l’initialisation, puis redémarrés à nouveau. Certains services n’ont pas aimé être redémarrés pendant l’initialisation.
Quelques-uns sont passés en état d’échec et y sont restés. La supervision s’est illuminée comme un guirlande de fête.

Le retour de bâton n’était pas la rotation en elle-même ; c’était le couplage : changements de mots de passe et redémarrages se produisaient pendant une fenêtre de démarrage instable,
sans contrôles de santé spécifiques par application.
Ils ont corrigé le tir en ajoutant des fenêtres de maintenance, des validations propres aux services, et en rotant moins fréquemment mais de manière plus sûre.
La conformité a accepté le compromis parce que les indisponibilités sont aussi un problème de sécurité.

Pratique ennuyeuse mais correcte qui a sauvé la mise : « Inventaire d’abord, puis changement »

Une autre équipe avait l’habitude, douloureusement lente, de lancer un script d’inventaire avant de modifier des comptes locaux; ce script exportait :
utilisateurs locaux, appartenance aux groupes, identités de logon de services et principaux des tâches planifiées. Chaque ticket de changement incluait le diff.

Lorsqu’un fournisseur a demandé un admin local « pour dépannage », l’équipe a créé un compte dédié, désactivé par défaut, et documenté son
appartenance requise aux groupes et son comportement d’expiration. Ils l’activaient seulement pendant les sessions fournisseur.

Des mois plus tard, un scan interne de réponse à incident a signalé ce compte comme « admin présent ». La réaction instinctive d’un autre groupe
a été de le supprimer immédiatement. Le diff d’inventaire leur a sauvé la mise : il montrait que le compte était désactivé et n’avait pas ouvert de session depuis la dernière session fournisseur.
Il listait aussi trois tâches planifiées qui référençaient ce nom d’utilisateur — mais ces tâches étaient elles aussi désactivées, liées à un ancien engagement.

L’équipe a désactivé définitivement les tâches planifiées, retiré le compte des Administrators, et l’a gardé désactivé comme un placeholder d’identité
jusqu’à la fin du contrat. Pas de panne, pas de drame, pas de refus d’accès surprise au pire moment possible. L’ennuyeux a gagné.

Playbook de diagnostic rapide

Quand « truc de compte local/politique de mot de passe » casse, ça casse généralement dans l’un des trois endroits : état de l’identité, application de la politique, ou usage par des dépendances.
Voici comment trouver rapidement le goulot d’étranglement sans faire de danse interprétative dans l’Observateur d’événements.

Premier : confirmez ce à quoi vous avez affaire (standalone vs domaine, cmdlets disponibles)

• Vérifier la jointure au domaine : (Get-CimInstance Win32_ComputerSystem).PartOfDomain
• Vérifier la build OS : Get-ComputerInfo
• Vérifier le module LocalAccounts : Get-Module -ListAvailable Microsoft.PowerShell.LocalAccounts

Pourquoi : Cela détermine si les changements de politique locale sont réels, et quel chemin d’automatisation est fiable.

Deuxième : inspectez l’état de l’objet compte

• Est-il activé ? Get-LocalUser -Name X | Select Enabled
• Flags de mot de passe : PasswordExpires, PasswordLastSet, UserMayChangePassword
• Appartenance aux groupes : Get-LocalGroupMember -Group Administrators

Pourquoi : « Échec de connexion » signifie souvent « compte désactivé » ou « pas dans le bon groupe », pas « mauvais mot de passe ».

Troisième : identifiez ce qui utilise le credential

• Services : Get-CimInstance Win32_Service | Where StartName -match X
• Tâches planifiées : Get-ScheduledTask | Where Principal.UserId -match X

Pourquoi : Changer les mots de passe est facile ; changer tous les consommateurs est là où naissent les pannes.

Quatrième : validez l’application de la politique (ce qui est réellement en vigueur)

• net accounts pour la vue locale courante
• secedit /export pour capturer l’état de politique et comparer entre hôtes

Pourquoi : Si un GPO écrase vos changements, vous devez ajuster la source de vérité, pas le symptôme.

Erreurs courantes : symptômes → cause racine → correction

1) « Mon script a défini la longueur min du mot de passe, mais ça n’a pas changé »

Symptômes : net accounts affiche les anciennes valeurs après un certain temps ; le scan de sécurité signale encore les anciens réglages.
Cause racine : Un GPO de domaine écrase la politique locale ; ou la machine est gouvernée par un baseline de sécurité.
Correction : Confirmez l’état de jointure au domaine, puis ajustez la politique à la couche gouvernante. Localement, traitez les changements comme éphémères à moins de contrôler le GPO.

2) « Compte créé avec succès, mais l’ouverture de session échoue »

Symptômes : L’utilisateur existe, est activé, mais ne peut pas se connecter via RDP/SMB/interactive.
Cause racine : Droits manquants (par ex., pas dans Remote Desktop Users), la politique de sécurité locale interdit la connexion,
ou le compte est forcé de changer le mot de passe au prochain logon et ne peut pas le faire dans ce contexte.
Correction : Vérifiez l’appartenance aux groupes et les droits locaux ; pour les comptes de service, évitez les scénarios de connexion interactive.

3) « Le service a commencé à échouer après la rotation du mot de passe »

Symptômes : Le service ne démarre pas ; les logs d’événements montrent un échec de logon ; la tâche renvoie 0x52e (mauvais mot de passe).
Cause racine : Le mot de passe a été changé sur le compte mais pas mis à jour pour le consommateur du service/tâche ; ou le redémarrage n’a pas eu lieu.
Correction : Trouvez tous les consommateurs (services + tâches), mettez à jour les credentials, puis redémarrez dans une fenêtre contrôlée. Validez la santé après.

4) « Le compte se verrouille tout le temps »

Symptômes : Événements de verrouillage ; échecs d’authentification répétés ; le compte se déverrouille puis se reverrouille rapidement.
Cause racine : Un processus utilise encore l’ancien credential (service, tâche, lecteur mappé, credential en cache).
Correction : Identifiez tous les consommateurs, mettez-les à jour, puis réinitialisez le verrouillage. Si vous ne trouvez pas, désactivez temporairement le compte et observez ce qui casse.

5) « Get-LocalUser dit que LastLogon est vide donc je ne peux pas dire s’il est utilisé »

Symptômes : LastLogon est vide pour certains comptes alors que vous suspectez une activité.
Cause racine : LastLogon n’est pas toujours renseigné pour tous les types d’authentification, et ce n’est pas une piste d’audit complète.
Correction : Utilisez les journaux d’événements/politique d’audit si vous avez besoin d’une utilisation définitive, et inventoriezn les dépendances (services/tâches) comme signal plus fort.

6) « Nous avons renommé Administrator ; les attaquants le trouvent quand même »

Symptômes : Les outils de sécurité identifient toujours l’admin intégré ; les audits le référencent encore.
Cause racine : Le compte intégré est identifié par SID (RID 500), pas seulement par le nom.
Correction : Renommez si la politique l’exige, mais désactivez aussi quand c’est possible, utilisez LAPS/mots de passe uniques, et surveillez le comportement du RID 500.

7) « Notre automatisation a tourné, mais certains serveurs n’ont pas changé »

Symptômes : La flotte a des comptes/politiques locales inconsistantes ; certains nœuds ont des admins supplémentaires.
Cause racine : Échecs de remoting, problèmes de permissions, ou scripts qui ne valident pas les résultats (ils supposent le succès).
Correction : Rendez les scripts idempotents et vérifiez l’état après chaque action ; exportez des inventaires et faites des diffs ; échouez l’exécution quand la dérive subsiste.

Listes de contrôle / plan étape par étape

Plan A : Créer un compte de service local avec des valeurs par défaut sensées

1. Inventaire avant changement : exporter les utilisateurs locaux actuels et l’appartenance aux Administrators.
2. Créer le compte avec une méthode d’entrée de mot de passe sécurisée (invite SecureString ou injection depuis un coffre).
3. Définir les flags intentionnellement : comportement d’expiration, possibilité de changer le mot de passe, activé/désactivé.
4. Accorder l’appartenance minimale aux groupes : commencer par Users ; éviter Administrators.
5. Lier les dépendances : configurer le service/la tâche pour utiliser le compte.
6. Valider : démarrer le service, exécuter la tâche, vérifier les logs, confirmer l’absence de verrouillages.
7. Documenter : champ description sur l’utilisateur ; ajouter propriétaire et but ; enregistrer dans l’inventaire.

Plan B : Faire respecter la politique de mot de passe et de verrouillage sur des serveurs autonomes

1. Vérifier si l’hôte est joint au domaine. Si oui, arrêtez et gérez la politique au niveau GPO.
2. Utiliser net accounts pour lire les réglages actuels ; exporter avec secedit pour obtenir un artefact diff.
3. Appliquer la politique avec net accounts (ou une approche de template de sécurité cohérente).
4. Relire les paramètres et confirmer qu’ils ont tenu.
5. Tester la création de compte et le changement de mot de passe contre les nouvelles règles (ne découvrez pas l’application pendant une panne).

Plan C : Flux de travail sûr pour désactiver/supprimer des comptes locaux

1. Identifier les dépendances (services, tâches, usages « run as ») avant de toucher au compte.
2. Désactiver d’abord le compte ; surveiller les ruptures.
3. Si pas de rupture, retirer immédiatement des groupes privilégiés (Administrators, Remote Desktop Users).
4. Après une période d’observation, envisager la suppression si nécessaire — mais conservez la preuve de ce qui a été supprimé.
5. Mettre à jour l’inventaire et la baseline pour éviter que le compte « repousse » sans être vu.

Plan D : Hygiène à l’échelle de la flotte (la partie que les gens évitent)

1. Standardiser les conventions de nommage (ex., svc_* pour les services, bg_* pour break-glass).
2. Centraliser l’inventaire : rassembler régulièrement les utilisateurs locaux, les admins locaux et les flags de mot de passe.
3. Alerter sur les changements d’appartenance aux Administrators et sur la création de nouveaux utilisateurs locaux activés.
4. Faire tourner les credentials privilégiés avec un système géré ; ne pas créer de mots de passe partagés entre hôtes.
5. Faire des revues trimestrielles des comptes « stale » avec preuves de dépendances, pas des impressions.

FAQ

1) Dois-je utiliser New-LocalUser ou net user ?

Utilisez New-LocalUser quand il est disponible ; c’est plus clair et les objets sont plus faciles à valider. Gardez net user pour la compatibilité et les diagnostics rapides.

2) Puis-je définir la complexité de mot de passe par utilisateur local ?

Pas comme les gens l’entendent. La complexité fait généralement partie de la politique machine/domaine, pas d’un réglage par utilisateur pour les comptes locaux.
Vous pouvez définir le comportement d’expiration par utilisateur (par ex., « never expires »), mais la complexité est imposée au niveau politique.

3) Pourquoi ma modification de politique de mot de passe revient-elle en arrière ?

Parce que quelque chose de plus prioritaire le possède — habituellement la Group Policy de domaine. Les changements locaux sont écrasés lors du rafraîchissement de la politique.
Votre script n’a pas « échoué » ; il a perdu un combat de gouvernance.

4) Quelle est la manière la plus sûre de gérer les comptes admin locaux ?

Mot de passe unique par hôte, rotation automatique et journalisée, et surveillance de l’appartenance. Si vous copiez encore un même mot de passe entre machines, arrêtez.
Ce n’est pas de « l’opération », c’est un incident en puissance.

5) Les comptes de service doivent-ils avoir des mots de passe expirants ?

Si vous pouvez automatiser la rotation et mettre à jour tous les consommateurs en toute sécurité, oui — l’expiration va. Si vous ne le pouvez pas, l’expiration forcée provoquera des pannes.
Dans ce cas, définissez « never expires » seulement avec un véritable mécanisme de rotation et de surveillance.

6) Pourquoi désactiver un utilisateur local ne résout parfois pas l’accès ?

Parce que l’accès peut provenir d’un autre principal (groupe de domaine, autre compte local, token en cache) ou parce que le vrai problème est
l’autorisation (appartenance à un groupe) et non l’authentification. Vérifiez qui se connecte et d’où.

7) Comment prouver quelle est la politique de mot de passe sur un hôte ?

Utilisez net accounts pour une vue rapide, et secedit /export pour obtenir un fichier que vous pouvez joindre à un ticket et diff entre machines.
La preuve bat les arguments.

8) Est-il acceptable de supprimer des comptes locaux après la décommission d’une appli ?

Généralement oui, mais désactivez d’abord et vérifiez les dépendances. La suppression peut orpheliner des ACL et casser des tâches que personne n’a remémorées.
Si vous avez besoin d’un état propre, capturez un snapshot d’inventaire avant suppression.

9) Quelle est la cause la plus courante de verrouillages de compte après un changement de mot de passe ?

Une tâche planifiée ou un service toujours configuré avec l’ancien mot de passe. Les tentatives répétées déclenchent les verrouillages.
Mettez d’abord à jour les consommateurs quand c’est possible, ou changez le mot de passe et le consommateur dans une fenêtre contrôlée.

Conclusion : prochaines étapes pratiques

Les comptes locaux ne sont pas intrinsèquement mauvais. Ils sont simplement non gérés par défaut, et le défaut est l’endroit où la fiabilité prend des coups.
Si vous voulez la voie opérationnelle courte : inventoriez, standardisez, automatisez, vérifiez, et gardez un plan de rollback.

Prochaines étapes réalisables cette semaine :

• Exécuter un inventaire de Get-LocalUser et de l’appartenance aux Administrators locaux sur votre parc de serveurs ; stocker les résultats centralement.
• Choisir une posture de politique pour les comptes locaux : lesquels sont autorisés, comment ils sont nommés, comment ils expirent, et qui les possède.
• Implémenter une alerte sur les changements d’appartenance aux Administrators locaux et sur la création de nouveaux utilisateurs locaux activés.
• Pour tout compte local privilégié, passer à une gestion de mot de passe unique par hôte et à une rotation avec workflow auditable.
• Rédiger un runbook de rotation de mot de passe incluant : découverte des dépendances, étapes de mise à jour, redémarrages de services, et contrôles de validation.

Faites cela, et la prochaine fois que quelqu’un dira « ce n’est que un compte local », vous aurez des données, des contrôles et moins de pannes surprises. Voilà tout le jeu.