Microfoft Windows verrouille constamment mon compte de service de domaine

Bienvenue sur Microsoft Q&A!

Merci d’avoir fourni ces informations supplémentaires.

D’après le comportement que vous décrivez, le compte est très probablement verrouillé parce qu’un élément de l’environnement tente de manière répétée de s’authentifier avec des informations d’identification qu’Active Directory rejette. Le compte fonctionne à nouveau immédiatement après que vous l’avez déverrouillé, puis se verrouille de nouveau quelques minutes plus tard. L’essentiel est donc de retracer ces tentatives d’authentification jusqu’à leur source.

Puisque vous avez déjà vérifié les emplacements les plus courants, tels que les informations d’identification stockées et les tâches planifiées, je vous suggère d’aborder l’investigation en partant des contrôleurs de domaine et en remontant jusqu’au système d’origine.

1. Commencez par l’ID d’événement 4740, mais ne vous fiez pas uniquement à celui-ci

Sur vos contrôleurs de domaine, recherchez l’ID d’événement de sécurité 4740, « Un compte d’utilisateur a été verrouillé », pour le compte de service concerné et notez l’horodatage exact.

Portez une attention particulière au nom de l’ordinateur appelant. Lorsque cette information est disponible, elle peut vous aider à identifier l’ordinateur associé au verrouillage.

Cependant, je ne me fierais pas exclusivement à ce champ. Si l’ordinateur appelant n’est pas renseigné, est incohérent ou semble être un serveur intermédiaire, corrélez les événements 4740 avec les échecs d’authentification survenus immédiatement avant le verrouillage.

2. Déterminez si les échecs concernent Kerberos ou NTLM

Aux alentours du même horodatage, examinez les journaux de sécurité des contrôleurs de domaine afin de rechercher les échecs d’authentification impliquant le compte concerné.

Pour Kerberos, recherchez l’ID d’événement 4771, en accordant une attention particulière aux éléments suivants :

• Nom du compte
• Adresse du client
• Code d’échec

Si vous trouvez l’ID d’événement 4771 avec le code d’échec 0x18, cela indique que les informations de pré-authentification Kerberos n’étaient pas valides. L’adresse du client peut être particulièrement utile pour déterminer l’origine de la demande d’authentification.

Pour NTLM, recherchez l’ID d’événement 4776, en particulier:

• Compte de connexion
• Station de travail source
• Code d’erreur

Une séquence de dépannage utile est donc la suivante :

Adresse du client 4771 (Kerberos) / Station de travail source 4776 (NTLM) → verrouillage du compte 4740

Vérifiez également les contrôleurs de domaine concernés plutôt que de supposer que tous les échecs d’authentification et le verrouillage qui en résulte apparaîtront nécessairement ensemble sur un seul contrôleur de domaine.

3. Examinez l’ordinateur source identifié

Une fois que vous avez identifié une adresse IP source ou une station de travail récurrente, poursuivez l’investigation sur ce système.

Vérifiez tout élément susceptible de s’exécuter ou de s’authentifier à l’aide du compte de service, notamment :

• Services Windows
• Tâches planifiées
• Pools d’applications IIS ou autres applications serveur
• Gestionnaire d’informations d’identification/informations d’identification stockées
• Scripts et automatisation
• Ressources mappées
• Applications héritées qui conservent leurs propres informations d’identification

Vous pouvez également corréler l’ID d’événement 4625 sur le serveur ou la station de travail concerné. Des informations telles que le type d’ouverture de session, le package d’authentification, l’état/sous-état et les informations sur la source peuvent aider à déterminer plus précisément quel chemin d’authentification échoue.

Si des informations d’identification explicites sont utilisées et que l’audit approprié est activé, l’ID d’événement 4648 peut fournir des informations supplémentaires sur le compte, le serveur cible et le processus impliqué.

4. Utilisez les outils de verrouillage et de gestion de compte de Microsoft

Les outils de verrouillage et de gestion de compte de Microsoft peuvent également vous aider dans cette investigation.

En particulier, LockoutStatus.exe peut aider à identifier les contrôleurs de domaine impliqués dans le verrouillage du compte, ce qui vous permet de concentrer l’analyse des journaux sur les contrôleurs de domaine appropriés.

Le package contient également NLParse.exe, qui peut être utilisé lors de l’analyse des journaux Netlogon.

Une précaution importante : ALockout.dll permet de dépanner les informations d’identification incorrectes provenant d’ordinateurs clients, mais Microsoft déconseille spécifiquement son utilisation sur les serveurs hébergeant des applications ou des services réseau, ainsi que sur les serveurs Exchange.

5. Si les journaux de sécurité ne permettent toujours pas d’identifier la source

Si la source reste incertaine, je passerais à des diagnostics d’authentification plus détaillés plutôt que de continuer à déverrouiller le compte de manière répétée.

À ce stade, la collecte des informations de diagnostic appropriées concernant la sécurité, Kerberos et, le cas échéant, Netlogon, à partir des systèmes impliqués, peut aider à établir le chemin d’authentification.

Cela devient particulièrement utile lorsque l’événement 4740 identifie un système intermédiaire ou ne permet pas de déterminer clairement d’où provient initialement la demande d’authentification.

6. Ce sur quoi je me concentrerais dans ce cas

Étant donné que le compte fonctionne correctement après avoir été déverrouillé, mais qu’il se verrouille de nouveau quelques minutes plus tard, je chercherais en priorité une tentative d’authentification récurrente en arrière-plan impliquant ce compte.

Essayez de capturer un cycle de verrouillage complet et de corréler les événements chronologiquement :

Échec d’authentification → adresse IP/station de travail source → protocole d’authentification → événement 4740 → hôte/processus d’origine

Une fois que vous avez identifié le système et le composant générant les tentatives d’authentification répétées, vous pouvez alors vérifier et mettre à jour les informations d’identification configurées à cet emplacement.

À plus long terme, si les applications qui utilisent ce compte le prennent en charge, vous pouvez également envisager un compte de service administré de groupe (gMSA) afin de réduire la charge administrative liée à la gestion manuelle des mots de passe des comptes de service.

J’espère que cela vous aidera à identifier plus précisément la source des verrouillages répétés. Je sais que ce type de problème peut être particulièrement frustrant lorsque plusieurs services de production dépendent du même compte. Je commencerais donc par relever l’horodatage de l’événement 4740 et le corréler avec les événements 4771/4776 avant d’apporter d’autres modifications aux informations d’identification.

Références :

Présentation des outils de verrouillage et de gestion de compte - Windows Server | Microsoft Learn

4740(S) A user account was locked out. - Windows 10 | Microsoft Learn

Si cela vous est utile, veuillez cliquer sur Accepter la réponse.

Merci d’avoir choisi Microsoft Q&A.

Remarque: Cette réponse a été traduite à l’aide d’un outil de traduction. Veuillez noter qu’elle peut contenir des erreurs grammaticales ou sémantiques. Merci de votre compréhension.