Журнал событий windows server 2003

событий (ID) и кодами, по-прежнему остаются весьма туманными, а соответствующие описания в документации — неточными. К тому же здесь мы вновь сталкиваемся с теми же проблемами построения отчетов, архивирования, оповещения и объединения данных, которые имели место в Windows NT Server. Дополнительные трудности также связаны со страстью Microsoft к внесению в продукты множественных изменений в интерпретацию ID от версии к версии. Однако, если иметь под рукой необходимые инструменты и знать, что именно следует искать, из журнала безопасности можно почерпнуть очень много ценной информации.

В этой первой статье из планируемой серии материалов, посвященных журналам безопасности Windows 2003, я представлю общий обзор политики аудита и структуры самого журнала безопасности, что наверняка будет полезно для новичков в данной области. Более продвинутых «следопытов» журналов безопасности может заинтересовать информация, содержащаяся в примечаниях «Новое в Windows 2003» по каждой из рассматриваемых здесь категорий. В примечаниях содержится обзор тех существенных изменений, которые претерпел журнал безопасности системы Windows 2003. На экране 1 показана закладка Filter диалогового окна Event Viewer?s Security Properties, из которой следует, что все события, связанные с системой безопасности, делятся на девять категорий аудита. В последующих статьях будет более подробно рассмотрена каждая из этих категорий, а также будет показано, как можно извлечь из этих ценных ресурсов максимальное количество информации.

Экран 1. Категории системы безопасности в Event Viewer

Event Viewer

Журнал безопасности можно просматривать с помощью оснастки Event Viewer консоли Microsoft Management Console (MMC). События отображаются в виде некоторого набора стандартных полей, и каждый ID имеет уникальное описание. Стандартными являются поля идентификатора (ID), даты (date), времени (time), имени пользователя (username), имени компьютера (computer name), источника (source), категории (category) и типа (type). Для многих ID, в соответствии с архитектурой системы безопасности Windows, поле имени пользователя отображается как not useful (не используется), соответственно в таких случаях нужно в описании события просматривать поля, содержащие относящуюся к пользователю информацию. В поле имени компьютера всегда содержится имя локальной системы, поэтому информация из этого поля может быть полезной в основном в тех случаях, когда в общую базу данных объединяется информация из журналов нескольких разных компьютеров. Поле источника служит для того, чтобы отображать информацию о том, какой компонент системы или приложение послужили причиной данного события, но при этом для всех событий, занесенных в журнал безопасности, в данном поле будет установлено значение Security. В поле категории отображается одна из девяти категорий аудита, а поле типа может содержать значение Success Audit (аудит был успешен) или Failure Audit (неудачная попытка аудита). Таким образом, по этому полю можно отделить, например, события успешной регистрации в системе от отказов в регистрации. Описание события представляет собой совокупность статического текста на обычном языке и изменяемого списка динамических строк, вставляемых в определенные позиции в этом статическом тексте. Наиболее важная информация по многим событиям содержится именно в строках описания, существуют и программные инструменты для анализа этих данных и построения соответствующих отчетов.

В утилите Event Viewer имеется ряд механизмов поиска и фильтрации, но их возможности весьма ограниченны. Посредством данной утилиты можно выполнять сохранение и/или очистку журнала безопасности. Для сохранения копии журнала (после щелчка правой кнопкой и выбора пункта Save Event Log As) можно выбрать один из трех предлагаемых форматов: «родной» формат Event Viewer (файл с расширением .evt), формат данных, разделяемых запятой (Comma-Separated Value CSV), или формат с разделителем в виде табуляции.

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

В Event Viewer можно задать максимально допустимый размер журнала безопасности и предопределить те действия, которые система Windows должна выполнить при достижении журналом максимального размера. Чтобы увидеть окно установки этих параметров, следует щелкнуть правой кнопкой мыши на соответствующем журнале и выбрать пункт Properties («Свойства»). Здесь можно предписать Windows при необходимости перезаписывать более ранние события, прекращать дальнейшую регистрацию до тех пор, пока кто-либо не очистит журнал, или перезаписывать события, произошедшие ранее заданного количества дней. В последнем случае при заполнении журнала дальнейшая запись событий будет временно прекращена, пока не пройдет достаточно времени для того, чтобы в журнале появились события, удовлетворяющие установленным временным критериям и, соответственно, допускающие удаление.

Категории аудита

Можно настроить Windows 2003 таким образом, чтобы в журнал безопасности записывались только те события, которые соответствуют заданным категориям аудита. Для этого в списке из девяти категорий политики аудита нужно выбрать только те, что представляют интерес для занесения соответствующих им событий в журнал. Чтобы просмотреть действующие в данный момент настройки политики аудита компьютера, запустите, как показано на экране 2, редактор групповых политик (Group Policy Editor, GPE) и раскройте следующую ветвь: Local Computer PolicyComputer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesAudit Policy. Обратите внимание, что порядок перечисления и наименования категорий журнала безопасности (экран 1) и соответствующих им политик аудита (экран 2) слегка различаются. Если посмотреть на экран 2, увидим, что для каждой категории можно включить аудит событий с успешным и/или неудачным результатом либо вообще отключить аудит для данной категории событий. Например, можно для категории Audit account logon events (выполнять аудит попыток регистрации с учетной записью в системе) включить аудит только для неудачных попыток, в результате чего в журнале событий Windows будут фиксироваться только те попытки регистрации в системе, которые по каким-либо причинам закончились неудачей.

Экран 2. Политики аудита системы безопасности

Упомянутые девять категорий аудита охватывают весьма широкий круг действий. Можно наблюдать за процедурами регистрации в системе и аутентификацией, за работой администратора, за поддержкой пользователей, групп и компьютеров, за действиями пользователей, связанными с доступом к файлам, за изменениями важных настроек параметров безопасности, за выполнением тех или иных программ, за изменениями свойств в Active Directory (AD) и т. д. Ниже приводятся краткие описания для каждой категории событий.

Регистрация и аутентификация

