Access windows event log

How to set event log security locally or by using Group Policy

You can customize security access rights to their event logs in Windows Server 2012. These settings can be configured locally or through Group Policy. This article describes how to use both of these methods.

Original product version: В Windows Server 2012 Standard, Windows Server 2012 Datacenter
Original KB number: В 323076


You can grant users one or more of the following access rights to event logs:

You can configure the security log in the same way. However, you can change only Read and Clear access permissions. Write access to the security log is reserved only for the Windows Local Security Authority (LSA).

You can use an Administrative Template Policy for the purpose. The path for the System Eventlog, for example, is:

Computer Configuration\Administrative Templates\Windows Components\Event log Service\System

The setting is configure log access and it takes the same Security Descriptor Definition Language (SDDL) string.

Microsoft suggests moving to this method once you are on Windows Server 2012.

Configure event log security locally

This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, see How to back up and restore the registry in Windows.

For example, the Application log Security Descriptor is configured through the following registry value: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog\Application\CustomSD

The Security Descriptor for each log is specified by using SDDL syntax. For more information about SDDL syntax, see the Platform SDK, or see the article mentioned in the References section of this article.

To construct an SDDL string, note that there are three distinct rights that pertain to event logs: Read, Write, and Clear. These rights correspond to the following bits in the access rights field of the ACE string:

The following is a sample SDDL that shows the default SDDL string for the Application log. The access rights (in hexadecimal) are bold-faced for illustration:

O:BAG:SYD:(D;; 0xf0007 ;;;AN)(D;; 0xf0007 ;;;BG)(A;; 0xf0007 ;;;SY)(A;; 0x5 ;;;BA)(A;; 0x7 ;;;SO)(A;; 0x3 ;;;IU)(A;; 0x2 ;;;BA)(A;; 0x2 ;;;LS)(A;; 0x2 ;;;NS)

For example, the first ACE denies Anonymous Users read, write, and clear access to the log. The sixth ACE permits Interactive Users to read and write to the log.

Modify your local policy to permit customization of the security of your event logs

Back up the %WinDir%\Inf\Sceregvl.inf file to a known location.

Open %WinDir%\Inf\Sceregvl.inf in Notepad.

Scroll to the middle of file, and then put the pointer immediately before [Strings].

Insert the following lines:

Scroll to the end of the file, and then insert the following lines:

AppLogSD=»Event log: Specify the security of the application log in Security Descriptor Definition Language (SDDL) syntax»
SysLogSD=»Event log: Specify the security of the System log in Security Descriptor Definition Language (SDDL) syntax»

Save and then close the file.

Select Start, select Run, type regsvr32 scecli.dll in the Open box, and then press ENTER.

In the DllRegisterServer in scecli.dll succeeded dialog box, select OK.

Use the computer’s local group policy to set your application and system log security

Use group policy to set your application and system log security for a domain, site, or organizational unit in Active Directory

To view the group policy settings that are described in this article in the Group Policy editor, first complete the following steps, and then continue to the Use group policy to set your application and system log security section:

Use a text editor such as Notepad to open the Sceregvl.inf in the %Windir%\Inf folder.

Add the following lines to the [Register Registry Values] section:

MACHINE\System\CurrentControlSet\Services\Eventlog\Directory Service\CustomSD,1,%DSCustomSD%,2
MACHINE\System\CurrentControlSet\Services\Eventlog\DNS Server\CustomSD,1,%DNSCustomSD%,2
MACHINE\System\CurrentControlSet\Services\Eventlog\File Replication Service\CustomSD,1,%FRSCustomSD%,2

Add the following lines to the [Strings] section:

AppCustomSD=»Eventlog: Security descriptor for Application event log»
SecCustomSD=»Eventlog: Security descriptor for Security event log»
SysCustomSD=»Eventlog: Security descriptor for System event log»
DSCustomSD=»Eventlog: Security descriptor for Directory Service event log»
DNSCustomSD=»Eventlog: Security descriptor for DNS Server event log»
FRSCustomSD=»Eventlog: Security descriptor for File Replication Service event log»

Save the changes you made to the Sceregvl.inf file, and then run the regsvr32 scecli.dll command.

Читайте также:  Environmental variables windows 10

Start Gpedit.msc, and then double-click the following branches to expand them:

Computer Configuration
Windows Settings
Security Settings
Local Policies
Security Options

View the right panel to find the new Eventlog settings.

Use group policy to set your application and system log security

In the Active Directory Sites and Services snap-in or the Active Directory Users and Computers snap-in, right-click the object for which you want to set the policy, and then select Properties.

Select the Group Policy tab.

If you must create a new policy, select New, and then define the policy’s name. Otherwise, go to step 5.

Select the policy that you want, and then select Edit.

The Local Group Policy MMC snap-in appears.

Expand Computer Configuration, expand Windows Settings, expand Security Settings, expand Local Policies, and then select Security Options.

Double-click Event log: Application log SDDL, type the SDDL string that you want for the log security, and then select OK.

Double-click Event log: System log SDDL, type the SDDL string that you want for the log security, and then select OK.


For more information about SDDL syntax and about how to construct an SDDL string, see Security Descriptor String Format.


Журналирование Windows EventLog и система оповещения для администраторов

Некоторое количество времени(года три) назад, в попытке найти способ экспорта Windows EventLog, была найдена возможность в удобном виде осуществлять аудит различных событий происходящих на сервере.

Microsoft своими «добрыми» технологиями сделала Windows практически несовместимым со штатными системами журналирования событий(syslog), но оставила небольшую лазейку которую можно использовать.
Лазейка представляет собой комбинацию SNMP trap и программы экспорта системных событий evntwin.

Для работы связки нужен настроенный snmptrapd, а также активированный сервис SNMP на windows сервере (добавляется через «добавление/удаление компонентов»).

Первым делом нужно настроить сервер на который будут сбрасываться сообщения из Eventlog.

После того как сервис настроен, запускаем программу evntwin.exe
Как она выглядит видно на следующем скриншоте.

Принцип использования evntwin прост. Вы выбираете категорию и код события которые Вас интересуют и добавляете их в список. При наступлении события сообщение одновременно будет сохранено в EventLog, а также будет «трапнуто» на сервер мониторинга.

На сервере мониторинга в snmptrapd.conf нужно добавить строку обработчика.

Сам обработчик написан мной на perl, код можно взять по ссылкеНе рекомендуется копипастить подсвеченный код из поста, лучше взять по ссылке). Он разбирает входящие trap сообщения и формирует письмо администраторам.

Source: UDP: []:1081

Change Password Attempt:
Target Account Name:pupkin_v
Target Domain:MYDOM
Target Account ID:%
Caller User Name:pupkin_v
Caller Domain:MYDOM
Caller Logon ID:(0x0,0x39B1BD)

Source: UDP: []:1074

User Account Locked Out:
Target Account Name:ivanov_v
Target Account ID:%
Caller Machine Name:MX
Caller User Name:SADC$
Caller Domain:MYDOM
Caller Logon ID:(0x0,0x3E7)

Source: UDP: []:1072

Logon Failure:
Reason:Unknown user name or bad password
User Name:Popov_V
Logon Type:3
Logon Process:Advapi
Authentication Package:Negotiate
Workstation Name:SADC
Caller User Name:SADC$
Caller Domain:MYDOM
Caller Logon ID:(0x0,0x3E7)
Caller Process ID:580
Source Network Address:
Source Port:36018

Так как мы подписаны только на интересующие нас сообщения, мы не видим остального системного мусора из EventLog.
Очень удобна данная система при вирусных эпидемиях типа Kido, когда сразу нельзя понять откуда пошло всё размножаться или при брутфорсе системных паролей. Потому что чётко виден Logon Failure и имя машины с которой была неудачная попытка.

Спокойной Вам работы.
PS: готовый конфиг с представленными на скриншоте категориями лежит тут


Журнал событий (Event Logging)

Win32: централизованное протоколирование событий

Автор: Серебряков Алексей (Smooky)
Источник: RSDN Magazine #3-2007

Опубликовано: 14.11.2007
Исправлено: 10.12.2016
Версия текста: 1.0


Для решения этой проблемы операционная система Windows предоставляет такой сервис и программный интерфейс, как Eventlog. Этот инструментарий относится к числу базовых сервисов Windows, т.е. поставляется с самой системой и система сама же его использует. Стоит заметить, что эта возможность есть только у систем семейств WinNT/XP, т.к. приложение для протоколирования событий является сервисом. Также стоит заметить, что в Windows Vista и Windows Longhorn этот сервис существенно переработан, новый вариант в этой статье рассматриваться не будет.

