Активация режима List Object в лесу

Гвидо Грилленмайер — главный инженер подразделения HP Enterprise Services Group. Имеет сертификаты Microsoft Directory Services MVP и Microsoft Certified Architect

Администратор может сделать хранящиеся в каталоге Active Directory (AD) данные видимыми только для тех пользователей, которым они действительно нужны. Сокрытие данных позволяет делегировать полномочия на управление пользователями, группами или компьютерами любому субъекту безопасности, что освобождает администраторов доменов от выполнения множества рутинных оперативных задач. Как я уже отмечал в одной из своих статей, один из методов сокрытия данных в AD предполагает использование обычных разрешений AD. Другой вариант — о нем как раз и пойдет речь в данной статье — предполагает активацию в лесу AD режима List Object Mode, который иногда называют режимом List Mode.

Режим List Object

Напомню, что прошедшим проверку полномочий пользователям (Authenticated Users) предоставляются разрешения на чтение и перечисление объектов Read and List Object во всех вновь созданных организационных единицах (OU). Надо сказать, что в конфигурации, используемой по умолчанию, служба AD не обеспечивает принудительное применение разрешения List Object, и редактор безопасности AD не отображает его. Однако после того как администратор предприятия активирует режим List Object (а такая активация возможна лишь в рамках всего леса), разрешение List Object вступает в силу. О том, каким образом активируется режим List Object, речь пойдет несколько позже, а пока давайте рассмотрим, как функционирует данный режим.

Для нас принципиально важно уяснить различие между разрешениями List Contents и List Object, а также разобраться с тем, какие последствия влечет их совместное применение. Концепция режима List Object довольно проста. Когда этот режим отключен (настройка по умолчанию), служба AD не рассматривает разрешений для объектов, расположенных внутри того или иного контейнера (скажем, OU), к которому обращается пользователь.

Пользователь может просмотреть содержимое организационной единицы лишь в том случае, если он получил для данной OU разрешение List Contents (являющееся подмножеством разрешения Read). Если разрешение List Contents не предоставляется (например, вследствие отзыва разрешения Read), дочерние объекты пользователю не возвращаются. Если же разрешение List Contents предоставляется, AD возвращает пользователю все дочерние объекты данной организационной единицы — вне зависимости от того, имеет ли пользователь разрешение на чтение содержимого того или иного дочернего объекта, либо вообще не имеет права доступа к этому объекту. Однако здесь надо отметить, что графические пользовательские интерфейсы, такие, как оснастка Active Directory Users and Computers консоли Microsoft Management Console (MMC) не в состоянии корректно отображать тип объекта, если соответствующий пользователь не имеет полномочий на считывание содержимого дочернего объекта. В таких случаях тип объекта отображается как неизвестный (Unknown), см. экран 1.

Экран 1. Отображение объектов в режиме List Object

При активации режима List Object служба AD, прежде чем возвратить список объектов пользователю, осуществляет оценку разрешений каждого объекта. Чтобы заблокировать возвращение всех дочерних объектов того или иного контейнера, администраторы могут отзывать или не предоставлять разрешения List Contents на родительский контейнер. Но в распоряжении AD все еще остаются разрешения на обращение ко всем этим дочерним объектам, так что данная служба может определить, получил ли тот или иной пользователь разрешение List Object применительно к какому-либо дочернему объекту. При положительном ответе на этот вопрос AD добавляет объект к результирующему набору, в противном случае объект опускается.

Сопоставление трех примеров, представленных на экране 1, показывает различие в механизмах сокрытия объектов с помощью режима List Object и в случае применения обычных разрешений.

* Ситуация A (обычный доступ на чтение).

— Режим List Object в AD отключен.

— Пользователю предоставляется разрешение List Contents для родительской организационной единицы US. Механизм предоставления — обычное разрешение на чтение, полагающееся всем пользователям, входящим в группу Authenticated Users.

— Наряду с этим пользователь имеет разрешение на считывание содержимого дочерних объектов (т.е. организационных единиц ATL и PHX).

— В итоге в окне оснастки Active Directory Users and Computers отображаются два объекта. Пользовательский интерфейс может произвести оценку обоих объектов, которые могут отображаться с применением корректных значков и т.д.

* Ситуация B (отказ в разрешении на чтение содержимого объекта ATL).

— Режим List Object в службе AD отключен.

