Аудит учетных записей, объектов групповых политик и организационных единиц поможет контролировать AD

Active Directory (AD) — типичный пример критически важной системы, которая определяет инфраструктуру компании. Часто объект AD самого высокого уровня (лес) соответствует всему предприятию, и одной ошибки достаточно, чтобы вызвать катастрофический сбой в масштабах организации. Чем больше в компании администраторов, тем выше вероятность ситуации, когда «у семи нянек дитя без глазу». Потребность в эффективных инструментах мониторинга AD становится еще более очевидна, если учесть попытки несанкционированного доступа извне и вредительство со стороны недовольных сотрудников отдела ИТ.

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

Администратор может следить за происходящим в AD и изменениями, которые вносят сотрудники, с помощью двух категорий аудита: управления учетными записями (account management) и доступа к службе каталога (directory service access). Аудит управления учетными записями обеспечивает оповещение о высокоуровневых качественных изменениях (создании, удалении и других изменениях) учетных записей пользователей, компьютеров и групп. Кроме того, с помощью аудита управления учетными записями можно отслеживать некоторые изменения, связанные с политиками.

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

Аудит управления учетными записями

Чтобы активизировать аудит управления учетными записями, нужно выбрать политику Domain Controller Security Policy в разделе Administrative Tools, перейти к Security Settings, Local Policies и Audit Policy и установить режим Audit account management для успешных событий и ошибок. В этом режиме можно получить идентификаторы отдельных событий создания, удаления и изменения учетных записей пользователей, компьютеров и групп. В табл. 1 перечислены ID событий управления учетными записями.

С помощью события создания учетных записей можно очистить AD от избыточных и нестандартных учетных записей пользователей, компьютеров и групп. Удалить избыточные и ненужные объекты гораздо легче вскоре после их создания, чем по прошествии значительного времени, когда никто не помнит, для чего предназначался объект или почему он был создан. Администратор может немедленно проверить события создания и определить соответствие новых учетных записей пользователей, групп и компьютеров политикам и процедурам организации. Появление новой учетной записи компьютера означает, что кто-то добавил в домен рабочую станцию или сервер. Сравнив событие с ID 645 с планом развертывания новых компьютеров, можно проверить, было ли добавление компьютера санкционированным. Событие с ID 624 позволяет отслеживать учетные записи новых пользователей домена, проверять корректность новых учетных записей пользователей и применять любые политики для соглашений об именовании, документирования информации о сотрудниках/подрядчиках, общих учетных записях или учетных записях приложений.

Наблюдение за событиями с ID 631, 635 и 658 позволяет четко применять к группам политики соглашения об именовании и ясно обозначить владельца каждой группы, ответственного за добавление новых и удаление существующих членов. Имя владельца группы можно указать на вкладке Managed By в окне Properties. В результате группа оказывается связанной с учетной записью пользователя в AD. Вкладка Managed By имеется и в диалоговых окнах Properties большинства других объектов AD.

В крупномасштабных реализациях AD трудно отслеживать ресурсы и права доступа конкретной группы, предоставляемые ее членам. Эту информацию можно документировать в поле Notes на вкладке General диалогового окна Properties.

Удаление пользователей, групп и компьютеров редко представляет угрозу для безопасности, поэтому выполнять текущий мониторинг событий удаления, как правило, не нужно. Однако это может быть полезным, если требуется выяснить, кто случайно удалил важную учетную запись или группу, и если происходит массовое удаление множества пользователей и групп в ходе атаки типа DoS (Denial of Service — отказ в обслуживании).

Изменения могут иметь негативные последствия для системы безопасности, в зависимости от того, какая информация о пользователе, группе или компьютере была изменена. За редким исключением, аудит управления учетными записями предоставляет лишь один ID события изменения для каждого типа объекта; поэтому по идентификатору события нельзя определить, что именно изменилось; но в некоторых случаях дополнительную информацию удается почерпнуть из деталей события.