Мы не будем также рассматривать этот замечательный инструмент с точки зрения администраторов, сборщиков журналов и прочих персон, которые призваны управлять системой. Итак, приступим.


Рисунок 1.

Наверное, почти все разработчики используют в своих программах протоколирование событий при выявлении ошибок, отладке и диагностировании приложений. Но даже после успешного сбора и просмотра статистики иной раз бывает сложно проанализировать, что же всё-таки случилось и в каком месте? Так вот, сервис «Журнал событий» является стандартным, централизованным способом сбора статистики и просмотра сообщений о событиях, поступающих от приложений, сервисов операционной системы и аппаратных устройств. Средство для просмотра этих событий является оснасткой Microsoft Management Console. В Windows XP Rus эта оснастка запускается так: Пуск->Настройка->Панель управления->Администрирование->Просмотр Событий (Event Viewer).


При использовании сервиса протоколирования в журнал следует записывать достаточно важные и нужные сведения о происшедших ошибках, которые действительно потом могут помочь разработчикам разобраться, что же произошло с приложением. Не следует, например, писать в системный журнал с периодичностью 100нс сообщения о том, что пользователь случайно удалил файл readme.txt. Журнал событий – это не средство трассировки.

Рекомендации по протоколированию событий

Сообщение в журнале событий – это, прежде всего, информация, способная помочь вам, администратору и даже пользователю понять, какая проблема возникла в приложении и как её устранить. В частности, это событие может предназначаться специалисту технической поддержки в вашей компании, и даже ему будет тоскливо читать сообщение: «Процесс А не смог прочитать 0x05 байт 0x2-ого сектора дисковода В». Поэтому идеальное сообщение должно помочь пользователю ответить на следующие вопросы:

Могут пригодиться и следующие рекомендации:

Соглашения о стиле содержания сообщения:

Это неполный список рекомендаций, взятый из MSDN. На самом деле в популярных книгах, например, у Саттера, есть более интересные рекомендации.

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

В журнал можно записывать пять типов событий. Все типы событий достаточно понятно классифицированы, определены и могут включать много дополнительной информации. Каждое событий, которое мы посылаем из своего приложения, может иметь только один тип. Определены следующие типы событий:

Тип события Пояснение
Ошибка (Error) Этим типом обычно определяется серьёзная ошибка приложения. Например, исполнение приложения прервалось из-за нехватки ресурсов.
Предупреждение (Warning) Этим типом приложение обычно информирует о том, что скоро может возникнуть проблема, например, закончится дисковое пространство.
Информация (Information) Этим типом приложение обычно информирует об успехе какой-либо важной операции, например, при старте сервиса.
Успешный отчёт (Success Audit) Этот тип события обычно означает об успехе какой-либо операции доступа, например, пользователь вошёл в систему.
Не успешный отчёт (Fault Audit) Этот тип события обычно означает, что произошла какая-то ошибка при доступе к ресурсу, например, пользователь не смог обратиться к сетевому диску.

Поскольку запись в журнал может происходить нечасто, в тексте сообщения следует достаточно полно описывать происшедшее событие. Следует достаточно понятно описывать событие, так как информацию о событии, до того как она попадёт к разработчику, может просмотреть, например, администратор системы и не придав ей особого значения, просто проигнорировать.


Элементы журнала событий


Всю информацию о настройках журнала сервис берёт из реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog.

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

Журнал (Log) Пояснение
Приложение (Application) Этот журнал содержит записи от приложений. Например, если мы зарегистрируем свой источник событий (т.е. приложение) и не укажем журнал, по умолчанию записи будут поступать сюда.
Система (System) Этот журнал содержит записи, поступающие от системных служб. Но писать в него может любое приложение.
Безопасность (Security) Этот журнал предназначен для аудита, например, событий входа пользователя в систему.
Другой (Custom) Можно создать свой журнал. Не поддерживается в Windows NT.

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