Одним из наиболее эффективных методов контроля действий пользователей и выявления атак на системы являются наблюдения за событиями регистрации в системе. Поскольку среда Windows имеет доменную архитектуру, для процессов регистрации в системе и аутентификации применяются различные подходы: если пользователь осуществляет регистрацию на своем компьютере при помощи доменной учетной записи, то данная система должна пройти процедуру аутентификации в AD на соответствующем контроллере домена (DC). Для отслеживания каждого из типов этих действий (или обоих вместе) в системе безопасности используются две категории событий: с помощью категории Logon/Logoff выполняется аудит событий, связанных с регистрацией, а категория Account Logon позволяет отслеживать события аутентификации.

Если мы вспомним эпоху Windows NT, то там категория Account Logon отсутствовала, а была только категория Logon/Logoff, что создавало значительные проблемы при необходимости отслеживать попытки аутентификации в домене. Информация о событиях категории Logon/Logoff записывалась в журналы тех компьютеров, где эти события произошли, т. е. в журналы рабочих станций и серверов домена, но не контроллеров домена. Поэтому, если требовалось отследить неудачные попытки регистрации в системах, приходилось просматривать журналы событий на каждой рабочей станции и сервере домена. Но еще хуже, что не было возможности отслеживать попытки регистрации с неавторизованных компьютеров.

Ситуация изменилась с появлением семейства продуктов Windows 2000, в них уже была предусмотрена категория Account Logon (хотя, на мой взгляд, название для нее было выбрано неудачно — правильнее было бы назвать эту категорию Authentication). Теперь стало возможным регистрировать все происходящие в домене события категории Account Logon на контроллере домена. Правда, при этом все равно требовалось отслеживать события на всех контроллерах домена, но, согласитесь, это намного лучше, чем просматривать журналы безопасности на каждом компьютере сети.

Несмотря на появление категории Account Logon, сохранилась и существовавшая категория событий Logon/Logoff. Причина этого заключается в том, что данная категория может помочь при необходимости проконтролировать весь сеанс регистрации в целом. При этом события категории Account Logon информируют о том, кем, где и когда предпринимались попытки регистрации в системе, а события категории Logoff/Logon сообщают о продолжительности этих сеансов. Кроме того, события типа Logon/Logoff содержат более подробную информацию о причинах неудачи той или иной попытки регистрации в системе.

Новое в Windows 2003. В Windows 2000 имеется набор идентификаторов для событий успешной аутентификации и еще один набор ID для событий неудачной аутентификации. В Windows XP события категории Account Logon не претерпели каких-либо изменений, но в системе Windows 2003 события этой категории содержат некоторые дополнительные данные. Следует также отметить, что разработчики Microsoft, по совершенно необъяснимым причинам, удалили некоторые ID для определенных событий неудачной аутентификации и объединили их с соответствующими событиями успешной аутентификации.

Управление учетными записями и доступ к службе каталогов

С помощью категории Account Management можно отслеживать изменения в учетных записях пользователей, групп и компьютеров, кроме того, она незаменима при наблюдении за некоторыми видами действий. Наилучший подход к управлению доступом состоит в том, чтобы предоставлять доступ группам, а не отдельным пользователям. С помощью категории событий Account Management можно легко идентифицировать случаи изменения членства в группах. Во многих случаях злоумышленники, получившие права административного доступа к системе, сначала создают новую учетную запись, а затем используют ее для дальнейших атак. С помощью событий категории Account Management факт создания новой учетной записи может быть легко выявлен. Использование категории Account Management может также помочь заставить администратора более ответственно относиться к своей работе. Если кем-то была случайно удалена учетная запись пользователя или внесены некорректные изменения в настройки пользователя или группы, то с помощью аудита событий категории Account Management подобные действия можно отследить.

Категория Directory Service Access обеспечивает низкоуровневый аудит объектов AD и их свойств. Поскольку данная категория имеет непосредственное отношение к AD, то активировать аудит подобных событий на системах, которые не являются контроллерами домена, не имеет ни малейшего смысла. Данная категория в значительной степени пересекается с Account Management, поскольку пользователи, группы и компьютеры тоже являются объектами AD. Но если отчеты Account Management содержат данные по высокоуровневым изменениям для пользователей, групп и компьютеров, то, применяя категорию Directory Service Access, можно обеспечить аудит объектов AD (в том числе пользователей, групп и компьютеров) на очень низком уровне. В категории Account Management каждому типу объектов и каждому событию доступа к объекту соответствует уникальный идентификатор ID. С другой стороны, в категории Directory Service Access для всех типов действий существует единственный идентификатор с ID 566. К ID 566 относятся тип объекта, имя объекта, имя пользователя, получившего доступ к объекту, а также тип доступа. В примере события, показанном на экране 3, администратор изменил в учетной записи Susan параметр job title.

Хотя категория Directory Service Access обладает весьма богатыми возможностями, тем не менее использоваться может лишь небольшая их часть. На контроллерах доменов Windows 2000 политика аудита событий Directory Service Access настроена по умолчанию таким образом, чтобы в журнал записывались как удачные, так и неудачные попытки изменений объектов AD, что приводит к наличию огромного количества событий. Отметим также, что названия типов объектов и свойств поступают в события с ID 566 непосредственно из схемы AD и могут при этом выглядеть весьма загадочно. Например, поле user?s city (город) отображается в виде «/» (местонахождение) а поле last name (фамилия) представлено в виде sn (surname). Обычно для обеспечения аудита событий, связанных с пользователями, группами и компьютерами, наибольший практический интерес представляет категория Account Management. Однако при этом следует понимать, что выполнять аудит изменений, вносимых в другие важнейшие объекты AD, такие как групповые политики (GPO) или организационные подразделения (organizational unit, OU), можно только с помощью категории Directory Service Access.

Новое в Windows 2003. В Windows 2003 исправлена имевшаяся в Windows 2000 ошибка, связанная с изменениями и сбросом пользовательского пароля. В документации на Windows 2000 указывается, что сбросу пароля в журнале событий соответствует ID 628, хотя на самом деле процедурам как сброса, так и изменения пароля в системном журнале соответствует один и тот же ID 627 и они всегда отображаются в отчетах как события смены пароля. В Windows 2003 смене пароля соответствует ID 627, а сбросу пароля — ID 628.

Аудит доступа к файлам

