Событие logon в журнале windows

При расследовании различных инцидентов администратору необходимо получить информацию кто и когда заходил на определенный компьютер Windows. Историю входов пользователя в доменной сети можно получить из журналов контроллеров домена. Но иногда проще получить информацию непосредсвенно из логов компьютера. В этой статье мы покажем, как получить и проанализировать историю входа пользователей на компьютер/сервер Windows. Такая статистика поможет вам ответить на вопрос “Как в Windows проверить кто и когда использовал этот компьютере”.

Настройка политики аудита входа пользователей в Windows

Сначала нужно включить политик аудита входа пользователей. На отдельностоящем компьютере для настройки параметров локальной групповой политики используется оснастка gpedit.msc. Если вы хотите включить политику для компьютеров в домене Active Directorty, нужно использовать редактор доменных GPO (
gpmc.msc
).

1. Запустите консоль GPMC, создайте новую GPO и назначьте ее на Organizational Units (OU) с компьютерами и / или серверами, для которых вы хотите включить политику аудита событий входа;
2. Откройте объект GPO и перейдите в раздел Computer Configuration -> Policies -> Windows Settings -> Security Settings –> Advanced Audit Policy Configuration -> Audit Policies -> Logon/Logoff;
3. Включите две политики аудита Audit Logon и Audit Logoff. Это позволит отслеживать как события входа, так и события выхода пользователей. Если вы хотите отслеживать только успешные события входа, включите в настройках политик только опцию Success;
4. Закройте редактор GPO и обновите настройки политик на клиентах.

Поиск событий входа пользователей в журнале событий Windows

После того как вы включили политики аудита входа, при каждом входе пользователя в Windows в журнале Event Viewer будет появляться запись о входе. Посмотрим, как она выглядит.

1. Откройте оснастку Event Viewer (
   eventvwr.msc
   );
2. Разверните секцию Windows Logs и выберите журнал Security;
3. Щелкните по нему правой клавишей и выберите пункт Filter Current Log;
4. В поле укажите ID события 4624 и нажмите OK;
5. В окне события останутся только события входа пользователей, системных служб с описанием
   An account was successfully logged on
   ;
6. В описании события указано имя и домен пользователя, вошедшего в систему:

   New Logon:
   Security ID: WINITPRO\a.khramov
   Account Name: a.khramov
   Account Domain: WINITPRO

Если полистать журнал событий, можно заметить, что в нем присутствуют не только события входа пользователей на компьютер. Здесь также будут события сетевого доступа к этому компьютеру (при открытии по сети общих файлов или печати на сетевых принтерах), запуске различных служб и заданий планировщика и т.д. Т.е. очень много лишний событий, которые не относятся ко входу локального пользователя. Чтобы выбрать только события интерактивного входа пользователя на консоль компьютера, нужно дополнительно сделать выборку по значению параметра Logon Type. В таблице ниже перечислены коды Logon Type.

Код Logon Type	Описание
0	System
2	Interactive
3	Network
4	Batch
5	Service
6	Proxy
7	Unlock
8	NetworkCleartext
9	NewCredentials
10	RemoteInteractive
11	CachedInteractive
12	CachedRemoteInteractive
13	CachedUnlock

При удаленном подключении к рабочему столу компьютера по RDP, в журнале событий появится записи с Logon Type 10 или 3. Подробнее об анализе RDP логов в Windows.

В соответствии с этой таблицей событие локального входа пользователя на компьютер должно содержать Logon Type: 2.

Для фильтрации события входа по содержать Logon Type лучше использовать PowerShell.

Анализ событий входа пользователей в Windows с помощью PowerShell

Допустим, наша задача получить информацию о том, какие пользователи входили на этот компьютер за последнее время. Нам интересует именно события интерактивного входа (через консоль) с
LogonType =2
. Для выбора события из журналов Event Viewer мы воспользуемся командлетом Get-WinEvent.

Следующий PowerShell скрипт выведет история входа пользователей на текущий компьютер и представит ее в виде графической таблицы Out-GridView.

