Windows 2008 R2 gpupdate verrouille mon compte d'utilisateur

J'ai construit un serveur Windows 2008 R2 l'année dernière et depuis, mon compte élevé se verrouille 10 à 12 fois par jour. Après de nombreuses recherches et tests, j'ai constaté que le serveur verrouillait mon compte à chaque tentative de mise à jour de la stratégie de groupe échouée (environ toutes les 90 minutes). Je n'ai trouvé aucune information sur le Web indiquant que quelqu'un d'autre a vu cela, et je trouve cela incroyable moi-même.

Chaque fois que 3 événements système sont enregistrés sur le serveur:

ID d'événement 14: le mot de passe stocké dans Credential Manager n'est pas valide. Cela peut être dû au fait que l'utilisateur modifie le mot de passe à partir de cet ordinateur ou d'un autre ordinateur. Pour résoudre cette erreur, ouvrez le Gestionnaire d'informations d'identification dans le Panneau de configuration et entrez à nouveau le mot de passe pour les informations d'identification contoso \ me.

Il n'y a aucune entrée dans Credential Manager. Cela se produit que je désactive ou non le service Credential Manager, que je sois connecté ou non, que je me déconnecte ou que j'utilise un compte d'administrateur local pour supprimer mon profil.

ID d'événement 40960: le système de sécurité a détecté une erreur d'authentification pour le serveur cifs / ContosoDC.contoso.com. Le code d'échec du protocole d'authentification Kerberos était "Le compte d'utilisateur a été automatiquement verrouillé car trop de tentatives de connexion non valides ou de tentatives de changement de mot de passe ont été demandées. (0xc0000234)".

-

ID d'événement 1058:

Le traitement de la stratégie de groupe a échoué. Windows a tenté de lire le fichier \ contoso.com \ SysVol \ contoso.com \ Policies {78719F0C-3091-4B5C-9BC3-6498F729531E} \ gpt.ini à partir d'un contrôleur de domaine et n'a pas réussi. Les paramètres de stratégie de groupe ne peuvent pas être appliqués tant que cet événement n'est pas résolu. Ce problème peut être transitoire et peut être provoqué par un ou plusieurs des éléments suivants: a) Résolution de nom / connectivité réseau au contrôleur de domaine actuel. b) Latence du service de réplication de fichiers (un fichier créé sur un autre contrôleur de domaine n'a pas été répliqué sur le contrôleur de domaine actuel). c) Le client DFS (Distributed File System) a été désactivé.

J'ai vérifié les articles ac, aucun ne semble être le cas.

J'ai testé cela en profondeur en vérifiant que le compte utilisateur n'est pas verrouillé, en exécutant gpupdate sur le serveur, puis en revérifiant le compte utilisateur, qui se verrouille immédiatement. J'ai utilisé des outils de verrouillage pour révéler que tous les verrouillages proviennent de ce serveur particulier. Le compte d'utilisateur n'a pas d'adresse e-mail associée, et j'ai longuement étudié le tableau habituel des problèmes de verrouillage connus.

Des indices pour moi? Je me prépare à supprimer ce serveur de production et à réinitialiser son objet ordinateur dans AD, mais je ne sais pas si cela aidera.

Apparemment, il peut y avoir des mots de passe dans le gestionnaire d'informations d'identification qui n'apparaissent pas. Ou, pour citer ce lien :

Certains mots de passe peuvent être stockés dans le contexte SYSTEM et ne peuvent pas être vus dans la vue Credential Manager normale.

Téléchargez PsExec.exe sur http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx et copiez-le dans C: \ Windows \ System32.

À partir d'une invite de commande, exécutez: psexec -i -s -d cmd.exe

Depuis la nouvelle fenêtre DOS, exécutez: rundll32 keymgr.dll,KRShowKeyMgr

Supprimez tous les éléments qui apparaissent dans la liste des noms d'utilisateur et mots de passe stockés. Redémarrer le PC.

J'espère que cela résoudra votre problème.

Si le gestionnaire d'informations d'identification n'aide pas, j'essaierais de mettre le système dans une unité d'organisation sans aucun GPO à tester.

Si le problème persiste, il est lié au GPO de domaine par défaut, un GPO qui s'applique à l'ensemble du domaine ou qui n'est pas lié au GPO. Dans les deux cas, cela peut aider à limiter la portée de la recherche.

À partir d'une invite cmd, utilisez gpupdate pour tester les modifications sans avoir à attendre et gpresult / R pour voir les objets de stratégie de groupe appliqués au système.

Si vous pensez qu'un GPO est toujours impliqué, utilisez le filtre WMI pour empêcher les GPO de s'appliquer.

Notez également qu'il pourrait y avoir des GPO appliqués au niveau du site, mais vous les verrez dans la sortie gpresult.

Si vous êtes en mesure de limiter les verrouillages en réduisant les objets de stratégie de groupe, ajoutez-les ensuite à l'unité d'organisation pour trouver celui qui fait partie de la cause. Recherchez ensuite ce GPO pour trouver la résolution.

Voici également une liste de choses que je vérifie lorsque le compte est verrouillé et je connais déjà le système dont il provient. Services Tâches planifiées Lecteurs mappés Applications Web Console VM Console KVM sessions RDP Scripts PW helper apps Connexion VPN Autres appareils qui se connectent aux e-mails Outils Bureau à distance Applications qui exécutent Credential Manager