Тайна входа в учетную запись администратора AD - отметка времени последнего входа

Мы нашли учетную запись администратора домена - что и делаем не использовать, за исключением сценария аварийного восстановления - в атрибуте LastLogonTimeStamp указана недавняя дата. Насколько мне известно, никто не должен был использовать эту учетную запись в соответствующий период времени (и несколько месяцев позже), но, возможно, какой-то идиот настроил ее для выполнения запланированной задачи.

Из-за большого количества событий журнала безопасности (и отсутствия инструмента SIEM для анализа) я хотел определить, на каком DC был фактический lastLogon время (т.е. не атрибут replicated) для учетной записи, но я запросил каждый DC в домене, и у каждого из них есть lastLogon «none» для администратора.

Это дочерний домен в лесу, поэтому возможно, что кто-то использовал эту учетную запись администратора дочернего домена для запуска чего-либо в родительском домене.

Может ли кто-нибудь придумать способ определить, какой DC выполняет вход в систему, кроме изучения возможных 20 миллионов событий из 16 лесных DC за время, записанное в LastLogonTimestamp? Полагаю, я мог бы сначала настроить таргетинг на контроллеры домена родительского домена (поскольку дочерние контроллеры домена, похоже, не выполнили аутентификацию).

Объяснение

[Добавлено после определения причины после использования repadmin согласно ниже]

Первоначальная причина этого запроса была связана с нашей командой ИТ-безопасности, которая задавалась вопросом, почему мы, по-видимому, часто входили в систему с учетной записью администратора домена по умолчанию.

Мы знали, что МЫ не входили в систему. Оказывается, существует механизм под названием «Kerberos S4u2Self», когда вызывающий процесс, работающий как локальная система, выполняет некоторую эскалацию привилегий. Это делает сеть вход в систему (не интерактивный) в качестве администратора на контроллере домена. Поскольку это не интерактивно, поэтому нет lastLogon для учетной записи на любом контроллере домена (эта учетная запись никогда не выполняла вход на какой-либо текущий контроллер домена).

В этой статье объясняется, почему эта штука проверяет ваши журналы и заставляет вашу команду безопасности заводить котят (исходные машины - Server 2003, что еще хуже). И как его отследить. https://blogs.technet.microsoft.com/askpfeplat/2014/04/13/how-lastlogontimestamp-is-updated-with-kerberos-s4u2self/

Извлеченный урок - предоставляйте отчеты только по lastLogon атрибуты для групп ИТ-безопасности, когда это касается входа в систему администратора.