В принципе с помощью категории Object Access можно следить за доступом к файлам, папкам, принтерам, разделам реестра и системным службам, но в большинстве случаев данная категория используется для отслеживания доступа к файлам и папкам. Как только будет включен аудит по данной категории, в журнале безопасности сразу же отобразится некоторое количество событий, касающихся доступа к объектам в базе безопасности SAM. Однако каких-либо других событий, связанных с доступом к файлам или другим объектам, вы здесь, вероятнее всего, не увидите, поскольку каждый объект имеет свои настройки параметров аудита, а по умолчанию почти у всех объектов аудит отключен. Это правильная практика, поскольку, если в системе будет включен аудит попыток доступа к каждому файлу или объекту, то данная система до своей полной остановки будет заниматься только обработкой этих событий, а ее журнал безопасности быстро переполнится, вне зависимости от назначенного ему объема. Я рекомендую применять эту категорию только к критически важным файлам, действительно требующим механизмов слежения за доступом к ним.

Для того чтобы активизировать аудит событий для выбранного объекта, нужно открыть его диалоговое окно свойств, выбрать закладку Security, нажать кнопку Advanced, выбрать закладку Auditing, после чего нажать кнопку Add. Например, на экране 4 можно увидеть настройку параметров аудита для файла 1st Quarter Cost Centers.xls, который я открыл из Windows Explorer. Обратите внимание, что можно указывать конкретных пользователей или группы, доступ которых к данному файлу необходимо отслеживать, можно назначать аудит лишь для конкретного типа доступа либо аудит только успешных (или неудачных) попыток доступа к данному объекту. Как только будет включен аудит для соответствующего объекта, Windows начнет регистрировать события открытия, закрытия и другие типы событий для данного объекта согласно выбранной для него политике аудита.

Экран 4. Настройки аудита для объекта

Новое в Windows 2003. Безусловно, журнал безопасности в Windows 2000 выполняет очень важную функцию, информируя о том типе доступа к объекту, который имеет пользователь или приложение, но при этом остается неизвестным, что в действительности пользователь или приложение делают с этим объектом. Предположим, что пользователь А открыл документ, на который у него есть разрешения на чтение и запись. При этом в журнал Windows 2000 записывается событие с ID 560, которое говорит о том, что пользователь, имеющий разрешения доступа List Folder / Read Data и Create Files / Write Data, открыл файл. Когда А закроет файл, в журнал Windows 2000 будет занесено событие с ID 562, означающее, что пользователь закрыл файл. В Windows 2003 добавлено новое событие с ID 567. Если пользователь А изменит содержимое файла на компьютере с Windows 2003, в журнале между событиями открытия и закрытия соответствующего файла будет зарегистрировано событие с ID 567. В нем содержится информация о названии объекта, пользователе и том типе доступа, который этот пользователь в действительности применял. Если в данном месте журнала событие с ID 567 не зарегистрировано, это говорит о том, что пользователь не изменял содержимое файла.

Слежение за выполнением программ

Категория Detailed Tracking предоставляет администратору возможность мониторинга каждой программы, запущенной на системе. Можно контролировать запуск (ID 592) и закрытие (ID 593) пользователями любых приложений. Эти два события могут быть связаны друг с другом через идентификатор процесса (process ID), который можно найти в описаниях обоих событий. Для того чтобы получить полное представление о сеансе работы пользователя, можно задействовать механизмы слежения за процессами с аудитом процедур входа/выхода (logon/logoff), а также открытия/закрытия файлов (file open/close). При этом будет видно, когда пользователь регистрировался в системе, какие запускал программы и к каким файлам из этих программ обращался.

Новое в Windows 2003. В Windows 2003 в категорию Detailed Tracking добавлено два новых события. Событие с ID 601 позволяет отслеживать моменты установки в систему новых служб, что может пригодиться для контроля установки служб на серверах и рабочих станциях с целью проверки их легитимности и выявления наличия несанкционированных служб. При этом нужно понимать, что данное событие может применяться только к системным службам, но не к приложениям, запущенным пользователем на компьютере. Кроме того, для выявления «троянцев» и шпионских программ данное событие также неприменимо, поскольку подобного рода программы обычно не устанавливают себя на системы в качестве служб. Событие с ID 602 информирует о фактах создания задач для службы планировщика, но при этом не отслеживаются моменты внесения изменений, удаления или попыток запуска кем-либо этих задач.

Права пользователей

Для обеспечения контроля возможностей выполнения пользователями функций системного уровня, таких как изменение системного времени или выключение, в Windows применяется система прав пользователей (привилегий). Контроль использования этих прав может быть реализован с помощью категории Privilege Use. Для большинства прав в журнале Windows регистрируются события Privilege Use (ID 577 или 578), однако некоторые виды прав используются настолько часто, что разработчики Microsoft предпочли не регистрировать каждый факт их применения. Вместо этого, когда реализуется какое-либо из этих прав, в журнале Windows просто отражается факт использования права с ID 576.

Новое в Windows 2003. В системе Windows 2000 при попытках просмотреть либо снять содержимое дампа памяти в журнал безопасности заносится событие с ID 578, но в Windows 2003 этого почему-то не происходит. И аналогично, когда кто-то хочет стать владельцем файла или другого объекта, система Windows 2003 не регистрирует никакого события (в Windows 2000 и в этом случае происходит запись события в журнал). Возможно, эти ошибки будут исправлены в первом пакете обновления системы Windows 2003, поскольку в Windows 2000 некоторые ошибки, связанные с аудитом, в выпущенных для данной системы пакетах обновления были устранены.

Изменения политик

В тех журналах безопасности, которые мне довелось просматривать, я так и не обнаружил нескольких событий категории Policy Changes, которые, в соответствии с документацией Microsoft, должны записываться в журнал. Так, одни события, связанные с протоколом IP Security (IPSec), похоже, никогда не регистрируются в журнале (например, ID 613, 614 и 616), в то время как другие (ID 615) регистрируются. И тем не менее категория Policy Changes предназначена для регистрации событий, связанных с изменениями конфигурации параметров безопасности, включая изменения доверительных отношений, политики Kerberos, шифрующей файловой системы EFS и параметров QoS.

