Заглянем в журнал безопасности Windows 2000

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

Следить за тем, что происходит в домене, - одна из основных обязанностей администратора. В случае с доменом Windows 2000 это особенно важно. Тому есть две причины. Во-первых, при переходе с NT на Windows 2000 многие организации объединяют несколько доменов NT в один домен Windows 2000 Active Directory (AD), а в большом домене гораздо легче потерять нить событий. Во-вторых, с переходом на AD у администратора появляется возможность делегировать задачи, связанные с управлением учетными записями, сменой паролей и т. д., сотрудникам службы поддержки или младшим администраторам. Однако, передав кому-либо часть своих полномочий, администратор должен следить за тем, как они используются.

При работе с доменом AD это особенно актуально, и в Windows 2000 предусмотрено несколько способов контроля событий, происходящих в AD. Категории аудита Audit account management (аудит управления учетными записями) и Audit directory access (аудит доступа к каталогу) помогают следить за изменениями в учетных записях пользователей, группах и политиках в домене Windows 2000, а также в локальных базах учетных записей безопасности SAM рабочих станций и автономных серверов домена.

Мозаика событий

Действие одного пользователя может вызвать множество событий, регистрируемых в журнале безопасности. Каждое событие категорий Audit account management и Audit directory access дает конкретную информацию, но ни одна категория не показывает всей картины действий пользователя. События Audit account management предоставляют конкретные ID событий для каждой ситуации, но не всегда указывают на измененные параметры объекта; событие Audit directory access с ID 565 показывает, какие свойства претерпели изменения. Однако, анализируя эти события во взаимосвязи друг с другом, можно получить представление об общей картине действий пользователя. Совместно обе названные категории позволяют следить за обслуживанием AD.

Многие администраторы знакомы с категорией аудита Audit account management, которая отслеживает операции создания, удаления и изменения учетных записей и групп пользователей. Она реализована в Windows 2000 так же, как и в NT. События данной категории имеют различные ID для каждой ситуации; в Таблице 1 перечислены идентификационные номера событий и их значения. Лучше всего использовать эту категорию на контроллерах домена (DC) для отслеживания изменений в AD, но можно задействовать ее и на рабочих станциях и автономных серверах для учета изменений локальных SAM.

Экран 1. Событие с ID 642, фиксирующее изменение в учетной записи пользователя.

Следует помнить, что в большинстве случаев события Audit account management фиксируют в журнале лишь сам факт изменения учетных записей или групп пользователей. Например, на Экране 1 показано событие с ID 642, которое отмечает изменение в учетной записи пользователя. Поля Target Account Name (имя целевой учетной записи), Target Domain (целевой домен) и Target Account ID (ID целевой учетной записи) идентифицируют измененную учетную запись пользователя. Поля Caller User Name и Caller Domain указывают, кто изменил учетную запись. Используя информацию из поля Caller Logon ID в сочетании с событиями с ID 528 и с ID 540, можно связать это событие с сеансом регистрации. [Более подробно об идентификации сеансов регистрации рассказано в статье «Аудит событий регистрации пользователей» в №3 Windows 20000 Magazine/RE за 2001 г. - прим. ред.] Однако точно определить, что именно изменено, нельзя (например, изменил ли администратор имя задания пользователя или ограничения, накладываемые на его учетную запись).

Чтобы это сделать, нужно воспользоваться категорией аудита Audit directory access, которая впервые появилась в Windows 2000 и применяется только на DC. Каждый объект AD имеет контрольный список аудита (audit control list - не путать с ACL, списком управления доступом), в котором перечислены типы доступа, регистрируемые в журнале безопасности Windows 2000. Если категория Audit directory access активизирована и кто-то обращается к объекту AD, то Windows 2000 просматривает контрольный список аудита объекта и определяет, нужно ли регистрировать событие доступа. Если категория Audit directory access отключена, то Windows 2000 игнорирует контрольные списки аудита в AD. Данная категория во всех ситуациях генерирует событие с ID 565.

Экран 2. Событие с ID 565 для отслеживания изменений в учетной записи пользователя.

На Экране 2 показано такое событие, созданное Windows 2000 для того же изменения учетной записи пользователя, которое сгенерировало событие Audit account management на Экране 1. Значение DS в поле Object Server говорит о том, что служба каталогов (AD) обнаружила событие. Object Type определяет тип объекта AD, к которому был направлен запрос на доступ, - в данном примере «пользователь». Object Na-me использует формат отличительного имени (distinguished name, DN) протокола Lightweight Directory Access Protocol (LDAP), чтобы идентифицировать объект доступа. В данном примере объектом доступа была учетная запись пользователя John в домене acme.com. Чтобы определить, кем была изменена учетная запись, можно использовать поля Client User Name, Client Domain и Client Logon с ID (так же, как поля Caller User Name, Caller Domain и Caller Logon с ID в событии с ID 642). Первая текстовая строка в разделе Properties показывает тип доступа - операция записи одного или нескольких свойств. Из остальных текстовых строк видно, что было изменено свойство displayName, т. е. поле Display name объекта user.