— Пользователь получает разрешение List Contents применительно к родительской организационной единице US (через обычное разрешение на чтение, выдаваемое всем пользователям, которые входят в группу Authenticated Users).

— Пользователь все еще располагает разрешением на считывание содержимого дочернего объекта PHX, но право на доступ для чтения к дочернему объекту ATL членам группы Authenticated Users не предоставляется.

— В результате в окне оснастки Active Directory Users and Computers отображаются два объекта, но пользовательский интерфейс в состоянии корректно оценить и отобразить только дочерний объект PHX; объект же ATL отображается как неизвестный, хотя пользователь знает, что этот объект существует.

* Ситуация C (режим Activated List Object в AD активирован).

— Режим List Object службы AD активирован.

— Разрешение List Contents применительно к родительской организационной единице US для данного пользователя отменяется, поскольку отзывается соответствующее разрешение для пользователей группы Authenticated Users.

— Пользователь имеет применяемые по умолчанию разрешения Read и List Object в отношении дочернего объекта PHX. Пользователь все еще располагает применяемым по умолчанию разрешением на чтение содержимого дочернего объекта ATL, но разрешение List Object отменяется.

— В результате в окне оснастки Active Directory Users and Computers отображается только один объект — тот самый, в отношении которого пользователь имеет разрешение List Object. Благодаря наличию дополнительного разрешения на считывание содержимого других атрибутов пользовательский интерфейс корректно оценивает и отображает данный объект. Дочерний объект ATL более не отображается, и пользователь не имеет данных о его существовании в каталоге AD.

Разрешение List Object — инструмент, весьма полезный в случаях, когда пользователям не положено просматривать определенные объекты в каталоге AD. Такое разрешение обычно используется применительно к организационным единицам; оно позволяет полностью отменять видимость соответствующей OU для всех пользователей (за исключением администратора, управляющего данной организационной единицей). Применение разрешения List Object дает особенно значительный эффект в сетях, где реализуются схемы аутсорсинга и субподрядчик предоставляет целый каталог нескольким компаниям с условием, что пользователи и администраторы OU каждой отдельно взятой компании не должны видеть содержимое OU остальных компаний.

Внутри организации разрешение List Object часто используется для сокрытия посторонних от глаз объектов, требующих особых мер по обеспечению секретности — таких, как учетные записи администраторов. Это усложняет задачу злоумышленников, пытающихся предпринять против этих учетных записей атаки типа «отказ в обслуживании».

Как я уже отмечал, разрешение List Object не является активно действующим или видимым в редакторе безопасности AD до тех пор, пока режим List Object не активируется по всему лесу. И только после активации режима новое разрешение появляется в окне редактора безопасности AD, как показано на экране 2.

Экран 2. Редактор безопасности Active Directory до?и?после активации режима List Object в Active Directory

Включение режима List Object

Чтобы активировать режим List Object службы AD, необходимо модифицировать одно из свойств объекта Directory Services в контейнере конфигурации AD, а это можно сделать, только обладая полномочиями уровня Enterprise Admin. Данное изменение автоматически реплицируется во всех остальных контроллерах доменов соответствующего леса. Возможность активации режима List Object в отдельно взятом домене или группе доменов не предусмотрена.

Активация режима List Object осуществляется посредством модификации третьего знака (байта) свойства DSHeuristics (строковый синтаксис Unicode) объекта Directory Service, значение которого должно быть установлено равным 1. Если свойству DSHeuristics не были присвоены другие значения, задайте значение 001. Если же первые два знака, или байта, уже имеют другие, отличные от нуля значения, оставьте их без изменений. Объект Directory Services размещается в контейнере AD имя контейнера=Directory Service, имя контейнера=Windows NT, имя контейнера=Services, имя контейнера=Configuration, контекст устройства=ForestRootDomain.

Другие настройки DSHeuristics объекта Directory Service используются для управления разрешением имен при выполнении, к примеру, процедур поиска в содержимом AD. В случае активации режима List Object соответствующим разрешением следует управлять в сочетании с разрешением List Contents. В таблице приведено краткое изложение правил для использования режима List Object совместно с разрешением List Contents.

Экран 3. Настройка разрешений на доступ к ?организационным единицам для ?нескольких клиентов