$query = @'
<QueryList>
<Query Id='0' Path='Security'>
<Select Path='Security'>
*[System[EventID='4624']
and(
EventData[Data[@Name='VirtualAccount']='%%1843']
and
EventData[Data[@Name='LogonType']='2']
)
]
</Select>
</Query>
</QueryList>
'@
$properties = @(
@{n='User';e={$_.Properties[5].Value}},
@{n='Domain';e={$_.Properties[6].Value}},
@{n='TimeStamp';e={$_.TimeCreated}}
@{n='LogonType';e={$_.Properties[8].Value}}
)
Get-WinEvent -FilterXml $query | Select-Object $properties|Out-GridView

Если нужно выбрать события входа за последние несколько дней, можно добавить pipe с таким условием:

|Where-Object {$_.TimeStamp -gt '5/10/22'}

Командлет Get-WinEvent позволяет получить информацию с удаленных компьютеров. Например, чтобы получить историю входов с двух компьютеров, выполните следующий скрипт:

'msk-comp1', 'msk-comp2' |
ForEach-Object {
Get-WinEvent -ComputerName $_ -FilterXml $query | Select-Object $properties
}

Время на прочтение
4 мин

Количество просмотров 262K

Рэнди Франклин Смит (CISA, SSCP, Security MVP) имеет в своем арсенале очень полезный документ, рассказывающий о том, какие события (event IDs) обязательно должны отслеживаться в рамках обеспечения информационной безопасности Windows. В этом документе изложена крайне полезная информация, которая позволит Вам “выжать” максимум из штатной системы аудита. Мы подготовили перевод этого материала. Заинтересованных приглашаем под кат.

О том, как настроить аудит, мы уже обстоятельно писали в одном из наших постов. Но из всех event id, которые встречаются в журналах событий, необходимо остановить свое внимание на нескольких критических важных. На каких именно – решать каждому. Однако Рэнди Франклин Смит предлагает сосредоточить внимание на 10 важных событиях безопасности в Windows.

Контроллеры доменов

Event ID — (Категория) — Описание

1) 675 или 4771
(Аудит событий входа в систему)
Событие 675/4771 на контроллере домена указывает на неудачную попытку войти через Kerberos на рабочей станции с доменной учетной записью. Обычно причиной этого является несоответствующий пароль, но код ошибки указывает, почему именно аутентификация была неудачной. Таблица кодов ошибок Kerberos приведена ниже.

2) 676, или Failed 672 или 4768
(Аудит событий входа в систему)
Событие 676/4768 логгируется для других типов неудачной аутентификации. Таблица кодов Kerberos приведена ниже.
ВНИМАНИЕ: В Windows 2003 Server событие отказа записывается как 672 вместо 676.

3) 681 или Failed 680 или 4776
(Аудит событий входа в систему)
Событие 681/4776 на контроллере домена указывает на неудачную попытку входа в систему через
NTLM с доменной учетной записью. Код ошибки указывает, почему именно аутентификация была неудачной.
Коды ошибок NTLM приведены ниже.
ВНИМАНИЕ: В Windows 2003 Server событие отказа записывается как 680 вместо 681.

4) 642 или 4738
(Аудит управления учетными записями)
Событие 642/4738 указывает на изменения в указанной учетной записи, такие как сброс пароля или активация деактивированной до этого учетной записи. Описание события уточняется в соответствие с типом изменения.

5) 632 или 4728; 636 или 4732; 660 или 4756
(Аудит управления учетными записями)
Все три события указывают на то, что указанный пользователь был добавлен в определенную группу. Обозначены Глобальная (Global), Локальная (Local) и Общая (Universal) соответственно для каждого ID.

6) 624 или 4720
(Аудит управления учетными записями)
Была создана новая учетная запись пользователя

7) 644 или 4740
(Аудит управления учетными записями)
Учетная запись указанного пользователя была заблокирована после нескольких попыток входа

517 или 1102
(Аудит системных событий)
Указанный пользователь очистил журнал безопасности

Вход и выход из системы (Logon/Logoff)

Event Id — Описание

