Recherchez le processus / programme à l'origine de l'erreur de pré-authentification Kerberos (code 0x18)
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é de 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 la pile ntdll.dll et 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 DC? C'est toujours la même DC donc nous savons que ce doit être un serveur sur ce site. Je pourrais essayer de chercher les appels dans Wireshark, mais je ne suis pas sûr que cela restreindrait le processus déclencher 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 d'ouverture de session "succès/échec" sont activés sur le DC en question - aucun événement d'échec n'est enregistré jusqu'à ce que le compte soit réellement verrouillé.
Des recherches plus approfondies montrent que LSASS.exe fait un appel de KERBEROS à DC 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 l'autre "server2" 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).
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 ticket avec klist et j'ai quand même fait un flush 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 l'ouverture de session ayant échoué (Paramètres de sécurité> Stratégies locales> Stratégie d'audit> Événements d'ouverture de session d'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
Kerberos 0x18 est en effet une mauvaise tentative de mot de passe.
Kerberos 0x12 est le 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 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'erreur 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 sur 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.
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 de réseau (l'identifiant du processus d'erreur Kerberos était 566 = lsass.exe). Permettez-moi de résumer les informations.
Connectez-vous au PC défectueux, exécutez PowerShell avec des droits élevés
Activer la connexion d'audit
auditpol /set /subcategory:"logon" /failure:enableVé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 en cours d'exécution à partir d'un 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é lors de son dernier commentaire. Java appel du processus vpxd.exe.
Notes supplémentaires Oui, les audits de connexion "Réussite/Échec" sont activés sur le DC en question - aucun événement d'échec n'est enregistré jusqu'à ce que le compte soit réellement verrouillé.
Une analyse plus approfondie montre que LSASS.exe effectue un appel KERBEROS au DC 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" où le verrouillage du 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 OS vSphere).