Ключ в реестре Пояснение
DisplayNameFile Имя файла, в котором содержится локализованная строка с названием журнала, то есть строка, которую покажет Event Viewer. Если параметр не указан, Event Viewer в качестве строки покажет наименование подключа, в котором определён параметр. По умолчанию все локализованные ресурсы находятся в %SystemRoot%\system32\ELS.DLL. Строковый параметр.
DisplayNameID Идентификатор строки в ресурсной DLL. Тип параметра DWORD.
File Путь к папке, где Event Viewer будет хранить файлы журналов. По умолчанию это %SystemRoot%\system32\config\MyLogName, где MyLogName – имя журнала. При создании нового файла журнала сервис должен иметь права на полный доступ к файлу. Если значение этого параметра будет неверным, все записи будут перенаправляться в журнал Application. В пути нельзя использовать имя удалённого компьютера, DOS-устройства, дисководы, именованные каналы. Нельзя использовать переменные окружения, которые нельзя раскрыть в контексте сервиса.
MaxSize Максимальный размер журнала в байтах. По умолчанию 512К. Параметр DWORD.
PrimaryModule Наименование ключа, где хранятся настройки по умолчанию. Обычно совпадает с наименованием журнала. Строковый параметр.
Retention Интервал в секундах, в течение которого записи могут остаться не перезаписанными. Если установлено в ноль, записи в журнале всегда перезаписываются, если не ноль или 0xFFFFFFFF, то записи никогда не перезаписываются. При достижении максимального размера журнал необходимо очистить вручную, иначе записи будут потеряны. Перед тем, как изменять это значение, журнал необходимо очистить. Параметр DWORD. По умолчанию – 0.
Sources Список приложений, сервисов, которые могут писать в журнал. Только для чтения. Этот список создаёт сам сервис. Названия приложений берутся из текущей ветки журнала и разделяются null-terminated. Параметр многострочный.
AutoBackupLogFiles Если значение параметра – 0, журнал не сохраняется как резервная копия. По умолчанию – 0.
RestrictGuestAccess Если значение – 1, то пользователи под учётной записью Guest и Anonymous не имеют доступа к журналу. По умолчанию – 0.
Isolation Не используется.

Источники событий

Каждая подветка в ветке Eventlog – это источник событий.

Например, для приложения MySuperApp.EXE, которое будет записывать события в журнал Application, необходимо создать такую подветку:

Здесь MySuperApp – это произвольное имя, по которому сервис (журнал) будет опознавать события, поступающие от нашего приложения. Каких либо соглашений об имени в документации не указано, но видимо, имя должно быть уникально в пределах одной подветки. Обычно используется название приложения или исполняемого модуля. По сути дела, это и есть регистрация приложения в сервисах Event Logging и Event Viewer.

Пользовательские приложения и сервисы должны либо регистрировать себя в журнале Application, либо создавать свой журнал. Журнал Security используется только системой. Драйверы устройств должны использовать журнал System.

Каждый источник событий (как мы уже знаем, приложение) должен в своей подветке определить перечисленные ключи. Они помогают Event Viewer сопоставлять сообщения и подставляемые параметры из ресурсной DLL-библиотеки с идентификаторами в приложении (позже я это продемонстрирую на примере):

Ключ в реестре Пояснение
CategoryCount Число используемых категорий. Тип DWORD.
CategoryMessageFile Путь к файлу с локализованными строками, определяющими категории. Строковый параметр.
EventMessageFile Путь к файлу с локализованными строками сообщений. Можно перечислить несколько файлов через запятую. Например, EVT_ENG.DLL, EVT_RUS.DLL. Строковый параметр.
ParameterMessageFile Путь к файлу с локализованными строками параметров, подставляемых в текст сообщения. Строковый параметр.
TypeSupported Параметр определяет типы поддерживаемых сообщений. Например, только ошибки и предупреждения: EVENTLOG_ERROR_TYPE | EVENTLOG_WARNING_TYPE. Параметр DWORD определяет маску из следующих типов:EVENTLOG_ERROR_TYPE, EVENTLOG_WARNING_TYPE, EVENTLOG_INFORMATION_TYPE, EVENTLOG_AUDIT_SUCCESS, EVENTLOG_AUDIT_FAILURE


Однако если ветка была найдена, но не были определены файлы сообщений для найденного источника событий, то при открытии Event Viewer сообщит об ошибке. Поэтому хорошим тоном будет, не только зарегистрировать источник событий, но и предоставить файлы сообщений.

Рисунок 2.