Как правило, при любом изменении учетной записи пользователя в результате аудита управления на вкладке Account диалогового окна Properties объекта выдается событие ID 642; текстовыми пояснениями сопровождаются только важные изменения в системе безопасности, такие как события активации или деактивации. Например, если изменено описание пользователя, то выдается просто событие с ID 642 с текстом User Account Changed, но без каких-либо дополнительных пояснений. Если активизировать или блокировать учетную запись, то будет выдано то же самое событие с ID 642, но с дополнительным сообщением: User Account Changed: Account Disabled. Автоматизация мониторинга и подготовка выборочных отчетов затрудняются из-за необходимости собирать дополнительную информацию о событиях; однако с помощью таких инструментов, как GFI LANguard Security Event Log Monitor (S.E.L.M.) фирмы GFI Software, AppManager Suite компании NetIQ и Microsoft Operations Manager (MOM), можно назначить правила и создать отчеты на основе деталей события.

В результате аудита управления учетными записями можно получить ID конкретных событий, связанных с некоторыми изменениями в учетных записях пользователей. Если лицо с соответствующими правами изменяет пароль пользователя, то выдается событие с ID 628 (установлен пароль учетной записи пользователя). Если кто-то пытается изменить собственный пароль, записывается событие с ID 627 (попытка изменения пароля). При обнаружении повторных попыток входа с неверным паролем Windows 2000 Server блокирует учетную запись (если в домене активизирована политика блокирования учетных записей) и генерирует событие с ID 644 (учетная запись user блокирована).

Событие с ID 643 (Domain Policy Changed: Password Policy modified, изменение политики применения пароля) случается часто, даже если политика применения паролей не изменялась. Причиной тому — ошибка в Windows 2000. При применении групповой политики Windows 2000 не проверяет, существуют ли отличия между новыми и старыми политиками. Для настройки политики применения паролей используется объект Default Domain Policy Group Policy Object (GPO); при этом Windows 2000 генерирует событие с ID 643. Отсюда вывод — событие с ID 643 смело можно игнорировать.

В табл. 2 перечислены идентификаторы событий, генерируемых при добавлении и удалении членов группы всех типов. Если в организации доступ пользователей к папкам и другим ресурсам разрешен исключительно через группы, то события с ID 632, 636 и 660 чрезвычайно полезны, так как с их помощью можно отслеживать все случаи предоставления пользователю или группе нового разрешения доступа. На экране 1 показаны подробности события при добавлении члена в универсальную (universal) группу. В деталях указывается, какая группа подверглась изменениям (Target Account Name), кто был добавлен в группу (Member Name) и кто выполнил операцию (Caller User Name). На основании этой информации можно определить владельца группы или убедиться в законности изменения через систему контроля службы поддержки.

Экран 1. Детали события с ID 660

Аудит доступа к службе каталога

Благодаря аудиту управления учетными записями можно получить полезную информацию для наблюдения за учетными записями пользователей, компьютерами и группами, но как вести мониторинг других элементов AD, таких как изменения GPO и организационные единицы (OU)? Эффективное средство для этих целей — аудит доступа к службе каталога. События аудита доступа к службе каталога менее известны и трудны для расшифровки, но содержат чрезвычайно подробную информацию о каждом событии, происходящем в AD. В результате аудита доступа к службе каталога генерируется единственное событие с ID 565 (Object open — объект открыт). Вся полезная информация содержится в деталях события. Для активизации аудита доступа к службе каталога следует выбрать политику Domain Controller Security Policy в разделе Administrative Tools, затем перейти к Security Settings, Local Policies, Audit Policy, дважды щелкнуть на Audit directory service access и выбрать как Success, так и Failure.

С помощью аудита доступа к службе каталога можно отслеживать изменения, связанные с групповыми политиками. Самые элементарные сведения об изменениях Group Policy, которые полезно получить администратору, — своевременное оповещение о редактировании одной или нескольких политик, определяемых GPO. Для данной ситуации не существует события с особым ID, но ее можно определить, зная отличительные признаки. В схеме AD объекты GPO имеют тип groupPolicyContainer и версию versionNumber. Если кто-то редактирует GPO, то Windows 2000 увеличивает номер версии. Заново применяя Group Policy, компьютеры домена сравнивают текущий номер версии каждого GPO с номером версии, который был у объекта во время предыдущего применения групповой политики. Если номер версии не изменился, то компьютер не выполняет GPO повторно, тем самым сохраняя ресурсы как локальных компьютеров, так и контроллера домена. Изменения GPO можно обнаружить, отыскав события с ID 565, у которых параметр Object Type имеет значение groupPolicyContainer, параметр Accesses — значение Write Property, а в Write Property указан versionNumber, как показано на экране 2.