Событие с ID 565 показывает, какие свойства были изменены. Обычно имена свойств понятны без дополнительных пояснений, но иногда их бывает трудно расшифровать, так как имена свойств в событии с ID 565 взяты непосредственно из схемы AD. Например, если изменить фамилию пользователя, то Windows 2000 регистрирует событие как изменение свойства sn, где sn обозначает фамилию (surname). Встретив свойство с непонятным именем, можно воспользоваться оснасткой Active Directory Schema консоли управления Microsoft Management Console (MMC), чтобы получить какие-то указания на смысл имени. Данная оснастка не регистрируется по умолчанию. Чтобы ею воспользоваться, необходимо обратиться к командной строке, перейти в каталог \%system root%system32 и выполнить команду

regsvr32 schmmgmt.dll

Экран 3. Определение имен свойств.

В столбце Description оснастки Active Directory Schema показаны имена свойств различных объектов. Например, свойство «1» объекта user - это Locality-Name (название местности) объекта, как показано на Экране 3. Однако затем нужно догадаться, что Locality-Name соответствует полю City (город) на закладке Address страницы Properties объекта user; доступ к этой странице можно получить из оснастки MMC Active Directory Users and Computers. Остальные поля события с ID 565 не имеют отношения к задаче отслеживания изменений в учетных записях и группах.

В зависимости от типа внесенного изменения Windows 2000 может зарегистрировать как событие Audit account management, так и событие с ID 565 или только событие с ID 565, так как события категории Audit account management не связаны с AD. Категория Audit account management отслеживает изменения политик пользователей, групп и учетных записей, выполняемых Windows 2000 с помощью функций SAM. В сущности, AD заменяет SAM на контроллерах домена Windows 2000, поэтому Windows 2000 преобразует изменения SAM в изменения AD. Чтобы увидеть общие свойства этих событий, нужно сравнить свойства учетной записи пользователя AD (которые видны в консоли Active Directory Users and Computers) с подмножеством свойств учетной записи пользователя SAM (показанных в разделе Local Users and Groups консоли MMC Computer Ma-nagement). При изменении свойства, обслуживаемого SAM (например, выводимого на экран имени пользователя), Windows 2000 регистрирует как событие управления учетной записью, так и событие с ID 565. Однако при изменении свойства, поддерживаемого лишь AD (например, фамилии пользователя), Windows 2000 регистрирует только событие с ID 565.