528 или 4624 — Успешный вход в систему
529 или 4625 — Отказ входа в систему – Неизвестное имя пользователя или неверный пароль
530 или 4625 Отказ входа в систему – Вход в систему не был осуществлен в течение обозначенного периода времени
531 или 4625 — Отказ входа в систему – Учетная запись временно деактивирована
532 или 4625 — Отказ входа в систему – Срок использования указанной учетной записи истек
533 или 4625 — Отказ входа в систему – Пользователю не разрешается осуществлять вход в систему на данном компьютере
534 или 4625 или 5461 — Отказ входа в систему – Пользователь не был разрешен запрашиваемый тип входа на данном компьютере
535 или 4625 — Отказ входа в систему – Срок действия пароля указанной учетной записи истек
539 или 4625 — Отказ входа в систему – Учетная запись заблокирована
540 или 4624 — Успешный сетевой вход в систему (Только Windows 2000, XP, 2003)

Типы входов в систему (Logon Types)

Тип входа в систему — Описание

2 — Интерактивный (вход с клавиатуры или экрана системы)
3 — Сетевой (например, подключение к общей папке на этом компьютере из любого места в сети или IIS вход — Никогда не заходил 528 на Windows Server 2000 и выше. См. событие 540)
4 — Пакет (batch) (например, запланированная задача)
5 — Служба (Запуск службы)
7 — Разблокировка (например, необслуживаемая рабочая станция с защищенным паролем скринсейвером)
8 — NetworkCleartext (Вход с полномочиями (credentials), отправленными в виде простого текст. Часто обозначает вход в IIS с “базовой аутентификацией”)
9 — NewCredentials
10 — RemoteInteractive (Терминальные службы, Удаленный рабочий стол или удаленный помощник)
11 — CachedInteractive (вход с кешированными доменными полномочиями, например, вход на рабочую станцию, которая находится не в сети)

Коды отказов Kerberos

Код ошибки — Причина

6 — Имя пользователя не существует
12 — Ограничение рабочей машины; ограничение времени входа в систему
18 — Учетная запись деактивирована, заблокирована или истек срок ее действия
23 — Истек срок действия пароля пользователя
24 — Предварительная аутентификация не удалась; обычно причиной является неверный пароль
32 — Истек срок действия заявки. Это нормальное событие, которое логгируется учетными записями компьютеров
37 — Время на рабочей машины давно не синхронизировалось со временем на контроллере домена

Коды ошибок NTLM

Код ошибки (десятичная система) — Код ошибки (16-ричная система) — Описание

3221225572 — C0000064 — Такого имени пользователя не существует
3221225578 — C000006A — Верное имя пользователя, но неверный пароль
3221226036 — C0000234 — Учетная запись пользователя заблокирована
3221225586 — C0000072 — Учетная запись деактивирована
3221225583 — C000006F — Пользователь пытается войти в систему вне обозначенного периода времени (рабочего времени)
3221225584 — C0000070 — Ограничение рабочей станции
3221225875 — C0000193 — Истек срок действия учетной записи
3221225585 — C0000071 — Истек срок действия пароля
3221226020 — C0000224 — Пользователь должен поменять пароль при следующем входе в систему

Еще раз продублируем ссылку на скачивание документа на сайте Рэнди Франклина Смита www.ultimatewindowssecurity.com/securitylog/quickref/Default.aspx. Нужно будет заполнить небольшую форму, чтобы получить к нему доступ.

P.S. Хотите полностью автоматизировать работу с журналами событий? Попробуйте новую версию NetWrix Event Log Manager 4.0, которая осуществляет сбор и архивирование журналов событий, строит отчеты и генерирует оповещения в режиме реального времени. Программа собирает данные с многочисленных компьютеров сети, предупреждает Вас о критических событиях и централизованно хранит данные обо всех событиях в сжатом формате для удобства анализа архивных данных журналов. Доступна бесплатная версия программы для 10 контроллеров доменов и 100 компьютеров.

Блог Event Log Explorer

Оригинал статьи тут http://eventlogxp.com/blog/logon-type-what-does-it-mean/

В описаниях некоторых событий журнала безопасности, связанных с сессиями входа в системы (например, 4624 и 4625)
присутствует параметр Тип входа (Logon type), но его описание слишком короткое:

В поле «Тип входа» указан тип выполненного входа. Самыми распространенными являются типы 2 (интерактивный) и 3 (сетевой).

