LastLogon против LastLogonTimestamp в Active Directory

LastLogon vsLastLogonTimestamp

Сначала по-простому: почему эти атрибуты это не «одно и то же»

Active Directory хранит дневник о логинах не потому что ей нравится наблюдать за пользователями, а потому что кому-то нужно знать, кто последний раз включил почту и когда пропал стажёр. Но AD ведёт себя экономно: некоторые атрибуты не реплицируются между контроллерами домена (DC), а некоторые — реплицируются редко, чтобы не превращать сеть в локомотив репликаций.

LastLogon — точно, но локально

• Это атрибут, который обновляется только на том DC, который аутентифицировал пользователя.
• Не реплицируется. Поэтому один DC может показывать одно значение, другой — другое.
• Это самый надёжный показатель реального, точного времени логона на конкретном контроллере. Но чтобы узнать реальную «последнюю активность» по всему лесу, нужно опросить все DC и взять максимальное значение.

LastLogonTimestamp — реплицируемая "приближенка"

• Его сделали для того, чтобы было удобно получать приблизительное время последнего логона по всем DC без опроса каждого.
• Реплицируется между контроллерами домена, но не при каждом логоне — обновление происходит только если текущее событие логона «значимо» по сравнению с уже записанным временем (по умолчанию — интервал порядка двух недель). Это снижает трафик репликаций.
• Отлично подходит для задач типа «найти неактивных пользователей за 90 дней» — но не для расследования «кто последний раз логинался вчера в 13:04».

Типичные ловушки и ошибки при использовании

• Если ты посмотрел только LastLogon на текущем DC — ты можешь получить устаревший или неполный результат. Чтобы быть уверенным, опрашивай все DC.
• Если ты полагаешься на LastLogonTimestamp для расследования инцидента «кто заходил вчера» — ты ошибаешься. Это агрегатная и сглаженная метрика.
• Иногда атрибуты равны нулю (значение = 0 или отсутствует) — значит пользователь никогда не аутентифицировался на контроллере, либо атрибут ещё не обновлён.

Как правильно получить реальное последнее время логона (PowerShell)

Если хочешь «истину в последней инстанции», опрашивай все DC и берёшь максимум lastLogon:

Import-Module ActiveDirectory
$User = "domain\username"
$DCs = Get-ADDomainController -Filter *
$max = 0
foreach ($dc in $DCs) {
$u = Get-ADUser -Identity $User -Server $dc.HostName -Properties lastLogon
if ($u.lastLogon -gt $max) { $max = $u.lastLogon }
}
if ($max -ne 0) { [DateTime]::FromFileTime($max) } else { "Never logged on (or attribute empty)" }

Если нужен быстрый вариант с LastLogonTimestamp (реплицируемый, но с погрешностью):

Get-ADUser -Identity domain\username -Properties LastLogonTimestamp |
Select-Object Name,@{N='LastLogonTimestamp';E={[DateTime]::FromFileTime($_.LastLogonTimestamp)}}

И помни: модуль AD в PowerShell добавляет удобное свойство LastLogonDate у некоторых командлетов — это уже сконвертированный в человекочитаемую дату LastLogon.

Ещё какие бывают «logon» вещи — и зачем их надо знать

AD-атрибуты не — единственный источник истины. Вот что ещё может встречаться в практике и логах, и почему это важно.

1) События безопасности (Windows Event Log)

Если тебе нужна хронология и контекст (какой компьютер, тип логона, процесс, SID), смотри логи:

• 4624 — успешный логон (Authentication). Здесь есть поле Logon Type (число), показывает как пользователь залогинился.
• 4634 — выход (logoff).
• 4768/4769/4776 — события Kerberos/NTLM/TGT, дают понимание авторизаций и запросов тикетов.

2) Logon Type (числовые коды) — что они значат

Когда видишь 4624, там будет Logon Type = N. Вот наиболее важные типы:

• 2 — Interactive (консоль, локальная клавиатура).
• 3 — Network (SMB, сетевой доступ, часто файловые шаринги).
• 4 — Batch (запланированные задачи).
• 5 — Service (службы).
• 7 — Unlock (разблокировка сессии).
• 8 — NetworkCleartext (аутентификация с передачей пароля в чистом виде).
• 9 — NewCredentials (RunAs / New credentials).
• 10 — RemoteInteractive (RDP).
• 11 — CachedInteractive (логон с использованием кешированных учётных данных — полезно для ноутбуков офлайн).

Эти числа помогают отличить «пользователь сидел за ноутом» от «скрипт на сервере сделал bind».

3) SIEM / Windows Event Forwarding

Если хочешь точную картину по всем хостам — собирай все 4624/4634 в SIEM, Elastic или Azure Sentinel. AD-атрибуты — это грубая справка, а логи — подробный допрос.

4) Azure AD и облачные логины

Если у тебя гибридная среда — у пользователей есть ещё и Azure AD signInActivity и прочие поля в Microsoft Graph. Они имеют свои нюансы и задержки, не путай их с on-prem AD.

Практические советы (боевые и тривиальные)

• Для инвентаризации неактивных аккаунтов используем LastLogonTimestamp — он реплицируется и подходит для долговременной аналитики (удаление/блокировка после N дней).
• Для расследования инцидента: опрашивай все DC за lastLogon и собирай события 4624/4768 с конечных хостов.
• Не доверяй одному DC как единственному источнику истинного lastLogon.
• Если атрибуты пустые — проверь, логин был ли вообще интерактивный или это только, скажем, HTTP-binds (some services don’t update these attributes).