Чтобы воспользоваться обеими категориями аудита для отслеживания изменений в домене, необходимо активизировать эти категории - для всех DC домена - в объекте групповой политики Default Domain Controllers Policy Group Policy Object (GPO), связанном с организационной единицей OU Domain Controllers. [О том, как задать политику аудита в GPO, рассказано в статье «Контроль событий регистрации в Windows 2000» в №3 электронного приложения «Профессионалам Windows 2000/NT» по адресу: http://www.osp.ru/win2000/worknt/2001/03/302.htm - прим. ред.] Контрольный список аудита индивидуальных объектов AD редактировать не нужно, потому что принимаемый по умолчанию контрольный список аудита в корне домена задает режим проверки всех изменений. Чтобы просмотреть этот контрольный список аудита, нужно открыть оснастку Active Direc-tory Users and Computers и выбрать пункты View и Advanced Features из строки меню. Затем следует щелкнуть правой кнопкой мыши на корне домена и выбрать Properties. Перейдя к закладке Security, нужно щелкнуть на кнопке Advanced, а затем перейти к закладке Auditing, показанной на Экране 4. Щелкнув на кнопке View/Edit, можно просмотреть все попытки внесения изменений.

Экран 4. Контрольный список аудита.

По умолчанию Windows 2000 использует группу Everyone, чтобы следить за всеми операциями независимо от того, кто их выполняет. Если нужно контролировать действия конкретных пользователей, можно указать их. Пользователи, группы и другие объекты AD автоматически наследуют принимаемый по умолчанию контрольный список аудита, если не указано иное. Для контрольных списков аудита в Windows 2000 применяются те же модели и варианты наследования, что и для списков ACL.

Отслеживание операций с учетными записями

Если кто-то создает учетную запись пользователя с помощью оснастки Active Directory Users and Computers, то Windows 2000 регистрирует по меньшей мере восемь событий. Последовательность событий может быть разной, но первым обычно регистрируется событие с ID 565.

В Object Name события содержится OU, в котором была создана учетная запись пользователя, и указывается тип доступа Create Child. В поле Object Type показан тип созданного объекта (user). Но событие с ID 565 не указывает его имя. Windows 2000 также регистрирует событие управления учетной записью с ID 624 (создана учетная запись пользователя), которое показывает имя вновь созданной учетной записи.

После того как создана учетная запись пользователя, сразу выполняется настройка различных параметров для этой учетной записи. Эти изменения генерируют различное число записей о событиях с ID 642, которые не указывают, какие именно свойства были изменены. При этом регистрируется столько же событий с ID 565, в которых перечислены измененные свойства. Число пар событий с ID 642 и с ID 565 зависит от параметров, выбранных при создании учетной записи.

Еще одно событие управления учетной записью, которое регистрируется при создании учетной записи пользователя, - событие с ID 627 (попытка изменения пароля). Если событие с ID 627 следует немедленно за созданием учетной записи пользователя, то оно просто отражает назначение начального пароля для учетной записи. Во всех остальных случаях событие с ID 627 можно использовать для отслеживания изменений пароля. Поля Target Account Name, Target Domain и Target Account с ID идентифицируют владельца данного пароля. Поля Caller User Name и Caller Domain указывают, кто изменил пароль. С помощью Logon с ID можно связать изменение пароля с соответствующим событием регистрации с ID 528 или событием с ID 540. Если имена Target Account Name и Caller User Name совпадают, то можно сделать вывод, что пользователь изменил свой собственный пароль. В противном случае событие означает, что пароль был изменен другим лицом. Отслеживая событие с ID 627, можно контролировать работу службы поддержки и сотрудников, меняющих забытые пароли.

Контролируя процесс обслуживания учетных записей пользователей, необходимо обращать внимание на событие с ID 642, которое происходит не сразу (т. е. по прошествии более чем 1 с) после создания учетной записи пользователя (событие с ID 624). Событие с ID 642 просто сообщает, что учетная запись пользователя изменена, и указывает, кем именно. Чтобы выяснить, какие поля были изменены, нужно посмотреть на смежные события с ID 565 и отметить свойства, упоминаемые в описаниях. В AD все параметры учетной записи пользователя (Account options), показанные на Экране 5, содержатся в одном свойстве, называемом userAccountControl. Поэтому, если обнаружено это свойство, значит, мог быть изменен любой из параметров.

Экран 5. Параметры учетной записи пользователя.

Чтобы обнаружить случаи удаления учетных записей пользователей, событие с ID 630 использует те же поля Target и Caller, что и событие с ID 642. Наряду с событием с ID 630 иногда регистрируются два смежных события с ID 565. В первом событии с ID 565 приведено DN организационной единицы удаленной учетной записи. Второе событие с ID 565 в сущности повторяет событие с ID 630 (т. е. показывает, что учетная запись пользователя была удалена), но идентифицирует пользователя по полному имени user principal name (UPN), а не по экранному имени.

Изменение статуса учетной записи пользователя - еще одна важная операция, отслеживаемая категорией Audit account management. Если Windows 2000 блокирует учетную запись пользователя в результате неудачной попытки регистрации, в журнал заносится событие с ID 644 (учетная запись пользователя блокирована). Target Account Name и Target Account с ID указывают пользователя, чья учетная запись была блокирована. Поле Caller Machine Name позволяет определить, с какого компьютера была сделана неудачная попытка регистрации. В журнале безопасности событию с ID 644 должно предшествовать несколько событий с ID 675 и с ID 681. События с ID 675 и с ID 681 сообщают о неудачной аутентификации. [О них было рассказано в статье «Аудит событий регистрации пользователей» - прим. ред.]

Если Windows 2000 регистрирует событие с ID 644, в журнале может появиться дополнительное событие с ID 642 с описанием User account locked («учетная запись блокирована»). Когда учетная запись пользователя активизируется или блокируется, Windows 2000 регистрирует только событие с ID 642 с описанием Account enabled или Account disabled.

Следить за операциями по обслуживанию групп значительно проще, чем за действиями, связанными с обслуживанием учетных записей пользователей. Поскольку категория Audit account management сообщает отдельные номера событий для каждой комбинации операций (создание, удаление, добавление членов, удаление членов и общие изменения) и тип группы (универсальная, глобальная и локальная), смежное событие с ID 565 не имеет значения для контроля групповых операций. Исключение составляют событие с ID 659, событие с ID 636 и событие с ID 641: они сообщают, что группа изменилась, не указывая измененных свойств (это описывается в сообщении о смежном событии с ID 565). При изменении сферы влияния или типа группы (т. е. безопасности или распространения) Win-dows 2000 регистрирует событие с ID 688 (изменение типа группы); в описании данного события измененные параметры указаны. Данное событие определяет группы безопасности как защищенные, Security Enabled, а группы распространения - как незащищенные, Security Disabled. Группы безопасности можно использовать для таких операций защиты, как назначение прав и составление списков контроля доступа (ACL); группы распространения можно использовать лишь в почтовых программах для рассылки сообщений сразу нескольким пользователям. Например, если изменить глобальную группу безопасности на универсальную группу распространения, то событие с ID 688 указывает описание Security Enabled Global Group Changed to Security Disabled Universal Group.

Отслеживание изменений политик

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

Экран 6. Событие с ID 565, фиксирующее изменение в групповой политике.

Изменения в групповой политике. Поскольку Group Policy управляет всеми аспектами конфигурации безопасности Windows 2000, изменения в групповой политике могут иметь далеко идущие последствия. С помощью события с ID 565 можно отслеживать изменения в отдельных объектах GPO и в параметрах групповой политики для OU, узлов и доменов. В процессе редактирования политик GPO (например, параметры безопасности изменяются в разделе Computer Configuration, а ограничения назначаются в User Configu-ration) Windows 2000 регистрирует событие с ID 565, в котором Object Type есть groupPolicyContainer. В поле Properties событие этого типа, как показано на Экране 6, содержит описание versionNumber для свойства Write Property (свойство «запись»). Событие с ID 565 точно указывает на изменившиеся политики внутри GPO, так как эти политики размещаются вне AD. Если блокировать разделы User Confi-guration или Computer Configuration объекта групповой политики, то событие с ID 565 в поле Properties свойство Flags Property. Если отметить GPO как No overrс IDe (запрет переопределения) или Disabled (блокированный), следует помнить, что эти изменения отражаются на OU, домене и узле, с которыми связан GPO, а не на GPO. Поэтому описание события с ID 565 определяет Object Type как organizatio-nalUnit, domainDNS или узел, а измененное свойство - как gPOptions. Если связать с OU, доменом или узлом другие объекты GPO, то в описании события с ID 565 будет указан соответствующий тип объекта, у которого изменено свойство gPLink. Если администратор изменяет ACL объекта GPO, то событие с ID 565 определяет тип объекта как groupPolicyContainer, имя объекта - как DN GPO, и тип доступа Accesses - как WRITE_DAC (что указывает на изменение соответствующего ACL). Список управления доступом GPO не только определяет круг лиц, имеющих право редактировать GPO, но и указывает, к каким компьютерам и пользователям Windows 2000 может применяться данный GPO. Если администратор делегирует право управления OU, то событие с ID 565 определяет объект как OU, а тип доступа - как WRITE_DAC.

Изменения политики учетной записи домена. Контроль изменений политики учетной записи домена (пароль, блокировка и политика Kerberos) необходим, так как эти политики влияют на безопасность всего домена. Их конфигурацию можно задать в любом GPO, связанном с корнем домена (в Computer Configuration, Windows Set-tings, Security Settings, Account). Поскольку эти параметры относятся к уровню домена, их изменение в объектах GPO, связанных с OU и узлами, не влияет на домен. Изменения в политике учетной записи домена должны быть редкими; их легко обнаружить с помощью еще одного отдельного события, с ID 643 категории Audit account management. Если изменить политику назначения паролей или политику Kerberos, то Windows 2000 регистрирует событие с ID 643 с описанием Domain Policy Changed: Password Policy modified («изменилась политика домена: обновление политики пароля»). Если изменить политику блокирования, то описание события с ID 643 примет вид Domain Policy Changed: Lockout Policy modified. Однако поле Caller User Name не идентифицирует администратора, изменившего политику, поскольку политика домена не изменяется напрямую; для этого требуется отредактировать GPO. При следующем обновлении групповой политики контроллер обнаруживает изменение и применяет его для локальной конфигурации в рамках своих полномочий. Поэтому, чтобы выяснить, кем были сделаны изменения в политике домена, необходимо исследовать предыдущие записи журнала и отыскать изменения, касающиеся Group Policy.

Таким образом, поняв взаимосвязь категорий Audit account management и Audit directory access, администратор сможет следить за всеми изменениями в домене AD. Необходимо помнить, что Windows 2000 регистрирует события этих категорий на том контроллере, где проводятся изменения. Например, если администратор сделает учетную запись пользователя, подключившись к контроллеру Philly, Windows 2000 заносит события в локальный журнал безопасности Philly. Знание этих категорий и событий позволит извлечь из журнала безопасности Windows 2000 больше полезной информации.

Рэнди Франклин Смит - президент компании Monterey Technology Group, занимающейся обучением и консалтингом в области защиты Windows NT. Связаться с ним можно по адресу: rsmith@montereytechgroup.com.