В статье https://technet.microsoft.com/en-us/library/cc787567(v=ws.10).aspx (Audit Logon Events)
приводится более детальное описание этого параметра.
Эта статья на сайте Microsoft описывает аудит событий входа для старых систем, до Windows Vista.
Но константы Типа входа актуальны и для более новых операционных систем Windows.

Так что сейчас мы рассмотри описания от Microsoft и прокомментируем их.

Тип входа 2: Интерактивный. Пользователь непосредственно вошел на этот компьютер.

Событие с типом входа = 2 записывается в журнал безопасности когда пользователь вошел
или попытался войти в систему непосредственно локально, используя клавиатуру и введя
имя пользователя и пароль в окне входа в систему.
Событие с типом входа = 2 возникает при использовании как локальной так и
доменной учетной записи.
Если пользователь входит с доменной учетной записью, событие с типом входа = 2
появится если пользователь будет действительно аутентифицирован в домене (контроллером домена)
В случае, если контроллер домена недоступен, но пользователь предоставил валидный пароль,
закэшированный в локальном компьютере, Windows поставит тип входа = 11.

Тип входа 3: Сетевой. Пользователь по сети подключился к этому компьютеру и авторизовался на нем.

Обычно такое событие появляется при подключении по сети к разделяемым (shared) ресурсам — папкам, файлам, принтерам.
Подключение с типом входа = 3 может быть установлено и с локального компьютера.

Тип входа 4: Пакетный.

Этот тип входа используется при выполнении пакетных заданий без непосредственного участия пользователя.
Например, когда запускается задание планировщика. Когда используется планировщик Windows и
приходит время запустить задание, Windows может создать новую пользовательскую сессию, чтобы выполнить задание от имени пользователя.
При этом регистрируются события (4648, 4624/4625).

Если запланированное задание сконфигурировано так, что не должно запускаться без интерактивного сеанса пользователя,
то новая сессия не создается и события не регистрируются.

Тип входа 5: Служба. Service Control Manager запустил службу (service).

Такое событие возникает когда Windows запускает службу от имени пользователя.
Windows создает новую сессию для запуска такой службы.
Так происходит только, если служба использует обычную учетную запись.
Если используется специальная учетная запись, например, “Local System”, “NT AUTHORITY\LocalService” или “NT AUTHORITY\NetworkService”,
то Windows не создает новых сессий.
Когда сервис остановится, новая сессия будет закрыта и будет зарегистрировано событие выхода (4634).
Имейте ввиду, что описание события не содержит информации о запускаемом сервисе или процессе.
Когда регистрируется событие Аудит отказа (4625) с типом входа = 5, это обычно означает
что пароль учетной записи для запуска сервиса был изменен пользователем и следует обновить
пераметры учетной записи для запуска службы в настройках того приложения, чья служба запускается.

Тип входа 7: разблокирование. Рабочая станция разблокирована.

Событие с типом входа = 7 происходит когда пользователь разблокировывает (или пытается это сделать) ранее заблокированный компьютер.
Имейте ввиду, что когда пользователь разблокировывает компьютер, Windows создает новую сессию (или даже 2 сессии в зависимости
от полномочий пользователя) и сразу же их завершает, после прохождения аутентификации (событие 4634).

При переключении между учетными записями уже осуществившими вход в систему с помощью функции быстрого переключения
учетной записи (Fast User Switching), Windows создает событие 4624 с типом входа = 2 (интерактивный).

Когда регистрируется событие отказа 4625 с типом входа = 7, это обычно означает что вы ошиблись при вводе пароля
или кто-то пытался подобрать пароль, чтобы разблокировать компьютер.

Тип входа 8: NetworkCleartext. Пользователь вошел на данный компьютер через сеть.
Пароль пользователя передан в пакет проверки подлинности в его нехешированной форме.
Встроенная проверка подлинности упаковывает все хешированные учетные записи перед их отправкой через сеть.
Учетные данные не передаются через сеть открытым текстом.

