Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Mystère de connexion du compte Administrateur AD - horodatage de dernière connexion

ayi

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 <code>repadmin</code> 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 <code>lastLogon</code> 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. <a href="https://blogs.technet.microsoft.com/askpfeplat/2014/04/13/how-lastlogontimestamp-is-updated-with-kerberos-s4u2self/" rel="noopener nofollow ugc">https://blogs.technet.microsoft.com/askpfeplat/2014/04/13/how-lastlogontimestamp-is-updated-with-kerberos-s4u2self/</a>
Leçon apprise - ne fournissez des rapports sur les attributs <code>lastLogon</code> aux équipes de sécurité informatique que lorsqu’il s’agit de connexions Administrateur.
<hr>
Source : [Server Fault](<a href="https://blogs.technet.microsoft.com/askpfeplat/2014/04/13/how-lastlogontimestamp-is-updated-with-kerberos-s4u2self/" rel="noopener nofollow ugc">https://blogs.technet.microsoft.com/askpfeplat/2014/04/13/how-lastlogontimestamp-is-updated-with-kerberos-s4u2self/</a>](<a href="https://blogs.technet.microsoft.com/askpfeplat/2014/04/13/how-lastlogontimestamp-is-updated-with-kerberos-s4u2self/" rel="noopener nofollow ugc">https://blogs.technet.microsoft.com/askpfeplat/2014/04/13/how-lastlogontimestamp-is-updated-with-kerberos-s4u2self/</a>)

ayi_2

<pre><code class="lang-auto">repadmin /showobjmeta DCNAME "ObjectDN"

</code></pre>
Affichera le DSA d’origine.
Exemple :
<pre><code class="lang-auto">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

</code></pre>