Новое в Windows 2003. В системе Windows 2000 событие с ID 615 относилось к категории Detailed Tracking, но в Windows 2003 оно перекочевало в категорию Policy Change. И это всего лишь один из примеров тех загадочных и ненужных изменений, которые мне удалось выявить при сравнении событий в системах Windows 2000 и Windows 2003. А вот еще одно интересное изменение: в документации утверждается, что при назначении и аннулировании пользовательских прав в журнал Windows заносятся события, имеющие соответственно ID 608 и 609. Однако в журнале Windows 2000 ни одно из этих событий не регистрируется. Что касается системы Windows 2003, то здесь при изменениях в правах пользователей происходит запись в журнал событий с ID 608 и 609, за исключением тех случаев, когда это связано с изменениями прав регистрации, таких как Allow logon locally и Access this computer from the network. В Windows 2003 для такого рода событий, в отличие от заявленных в документации ID 608 и 609, используются идентификаторы ID 621 и 622 (соответственно для предоставления и лишения прав). Подобные необъяснимые и недокументированные изменения приводят к нарушениям работы программ мониторинга и построения отчетов, которые выполняют фильтрацию и анализ событий, основываясь на категориях, ID, или на поле, расположенном в определенном месте в описании события.

Системные события

Категория System Events является вместилищем для разнообразных событий, касающихся системы безопасности. В данной категории система предоставляет информацию о процессах начальной загрузки (ID 512) и выключения (ID 513), а также о работе различных компонентов системы безопасности (в частности, о процессах регистрации и процедурах аутентификации) во время начальной загрузки системы. Здесь есть два чрезвычайно полезных события, а именно: событие с ID 517, информирующее пользователя об очистке журнала событий и о том, кто это сделал, и событие с ID 520, которое присутствует только в Windows 2003.

Новое в Windows 2003. При тестировании Windows 2003 в категории System Events единственным новым событием, которое мне действительно удалось обнаружить, было событие с ID 520. Наличие данного события в журнале говорит о том, что системные время и дата были изменены, здесь же в его описании приводятся новое и старое значения даты и времени.

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

Примечание автора

Данная серия статей построена на базе курса Security Log Secrets компании Monterey Technology Group.

---

Редактор Windows IT Pro и ведущий инструктор и разработчик курсов для программы по безопасности Windows NT/2000 института MIS Training. Его компания, Monterey Technology Group, занимается консалтингом в области информационной безопасности. Связаться с ним можно по адресу: rsmith@monterey techgroup.com

Администраторы Windows Server 2003 смогут существенно улучшить процесс управления сервером при помощи различных системных приложений консоли управления Computer Management Console. В этой статье будет подробно рассмотрено одно из них: Event Viewer (Просмотр событий). Для доступа к Computer Management Console в системе Windows Server 2003, нажмите правой кнопкой мыши на значок My Computer (Мой компьютер) в меню Start (Пуск) и выберите пункт Manage (Управление).

Оснастка Event Viewer отображает события, регистрируемые системой при выполнении различных операций. Ее можно запустить путем ввода команды eventvwr в строку Run и нажав OK.

По умолчанию события записываются в одном из трех журналов:

System (Система): отображает системные события Windows.
Application (Приложения): отображает события, записанные установленными приложениями.
Security (Безопасность): отображает записи регистрации входа и выхода в систему, а также действия, связанные с доступом к файлам и папкам.

(Прочие программы, в том числе последние версии Microsoft Office и Internet Explorer, Microsoft Active Directory и File Replication Services, создают собственные журналы событий)

В каждом из них при помощи Event Viewer можно просмотреть, какие действия выполнялись в системе. Например, в журнале System записывается информация о запуске и остановке системных служб.

Журналы System и Application регистрируют предупреждения и критические события. Предупреждения (Warning events) — тип событий, которые не сигнализируют о неотложной проблеме, но могут вызвать более серьезные неприятности, если их не решить вовремя. Критические события (Critical events) записываются, когда в работе компонентов системы или приложений возникают ошибки при выполнении заданий. Примером критического события в журнале служб каталогов (Directory Services) может служить ошибка, которая случается, когда контроллеры домена (Domain Controllers) в среде активной директории (Active Directory) не могут копировать друг другу информацию о службе каталогов. Несмотря на то, что вызвавшие ее причины могут быть самыми разными, включая перебои в сети и проблемы с DNS, она классифицируется как критическая, так служит предвестником возможных нарушений в системной среде.

Резервное копирование, очистка и изменение размеров журналов событий

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

Для удаления из журнала всех записей:

1…В левой части окна консоли управления Computer Management Console нажмите правой кнопкой на журнал, который требуется очистить, и выберите пункт меню Clear Log (Очистка журнала).
2…Windows Server 2003 спросит, не желаете ли вы сохранить содержимое файла перед его удалением. Нажмите Yes (Да) и укажите путь к папке для сохранения записей из журнала.
3…Нажмите Save (Сохранить). Таким образом, все записи из журнала удалятся, но будут сохранены в виде архивной копии на жестком диске.

Для изменения предельно допустимого размера журнала:

1…Нажмите правой кнопкой на нужный журнал и выберите пункт Properties (Свойства).
2…В поле Maximum Size (Максимальный размер) введите новое значение (по умолчанию 512 Кб) и нажмите OK.

Автоматическое управление журналами событий

По умолчанию максимально допустимая величина создаваемых журналов составляет 512 Кб. Этого вполне достаточно для удобного управления ими; однако система довольно часто регистрирует в них различные процессы. Журнал Security, например, может пополняться гораздо быстрее, чем хотелось бы, и в результате система со временем станет запрещать вход всем пользователям, не имеющим полномочий администратора. Это не столько типичная проблема серверных систем, сколько пример того, что может случиться при переполненном объеме журнала событий.

Для решения такой проблемы предусмотрены три опции:

• Overwrite events as needed — Перезаписывать события (перезапись начинается с самых старых записей).
• Archive log when full — Архивировать журнал при достижении предельного объема (перезапись событий не происходит).
• Do not overwrite events — Не перезаписывать события (очистка журнала производится в ручную).

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