Это событие возникает, если пароль пользователя был получен по сети открытым текстом.
Такое событие может произойти когда пользователь входит в
IIS (Internet Information Services) с базовым методом аутентификации.
Передача паролей в формате открытого текста опасна потому что пароли могут быть перехвачены и раскрыты.
Если нет возможности использовать более надежную аутентификацию, то стоит хотя бы защитить сетевое соединение
(используя зашифрованные протоколы типа SSL/TLS, создав защищенную виртуальную частную сеть и т.д.).

Тип входа 9: NewCredentials. Посетитель клонировал свой текущий маркер и указал новые учетные записи для исходящих соединений. Новый сеанс входа в систему имеет ту же самую локальную тождественность, но использует отличающиеся учетные записи для сетевых соединений.

Это событие регистрируется, когда используется команда «Запустить от имени» вместе с опцией «/netonly».
Это нужно для запуска программы с дополнительными привилегиями для сетевых компьютеров.
Например, нужно запустить Event Log Explorer и дать ему дополнительные права для некоторого компьютера
или домена (это может понадобиться если вы захотите использовать определенный компьютер в качестве сервера
описаний событий, но ваших текущих прав не достаточно для доступа к администраторским ресурсам этого сервера).
В таком случае вы можете запустить Event Log Explorer через командную строку со следующими параметрами:

runas.exe /netonly /user:SERVER\Administrator “c:\program files\event log explorer\elex.exe”

где SERVER — имя сервера, с которого предполагается брать описания событий (также потребуется настроить
имя сервера в программе).
При запуске программы, Windows потребует ввести пароль пользователя Administrator
для сервера SERVER.
Event Log Explorer запустится даже если вы введете неправильный пароль.
При этом будет создана новая пользовательская сессия с учетными данными текущего пользователя
и в журнал будет записано событие 4624 с типом входа = 9.
А событие выхода из системы для этой сессии будет записано после того, как приложение будет завершено.
Также, в журнале безопасности сервера SERVER будут записаны события 4624 или 4625
с типом входа = 3, но только в момент обращения нашего приложения к разделяемым ресурсам сервера SERVER.
То есть, когда Event Log Explorer попытается открыть файл описаний событий на сервере SERVER.

Тип входа 10: RemoteInteractive. Пользователь выполнил удаленный вход на этот компьютер, используя Terminal Services или Remote Desktop.

Этот тип входа похож на 2 (интерактивный), но пользователь подключаетс к компьютеру с удаленного компьютера
через RDP, используя Удаленный рабочий стол (Remote Desktop), сервисы терминального доступа (Terminal Services)
или Удаленный помощник (Remote Assistance).

Тип входа 11: CachedInteractive. Пользователь вошел на этот компьютер с сетевыми учетными данными, которые хранились локально на компьютере. Контроллер домена не использовался для проверки учетных данных.

Когда пользователь входит в домен, Windows кэширует учетные данные пользователя локально, так что он позже может войти даже если контроллер домена будет недоступен.
По умолчанию, Windows кэширует 10-25 последних использованных доменных учетных записей (это зависит от версии Windows).
Когда пользователь пытается войти с доменной учетной записью, а контроллер домена не доступен,
Windows проверяет учетные данные по сохраненным хэшам и регистрирует события 4624 или 4625 с типом входа = 11.

Скачать Event Log Explorer

Посмотреть цены на Event Log Explorer

Logon/Logoff events in the Security log correspond to the Audit logon events policy category, which comprises nine subcategories. As the name implies, the Logon/Logoff category’s primary purpose is to
allow you to track all logon sessions for the local computer. As we discussed
earlier, there is a subtle difference between authentication events, which are
covered by the Account Logon events discussed in the previous chapter, and
logon events, which track access to a given computer. No matter which type of account (i.e., domain or local) or which type of logon session (e.g., interactive, network, remote desktop) the Logon/Logoff category generates a logon event and a logoff event at the beginning and end of each logon session. Those two events are logged by the Logon and Logoff subcategories.

As for the other seven subcategories, some of them have
nothing to do with logon or logoff activity. You’ll see some events that allow
you to track the use of Terminal Services, screensaver logons, and so forth. In
our opinion, the three IP Security (IPsec)-related subcategories and the
Network Policy Server subcategory belong somewhere else. Windows
provides IPsec support for authentication, encryption, and integrity at the
IP-packet level. Network Policy Server a role that can be added to Server 2008,
as well as the Microsoft’s RADIUS Server role. It includes what was previously
known as Internet Access Server (IAS) and Network Access Protection (NAP). Regardless,
Microsoft has done a lot to help you track every avenue that is used to access
the server.

