Объект AdminSDHolder как на ладони

Для наглядности возьмем простой пример объекта AdminSDHolder. Джо работает в справочной службе ИТ-подразделения и, как член группы Service Desk, обладает делегированным разрешением на восстановление паролей для всех пользователей организационной единицы (organizational unit, OU), именуемой Wellington Users. Когда Джо пытается изменить пароль для пользователя Джеймса Смита, он получает сообщение об ошибке " Отказано в доступе ". Джо, получивший неплохую техническую подготовку, открывает оснастку Active Directory Users and Computers консоли MMC (Microsoft Management Console) и сравнивает настройки безопасности Джеймса Смита, которые показаны на Экране 1, с настройками Дона Мерфи, чей пароль он может изменить, как показано на Экране 2.

В настройках Дона Мерфи Джо видит, что группа Service Desk имеет разрешение на изменение паролей. А вот в настройках Джеймса Смита такого разрешения нет, что также свидетельствует  о том, что цепочка наследования разрешений разорвана. Джо просит одного из администраторов AD изменить настройки безопасности Джеймса Смита так, чтобы они соответствовали настройкам Дона Мерфи. Джо отправляется на обед и, вернувшись, находит записку от администратора AD, в которой говорится, что настройки безопасности были изменены в соответствии с его пожеланиями. Джо вновь пытается изменить пароль Джеймся Смита и видит все то же сообщение об отказе в доступе. Что же произошло?

В результате более тщательного исследования учетной записи Джеймса Смита выясняется, что он является членом группы Domain Admins. AD защищает от угроз определенные привилегированные группы и учетные записи, в том числе группу Domain Admins. В Таблице 1 приводится перечень этих групп и учетных записей. Защита распространяется на всех членов этих групп, включая членов вложенных групп. В нашем примере можно было бы говорить о плохой организации безопасности, если бы Джо имел возможность изменять пароль учетной записи, входящей в группу Domain Admins. Ведь при этом он мог бы с легкостью сам использовать эту учетную запись, мог бы сделать свою учетную запись членом группы Domain Admins, мог бы создать новую учетную запись с расширенными привилегиями или выполнять сходные задачи. Очевидно, что с точки зрения обеспечения безопасности данных вполне разумно иметь встроенные средства защиты.

Что такое AdminSDHolder?

Нередко термин AdminSDHolder используют для обозначения процесса, с помощью которого AD защищает привилегированные группы и учетные записи, но на самом деле речь идет об имени объекта AD.

AdminSDHolder - это объект-контейнер в разделе каталога домена CN=AdminSDHolder, CN=System, - например, CN=AdminSDHolder, CN=System, DC=north, DC=com.

Сам по себе объект не играет какой-то особой роли; он используется в качестве объекта-заполнителя для ограниченного дескриптора безопасности. На экране 3 представлен пример дескриптора безопасности объекта AdminSDHolder. Ежечасно на контроллере домена (DC), где размещаются роли эмулятора главного контроллера домена, выполняется фоновая задача SAM. При выполнении этой задачи, помимо прочего, осуществляется проверка дескрипторов безопасности защищаемых групп на предмет соответствия дескрипторам безопасности объекта AdminSDHolder. Если дескрипторы не совпадают, задача AdminSDHolder вместо разрешений, назначенных проблемной группе или пользователю, записывает дескриптор безопасности AdminSDHolder. В нашем примере задача AdminSDHolder заменила унаследованные разрешения, которые администратор AD установил в учетной записи Джеймса Смита; в результате и возникла неразбериха.

Наряду с этим задача AdminSDHolder меняет значение атрибута пользователя или группы adminCount. Если ранее его значение было , то теперь оно равно 1. На Экране 4 показан пример атрибутов Джеймса Смита при просмотре с помощью инструмента ADSI Edit.

Вы можете изменить дескриптор безопасности, связанный с объектом AdminSDHolder, но я не советую этого делать. Имейте в виду, что после внесения изменений меняются все защищаемые пользователи и группы с новым дескриптором безопасности. Плохо спланированная конфигурация может превратить среду AD в мишень для всевозможных атак. К примеру, если вы предоставите членам группы Domain Users полную свободу действий в отношении объекта AdminSDHolder, это приведет к тому, что любой пользователь в домене будет иметь потенциальную возможность получить полномочия членов группы Domain Admins.

Не изменяйте дескрипторов безопасности

Я полагаю, оптимальный метод состоит в том, чтобы не вводить стандартные пользовательские учетные записи в состав групп, защищаемых объектом AdminSDHolder. Под "стандартными" учетными записями я имею в виду те, под которыми администратор обычно регистрируется в домене с рабочей станции для выполнения повседневных задач, таких как создание документов Microsoft Word или работа с электронной почтой. Если необходимо, чтобы пользователь выполнял административные задачи, создайте для него вторую учетную запись специально для этой цели. Это позволит избежать ситуаций, подобных описанной в начале статьи. Чтобы решить проблему из этого примера, Джеймсу Смиту можно назначить еще одну учетную запись для выполнения административных функций, сделать ее членом группы Domain Admins и разместить запись в отдельную организационную единицу, куда не могут обращаться члены группы Service Desk.