Вот, собственно, основные теоретические сведения. Можно приступить к практическим занятиям.


Создадим сначала ресурсную библиотеку с категориями, сообщениями и параметрами. Для этого необходимо создать обычный текстовый файл с расширением MC.

Файл сообщений

Категории, сообщения и подставляемые параметры можно разместить как в одном файле, так и в разных. Для удобства и наглядности разместим всё в одном файле MYEVT_ENG.MC.

Категории событий

Категории событий – это всего лишь числовые идентификаторы, которые помогают фильтровать записи при просмотре журнала в Event Viewer. Каждый источник событий может обозначить свои категории любым числом. Надо только учесть, что они должны располагаться в начале файла сообщений последовательно (по порядку) и начинаться с 1. Подробное описание формата файла *.MC можно найти в в MSDN.

Идентификаторы событий

Каждый идентификатор события уникален в пределах файла сообщений. Каждый источник событий может определять свои собственные идентификаторы и связанные с ними строки. В Event Viewer при просмотре журнала мы как раз и видим эти строки (см. рисунок).

Формат кода идентификатора события выглядит так (впрочем, это соглашение, принятое в Windows):

3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
7 6 5 4 3 2 1 7 6 5 4 3 2 1 7 6 5 4 3 2 1 7 6 5 4 3 2 1
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
Severiry C R Facility Code

Важность ошибки (Severity):

Принадлежность (Customer bit):

Подробные пояснения можно найти в книге Рихтера или в MSDN.

Строки сообщений

Теперь определим строки сообщений, поясняющие событие. Строки сообщений могут содержать подставляемые параметры.

Итак, мы написали файл MYEVT_ENG.MC. Теперь нам понадобится утилита MessageCompiler (MC.EXE), которая поставляется с MSVC6.0 и Platform SDK. Это консольное приложение скомпилирует файл сообщений:

В результате мы получим следующие файлы: MYEVT_ENG.H (определения символических имён), Msg00001.bin (бинарный ресурс для каждого языка), MYEVT_ENG.RC (в нём подключены бинарные ресурсы). Кстати, файл WINERROR.H, поставляемый с Microsoft Visual Studio, именно так и сгенерирован.

Теперь скомпилируем файл ресурсов MYEVT_ENG.RC:

В результате мы получим файл MYEVT_ENG.RES. И, наконец-то, скомпилируем библиотеку:

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


Один и тот же файл сообщений могут использовать несколько приложений. И даже если сообщения написаны на разных языках, они всё равно могут находиться в одном ресурсном файле.

Регистрация источника событий

Для регистрации источника событий достаточно всего лишь определить несколько ключей в реестре (описание ключей приведены выше).

Теперь сервис Eventlog готов принимать сообщения о событиях, а Event Viewer – показывать их. Осталось только это использовать.

Использование журнала событий

Здесь стоит пояснить две важные функции: RegisterEventSource и ReportEvent.

lpSourceName – это имя источника события, который будет отсылать сообщения в журнал. В нашем примере это был MySuperApp. Нельзя использовать журнал Security (функция вернёт INVALID_HANDLE_VALUE). Если имя источника события не было найдено в реестре (в подключе \Eventlog), будет использоваться журнал Application.

Функция возвращает описатель журнала или NULL.

hEventLog – описатель, который вернула функция RegisterEventSource.


wCategory – категория (см. Категории событий)

dwEventType – сообщение (см. Идентификаторы событий)

lpUserSid – указатель на структуру SID.

wNumStrings – количество подставляемых параметров в lpStrings. Каждая строка ограничена 32К.

dwDataSize – число байт в lpRawData.

lpRawData – произвольный массив байтов. Event Viewer никак не интерпретирует эти данные и отображает их в том виде, в котором они были переданы.

Eventlog предоставляет еще несколько функций (перебрать записи в журнале, найти запись, и т.д.) для работы с журналами событий. Почти все они нужны только для какой-либо программы-анализатора.


Кому-то это может показаться нудным и даже ненужным занятием. Но логи всегда были очень полезным и действенным способом отладки приложений и устранения ошибок. Использование журналов событий имеет ряд преимуществ:

В Windows Vista Microsoft переработала этот сервис. Например, можно генерировать логи в XML, отсылать отчёты о логах и т.д.


Поделиться с друзьями
Советы экспертов и специалистов