Цель приведенного ниже примера с разрешениями состоит в том, чтобы показать, как следует, применяя надлежащим образом разрешения List Contents и List Object, формировать разрешения на работу с OU для компании, выступающей в роли стороннего исполнителя для нескольких клиентов (экран 3). При таком раскладе очень важно, чтобы просматривать содержимое соответствующих организационных единиц (скажем, CompanyA, CompanyB или CompanyC), включая содержимое родительской OU UserAccounts, могли только уполномоченные члены групп UserAdmins_CompanyX. Процедура создания такого сценария включает следующие этапы.

1. Из организационной единицы UserAccounts удаляем применяемое по умолчанию разрешение List Contents для членов группы Authenticated Users. Это действие инициирует оценку разрешений на обращение к дочерним объектам. О том, как выполняется данный этап, рассказано в статье «Скрываем объекты и атрибуты Active Directory. Часть 2», опубликованной в Windows IT Pro/RE № 10 за 2012 год.

2. С целью отключения видимости организационных единиц интересующей нас компании отзываем применявшееся по умолчанию разрешение List Object для членов групп Authenticated Users из всех организационных единиц этой компании. Кроме того, отменяем разрешение List Contents для данной OU с целью сокрытия объектов внутри данной организационной единицы. В результате такие объекты не будут возвращаться при выполнении поиска внутри поддерева.

3. Членам каждой группы UserAdmins в организационной единице соответствующей компании предоставляем разрешения List Object и List Contents.

Пример использования утилиты DSACLS

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

set DN=«OU=UserAccounts, DC=root, DC=net»&& set SP=
«Authenticated Users»&& DSACLS %DN% /R %SP%&&
DSACLS %DN% /G %SP%: RCRPLO

Цель второго этапа — отменить разрешения List Object и List Contents, применяемые по умолчанию членами групп Authenticated Users всех организационных единиц компании. Как и в случае с использованием инструмента Dsacls с единственной целью удалить разрешение List Contents, данный этап включает удаление всех разрешений для членов групп Authenticated Users, а затем перенастройку разрешений, которые администратор хочет сохранить (в данном случае речь идет о разрешениях Read и Read All Properties). В нашем примере используется всего лишь одна организационная единица, поэтому воспользуемся следующей командой:

set DN=«OU=CompanyA, OU=UserAccounts, DC=root,
DC=net»&& set SP=«Authenticated Users»&&
DSACLS %DN% /R %SP%&& DSACLS %DN% /G %SP%: RCRP

Если имеется несколько организационных единиц, проще создать список отличительных имен (distinguished names, DN) и сохранить его в отдельном файле. Задача решается с помощью команды Dsquery:

DSQUERY ou  -scope onelevel > queryresult.txt

В нашем случае команда будет выглядеть следующим образом:

DSQUERY ou «OU=UserAccounts, DC=root, DC=net» -scope onelevel > queryresult.txt

После проверки правильности результатов запроса мы можем с помощью цикла FOR выполнить ранее описанную команду Dsacls применительно ко всем объектам файла:

for /f «delims=» %I in (queryresult.txt) do set SP=
«Authenticated Users»&& DSACLS «%~I» /R %SP%&&
DSACLS «%~I» /G %SP%: RCRP

Отметим, что при использовании команды For в пакетном файле вместо %I следует указывать %%I.

На третьем этапе соответствующей группе UserAdmins в каждой компании необходимо разрешить просмотр надлежащей организационной единицы со всем ее содержимым; для этого группе предоставляется разрешение List Object:

DSACLS  /G : LOLC

В нашем примере команда будет выглядеть следующим образом:

DSACLS «OU=CompanyA, OU=UserAccounts, DC=root, DC=net» /G «UserAdmins-CompanyA»: LOLC

Отметим, что, предоставляя для данной OU разрешение List Contents наряду с разрешением List Object, мы обеспечиваем возвращение всех объектов организационной единицы для уполномоченных пользователей. Если же мы хотим указать, какие объекты внутри организационной единицы должны быть возвращены в ходе выполнения запроса, предоставлять разрешение List Contents не следует. В этом случае с целью включения объекта в список необходимо для каждого дочернего объекта предоставить разрешение List Object. Воспользовавшись циклом For, мы можем также автоматизировать предшествующий этап с помощью синтаксической конструкции

for /f «delims=» %I in (companylist.txt) do DSACLS «OU=%~I, OU= UserAccounts, DC=root, DC=net» /G «UserAdmins_%~I»: LOLC

