Nous avons constaté que le compte d'administrateur de domaine - que nous n'utilisons pas sauf en cas de scénario de reprise après sinistre - a une date récente dans l'attribut LastLogonTimeStamp. Pour autant que je sache, personne n'aurait dû utiliser ce compte pendant la période concernée (et plusieurs mois au-delà), mais peut-être qu'un idiot l'a configuré pour exécuter une tâche planifiée.
En raison de la quantité d'événements du journal de sécurité (et du manque d'outil SIEM pour l'analyse), je voulais déterminer quel contrôleur de domaine avait l' heure de dernière connexion réelle (c'est-à-dire pas l'attribut répliqué) pour le compte, mais j'ai interrogé chaque contrôleur de domaine du domaine, et ils ont chacun un lastLogon de «aucun» pour l'administrateur.
Il s'agit d'un domaine enfant dans la forêt, il est donc possible que quelqu'un ait utilisé ce compte Administrateur de domaine enfant pour exécuter quelque chose dans le domaine parent.
Quelqu'un peut-il penser à un moyen de déterminer quel contrôleur de domaine fait l'ouverture de session autre que d'examiner les 20 millions d'événements potentiels de 16 contrôleurs de domaine forestiers à peu près à la date enregistrée dans LastLogonTimestamp? Je suppose que je pourrais cibler les DC du domaine parent en premier (car les DC enfants ne semblent pas avoir fait l'authentification).
Explication
[Ajouté après la mise à zéro de la cause après utilisation repadminselon ce qui suit]
La raison initiale de cette demande était due à notre équipe de sécurité informatique, qui se demandait pourquoi nous nous connections apparemment avec le compte Administrateur de domaine par défaut sur une base fréquente.
Nous savions que NOUS ne le connections pas. Il s'avère qu'il existe un mécanisme appelé "Kerberos S4u2Self" qui est lorsqu'un processus d'appel s'exécutant en tant que système local fait une élévation de privilèges. Il effectue une connexion réseau (non interactive) en tant qu'administrateur sur un contrôleur de domaine. Comme il n'est pas interactif, c'est pourquoi il n'y a pas lastLogonde compte sur aucun DC (ce compte n'a jamais été connecté à aucun contrôleur de domaine actuel).
Cet article explique pourquoi la chose envoie un ping à vos journaux et fait que votre équipe de sécurité a des chatons (les machines sources sont Server 2003, pour aggraver les choses). Et comment le retrouver. https://blogs.technet.microsoft.com/askpfeplat/2014/04/13/how-lastlogontimestamp-is-updated-with-kerberos-s4u2self/
Leçon apprise: ne fournissez des rapports sur les lastLogonattributs aux équipes de sécurité informatique que lorsqu'il s'agit de connexions administrateur.