Примечание: Для проверки функционирования Windows Server 2003 необходимо регулярно просматривать журналы событий. Возможность создания архивных копий записей позволит администратору анализировать содержимое старых событий, не вмешиваясь в работу текущих журналов.

Автор: Derek Schauland
Версия на английском:

techrepublic.com.com
Копирование статьи разрешается только в случае указания явной гиперссылки на веб-сайт winblog.ru, как на источник русскоязычной версии.

Оцените статью: Голосов

In this section, we discuss the Event Viewer format and examine the way information is presented in each log. Every event log entry is comprised of several pieces of information. These components are listed in Table 9.5. All of these components can be enabled or disabled by using the View | Add/Remove Columns menu item.

Table 9.5 Columns Available in Event Logs Column Name Description

Date

Time User

Computer

Source

Event

The date the event occurred. This is stored in Universal Time Coordinate (UTC) format, but the date is displayed according to the user’s local settings.

The time the event occurred. This is also stored in UTC format and displayed according to the user’s local settings.

The user name of the process that caused the event. This can be a user account name or an impersonation name. (Impersonation is the term used to describe when a user impersonates someone else’s credentials; e.g., the IIS anonymous user logs on as IUSER_ MachineName account.) If the account is impersonated, both the impersonated account and user name are logged.

The name of the server where the event took place. This could be a remote computer name if you are accessing a remote computer’s event log.

The name of the application that generated the event. This could be a software program or a Windows Server 2003 component (e.g., SQL Server as a program and USB device driver as a component).

Unique ID number for each event. This is supported with a brief explanation of the error (e.g., the description for Event ID (19011) is Source (MSSQL$WEBDB) cannot be found). You can troubleshoot the application by using these event details and the source information.

Continued

Table 9.5 Columns Available in Event Logs

Column Name Description

Type The type of the event. This could be any one of those event types discussed earlier: error, information, and warning in the system and application logs, or success audit or failure audit in the security log. Each type has a unique icon to represent it in the Event Viewer.

Category This feature is primarily used in the security log. This is the category to which the event belongs according to the source of the event.

Event Log Types

The event log service is automatically started when the Windows Server 2003 systems starts. Three default log files are available in Windows Server 2003. These same logs were also available in Windows NT, 2000, and XP. The default logs are as follows:

■ Application log This log is available for general troubleshooting as well as the application developers. It can be used to record application errors, warnings, and information events. Scripting languages (such as C#, C++,VB 6.0) include Application Programming Interface (API) calls to log entries in the application log.This log can be used to display a myriad of application errors. (e.g.,The application can record a Source file not found error when files needed to complete a transaction are missing.)

■ Security log Events that affect system security are included in this event log. These events include failed or successful logon attempts, creating, opening or deleting files, changing properties or permissions on user accounts and groups, etc.

■ System log Events related to Windows system components are stored in this log file. This includes entries regarding failure of drivers and other system components during startup and shutdown.

These are the logs available for a Windows Server 2003 standalone server. The application or system event log of a Windows Server 2003 non-domain controller machine is similar to Figure 9.24.This image displays the Application event log on a machine called HOME-NET. This image clearly shows the information, warning, and error events that have occurred on this server. (For example, the first entry is an information event, followed by two warnings and two errors.) Note the different icons the Event Viewer uses for information, warning, or error events. Also note the columns that are displayed.

You can get further information about a specific event by double-clicking the event name in the list. The list view does not give any specific information about the event; it only provides you with an event ID. Double-clicking the event gives you more information. Figure 9.25 shows the Event Properties box that is displayed when you double-click the first error message in the list.You can view a detailed error message using this view.You can also use the arrow keys (up and down arrow keys) to navigate through the Event Viewer, or you can copy the event information to the clipboard by using the icon below the down arrow key.

Figure 9.24 Application Event Viewer

Figure 9.24 Application Event Viewer

Test Day Tip

Some errors display the input and output parameters for a process. This data can be viewed via the Data group box at the bottom. The data can be viewed in Hexadecimal (displayed as Bytes) or DWORD (displayed as Words) format. Not all applications generate binary data. Expert programmers can use the information contained in these descriptions to troubleshoot problems.

Figure 9.25 Application Error Description

The Security Event Viewer is similar to Figure 9.26. However, there are two differ-ences.The type of the Security Event Viewer is either Success Audit or Failure Audit.The other significant difference is the information in the Category column. The Security Event Viewer is shown in Figure 9.26.

Figure 9.26 Security Event Viewer

Figure 9.26 Security Event Viewer

If the server is a domain controller, it displays additional event logs. Here are the additional events logs you might see on a domain controller:

■ Directory Service log Used to log Windows Active Directory events.The Active Directory Service logs these entries in the event log. (For example, a connection error between the Active Directory global catalog and the server is recorded in this section.)

■ File Replication Service log Contains the events logged by the File Replication Service. File replication failures and other events regarding system and shared volumes are recorded here.

■ DNS server log Domain Name System (DNS) service log entries are include in this log file. This log appears on any computer configured as a DNS server (not just domain controllers).

Continue reading here: Eventqueryvbs

Was this article helpful?

Реализация аудита

Аудит — это основное средство для администраторов, позволяющее выявлять и отслеживать потенциальные проблемы безопасности, обеспечивать учет пользователей и обнаруживать признаки проникновения в систему безопасности. Для реализации политики аудита требуется, чтобы вы определили, какие события и объекты нужно включить в аудит. Наиболее часто в аудит включаются следующие типы событий.

• Вход и выход пользователей из системы.
• Изменения в пользовательских учетных записях и группах.
• Доступ пользователей к важным объектам, таким как файлы и папки.
• Изменения политик.

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

Для эффективного аудита Windows Server 2003 вы должны выработать стратегию аудита, которая определяет следующее.

• События безопасности сервера, которые следует включить в аудит.
• Максимальный размер и срок хранения записей для журнала Windows Security. Эти значения можно задать в Event Viewer (выберите Start/Settings/Control Panel/ Administrative Tools/Event Viewer, щелкните правой кнопкой на конкретном журнале и выберите пункт Properties).
• Объекты, такие как файлы и папки, которые должны быть включены в мониторинг. Администраторам следует включать в аудит только необходимые объекты, иначе это вызовет очень быстрое заполнение журналов аудита.
• Развертывание политики аудита (Auditing Policy) с помощью средства Local Security Policy (Start/Settings/Control Panel/Administrative Tools/Local Security Policy) на автономной машине или (с помощью Group Policy) в домене.
• Регулярный просмотр журналов безопасности. Ценность аудита заключается именно в том, что вы можете просматривать журналы безопасности для выявления проникновений в систему безопасности. Ниже приводится местоположение журналов Windows Server 2003.
  • %SYSTEMROOT%\system32\config\SysEvent.Evt
  • %SYSTEMROOT%\system32\config\SecEvent.Evt
  • %SYSTEMROOT%\system32\config\AppEvent.Evt
• Обновление политики аудита по мере необходимости. После просмотра журналов за определенный период времени может потребоваться сбор большего или меньшего объема информации.

Чтобы активизировать локальный аудит безопасности Windows с помощью Local Security Policy, выполните следующие шаги.

1. Выполните вход в качестве администратора в Windows Server 2003.
2. Выберите Start/Settings/Control Panel.
3. Дважды щелкните на Administrative Tools.
4. Дважды щелкните на Local Security Policy, чтобы запустить оснастку MMC Local Security Settings.
5. Дважды щелкните на Local Policies, чтобы раскрыть этот контейнер, и затем дважды щелкните на Audit Policy (Политика аудита).
6. В правой панели дважды щелкните на политике, которую хотите активизировать или отключить.
7. Установите флажки Success (Успешные) и Fail (Неуспешные).

Чтобы активизировать аудит безопасности с помощью консоли MMC, выполните следующие шаги.

1. Выполните вход в качестве администратора в Windows Server 2003.
2. Выберите Start/Run, введите mmc и затем щелкните на кнопке OK.
3. Добавьте оснастку Group Policy.
4. В поле Select Group Policy Object щелкните на Local Computer, щелкните на кнопке Finish, щелкните на кнопке Close и затем щелкните на кнопке OK.
5. Раскройте Local Computer Policy\Computer Configuration\Windows Settings\ Security Settings\Local Policies и затем щелкните на Audit Policy.
6. В правой панели дважды щелкните на политике, которую хотите активизировать или отключить.
7. Установите флажки Success и Fail.

Имеется несколько политик аудита, которые можно реализовать для повышения безопасности Windows Server 2003.

• Audit Account Logon Events (Аудит событий входа по учетным записям). Аудит событий входа, связанных с аутентификацией пользователя. Рекомендуется аудит успешных и неудачных попыток входа (SUCCESS и FAILURE).
• Audit Account Management (Аудит управления учетными записями). Аудит таких событий, как создание учетной записи, блокировка учетной записи и удаление учетной записи. Рекомендуется аудит событий типа SUCCESS и FAILURE.
• Audit Directory Service Access (Аудит доступа к службе каталога).Активизирует аудит доступа к объектам Active Directory. Рекомендуется аудит событий типа SUCCESS и FAILURE.
• Audit Logon Events (Аудит событий входа). Аудит событий входа в систему, к которой применяется данная политика. Рекомендуется аудит событий типа SUCCESS и FAILURE.
• Audit Object Access (Аудит доступа к объектам). Активизирует аудит доступа ко всем объектам, которые можно включать в аудит, например, объекты файловой системы и реестра. Рекомендуется аудит событий типа SUCCESS и FAILURE.
• Audit Policy Change (Проверка изменений политик). Определяет, нужен ли аудит изменений, вносимых в политики назначения прав пользователей, в политики аудита или в политики доверия. Рекомендуется аудит событий типа SUCCESS.
• Audit System Events (Аудит системных событий). Аудит таких событий, как завершение работы системы и загрузка системы, или событий, влияющих на системный журнал и/или журнал безопасности, например, очистка этих журналов. Рекомендуется аудит событий типа SUCCESS.

Примечание. Наиболее важными событиями, для которых требуется мониторинг, являются события Audit Logon Events (из них можно определить, кто пытался выполнить вход), Audit Policy Change (из них можно определить, вносились ли изменения в какую-либо политику) и Audit System Events (они позволяют выявить необычные действия на данном компьютере). Эти события аудита часто используются для выявления проникновений в систему.

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

Чтобы задать аудит по файлу или папке, выполните следующие шаги.

1. Запустите Windows Explorer и затем найдите файл или папку, для которой хотите задать аудит.
2. Щелкните правой кнопкой на этом файле или папке, выберите пункт Properties и затем щелкните на вкладке Security.
3. Щелкните на кнопке Advanced и затем щелкните на вкладке Auditing.
4. Определите тип изменений в аудите, которые нужно выполнить.

   Чтобы задать аудит для новой группы или нового пользователя, щелкните на кнопке Add. В поле Name введите имя пользователя или используйте кнопку Advanced, чтобы найти конкретного пользователя.

   Для просмотра или изменения аудита для существующей группы или пользователя щелкните на имени и затем щелкните на кнопке View/Edit.

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

5. В панели Access (Доступ) щелкните на флажках Successful (Успешные) и/или Failed (Безуспешные) в зависимости от типа доступа, аудит которого вам нужен.
6. Если вы хотите, чтобы файлы и подпапки в данной папке не наследовали настройки аудита, сбросьте флажок Apply these auditing entries.

Примечание. Вы можете просматривать события IPSec Policy Agent в журнале аудита и события драйвера IPSec в системном журнале. Чтобы активизировать регистрацию событий драйвера IPSec, задайте в реестре для HKEY_LOCAL_MACHINE\ System\CurrentControlSet\Services\IPSec\DiagnosticMode значение 1 и перезагрузите компьютер. Драйвер IPSec записывает события в системный журнал только раз в час.

Выявление проникновений в систему безопасности путем аудита журналов

Попытки несанкционированного доступа, записанные в журнале Windows Security, можно видеть как записи предупреждений или ошибок. Чтобы выявить возможные проблемы безопасности, просмотрите журнал Windows Security.

1. Выберите Start/Settings/Control Panel.
2. Дважды щелкните на Administrative Tools и затем дважды щелкните на Computer Management.
3. Раскройте System Tools и затем раскройте Event Viewer.
4. Щелкните на Security.
5. Просмотрите, нет ли в журналах «подозрительных» событий безопасности, включая следующие события.
6. Неверные попытки входа.
7. Безуспешное использование привилегий.
8. Безуспешные попытки доступа и изменения файлов .bat или .cmd.
9. Попытки изменить привилегии безопасности или журнал аудита.
10. Попытки завершить работу сервера.

Защита журналов событий

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

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

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

• Отмените права доступа группы Everyone и ограничьте доступ группами Administrators и System. Определите политику для хранения, перезаписи и обслуживания всех журналов событий. Эта политика должна определять все требуемые настройки журналов событий и поддерживаться Group Policy.
• Проследите, чтобы в политике указывалось, что делать в случае заполнения всего журнала событий, особенно журнала безопасности. В этом случае рекомендуется требовать, чтобы по возможности была завершена работа сервера.
• Задайте настройки политики безопасности, чтобы локальные учетные записи Guest не могли получать доступ к системному журналу и к журналам приложений и безопасности.
• Проследите, чтобы для системных событий выполнялся аудит как успешных, так и безуспешных попыток, чтобы выявить возможные попытки стирания содержимого журнала безопасности.
• Все администраторы, которые имеют возможность просматривать или модифицировать настройки аудита, должны использовать сложные пароли или двух-факторные методы аутентификации, например, вход по смарт-карте, чтобы предотвратить атаки на эти учетные записи для получения доступа к информации аудита.

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

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

Необходимость мониторинга журнала событий Windows не вызывает сомнений. На эту тему регулярно появляются статьи, в том числе и на Хабре. Однако, почему-то все примеры сводятся к мониторингу заранее определенных EventID. В своей утилите WinLogCheck я выбрал другой путь — получить отчет по EventLog, исключив события, которые регулярно появляются и не представляют для меня интереса.

Как оказалось, это не уникальный вариант, на таком же подходе основана утилита для Linux — logcheck. Но вполне возможно, что мое решение, все-таки, появилось чуть раньше.

В этой статье я постараюсь обойтись без технических подробностей. Немного об истории создания — по-моему, это позволит понять, почему и в каких условиях появилась эта утилита и где-когда ее лучше использовать. Далее краткое описание алгоритма работы и что-то похожее на инструкцию по применению.

Краткая история и кому может пригодится WinLogCheck

Это решение позволяет мне в настоящее время контролировать больше десятка Windows Server и помогает мне в работе с 1998 года. Первая версия была написана на ActiveState Perl для мониторинга трех серверов на Windows NT 4. Для Windows Server 2003 была написана оболочка для Logparser на JScript. Но с выходом Windows Server 2008 пришлось начать с нуля. Была попытка написать на Powershell, но, поскольку иногда я принимаю участие в разработке программ и немного знаю C#, для меня оказался удобным именно этот вариант.

Самая первая версия была предназначена для работы в домене — утилита запускалась на одном из серверов и формировался отчет по всем серверам в домене. Однако, уже в Windows Server 2003 запрос к журналу событий по сети стал выполнятся слишком долго (в причинах не разбирался), а на обслуживании появились сервера вне основного домена компании, в которой работаю. Поэтому использовать какое-либо готовое централизованное решение в некоторых случаях просто невозможно.

Когда несколько лет назад в моем “подчинении” появились сервера под управлением Linux я узнал о существовании аналога своей утилиты — logcheck. Для тех кто не в курсе — утилита упоминается и рекомендуется во многих материалах по безопасности Linux и FreeBSD, например, в Debian Security Guide. После этого было принято решение сделать свою утилиту более удобной в использовании и опубликовать под именем WinLogCheck (первоначально она называлась UnknownEvents).

В результате утилита еще больше стала похожа logcheck — у меня она запускается в 9:00 на каждом сервере и через 5-10 минут в моем почтовом ящике больше десятка сообщений с отчетами. Обычно мне достаточно пары минут, чтобы просмотреть все.

Я несколько раз пытался найти готовый инструмент мониторинга, но ничего удобного, простого и практичного так и не встретил. Возможно, все дело в привычке. Тем не менее, если у вас не очень большое количество серверов — попробуйте, возможно, вам понравится мой вариант.

Как работает Winlogcheck

Алгоритм основного режима работы:

1. Получить список зарегистрированных журналов событий. Для обычного Windows Server 2008 — 7, для сервера с Active Directory — 10.
2. Для каждого журнала событий формируется запрос — получить список событий за последние сутки (приблизительно), исключая события, указанные в файле исключений “\path\to\winlogcheck\exclude\<eventlog_name>.conf
3. Из полученного списка формируется отчет в HTML, который пишется во временный файл (на тот случай, если письмо с отчетом не дойдет).
4. Отчет отправляется по почте.

Несмотря на то, что в .NET есть свои методы для получения списка событий, я использую WMI (подробнее WMI Tasks: Event Logs). Так проще работать с тестом сообщения. Единственный минус — задержка при выполнении запросов при большом количестве записей в журнале. Например, на одном из контролеров домена создание отчета занимает 5-6 минут.

Вначале рабочего дня по каждому серверу я получаю примерно такой отчет (это отчет с реально работающего Windows Server 2008 R2 with Hyper-V):

Все в порядке, разовая ошибка в DNS-Client не требует особого внимания. Обратите внимание на Subject сообщения — чаще всего письма даже не требуется открывать: обычно тема заканчивается фразой “errors=0, warnings=0, other=0”.

Как использовать WinLogCheck

Параметры командной строки

Утилита запускается из командной строки с правами администратора.
Обязательный параметр — режим работы: EXCLUDE или INCLUDE. Запуск в основном EXCLUDE-режиме:

winlogcheck -m exclude

Два опциональных параметра предусмотрены для INCLUDE-режима (для себя я его называю режим спецотчетов):

-l <eventlog_name> — для указания журнала по которому надо получить отчет
-f — имя фильтра в файле “\path\to\winlogcheck\include\<eventlog_name>.conf

Например, для отдельного отчета по успешным подключениям к RAS серверу на этом сервере у меня есть файл “\path\to\winlogcheck\include\system.conf” с таким текстом (о формате файла с фильтром — ниже):

[General]
RASconnects : SourceName = 'RemoteAccess' AND EventCode = 20272

Запускается тоже раз в день:

winlogcheck -m include -l system -f RASconnects

Естественно, такой же фильтр есть и для режима EXCUDE — чтобы в общем отчете по серверу эти записи отсутствовали. Один из отчетов:

В режиме EXCLUDE опциональные параметры использую только для тестирования.

Параметры программы

Параметры хранятся в конфигурационном файле winlogcheck.ini. Файл небольшой, поэтому привожу полностью с дополнительными комментариями:

[General]

## Глубина запроса (в часах). 
## По умолчанию: за 24 часа (за последние сутки)
##
#TimePeriod = 24

## Каталог для записи отчетов
## По умолчанию: 'path\to\winlogcheck\reports\' 
## Если вы не хотите получать отчеты по почте, можете записывать
## их в каталог, доступный на внутреннем веб-сервере.
## Когда-то я использовал такой вариант.
##
#ReportPath = c:\inetpub\wwwroot\winlogcheckreports

## CSS оформление для отчета.
## В одну строку!
##
ReportCSS = h1 {margin:0;font-weight:400} .servername, .subhead {font-weight:700} table {width:100%;} td {padding:0.25em} th {border:1px 0} tr:nth-child(odd) td {padding-bottom:1.5em, border-bottom:1px} tr:nth-child(even) {background-color:rgb(248,248,248)} caption {font-size:120%;text-align:left;padding:10px;background:rgb(216,216,216)} .error, .failure {background:rgb(255,127,127)} .warning {background:rgb(255,233,127)}

## Настройка почты
## Если закомментировано - отчеты не посылаются.
## Я использую свой почтовый сервер, поэтому
## аутентификация не поддерживается.
##
#[Mail]
#SMTP_Server = localhost
#Mail_From = Winlogcheck SERVERNAME <administrator@example.com>
#Mail_To = Administrator SERVERNAME <administrator@example.com>

Мониторинг работы самой утилиты

В разработках нашей компании используется NLog, поэтому я не стал изобретать велосипед. Во включенном в пакет конфигурационном файле для NLog настроены вывод журнала выполнения на консоль и в файл “\path\to\winlogcheck\logs\winlogcheck.log” с ротацией (каждый день новый файл, срок хранения — 10 дней).

Настройка фильтров

Переходим к самому интересному. Типичный экран Event Viewer на сервере с установленным IIS:

Наверное всем знакомы события:

• «Winlogon»: ID 7001 или 7002 — «User Logon/Logoff Notification for Customer Experience Improvement Program»
• «Service Control Manager»: ID 7036 или 7040 с сообщениями: «The WinHTTP Web Proxy Auto-Discovery Service service entered the running/stopped state» или «The start type of the WinHTTP Web Proxy Auto-Discovery service was changed from… to… „

С ними все ясно — нам в отчете они не нужны.

Фильтры записываются с использованием SQL синтаксиса, названия полей в журнале событий отличаются от того, что мы видим на экране. Для составления фильтра мы можем использовать:

1. Имя журнала событий. В данном случае “System”, значит фильтр запишем в файл “\path\to\winlogcheck\exclude\system.conf”.
2. Уровень — EventType (integer). В самом журнале определяется числами:
   • 1 — Error
   • 2 — Warning
   • 3 — Information
   • 4 — Success
   • 5 — Failure

3. Идентификатор события — Eventcode (integer)
4. Категория — CategoryString (string)
5. Источник — SourceName (string)

А то, что мы видим в описании события, находится в поле Message.

Таким образом, чтобы исключить из отчета указанные выше события, необходимо сформировать файл “\path\to\winlogcheck\exclude\system.conf” с текстом:

[General]

UserNotify : SourceName = 'Microsoft-Windows-Winlogon' AND ( EventCode = 7001 OR EventCode = 7002 )

WinHTTP : SourceName = 'Service Control Manager' AND (EventCode = 7036 OR EventCode = 7040) AND Message LIKE '%WinHTTP%'

Комментарии к формату файла с фильтрами

• Первоначально в файлах с фильтрами использовались встроенные в язык типы данных, например в версии на JScript — объект Dictonary. Потом пробовал JSON. Но во всех случаях легко допустить ошибку, поэтому был выбран формат ini-файлов.
• Имя фильтра обязательно, но в настоящее время используется только в INCLUDE-режиме при построении специальных отчетов.
• Строка условия — вопросов вызывать не должна.
• Как вы могли заметить — все примеры для английской версии Windows Server. Тем не менее все прекрасно работает и на русской версии. Для этого необходимо, чтобы файлы фильтров были в UTF-8. Значение полей SourceName и CategoryString переводятся в самом Event Viewer, поэтому в запросах необходимо использовать английские аналоги, а вот текст сообщения — на русском. Возможно, в следующее обновление программы включу пример для русской версии Windows Server.

Основные фильтры, которые я использую в своей работе, включены в архив с утилитой.

Особое отношение только к журналу безопасности — очень часто в нем очень много событий, поэтому действует фильтр по умолчанию: в отчет попадают только ошибки.

Последние замечания

• На Codeplex опубликованы архив с программой и исходные коды программы под лицензией LGPL (особо не разбирался). Поскольку я не являюсь профессиональным программистом — кодом не хвастаюсь.
• Утилита была написана специально для WIndows Server 2008, однако работает и на единственном доступном Windows Server 2003. На новой версии WIndows Server 2012 еще не проверял, но проблем быть не должно. Также должна работать на Windows XP / Vista / 7 / 8.
• Описание и краткая инструкция для Codeplex были подготовлены с помощью Google Translate. Готовый перевод был проверен знающими и признан похожим на настоящий английский.:-). Если у кого есть опыт переводов технической документации — буду рад услышать замечания и предложения.

Очень часто поднимается вопрос о мониторинге Active Directory. Мое решение вполне можно использовать для решения этой задачи. Однако, я уже давно не занимаюсь управлением “большими» доменами, поэтому вымышленных примеров для мониторинга событий AD придумывать не стал.

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