Экран 2. Детали события изменения GPO

Следует обратить внимание, что Windows 2000 не сообщает описательное имя GPO, как в оснастке Active Directory Users and Computers консоли Microsoft Management Console (MMC). Вместо этого событие сообщает отличительное имя (distinguished name, DN) объекта в формате X.500. Например, на экране 2 Object Name — CN={6AC1786C-016F-11D2-945F-00C04fB984F9}, CN=Policies,CN=System, DC=ad,DC=local. Полезная информация в DN объекта GPO содержится в длинной начальной последовательности символов — это глобально уникальный идентификатор (GUID) GPO. С помощью оснастки Active Directory Users and Computers можно связать описательное имя GPO с его GUID. Например, чтобы получить GUID для Default Domain Controllers Policy GPO, требуется открыть диалоговое окно Properties для Domain Controllers OU и выбрать вкладку Group Policy. В списке GPO нужно выбрать политику Default Domain Controllers Policy и щелкнуть на Properties. GUID объекта GPO отображается на вкладке General в поле Unique name (экран 3).

Экран 3. Идентификатор GUID политики Default Domain Controllers Policy

Следует обратить внимание, что в разделе Disable (экран 3) можно блокировать одну или обе политики Computer Configuration и User Configuration. Если установить один или оба флажка, то Windows 2000 прекращает применять все ассоциированные политики, что может иметь важные последствия для всех компьютеров и пользователей домена. Чтобы обнаружить изменение одного или обоих флажков в любом GPO, необходимо обратиться к событию с ID 565, в котором параметр Object Type имеет значение groupPolicyContainer, а Properties — flags.

Последний тип изменения GPO, который можно отслеживать, — это изменение списка управления доступом (Access Control List, ACL) GPO. ACL определяет, кто из пользователей может редактировать GPO, и позволяет ограничить число пользователей и компьютеров, к которым применяется GPO внутри связанной с объектом групповой политики организационной единицы или домена. В этом случае следует, как обычно, обратить внимание на событие с ID 565 Object Type groupPolicyContainer, но поле Accesses должно содержать значение WRITE_DAC (доступ для записи к дискреционному ACL).

Если кто-то удаляет GPO, то генерируется событие с ID 565, параметр Object Type которого имеет значение groupPolicyContainer, Object Name начинается с CN=Policies,CN=System, а Accesses имеет значение Delete Child. Событие с тем же ID, Object Type и начальной фразой Object Name, но значением параметра Accesses — Create Child вместо Delete Child указывает, что кто-то создал новый GPO. К сожалению, ни в одном событии не указывается GUID или описательное имя GPO.

Экран 4. Связанные с OU объекты GPO

Другая область изменений, связанных с Group Policy и требующих мониторинга, — изменение определяемых групповыми политиками свойств OU. Как показано на экране 4, у каждой OU есть список связанных с ней GPO; каждый GPO из этого списка имеет два параметра — No Override и Disabled. Кроме того, OU располагает наследуемым флажком Block Policy, также связанным с Group Policy. Если кто-то устанавливает или разрывает связь с GPO либо устанавливает или сбрасывает любые другие параметры, эти изменения могут иметь важные последствия для компьютеров и пользователей в данной OU. Чтобы обнаружить изменения в списке связанных GPO, изменения параметров No Override или Disabled либо изменения наследуемого значения Block Policy, необходимо отыскать событие с ID 565 со значением organizationalUnit параметра Object Type и значениями gPOptions и gPLink параметра Write Property (экран 5).

Экран 5. Детали с ID события для измененного OU GPO

GPO могут быть связаны с доменами и сайтами. Чтобы обнаружить связанные с GPO изменения в домене или сайте, следует обратиться к событию с ID 565, параметр Object Type которого имеет значение domainDNS или site, а значения параметра Write Property — gPLink и gPOptions.