Изменение графика выполнения задания AdminSDHolder

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

Найдите в реестре подраздел HKEY_LOCAL_MACHINE SYSTEMCurrentControlSetServicesNTDS Parameters. Если такого раздела пока нет, добавьте новое значение DWORD с именем AdminSDProtectFrequency и установите его значение (в десятичном формате) в секундах. Наименьшее возможное значение составляет одну минуту (60 секунд), а наибольшее - 120 минут (7200 секунд).

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

Удаление учетных записей из защищенных групп

В обычной среде AD администраторы регулярно вводят учетные записи в защищенные группы и выводят их из этих групп. К примеру, возможна ситуация, когда необходимо временно расширить полномочия той или иной учетной записи для выполнения конкретной задачи. В таких случаях задача AdminSDHolder применяет дескриптор безопасности, ассоциированный с объектом AdminSDHolder (как описано выше), но не возвращается к прежнему дескриптору безопасности, когда учетная запись удаляется из защищенной группы. Кроме того, задача AdminSDHolder не удаляет значение атрибута adminCount, равное 1. На мой взгляд, ситуация оставляет желать лучшего, поскольку у нас имеется дескриптор безопасности с отключенной функцией наследования разрешений и со значением атрибута adminCount, которое может вызывать проблемы, если использовать его в запросах LDAP. На мой взгляд, было бы лучше, если бы задача AdminSDHolder могла «убирать за собой», но увы, в текущей версии Windows такая возможность не реализована.

Какие объекты модифицировала задача AdminSDHolder

Самый популярный эффективный метод определения, какие учетные записи и группы были затронуты в ходе выполнения задачи AdminSDHolder, сводится к проверке записей аудита управления учетными записями с ID 684 в журнале регистрации событий безопасности на контроллере домена, эмулирующего главный контроллер домена. На экране 5 представлен пример подобной регистрационной записи. Отметим, кстати, такое обстоятельство: для того чтобы система могла регистрировать интересующие нас объекты, необходимо включить функцию аудита управления учетными записями. Дополнительные сведения о включении средств аудита AD можно найти в статье "Мониторинг изменений в Active Directory".

В качестве альтернативного метода можно регистрировать задачу  распространения дескриптора безопасности (security descriptor propagation, SDPROP). Задача AdminSDHolder и SDPROP взаимосвязаны, но всякий раз, когда происходит обновление Security Descriptor (SD), SDPROP пытается распространить изменения на дочерние объекты. Иными словами, информационные события SDPROP дают представление о том, какие объекты были затронуты задачей AdminSDHolder, но не забывайте о том, что SDPROP может регистрировать и другие действия, не имеющие отношения к рассматриваемой нами проблеме.

SDPROP не регистрирует информационные события в журнале Directory Service (DS), если пользователь не повысит уровень диагностики по сравнению со значением, принимаемым по умолчанию. Чтобы включить функцию регистрации информационных событий SDPROP, нужно (опять-таки на контроллере домена, эмулирующем главный контроллер домена) изменить значение 9 для Internal Processing в следующем подразделе реестра на 5 (десятичное значение): HKEY_ LOCAL_MACHINESYSTEMCurrentControl SetServicesNTDSDiagnostics. После того как вы установили более высокий уровень регистрации, ищите в журнале регистрации событий DS идентификаторы событий с ID 1257 и ID 1258; при этом в роли источника должен выступать NTDS SDPROP. Эти события будут содержать имена объектов, обновленных средствами SDPROP. Надо сказать, что в случае повышения уровня регистрации генерируется большое число событий, так что к этому средству следует прибегать лишь при выяснении причин какой-либо проблемы; по завершении операции диагностики нужно снизить уровень регистрации.

Третий метод состоит в направлении LDAP-запроса по всем объектам внутри домена, имеющим значение атрибута adminCount, равное 1. Но этот метод ненадежен по причине, которую я уже назвал, а именно потому, что задача AdminSDHolder не удаляет значение данного атрибута в ситуациях, когда объект выводится из числа членов одной из защищаемых групп. В следующем примере я направляю запрос LDAP с помощью ADFind (это превосходная бесплатно распространяемая утилита командной строки, которую можно загрузить по адресу http://www.joeware.net). Запрос осуществляет поиск принимаемого по умолчанию раздела каталога (доменного раздела) и возвращает все пользовательские объекты, у которых значение атрибута adminCount равно 1. Запрос записан на нескольких строках из-за недостатка места, но его следует печатать на одной строке.

adfind -default -f "(&(objectClass=user)
  (objectCategory=Person)(adminCount=1))"
Избегайте ловушек

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

Таблица 1. Защищаемые группы AD и учетные записи