Logon/Logoff Subcategories	Comment
Logon	Use logon ID to correlate other events
Logoff	Not always present
Account Lockout	Not used (see Chapter 4 for lockout events)
IPsec Main Mode	Establish Internet Key Exchange (IKE)
IPsec Quick Mode	IPsec security associations
IPsec Extended Mode	Multiple authentications
Special Logon	Admin type logons
Other Logon/Logoff Events	Screensaver, Remote Desktop. etc.
Network Policy Server	Combination of IAS and NAP

Logon Events

Whether a user tries to log on by using a local SAM
account or by using a domain account, the Logon subcategory records the attempt
on the system to which the user tried to log on as shown below. When the user logs on to a workstation’s console, the workstation records
a Logon/Logoff event. When you access a Windows server on the network, the
relevant Logon/Logoff events appear in the server’s Security log. So, although
account logon events that are associated with domain accounts are centralized
on DCs, Logon/Logoff events are found on every system in the domain. The diagram below demonstrates the event IDs that are recorded when a user initially logs on
interactively to a workstation and accesses a shared folder on a file server.
These events are the same whether the user logs on with a local account or a
domain account.

How do you link a successful logon event to its
corresponding logoff event? You use the Logon ID field in the New Logon section.
Do not confuse this with the Logon ID field in the Subject section; the latter
displays the logon ID (0x3e7 in our example below) of the computer or server on which the event is recorded. The logon ID (0xe9cd0 in our example) is a
unique number between system restarts (on that system) that identifies a particular
logon session.

You might think by looking for a subsequent instance of
event ID 4634 that has the same logon ID as an instance of event ID 4624, you can
show when a user logged on and logged off. However, Windows doesn’t log event
ID 4634 in the way you’d expect, especially for network logons.

Let’s discuss interactive logons first. When Sue logs on
to her workstation, Windows logs event ID 4624 with logon type 2 and the logon
ID for the logon session. When Sue logs off, Windows logs event ID 4634 with
the same logon ID. But what if the system crashes or is unceremoniously powered
down before Sue logs off? When Windows restarts, it might reconstruct the fact
that Sue was logged on and record an instance of event ID 4634. Taken
literally, the event log won’t make sense because you’ll see a system restart
followed by a logoff. Logging that artificial instance of event ID 4634 is a
bit of a formality. At any rate, tracking user logoffs in a workstation’s
Security log is pretty easy.

Tracking network-session logoffs in a server’s Security
log is another story. When a user maps to a shared folder, the server logs
event ID 4624 with the logon ID of the logon session. However, if the user
opens no files and no other activity occurs on the network connection, the
server closes the logon session after a period of time to conserve
resources—even if the user remains connected to that share. This
server-initiated logoff is invisible to the user because when he or she finally
accesses a file, the server opens a new logon session.

DC Security logs contain many Logon/Logoff events that are
generated by computer accounts as opposed to user accounts. As with
computer-generated account logon events, you can recognize these logon and
logoff events because the Account Name field in the New Logon section will list
a computer name followed by a dollar sign ($). You can ignore
computer-generated Logon/Logoff events.

The Logon Process description field in the Detailed
Authentication Information section identifies the Windows process that
submitted the logon request. A logon process collects identification and
authentication information and then uses Local Security Authority services to
log on users. Because different logon processes handle specific logon types and
scenarios, the logon process name can help you fill in some gaps in the
information provided by Logon/Logoff events.

For instance, you might see event ID 4624 with logon type
3 and Bob’s username. Does that mean that Bob connected to a Windows resource
such as a shared folder or that he accessed a Web page on the server? If the
logon process is “advapi,” you can determine that the logon was a Web-based
logon: IIS processes logon requests through the advapi process. If the logon
was to a Windows resource and authenticated via Kerberos, the Logon Process
field would list “Kerberos.” Generally, the Logon Process field provides a hint
at how the user tried to access the system: at its console, through Server
Message Block (SMB) or Common Internet File System (CIFS) for shared-folder
access, or through IIS. Some logon processes are authentication-protocol
specific as shown in the chart below.

