Objectif
Changer le secret d’un compte de service Windows utilisé par plusieurs composants sans perdre une dépendance cachée, en inventoriant les usages, en préparant l’ordre de mise à jour, en testant chaque service et en surveillant les authentifications échouées après la rotation.
Prérequis
- Identité exacte du compte et propriétaire métier/technique.
- Accès aux serveurs où le compte est utilisé et droit de modifier les dépendances.
- Nouveau secret conforme généré et stocké dans le coffre prévu.
- Fenêtre de maintenance et compte administrateur de secours.
- État initial des services, tâches et applications documenté.
Procédure pas à pas
Inventorier les services Windows utilisant le compte
Recherchez le compte dans les services locaux et sur les serveurs concernés. Utilisez StartName plutôt que le nom du service, car plusieurs services peuvent partager la même identité. Exportez la liste avec l’état actuel afin de savoir ce qui doit être redémarré et validé après la rotation. Si le compte est présent sur plusieurs serveurs, centralisez la liste avant de modifier quoi que ce soit.
Get-CimInstance Win32_Service | Where-Object StartName -match '<DOMAINE\COMPTE>' | Select Name,DisplayName,State,StartMode,StartName- La liste des services dépendants est complète et horodatée.
Inventorier les tâches planifiées
Les tâches planifiées sont une source fréquente d’ancien mot de passe oublié. Listez les tâches dont le Principal.UserId correspond au compte. Notez le chemin de la tâche, son dernier résultat, son prochain déclenchement et le serveur. Certaines applications créent leurs propres tâches : ne limitez pas la recherche au dossier racine de Task Scheduler.
Get-ScheduledTask | Where-Object {$_.Principal.UserId -match '<DOMAINE\COMPTE>'} | Select TaskPath,TaskName,@{n='UserId';e={$_.Principal.UserId}}Get-ScheduledTaskInfo -TaskName '<TASK-NAME>' -TaskPath '<TASK-PATH>'- Toutes les tâches connues utilisant le compte sont intégrées au plan de changement.
Rechercher les pools IIS et autres dépendances
Sur les serveurs IIS, inspectez les pools d’applications configurés avec SpecificUser. Complétez l’inventaire avec les applications métiers, services SQL Agent, outils de sauvegarde, connecteurs et scripts documentés. Les commandes ci-dessous servent uniquement à découvrir l’identité ; ne placez jamais le nouveau mot de passe dans une commande enregistrée dans l’historique.
Import-Module WebAdministrationGet-ChildItem IIS:AppPools | Select Name,@{n='IdentityType';e={$_.processModel.identityType}},@{n='UserName';e={$_.processModel.userName}}- Le plan contient services, tâches, IIS et dépendances applicatives non Windows.
Mesurer l’état de référence avant rotation
Avant le changement, vérifiez que les composants sont réellement sains. Un service déjà arrêté ou une tâche déjà en erreur ne doit pas être attribué à la rotation. Relevez les événements 4625 récents pour le compte, si l’audit de connexion est disponible, et les journaux applicatifs. Fixez également l’ordre de changement : annuaire, puis dépendances, puis redémarrages/tests.
Get-Service | Where-Object Status -eq 'Stopped' | Select Name,DisplayNameGet-WinEvent -FilterHashtable @{LogName='Security';Id=4625;StartTime=(Get-Date).AddHours(-2)} -ErrorAction SilentlyContinue | Select -First 20 TimeCreated,Id,Message- Les anomalies préexistantes sont séparées des incidents causés par la rotation.
Changer le secret dans l’autorité de compte
Effectuez la rotation dans Active Directory ou dans l’autorité concernée avec l’outil administratif sécurisé de votre organisation. Si vous utilisez le module ActiveDirectory, une méthode interactive peut éviter d’exposer le nouveau mot de passe en clair dans l’historique. Après changement, ne testez pas le secret en ouvrant une session interactive si le compte n’est pas destiné à cet usage.
$NewPassword = Read-Host 'Nouveau mot de passe' -AsSecureStringSet-ADAccountPassword -Identity '<SERVICE-ACCOUNT>' -Reset -NewPassword $NewPassword- Le mot de passe du compte est changé sans apparaître en clair dans la commande ou le ticket.
Mettre à jour les dépendances par lots
Commencez par les composants dont l’impact est le plus faible et mettez à jour le mot de passe avec l’interface de gestion appropriée : propriétés du service, Task Scheduler, IIS Manager ou console applicative. Pour chaque élément, sauvegardez la configuration si possible, appliquez le nouveau secret, puis redémarrez uniquement le composant concerné. Ne passez au lot suivant qu’après validation.
- Chaque dépendance est mise à jour et testée avant la suivante.
Valider services, tâches et application
Vérifiez que les services redémarrent avec le compte attendu. Déclenchez manuellement une tâche non destructive ou attendez son prochain passage et contrôlez LastTaskResult. Pour IIS, recyclez uniquement le pool concerné si le changement le nécessite et testez l’URL ou l’application. Le fait qu’un service soit Running ne prouve pas qu’il accède encore correctement aux ressources réseau.
Get-CimInstance Win32_Service | Where-Object StartName -match '<DOMAINE\COMPTE>' | Select Name,State,StartNameGet-ScheduledTask | Where-Object {$_.Principal.UserId -match '<DOMAINE\COMPTE>'} | Get-ScheduledTaskInfo | Select LastRunTime,LastTaskResult,NextRunTime- Les dépendances sont démarrées et les fonctions métier utilisant des ressources distantes réussissent.
Surveiller les échecs 4625 et comptes verrouillés
Après la rotation, surveillez les échecs d’authentification sur une durée couvrant au moins le cycle des tâches non fréquentes. Un événement 4625 répétitif provenant d’une machine précise indique souvent un service, une tâche ou un script resté avec l’ancien secret. Corrigez la source au lieu de simplement déverrouiller le compte à répétition.
Get-WinEvent -FilterHashtable @{LogName='Security';Id=4625;StartTime=(Get-Date).AddHours(-1)} -ErrorAction SilentlyContinue | Where-Object {$_.Message -match '<SERVICE-ACCOUNT>'} | Select TimeCreated,MachineName,Message- Aucun 4625 persistant lié au compte n’apparaît après la période de surveillance.
Documenter et préparer la prochaine rotation
Enregistrez la date, le propriétaire, les dépendances découvertes et le prochain jalon de rotation dans le coffre ou la CMDB
- La prochaine rotation dispose d’un inventaire à jour et d’un responsable clairement identifié.
Validation
La procédure est validée lorsque :
- Tous les services dépendants sont démarrés avec le compte prévu.
- Les tâches planifiées exécutent leur action avec un résultat attendu.
- Les applications accèdent encore à leurs ressources réseau et bases nécessaires.
- Aucun événement 4625 persistant ni verrouillage du compte n’apparaît après surveillance.
Retour arrière
- Si une dépendance critique échoue et que la politique l’autorise, restaurer temporairement l’ancien secret dans l’autorité et dans les composants déjà modifiés.
- Si l’ancien secret ne peut pas être réutilisé, appliquer un nouveau secret de secours coordonné à toutes les dépendances plutôt que multiplier les valeurs.
- Remettre chaque service ou tâche à sa configuration sauvegardée si une autre propriété a été modifiée par erreur.
- Documenter le rollback et relancer l’inventaire avant une nouvelle tentative.
Dépannage / erreurs fréquentes
- Service 1069 après rotation : vérifier le nom de compte et le secret configurés dans Log On, ainsi que le droit Log on as a service.
- Tâche 0x8007052E : rechercher une mauvaise paire utilisateur/mot de passe ou un compte verrouillé.
- 4625 depuis un serveur inattendu : identifier une dépendance non inventoriée sur cette machine.
- Application démarre mais n’accède plus au partage/SQL : vérifier les droits réseau et l’identité réellement utilisée.
- Le compte est verrouillé régulièrement : ne déverrouillez pas en boucle ; corrigez d’abord toutes les sources conservant l’ancien secret.