Nous avons découvert que le compte Administrateur du domaine - que nous n’utilisons pas sauf en cas de scénario de récupération après sinistre - a une date récente dans l’attribut LastLogonTimeStamp. À ma connaissance, 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 dans le journal de sécurité (et du manque d’outil SIEM pour l’analyse), je voulais déterminer quel DC avait le lastLogon réel (c.-à-d. pas l’attribut répliqué) pour le compte, mais j’ai interrogé chaque DC du domaine, et ils ont tous un lastLogon de « aucun » pour Administrateur.
C’est un domaine enfant dans la forêt, il est donc possible que quelqu’un ait utilisé ce compte Administrateur du domaine enfant pour exécuter quelque chose dans le domaine parent.
Quelqu’un peut-il penser à un moyen de déterminer quel DC effectue la connexion autrement qu’en examinant les potentiellement 20 millions d’événements provenant de 16 DC de la forêt autour de l’heure enregistrée dans LastLogonTimestamp ? Je suppose que je pourrais cibler les DC du domaine parent en premier (puisque les DC enfants ne semblent pas avoir effectué l’authentification).
Explication
[Ajouté après avoir identifié la cause en utilisant repadmin comme indiqué ci-dessous]
La raison initiale de cette demande était due à notre équipe de sécurité informatique, qui se demandait pourquoi nous nous connections apparemment fréquemment avec le compte Administrateur de domaine par défaut.
Nous savions que NOUS ne nous connections pas avec. Il s’avère qu’il existe un mécanisme appelé « Kerberos S4u2Self » qui intervient lorsqu’un processus appelant s’exécutant en tant que Système Local effectue une élévation de privilèges. Il effectue une connexion réseau (pas interactive) en tant qu’Administrateur sur un contrôleur de domaine. Comme c’est non interactif, c’est pourquoi il n’y a pas de lastLogon pour le compte sur aucun DC (ce compte n’avait jamais été connecté sur aucun contrôleur de domaine actuel).
Cet article explique pourquoi la chose fait sonner vos journaux et rend votre équipe de sécurité nerveuse (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 attributs lastLogon aux équipes de sécurité informatique que lorsqu’il s’agit de connexions Administrateur.