Process	Explanation
Winlogon	Windows Logon Process
Schannell	Secure connection such as SSL
KSecDD	Kernel Security Device Driver
Secondary Logon Service	(runas)
IKE	Internet Key Exchange
HTTP.SYS	Kernel for Web server
SspTest
dsRole	Directory Service function
DS Replication	Directory Service function
CredProvConsent	(user account control)
NtLmSsp	Might also be anonymous authentication

The Authentication Package description field is closely
related to the Logon Process and Process Information fields. These fields
identify the DLL that was used to handle the actual authentication of the logon
attempt. Together, Logon Process and Authentication Package shown below provide valuable information about where and how a user attempted to log on
to the system. This information is important because there are so many ways to
access a Windows computer.

Package	Explanation
MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 or NTLM	NT LanManager, used for logon with local account and others
Wdigest	Digest authentication, usually through IIS
Microsoft Unified Security Protocol Provider or Schannel.dll	TLS/SSL authentication usually has to do with IIS Web content that requires SSL and authentication
Kerberos	Kerberos (default authentication)
Negotiate	Kerberos or NTLM, depending on client capability

Logon/Logoff events aren’t a good option for tracking
domain account authentication or for detecting attempts to use local SAM
accounts to access computers. However, they do provide some information that
would otherwise be unavailable.

First and foremost, Logon/Logoff events on a system give
you a complete record of all attempts to access that computer, regardless of
the type of account used. Second, these events reveal the type of logon, which
you can’t determine from Account Logon events. Logon/Logoff events also provide
the IP address of the client computer, which is useful information for
NTLM-based logons because NTLM Account Logon events don’t provide the IP
address. An example of the first part of a logon event is in
Error!
Reference source not found.
. (When you copy an event, Microsoft also
includes an attempt to explain parts of the event and presents the info in XML
format.) Both network and interactive logons are recorded by event ID 4624.

The logon type fields shown in the chart below are useful because they help you to identify how the user logged on. Logon type 2 indicates an
interactive logon at the console. Type 3 indicates a network logon. You’ll
likely see a lot of these two types; sessions can time out or be torn down and
be re-established by a server without the user being aware of it; most
connections to a server will be type 3.

Logon Type	Description
2	Interactive (logon at keyboard and screen of system)
3	Network (i.e., connection to shared folder on this computer from elsewhere on network)
4	Batch (i.e., scheduled task)
5	Service (service startup)
7	Unlock (i.e., unattended workstation with password-protected screen saver)
8	NetworkCleartext (i.e., logon with credentials sent in clear text; most often indicates a logon to IIS with basic authentication)
9	NewCredentials (e.g., RunAs, mapping a network drive with alternate credentials; does not seem to show up in any events) If you want to track users attempting to logon with alternate credentials see event ID 4648.
10	RemoteInteractive (e.g., Terminal Services, Remote Desktop, Remote Assistance)
11	CachedInteractive (logon with cached domain credentials such as when logging on to a laptop when away from the network)

So now you know who logged on and how. Knowing where the
user logged on would also be useful; you can use the identified workstation
name and IP address to track down that information. Keep in mind that in a Dynamic
Host Configuration Protocol (DHCP) environment, computer names and IP addresses
can change from time to time.

Two other events appear under the Logon subcategory. Logon
failures will appear as event ID 4625.

In earlier Windows versions, several different events were
used for failures. Event ID 4625 merges those events and indicates a failure
code that will help to identify the reason for the failure. Microsoft did a good thing by adding the Failure Reason section to Windows
Server 2008 events. This section provides some of the translation for you, but
you can still earn your salt by becoming familiar with all these codes which are shown below.

Status and Sub Status Codes	Description
0xC0000064	user name does not exist
0xC000006A	user name is correct but the password is wrong
0xC0000234	user is currently locked out
0xC0000072	account is currently disabled
0xC000006D	reason not specified (Sub status may provide more information)
0xC000006F	user tried to logon outside his day of week or time of day restrictions
0xC0000070	workstation restriction
0xC0000193	account expiration
0xC0000071	expired password
0xC0000133	clocks between DC and other computer too far out of sync
0xC0000224	user is required to change password at next logon
0xC0000225	evidently a bug in Windows and not a risk

