Question Mystère de connexion du compte d'administrateur AD - horodatage de la dernière connexion


Nous avons trouvé le compte d'administrateur de domaine - ce que nous faisons ne pas utiliser sauf en cas de scénario de récupération après sinistre - a une date récente dans l'attribut LastLogonTimeStamp. Autant que je sache, personne n'aurait dû utiliser ce compte pendant la période concernée (et plusieurs mois après), mais peut-être qu'un idiot l'a-t-il configuré pour exécuter une tâche planifiée.

En raison de la quantité d’événements du journal de sécurité (et de l’absence d’outil SIEM pour l’analyse), j’ai voulu déterminer quel DC avait le dernierLogon le temps (c'est-à-dire ne pas l'attribut répliqué) pour le compte, mais j'ai interrogé tous les contrôleurs 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 CD exécute la connexion autrement qu'en examinant les 20 millions d'événements potentiels provenant de 16 CD en forêt vers la période enregistrée dans LastLogonTimestamp? Je suppose que je pourrais commencer par cibler les contrôleurs de domaine du domaine parent (car les contrôleurs de domaine enfants ne semblent pas avoir effectué l’autorisation).

Addenda

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 d'administrateur de domaine par défaut fréquemment.

Nous savions que nous ne le connections pas. Il se trouve qu'il existe un mécanisme appelé "Kerberos S4u2Self" lorsqu'un processus appelant exécuté en tant que système local procède à une élévation de privilèges. Il fait un réseau Ouverture de session (non interactive) en tant qu'administrateur sur un contrôleur de domaine. Comme c'est non-interactif, c'est pourquoi il n'y a pas lastLogon pour le compte sur n'importe quel contrôleur de domaine (ce compte n'a jamais été connecté à aucun contrôleur de domaine actuel).

Cet article explique pourquoi les pings de vos journaux et votre équipe de sécurité ont 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 fournir que des rapports sur lastLogon attribuer des attributs aux équipes de sécurité informatique s’agissant des ouvertures de session administrateur.


14
2018-03-22 14:28


origine




Réponses:


repadmin /showobjmeta DCNAME "ObjectDN"  

Affiche le DSA d'origine.

Exemple:

repadmin /showobjmeta CONTOSOMDDC1 "CN=Administrator,CN=Users,DC=contoso,DC=com"  

54 entries.
Loc.USN                           Originating DSA  Org.USN  Org.Time/Date        Ver Attribute
=======                           =============== ========= =============        === =========
4178442               CONTOSO-MDSite\CONTOSOMDDC1   4178442 2017-03-15 11:37:30   55 lastLogonTimestamp

17
2018-03-22 14:58



frappe la tête Je vous remercie! J'étais justement ici pour recommander repadmin pour autre chose, et j'aurais dû penser à celui-là! Merci beaucoup pour la réponse rapide. - Trix