Lors d’une mission de test, j’ai rencontrĂ© un comportement pour le moins surprenant sous Windows 11 : le simple fait de convertir un compte Microsoft en compte local a conduit Ă un verrouillage complet de la session, rendant impossible toute connexion.
Et se sentir enfermĂ© en dehors de chez soit, c’est jamais agrĂ©able et pas stressant comme situation.
🎯 Contexte de l’intervention
Mon PC concerné était utilisé pour des tests d’intégration dans un environnement hybride (Windows/Proxmox).
L’objectif était de remplacer mon compte Microsoft personnel (@live.com) par un compte local “aperrot”, pour des raisons de cyber.
L’opération s’est déroulée sans erreur apparente.
Mais après redémarrage, impossible d’ouvrir ma session locale :
« Le compte référencé est verrouillé. »
🔍 Analyse du problème
Court reboot pour dĂ©clencher l’administrateur cachĂ©, viens le moment de dĂ©bug tout ça
En consultant les journaux de sécurité Windows (Event ID 4625), plusieurs tentatives d’authentification réseau échouées ont été détectées, provenant d’une adresse interne de type 10.x.x.x.
Les événements montraient clairement :
Raison de l’échec : Nom d’utilisateur inconnu ou mot de passe incorrect
Nom du compte : aperrot
Domaine du compte : live.fr
Type d’ouverture : 3 (réseau)
Processus d’ouverture : NtLmSsp
Ce type de connexion correspond Ă une authentification NTLM sur un partage SMB distant.
⚙️ La cause identifiée
Après investigation, l’origine a été trouvée :
un serveur Proxmox présent sur mon réseau de test, relié via un tunnel WireGuard, utilisait ce poste comme cible pour des sauvegardes SMB planifiées.
🔸 À noter : aucune sauvegarde n’était en cours au moment du problème.
Les processus Proxmox essayaient simplement de vérifier la disponibilité du partage SMB avec les anciens identifiants.
Ces tentatives d’accès échouées ont déclenché, côté Windows, la sécurité de verrouillage automatique du compte “aperrot”, considérant les requêtes répétées comme suspectes.
🧠Résolution
- Coupure temporaire du tunnel WireGuard, isolant le poste de tout trafic SMB externe.
- RĂ©activation du compte local via PowerShell :
Enable-LocalUser -Name "aperrot" - Redémarrage du poste.
→ Le compte a immédiatement retrouvé un comportement normal, sans nouveau verrouillage.
💡 Enseignements tirés
Ce cas met en évidence plusieurs points clés :
- Un simple changement de type de compte (Microsoft → local) peut laisser des traces d’authentification sur le réseau.
- Les tunnels VPN/WireGuard peuvent maintenir des sessions NTLM même lorsque les sauvegardes ou tâches ne sont pas actives.
- Les services SMB ou scripts automatisés configurés sous un ancien compte doivent être révisés avant conversion d’un profil Windows.
🧰 Bonnes pratiques DYB pour éviter ce cas
Dans un environnement de prod, veillez Ă bien respecter quelques principes de base :
- Utiliser un compte dédié pour les sauvegardes réseau, distinct des comptes utilisateurs interactifs.
- Couper les connexions VPN ou WireGuard pendant la conversion d’un compte Microsoft vers un compte local.
- Vérifier les tâches planifiées et services exécutés sous l’ancien identifiant avant la modification.
- Après conversion, purger les identifiants stockés avec :
cmdkey /list cmdkey /delete:...