Чтобы контролировать изменения прав администраторов и других полномочий в AD, можно следить за изменениями в ACL-списках OU. Заслуживающие внимания детали событий подобны описанным выше для ACL-списков GPO. Обнаружив событие с ID 565, Object Type organizationalUnit и Accesses WRITE_DAC, можно сделать вывод, что кто-то изменил полномочия в данной OU. В поле Object Name явно указано DN организационной единицы.

Создание новой OU можно обнаружить, взглянув на событие с ID 565, где параметр Object Type имеет значение organizationalUnit, а Accesses — Create Child. В таком событии Object Name указывает родительскую OU, а не имя новой OU. Детали событий удаления — те же, за исключением того, что параметр Accesses имеет значение Delete Child вместо Create Child.

Изменения в сайтах можно обнаружить, изучив событие с ID 565, параметр Object Type которого имеет значение site, siteLink, siteLinkBridge, subnet, nTDSSiteSettings или serversContainer. Изменения в репликации между контроллерами домена представлены событием с ID 565 со значениями nTDSConnection или nTDSSiteSettings параметра Object Type. Для мониторинга изменений в доверительных отношениях следует обратить внимание на событие с ID 565 с параметром Object Type, имеющим значение trustedDomain, который используется Windows 2000 как для доверенных, так и для не связанных доверительными отношениями доменов. При наличии в домене одного или нескольких корпоративных сертификатов Certificate Authorities (CA) можно контролировать изменения в шаблонах сертификатов, самих CA и списках отзыва сертификатов (Certificate Revocation Lists, CRL), отыскав параметр Object Type со значением Type pKICertificateTemplate, pKIEnrollmentService, certificationAuthority или cRLDistributionPoint.

Поиск в журнале безопасности

Аудит управления учетными записями и доступом к службе каталога обеспечивает ценную информацию, необходимую для контроля изменений в AD. Подробные сведения содержатся в журнале безопасности, но как найти их? Очевидно, что просматривать каждое событие вручную невозможно. Для специализированного поиска можно использовать функцию утилиты Event Viewer. Следует открыть Event Viewer, щелкнуть правой кнопкой мыши на журнале Security и выбрать пункт View/Find. Как показано на экране 6, можно указать ID события и ввести в поле Description текст, который утилита должна отыскать в деталях обнаруженных событий.

Экран 6. Поиск события в журнале событий

Для регулярного мониторинга необходимы более эффективные инструменты. Например, можно воспользоваться утилитой dumpel.exe из комплекта Microsoft Windows 2000 Resource Kit, которая также предоставляется по адресу: http://www.microsoft.com/windows2000/techinfo/reskit/ tools/existing/dumpel-o.asp. Dumpel фильтрует события по номеру, но не по деталям событий, которые он воспринимает как строки. Для дальнейшей фильтрации событий, например с ID 565, по содержимому строк можно использовать команду Findstr.

К сожалению, Windows 2000 регистрирует в журнале Security не описательное имя, а GUID атрибутов схемы, и Dumpel не преобразует GUID в имя. Поэтому дамп события с ID 565 выглядит так, как показано на экране 7. Расшифровать его можно с помощью документации схемы Windows 2000 AD, приведенной по адресу http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adschema/adschema/windows_2000_schema.asp. Просмотрев данный сайт, можно убедиться, что bf967aa5-0de6-11d0-a285-00aa003049e2 — схема GUID для organizational-Unit, а f30e3bbe-9ff0-11d1-b603-0000f80367c1 и f30e3bbf-9ff0-11d1-b603-0000f80367c1 — идентификаторы GUID для gPLink и gPOptions. Располагая этой информацией, можно использовать команды

dumpel -l security -t
-format Idtus -m security
-e 565 > events.txt
findstr «bf967aa5-0de6-11d0-
a285-00aa003049e2» events.txt

чтобы получить список всех событий с ID 565, в которых тип объекта имеет значение organizationalUnit.

Таким образом, зная, где отыскать нужные сведения, можно получить точную информацию о происходящем в AD, или по крайней мере выявить причины неполадок. Необходимо активизировать режимы Audit account management и Audit directory service access в Default Domain Controllers Policy GPO, а для того, чтобы получить полную картину активности в домене, требуется проверить каждый домен. Удачи в анализе журнала Security!

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