Ключові висновки
- Дізнайтеся про сім event ID Windows, що мають значення для аудиту logon у AD, та чому справжній logoff фіксують лише робочі станції.
- Створіть паралелізований PowerShell-скрипт, що за секунди витягує історію logon з кожного domain controller.
- Сплануйте retention журналів з формулою sizing, налаштуваннями GPO та Windows Event Forwarding у SIEM.
- Порівняйте нативний аудит, сторонніх аудиторів і запобігання FIDO2 як три відповіді на одне питання.
Відстеження входу та виходу користувачів у Active Directory — це поєднання налаштувань аудиту Group Policy, правильних event ID Windows (4624, 4625, 4634, 4647, 4768, 4769, 4776), масштабного PowerShell, форвардингу журналів у SIEM та стратегії retention, узгодженої з SOX, HIPAA, PCI DSS 4.0, NIS2 та DORA. Domain controller видає квитки Kerberos, але не бачить завершення сесії — тож форвардинг подій з робочих станцій є обов'язковим у будь-якому сучасному гібридному парку.
Три дні. Саме настільки сягають журнали безпеки більшості domain controller, перш ніж перезаписатися — і адміністратор лишається сліпим, щойно на стіл потрапляє account lockout, інсайдерський інцидент або розслідування скомпрометованих облікових даних. Нативний аудит Active Directory створювали для статичних робочих станцій і on-prem-доменів, а не для RDS-ферм, VPN-тунелів, гібридної ідентичності та паралельних SaaS-сесій. Цей посібник проходить кожен рівень — від event 4624 на domain controller до фішинг-стійкої автентифікації FIDO2, що видаляє більшість парольного шуму з вашого аудит-конвеєра в самому джерелі.
Нативний аудит logon у AD: налаштування GPO, event ID та реальні обмеження
Активація аудиту Logon/Logoff через Advanced Audit Policy Configuration
Стандартні налаштування audit logon на свіжому домені занадто дозвільні для форензики й занадто тихі для compliance. Відкрийте Default Domain Controllers Policy і перейдіть до Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Logon/Logoff. Увімкніть Success і Failure для Logon, Logoff, Account Lockout та Special Logon. Доповніть це налаштуваннями Account Logon > Audit Kerberos Authentication Service і Audit Credential Validation, щоб фіксувати спроби NTLM-fallback.
Довідник Event ID (4624, 4625, 4634, 4647, 4768, 4769, 4776) і чому domain controller не реєструє справжніх подій logoff
| Event ID | Значення | Де реєструється |
|---|---|---|
| 4624 | Успішний logon | DC + робоча станція |
| 4625 | Невдалий logon | DC + робоча станція |
| 4634 / 4647 | Logoff / logoff, ініційований користувачем | Лише робоча станція |
| 4768 / 4769 | Kerberos TGT / сервісний квиток | Domain controller |
| 4776 | Перевірка облікових даних NTLM | Domain controller |
Domain controller видає квитки Kerberos, але не бачить завершення сесії — тож справжні logoff живуть на endpoint, а не на DC. Довідник Microsoft Learn щодо event 4624 документує повну схему та коди Logon Type, які зміщують інтерпретацію далі по конвеєру.
PowerShell-скрипти для витягування історії logon з усіх domain controller
Сучасний скрипт Get-WinEvent + FilterHashtable з паралельною обробкою
Get-EventLog застарів з PowerShell 5 і не справляється з великими лісами. Використовуйте Get-WinEvent з FilterHashtable і опитуйте кожний domain controller паралельно:
powershell
$DCs = (Get-ADDomainController -Filter *).HostName
$DCs | ForEach-Object -Parallel {
Get-WinEvent -ComputerName $_ -FilterHashtable @{
LogName='Security'; ID=4624,4625; StartTime=(Get-Date).AddDays(-7)
} | Select TimeCreated, MachineName, @{n='User';e={$_.Properties[5].Value}}
} -ThrottleLimit 10 | Export-Csv .\logons.csv -NoTypeInformation
Додайте try/catch навколо кожного віддаленого виклику, щоб обробляти недосяжні DC без переривання запуску.
Кореляція пар 4624/4634 і відстеження сесій RDS/VPN
Справжню тривалість сесії можна обчислити, лише поєднавши кожний 4624 з відповідним 4634/4647 за LogonID (Properties[7]). Для RDS опитуйте Microsoft-Windows-TerminalServices-LocalSessionManager/Operational (ID 21, 23, 25) на session host. Для VPN парсіть RRAS або журнали вашого концентратора та робіть join за іменем користувача й часовою міткою.
Централізація та зберігання журналів logon без втрат даних
Стандартні обмеження журналу безпеки (часто 128 МБ) пояснюють, чому адміністратори на Spiceworks раз у раз скаржаться: «журнали сягають лише трьох днів». Retention треба проєктувати, а не припускати.
Формула sizing і налаштування GPO, щоб журнали не перезаписувалися
Використовуйте формулу: події/користувач/день × користувачі × дні retention × 1,5 КБ = потрібний розмір журналу. Для 500 користувачів, що генерують ~80 подій/день за 90 днів, плануйте ~5,4 ГБ на DC. Налаштуйте через Computer Configuration > Policies > Windows Settings > Security Settings > Event Log: задайте максимальний розмір, оберіть Архівувати журнал, коли він заповнений замість перезапису та стежте за тиском диска на domain controller.
Windows Event Forwarding (WEF) + SIEM/Splunk для гібридних AD- та Entra ID-середовищ
Розгорніть WEF-collector, поширте GPO з URL subscription manager та фільтруйте event ID 4624/4625/4634/4647/4776 через XPath. Форвардьте до Splunk через heavy forwarder, потім додавайте журнали входу Entra ID через Graph API, щоб корелювати гібридні ідентичності в одній панелі.
Від детекції до запобігання: як FIDO2 і безпарольний підхід зменшують вашу аудит-поверхню
Детекція масштабується лінійно з парольним шумом. Verizon 2025 DBIR фіксує зловживання обліковими даними у 22% усіх breaches, а вкрадені облікові дані разом з фішингом сукупно перевищують половину інцидентів з людським елементом. Заберіть пароль — і цей вектор обвалюється в самому джерелі: brute force, password spraying та спроби NTLM-downgrade зникають. Ваш SOC припиняє перебирати штормі 4625 і починає полювати на справжні аномалії.
Обсяг SIEM до/після та рецепти патернів MITRE ATT&CK (T1078, T1110, T1558)
На парку з 1 000 користувачів очікуйте, що події 4625/4776 знизяться на порядок після розгортання Hideez FIDO2. Облікові дані, прив'язані до апаратного ключа, нейтралізують T1110 (brute force), T1558 (Kerberoasting) і більшість варіантів T1078 (valid accounts), оскільки приватний ключ ніколи не залишає security key.
Зіставлення з compliance: SOX, HIPAA, PCI DSS 4.0, NIS2 і DORA
PCI DSS 4.0 §8.4 і NIS2 Стаття 21 явно вимагають фішинг-стійкої автентифікації. FIDO2 задовольняє обидві вимоги, водночас формуючи захищені від маніпуляцій записи logon, які приймають аудитори.
DORA Стаття 9 поширює таку саму вимогу на фінансові установи ЄС, а NIST SP 800-63B визначає рівень assurance AAL3, на який зрештою спираються всі п'ять фреймворків.
Каркас рішення: нативний аудит проти стороннього аудитора проти рішення на рівні автентифікації
Вибір між нативним аудитом AD, виділеним аудитором і контролем на рівні автентифікації — це не бінарне рішення. Кожен рівень відповідає на окреме питання: що сталося, що відбувається зараз і чого взагалі не повинно статися.
Матриця оцінювання: вартість, гібридне покриття, alerting у реальному часі та запобігання проти детекції
| Критерій | Нативний AD | Сторонній аудитор | Hideez (рівень auth) |
|---|---|---|---|
| Вартість | Безкоштовно | 3-8 $/користувач/рік | За ключ + ліцензія |
| Гібридне покриття Entra ID | Часткове | Змінне | Повне |
| Alerting у реальному часі | Ні | Так | Не застосовується (запобігає) |
| Підхід | Детекція | Детекція | Запобігання |
Коли ADAudit Plus, UserLock чи Netwrix достатньо — і чому Hideez їх доповнює
Якщо ваш пріоритет — форензичні докази й SOC 2-звітність, сторонній аудитор добре закриває рівень детекції. Hideez не замінює його; він прибирає події на основі облікових даних, на triage яких аудитор витрачає цикли, у багаторівневій архітектурі, лишаючи правилам аудитора зосередитись на справжніх аномаліях замість парольного шуму.
Hideez замінює поверхню атаки на облікові дані фішинг-стійкими FIDO2-входами, які приймають аудитори і обожнюють SOC. Замовте демо, щоб побачити, як це впишеться у ваш парк AD або гібридного Entra ID, або станьте партнером Hideez, щоб надати ту саму перевагу своїм клієнтам.
Поширені запитання
Чому Active Directory не реєструє справжніх подій logoff на domain controller?
Модель квитків Kerberos автентифікує користувача один раз — далі сесія живе на робочій станції. DC видає TGT, але не знає, коли користувач закриває свою сесію доступу. Події logoff (4634, 4647) пишуться локально на endpoint, а не централізовано. Щоб їх захопити, форвардьте журнали робочих станцій через Windows Event Forwarding до collector або SIEM.
Як отримати історію logon користувача AD за допомогою PowerShell на всіх domain controller?
Використовуйте Get-WinEvent -FilterHashtable проти кожного DC, що повертає Get-ADDomainController -Filter *, з ForEach-Object -Parallel для масштабу. Фільтруйте за event ID logon 4624, експортуйте в CSV, потім корелюйте з 4634, щоб обчислити справжню тривалість сесії.
Аудит logon проти безпарольної автентифікації: що насправді знижує ризик облікових даних?
Аудит виявляє постфактум. Апаратна автентифікація FIDO2 усуває поверхню атаки, нейтралізуючи brute force, фішинг і password spraying у корені.