где companylist.txt означает файл с простым списком имен компаний.

Выполнение кода в приведенном выше примере обеспечивает сокрытие учетных записей пользователей всех размещенных в каталоге AD внешнего подрядчика компаний от пользователей, не получивших санкции на их просмотр. Члены соответствующей группы UserAdmins_CompanyX теперь могут просматривать учетные записи только сотрудников своей компании. Разрешения для членов группы UserAdmins отдельно взятой компании могут быть расширены. Они могут включать право на выполнение уполномоченными администраторами таких функций, как, например, переустановка паролей.

Чтобы скрыть от пользователей, не относящихся к категории Domain Admins, все остальные размещенные в домене AD объекты — такие, как контейнеры Builtin, Computers, System и Users, — следует снять разрешение List Contents для членов группы Authenticated Users с самого объекта «домен» (например, root.net). Затем нужно удалить разрешение List Object для членов группы Authenticated Users для каждого контейнера, который должен быть скрыт. При этом члены групп Domain Admins (равно как и групп Enterprise Admins) сохранят полный доступ ко всем объектам, поскольку обладают предоставленными для соответствующих групп другими унаследованными либо явно указанными разрешениями на работу с интересующими их организационными единицами. Результаты представлены на экранах 4 и 5.

Экран 4. Просмотр скрытых объектов OU пользователем с?правами Domain Admin

Экран 5. Просмотр скрытых объектов OU пользователем с?правами UserAdmin организации CompanyC

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

В среде Exchange Server, развернутой на оборудовании стороннего подрядчика, такой подход дает неплохие результаты, поскольку серверам Exchange предоставляются собственные особые разрешения на работу с объектами. Тем не менее, в целях обеспечения корректного отображения списков адресов для пользователей необходимо внести дополнительные корректировки. Обычно в таких случаях администраторы отключают глобальный список адресов Global Address List (GAL) и создают особые списки для каждой компании; при этом используется фильтр LDAP, указывающий только на организационную единицу соответствующей компании.

Режим List Object в AD, впервые реализованный в Windows 2000, можно уподобить предназначенному для работы с файловой системой средству Access-Based Enumeration (ABE), которым впервые было оснащен продукт Windows Server 2003 Service Pack 1 (SP1). По умолчанию стандартные для файловой системы NTFS разрешения на работу с папками позволяют пользователю, имеющему разрешения Read или List для данной папки, просматривать все файлы и подпапки вне зависимости от того, имеет ли данный пользователь право открывать эти файлы с целью прочтения. В случае активации функции ABE для совместно используемого ресурса файловый сервер оценивает разрешения пользователя для каждого файла и каждой подпапки и только после этого возвращает пользователю список объектов. Специальное разрешение List Object для файлов и папок в системе NTFS не предусмотрено, поэтому при активированной функции ABE пользователь может просмотреть файл или папку совместно используемого ресурса лишь при наличии у него разрешения Read либо более широких полномочий.

Как бы то ни было, в процессе работы с режимом List Object всегда следует помнить о следующих обстоятельствах.

-Режим List Object может быть активирован только для всего леса AD; активация режима для отдельных доменов не допускается.

-Чтобы с максимальной эффективностью использовать разрешение List Object применительно к дочерним объектам, нужно удалить из соответствующего родительского контейнера разрешение List Contents для членов группы Authenticated Users. Если пользователю предоставляется разрешение на объект «контейнер», это значит, что содержащиеся в последнем объекты видны данному пользователю вне зависимости от базовых разрешений List Object этих дочерних объектов.

-Активация режима List Object не влечет за собой подключение дополнительных средств, предназначенных для сокрытия атрибутов в AD. Назначение этого режима состоит лишь в том, чтобы обеспечить формирование более тонко настраиваемых разрешений на перечисление объектов внутри контейнера с тем, чтобы эти объекты были доступны для просмотра только уполномоченными пользователями.

Понимать решаемые задачи

Если вы читали статью «Скрываем объекты и атрибуты Active Directory. Часть 2», то уже знаете, что сокрытие данных в AD может быть чрезвычайно сложной задачей. Успешно осуществлять модификацию разрешений, особенно не прибегая к помощи режима List Object, может только администратор, который разбирается в разрешениях, применяемых по умолчанию к объектам AD.

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