Nous avons un compte de domaine qui est verrouillé via 1 des 2 serveurs. L'audit intégré ne nous en dit que beaucoup (verrouillé sur SERVER1, SERVER2).

Le compte est verrouillé dans les 5 minutes, environ 1 demande par minute semble-t-il.

J'ai d'abord essayé d'exécuter procmon (à partir de sysinternals) pour voir si un nouveau DÉMARRAGE DE PROCESS était en cours de création après avoir déverrouillé le compte. Rien de suspect ne se présente. Après avoir exécuté procmon sur mon poste de travail et être passé à un shell UAC (conscent.exe), il semble que depuis la pile cela ntdll.dllet rpct4.dllêtre appelé lorsque vous essayez de vous authentifier contre AD (pas sûr).

Existe-t-il un moyen de restreindre le processus qui provoque une demande d'authentification à notre contrôleur de domaine? C'est toujours le même DC donc nous savons que ce doit être un serveur sur ce site. Je pourrais essayer de rechercher les appels dans Wireshark, mais je ne suis pas sûr que cela restreindrait le processus qui le déclenche réellement.

Aucun service, mappage de lecteur ou tâche planifiée n'utilise ce compte de domaine non plus - il doit donc y avoir quelque chose dans lequel les informations de domaine sont stockées. Il n'y a aucune session RDP ouverte avec ce compte de domaine sur aucun serveur (nous avons vérifié).

Notes complémentaires

Oui, les audits de connexion «réussite / échec» sont activés sur le contrôleur de domaine en question - aucun événement d'échec n'est enregistré tant que le compte n'est pas verrouillé.

Une recherche plus approfondie montre que LSASS.exefait un KERBEROSappel au contrôleur de domaine en question une fois le compte déverrouillé. Il est précédé (généralement) de java qui semble être appelé par vpxd.exelequel est un processus vCenter. MAIS, quand je regarde les autres "server2" d'où le verrouillage de compte peut (aussi) se produire, je ne vois jamais d'appel lsass.exeet seuls les processus apache sont en train d'apparaître. La seule relation entre les deux est que SERVER2 fait partie du cluster vSphere de SERVER1 (server1 étant un système d'exploitation vSphere).

Erreur sur DC

Donc, il semble que tout ce que AD me dira, c'est qu'il s'agit d'une erreur Kerberos de pré-authentification. J'ai vérifié et il n'y avait pas de billets klistet j'ai quand même fait une chasse d'eau au cas où. Je n'ai toujours aucune idée de la cause de cette erreur Kerberos.

Index              : 202500597
EntryType          : FailureAudit
InstanceId         : 4771
Message            : Kerberos pre-authentication failed.

                     Account Information:
                         Security ID:        S-1-5-21-3381590919-2827822839-3002869273-5848
                         Account Name:        USER

                     Service Information:
                         Service Name:        krbtgt/DOMAIN

                     Network Information:
                         Client Address:        ::ffff:x.x.x.x
                         Client Port:        61450

                     Additional Information:
                         Ticket Options:        0x40810010
                         Failure Code:        0x18
                         Pre-Authentication Type:    2

                     Certificate Information:
                         Certificate Issuer Name:
                         Certificate Serial Number:
                         Certificate Thumbprint:

                     Certificate information is only provided if a certificate was used for pre-authentication.

                     Pre-authentication types, ticket options and failure codes are defined in RFC 4120.

                     If the ticket was malformed or damaged during transit and could not be decrypted, then many fields
                      in this event might not be present.

Les événements de connexion enregistrent le processus tentant de se connecter. Activez l'audit de la connexion ayant échoué (Paramètres de sécurité> Stratégies locales> Stratégie d'audit> Événements de connexion à l'audit) dans la stratégie de sécurité locale (secpol.msc), puis recherchez un événement dans le journal des événements de sécurité. Vous pouvez également l'activer via la stratégie de groupe, si cela est préférable.

Il y aura une section Informations sur le processus qui enregistrera à la fois le chemin exécutable et l'ID du processus.

Exemple:

Process Information:
    Process ID:         0x2a4
    Process Name:       C:\Windows\System32\services.exe

J'ai trouvé cette vieille question en recherchant un problème différent, mais pour toute personne ayant un problème similaire:

Le code d'échec 0x18 signifie que le compte était déjà désactivé ou verrouillé lorsque le client a tenté de s'authentifier.

Vous devez trouver le même ID d'événement avec le code d'échec 0x24 , qui identifiera les tentatives de connexion ayant échoué qui ont provoqué le verrouillage du compte. (Cela suppose qu'il se produit en raison d'un mauvais mot de passe mis en cache quelque part.)

Vous pouvez ensuite consulter l'adresse client de ces événements pour voir quel système transmet les informations d'identification incorrectes. À partir de là, vous devrez déterminer s'il s'agit d'un service avec un ancien mot de passe, un lecteur réseau mappé, etc.

Il existe une variété de codes d'échec, vous devez donc rechercher autre chose que 0x18 pour déterminer la cause du verrouillage du compte s'il n'y a aucun événement avec des codes 0x24. Je crois que le seul type d'échec qui conduira à un verrouillage est 0x24 (mauvais mot de passe), mais je peux me tromper.

Kerberos 0x18 est en effet une mauvaise tentative de mot de passe.

Kerberos 0x12 est un compte désactivé, expiré, verrouillé ou restriction des heures d'ouverture de session.

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4771

J'ai passé beaucoup de temps aujourd'hui à découvrir la cause profonde. Je me suis trompé - à partir des informations capturées avec le renifleur réseau (l'identifiant du processus d'erreur Kerberos était 566 = lsass.exe). Permettez-moi de résumer les informations.

1. Connectez-vous au PC défectueux, exécutez PowerShell avec des droits élevés

2. Activer la connexion d'audit

   auditpol /set /subcategory:"logon" /failure:enable

3. Vérifiez la source

   Get-WinEvent -Logname 'Security' -FilterXPath "*[System[EventID=4625]]" -MaxEvents 2 | fl

Si tu vois:

Traitement de l'information:

ID de processus de l'appelant: 0x140

Nom du processus de l'appelant: C: \ Windows \ System32 \ services.exe

Cela signifie que vous avez un service exécuté à partir du compte problématique avec un ancien mot de passe

C'est à partir des notes ci-dessus. On dirait que l'initiateur de ce post a déclaré sur son dernier commentaire. Java appelant le processus vpxd.exe.

Notes supplémentaires Oui, les audits de connexion «Succès / Échec» sont activés sur le contrôleur de domaine en question - aucun événement d'échec n'est enregistré tant que le compte n'est pas réellement verrouillé.

Une analyse plus approfondie montre que LSASS.exe effectue un appel KERBEROS au contrôleur de domaine en question une fois le compte déverrouillé. Il est précédé (généralement) de java qui semble être appelé par vpxd.exe qui est un processus vCenter. MAIS, quand je regarde les autres "server2" d'où le verrouillage de compte peut (aussi) se produire, je ne vois jamais d'appel à lsass.exe et seuls les processus apache sont générés. La seule relation entre les deux est que SERVER2 fait partie du cluster vSphere de SERVER1 (server1 étant un système d'exploitation vSphere).