Finally, this subcategory includes event ID 4648 (A logon
was attempted using explicit credentials), which will appear in a variety of
situations, such as when RunAs is invoked or when a scheduled task runs.

Logoff Events

Ostensibly, the Logoff subcategory should also provide the
ability to track the logon session that relates to a logoff (event ID 4634).
Unfortunately, the value of the Logoff subcategory is questionable at best;
these events don’t always tell you exactly when a particular user logged off.
For example if a dirty shutdown occurs, a logoff event will appear only during
the subsequent startup, when the operating system realizes that the user is no
longer connected.

To compensate for the problems with using event ID 4634 to
accurately track logoffs, Windows also logs event ID 4647 (A user initiated a
logoff). This event indicates that the user (rather than the system) started
the logoff process. Event ID 4634 usually occurs a couple of seconds later.
Event ID 4647 is probably a better event to use for tracking the termination of
interactive logon sessions.

Account Lockout

No events are associated with the Account Lockout
subcategory. You’ll find lockout events under User Account Management
subcategory discussed in Chapter 8.

IPsec Main Mode, IPsec Quick Mode, IPsec Extended Mode

These three subcategories
will generate many events, so you might want to consider turning on this
auditing only for troubleshooting IPsec or firewall issues. IPsec uses packet
filtering and encryption to enhance security and provides authentication,
integrity checking, and optional encryption at the packet level. IPsec can
provide a defense against a network attack by untrusted computers. A security
association (SA) is first established with IPsec Main Mode (also known as Phase
1); if this subcategory is enabled, the events will appear in the audit log.
After Phase 1 is used, Quick Mode (aka Phase II) negotiation takes place. The
negotiation of Quick Mode is protected by the Main Mode encryption and
filtering rules. In Quick Mode, two SAs are used: one for incoming packets and
one for outgoing packets. With Extended Mode, another round of authentications
can be performed. Multiple authentication is part of IPsec support for Network
Access Protection (NAP). See the article
«IPsec
and Group Policy: A Stronger Defense»
for an in-depth description. The events tell you whether negotiation and
authentication is successful and SAs are established, or whether negotiation
fails.

Special Logon

The Special Logon subcategory contains only one event:
event ID 4672, which indicates that a highly privileged user has logged on. This
event lets you know whenever an account that is assigned any
«administrator-equivalent» user rights logs on. For instance, you
will see event ID 4672 in close proximity to logon events (event ID 4624) for
administrators because administrators have most of these administrator-equivalent
rights. This right is a useful for detecting any «super user» account
logons. The right also is logged for any server or application accounts that
log on as a batch job (scheduled task) or system service. See the Logon Type
field in event ID 4624. You can correlate event ID 4672 to event ID 4624 by matching
the Logon ID.

Note: «User rights» and «privileges»
are synonymous terms that are used interchangeably in Windows. Administrator-equivalent
rights are powerful authorities that allow you to circumvent other Windows
security controls. Most administrator-equivalent privileges are intended for
services and applications that interact closely with the operating system. With
just a few exceptions, most administrator-equivalent privileges neither need
nor should be granted to end user accounts.

Other Logon/Logoff Events

The Other Logon/Logoff Events subcategory contains events
that are associated with screensaver, console locking, and Remote Desktop
connections. If your organization has a lockout policy—and it should—these
events can enable an auditor to see whether interactive and remote Terminal
Server sessions are actually being locked out when unattended.

Network Policy Server

The Network Policy Server subcategory logs events
associated with Windows’s Network Policy Server, which provides
Network Access Policy functionality for Windows networks including IPsec,
802.1x, quarantine and more. You can configure granular auditing for this and
other subcategories by using Auditpol.

Bottom Line

Logon/Logoff events correspond to the Audit logon events
policy category and can help you track the local computer’s logon sessions.
Although not the best option for tracking domain account authentication, these
events can provide information you won’t be able to obtain elsewhere.