我们发现域管理员帐户 – 除了在灾难恢复方案中我们不使用 – 在LastlogonTimeStamp属性中具有最近的日期.据我所知,没有人应该在有关的时间段内(以及几个月之后)使用此帐户,但也许有些白痴已将其配置为运行预定任务.

由于安全日志事件的数量(以及缺少用于分析的SIEM工具),我想确定哪个DC具有帐户的实际lastlogon时间(即不是复制属性),但我查询了域中的每个DC,并且每个管理员都有一个“无”的lastlogon.

这是林中的子域,因此有人可能已使用此子域管理员帐户在父域中运行某些内容.

除了在LastlogonTimestamp中记录的时间内检查来自16个森林DC的潜在的2000万个事件之外,还有人能想出一种方法来确定哪个DC正在进行登录吗？我想我可以首先定位父域DC(因为子DC似乎没有完成auth).

附录

此请求的原因是我们的IT安全团队,他们想知道我们为什么经常使用默认域管理员帐户登录.

我们知道我们没有登录它.事实证明,有一种称为“Kerberos S4u2Self”的机制,当一个作为本地系统运行的调用进程正在进行某些权限提升时.它在域控制器上以管理员身份进行网络登录(非交互式).由于它是非交互式的,这就是为什么任何DC上的帐户都没有lastlogon(此帐户从未登录到任何当前域控制器).

这篇文章解释了为什么事情ping你的日志并使你的安全团队有小猫(源机器是Server 2003,使事情变得更糟).以及如何追踪它. https://blogs.technet.microsoft.com/askpfeplat/2014/04/13/how-lastlogontimestamp-is-updated-with-kerberos-s4u2self/

获得的经验教训 – 仅在涉及管理员登录时向IT安全团队提供有关lastlogon属性的报告.

repadmin /showobjMeta DCNAME "ObjectDN"

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