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

Все о списках управления доступом

Список управления доступом (ACL) сопоставляется со всеми объектами каталога и управляет средствами защиты каждого из них. Список управления доступом, известный также как дескриптор безопасности, хранится в формате двоичных данных в атрибуте nTSecurityDescriptor соответствующего объекта. Начиная с версии Windows Server 2003, для хранения в базе данных AD списков управления доступом в структуре AD предусмотрен внутренний механизм, обеспечивающий хранение одного экземпляра каждого списка. Этого вполне достаточно, поскольку почти все объекты каталога совместно используют общий набор списков ACL. Фактический объем данных ACL довольно велик, и при сведении числа копий к одной обеспечивается существенная экономия дискового пространства.

Списки ACL состоят из двух компонентов: разграничительный список ACL (Discretionary ACL, DACL) и системный список ACL (System ACL, SACL). Компонент SACL используется в случаях, когда для соответствующего объекта проводится аудит безопасности (скажем, когда объект модифицируется). Оба компонента включают в себя ряд записей управления доступом access control entries (ACE), которые представляют фактические разрешения доступа в данном ACL. В дальнейшем при упоминании термина ACL мы будем иметь в виду компонент DACL.

Чтобы просмотреть компонент ACL с использованием оснастки ADUC, нужно прежде всего активировать в консоли режим просмотра Advanced Features; для этого следует выбрать пункт View, а затем Advanced Features. Теперь правой кнопкой мыши щелкните на одном из объектов, откройте вкладку Properties и перейдите на вкладку Security, показанную на экране 1. Вы увидите, что пользовательский интерфейс оснастки и интерфейс, используемый при управлении системными разрешениями, в общих чертах одинаковые, просто в первом случае назначаются одни разрешения доступа, а во втором — другие. Более подробно структура ACL описана во врезке «Внутри абстракций ACL».

Подобно разрешениям в файловой системе, разрешения в каталоге AD наследуются объектами-потомками, если пользователь не дает каталогу инструкцию отменить такое наследование. Благодаря этому обстоятельству процедура предоставления администратору разрешений на выполнение той или иной операции (скажем, изменения пароля) во всех объектах заданной организационной единицы organizational unit (OU) или в иерархии OU выполняется очень легко. Если бы такой функции не было, нам приходилось бы предоставлять разрешения каждому пользователю в индивидуальном порядке.

Для применения унаследованных разрешений к дочерним объектам в AD используется внутренний фоновый процесс, именуемый распространителем дескрипторов безопасности Security Descriptor Propagator (SDProp). В очень больших сетях унаследованные разрешения обычно применяются с некоторой задержкой. Кстати, если в AD вам попадался атрибут dSCorePropagationData и вы задавались вопросом, для чего он нужен, имейте в виду, что данный атрибут используется с целью хранения информации о состоянии процесса SDProp.

Что делегировать

На высоком уровне имеется ограниченный набор операций, разрешения на выполнение которых могут быть делегированы, причем их можно применять как для всех классов объектов, так и для отдельного класса, например для класса users. Если вы незнакомы с основными принципами функционирования схемы AD, рекомендую прочитать статью «Расширяем схему Active Directory» (опубликованную в Windows IT Pro/RE № 1 за 2011 год), поскольку ниже мы будем использовать некоторые термины из этой статьи. Метод делегирования разрешений доступа можно применять для предоставления разрешений пользователям или группам. С функциональной точки зрения нет ничего дурного в том, чтобы делегировать разрешения непосредственно пользователям, однако в любом случае будет правильнее делегировать разрешения группе, а затем уже включать в эту группу тех или иных пользователей. В этом случае вы сможете управлять разрешениями пользователей, вводя или выводя их из состава соответствующих групп. Решать подобную задачу гораздо проще, чем управлять разрешениями.

Самое типичное полномочие из тех, что вам предстоит предоставлять, это, пожалуй, разрешение на запись в том или ином атрибуте либо в наборе атрибутов. Если, к примеру, вы намереваетесь предоставить кому-то разрешение отменять блокировку учетных записей пользователей, вы предоставите этому лицу разрешение записи (Write Property) в атрибуте lockoutTime.

Некоторые операции, сводящиеся на первый взгляд к предоставлению разрешения Write Property на один-два атрибута, фактически предполагают делегирование одного или нескольких расширенных разрешений. Два расширенных разрешения, с которыми вам придется сталкиваться чаще всего, — это разрешения Reset Password и Change Password. В случае поступления через стандартные интерфейсы прикладного программирования запроса на выполнение той или иной операции, AD и другие приложения могут выяснять, имеются ли разрешения на пользование расширенными разрешениями, причем приложения могут даже определять в каталоге специализированные расширенные разрешения. Если в вашей сети развернута система Microsoft Exchange Server, вы обнаружите, что в ней предусмотрен целый ряд расширенных разрешений, таких как Send-As и Receive-As.

Если присмотреться к компоненту ACL в учетной записи пользователя (подобному на экране 1), можно увидеть, что участнику безопасности SELF делегировано расширенное разрешение Change Password. Кроме того, вы заметите, что этому участнику делегировано разрешение вводить ряд дополнительных записей, таких как Personal Information. Personal Information — пример объекта Property Set, коллекции атрибутов, сведенных вместе. Этот объект позволяет предоставлять разрешения не на уровне индивидуальных атрибутов, а на уровне всего их набора. AD допускает включение каждого атрибута в один набор Property Set. Достоинство этого набора состоит в том, что администратору нет нужды создавать индивидуальные записи управления доступом с целью предоставления разрешений на чтение или запись в большое количество атрибутов; он может выполнить одну-единственную процедуру делегирования для всего набора Property Set, и необходимые разрешения будут предоставлены всем входящим в этот набор атрибутам.

Экран 1. Редактор ACL оснастки Active Directory Users and Computers

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

Если вас интересует, какие атрибуты включаются в набор Property Set, вы можете получить ответ на этот вопрос с помощью инструмента, поставляемого со службой Active Directory Lightweight Directory Service (AD LDS). На системе, где установлены средства удаленного администрирования сервера Remote Server Administration Tools (RSAT) системы Windows Server 2008 или более новой версии и активированы средства доменных служб Active Directory (AD DS), а также служб Active Directory облегченного доступа к каталогам (AD LDS), перейдите в каталог C:\Windows\ADAM и запустите программу ADSchemaAnalyzer.exe. После этого откройте меню File, выберите пункт Load Target Schema, укажите один из контроллеров домена (DC) в своем лесу и введите действительные учетные данные пользователя. Анализатор схемы Active Directory загрузит схему AD и отобразит ее в графическом представлении, так что вы сможете уяснить отношения между классами, атрибутами и наборами свойств (экран 2). Атрибуты каждого набора свойств перечислены в контейнере Dependents.

Экран 2. Атрибуты набора свойств, отображаемые анализатором схемы Active Directory

Еще одна типичная задача, разрешения на выполнение которой вы, вероятно, захотите делегировать, — задача формирования определенного набора объектов, скажем, чтобы сотрудники службы поддержки могли создавать объекты user. Делегировать такие разрешения в высшей степени просто; однако важно при этом тщательно проанализировать некоторые скрытые последствия для системы безопасности в связи с предоставлением пользователям разрешения создавать объекты. В момент создания объекта создавшему его пользователю в одном из полей ACL присваивается статус владельца данного объекта. Владелец объекта имеет над ним полный контроль и может обойти ограничения, содержащиеся в детализированных разрешениях, полученных этим владельцем на доступ к объекту. Вот наглядный пример того, как делегирование разрешения на создание объектов создает для администратора неожиданные проблемы. Допустим, вы делегировали пользователю разрешение на создание организационных единиц (OU) и сверх того — разрешение на создание учетных записей пользователей внутри этих OU. Поскольку упомянутый пользователь имеет полный контроль над созданными им OU, он может создавать внутри них объекты любых типов, скажем компьютеры или группы. После того как ваш домен будет переведен в режим работы Windows Server 2008 Domain Functional Level (DFL) 3 или более современный, вы сможете решить эту проблему с помощью средств Owner Access Rights.

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

Разрешения Password Reset и Account Unlock

Одна из задач, разрешения на выполнение которых часто делегируются (как правило, сотрудникам службы поддержки либо службы поддержки), — это переустановка паролей пользователей в случаях, когда последние их забывают, и снятие блокировки учетных записей этих пользователей. Здесь нужно осуществить несколько процедур делегирования: делегировать разрешение на использование расширенного разрешения Reset Password, а также разрешение Write Property для атрибутов pwdLastSet и lockoutTime.

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

Далее на протяжении всей статьи мы будем выполнять операции делегирования, о которых пойдет речь, с использованием редактора ACL в оснастке ADUC. Часть задач, выполняемых средствами этого редактора, можно решать и с помощью мастера Delegate Control Wizard оснастки ADUC. Но если действовать без дополнительных ухищрений только с помощью редактора ACL, мы получим гораздо более полное представление о вносимых изменениях. Если вы следуете предлагаемым мной инструкциям, используя версию ADUC, которая была выпущена до появления системы Windows Server 2008 R2, отдельные надписи на экранах и ряд этапов процесса будут несколько отличаться от описываемых мной. При работе со старыми версиями AD вы можете смело использовать более новые версии ADUC и других средств удаленного администрирования сервера.

В рамках данной статьи мы будем исходить из того, что вам предстоит делегировать членам группы Service Desk Users разрешения на переустановку паролей всех пользователей, входящих в организационную единицу People OU. Для решения этой задачи выполните следующие действия.

  1. В окне оснастки ADUC откройте вкладку Properties организационной единицы People, перейдите на вкладку Security и щелкните на элементе Advanced.
  2. Нажмите кнопки Add и Find Service Desk Users.
  3. На вкладке Object выберите параметр Apply onto Descendant User objects.
  4. На вкладке Allow for the Reset Password permission выставьте флажок Allow for the Reset Password permission.
  5. На вкладке Properties выберите настройку Apply onto Descendant User objects.
  6. На вкладке Properties выберите настройку Allow for Write lockoutTime and for Write pwdLastSet.
  7. Нажмите кнопку ОК.
  8. Зарегистрируйтесь в системе с учетной записью члена группы Service Desk Users и убедитесь, что у вас имеются разрешения на переустановку пароля пользователя, входящего в организационную единицу People.

Вы увидите три дополнительные записи управления доступом, представленные на экране 3. Редактор ACL оснастки ADUC позволяет с легкостью предоставлять несколько разрешений одновременно — даже в ситуациях, когда для делегирования таких разрешений необходимо использовать несколько записей управления доступом. Если бы вы выполняли описанные выше действия с помощью программы редактирования с минимумом необходимых функций, такой как LDP, вам пришлось бы создавать три индивидуальные записи управления доступом: одну для осуществления операции Reset Password, другую для операции Write Property pwdLastSet и третью — для операции Write Property lockoutTime.

Экран 3. Заполнение списка ACL после предоставления разрешений Password Reset и Unlock Account

Добавление компьютеров в домен

Еще одна типичная задача — делегирование группе пользователей разрешений по включению компьютеров в домен. Служба AD позволяет любому прошедшему процедуру аутентификации пользователю в любое время без предварительной подготовки добавлять в домен до десяти систем. Разработчики AD реализовали это ограничение с помощью функции, известной как «квоты на объекты». Она дает администратору возможность определять число объектов определенного типа, которые пользователь может иметь в каталоге в любой момент времени. AD определяет, сколько объектов входит в квоту того или иного пользователя, на основании сведений о принадлежности, которые хранятся в списке ACL наряду с компонентами DACL и SACL.

Вы можете предоставить другому лицу (возможно, младшему администратору) разрешение добавлять в домен неограниченное число компьютеров. Задача решается двумя способами. Первый способ — воспользоваться унаследованным от прежних систем разрешением NT Security Privilege (SeMachineAccount­Privilege); обладающий им пользователь может добавлять компьютеры в домен. Это разрешение предоставляется на контроллерах доменов через групповую политику и включается в маркер безопасности пользователя, когда тот регистрируется в системе. Если вы просто хотите дать пользователям возможность добавлять системы в контейнер Computers, эта задача, по-видимому, легче всего решается посредством предоставления рассматриваемого разрешения с помощью групповой политики. Чтобы предоставить это разрешение пользователям группы Service Desk Users через групповую политику, выполните следующие действия.

  1. Запустите консоль Group Policy Management Console. Для этого нужно открыть меню Start, выбрать пункт Run и ввести имя gpmc.msc.
  2. Правой кнопкой мыши щелкните на элементе Default Domain Controller Policy и в открывшемся меню выберите пункт Edit.
  3. Перейдите в папку Policies\Windows Settings\Security Settings\Local Policies\User Rights Assign­ment.
  4. Откройте запись Add Workstations to Domain.
  5. Добавьте пользователей службы техподдержки (Service Desk Users), как показано на экране 4.
  6. Если вы хотите лишить того или иного пользователя возможности добавлять рабочие станции в домен, удалите Authenticated Users.
Экран 4. Делегирование разрешений Add Workstations to Domain

Если вместо этого вы хотите определить, к каким организационным единицам может быть присоединен тот или иной компьютер, вам придется воспользоваться собственными списками ACL каталога Active Directory, подобными тем, что упоминались в предыдущей пошаговой инструкции. В данном примере мы делегируем группе Service Desk Users разрешения по присоединению компьютеров к организационной единице Desktops, а кроме того, предоставляем членам этой группы возможность менять пароли учетных записей машин на тот случай, если у них возникнет необходимость вновь ввести ту или иную систему в состав домена. С целью выполнения этих задач мы делегируем группе Service Desk Users разрешение создавать объекты computer в организационной единице Desktops, а затем предоставим членам этой группы разрешение Reset Password, а также разрешение Write to pwdLastSet применительно к объектам computer.

Атрибуты и разрешения, доступные в редакторе ADUC ACL Editor, загружаются не из каталога, а из файла dssec.dat на локальной системе. Один из атрибутов, который вам придется модифицировать в процессе выполнения указанной задачи, по умолчанию не указывается в файле dssec.dat. Чтобы редактировать файл dssec.dat, выполните следующие действия на компьютере, где выполняется оснастка ADUC.

  1. Откройте окно командной строки с повышенными привилегиями и перейдите в каталог %windir%\system32.
  2. В окне командной строки с повышенными привилегиями откройте файл dssec.dat в редакторе notepad.
  3. Найдите в этом файле раздел computer.
  4. В разделе computer найдите строку pwdLastSet=7 и придайте ей вид pwdLastSet=0.
  5. Перезагрузите оснастку ADUC.

Для предоставления указанных разрешений выполните следующие действия.

  1. В окне ADUC откройте свойства организационной единицы Desktops, перейдите на вкладку Security и выберите элемент Advanced.
  2. Нажмите кнопку Add и щелкните на пункте Find Service Desk Users.
  3. На вкладке Object выберите параметр Apply to This object only. Отметим, что, если в вашей сети в организационной единице Desktops имеются другие организационные единицы, стоит настроить программу таким образом, чтобы присоединяемые к домену компьютеры вместо этого указывали на объекты «организационная единица».
  4. Переключатель Allow установите в положение Create Computer objects.
  5. Нажмите ОК.
  6. Нажмите кнопку Add и еще раз щелкните на пункте Find Service Desk Users.
  7. Выберите элемент Apply to Descendant Computer objects.
  8. Для разрешения Reset Password укажите параметр Allow.
  9. На вкладке Properties выберите настройку Apply to Computer objects.
  10. Щелкните на пункте Allow for Write pwdLastSet.
  11. Нажмите кнопку ОК.

Теперь нужно выяснить, каков результат процедуры делегирования разрешений. Попытайтесь присоединить тестовый компьютер к домену с использованием учетной записи пользователя, входящего в группу Service Desk Users. Задачу включения компьютера в состав домена с указанием, в какую организационную единицу он будет при этом входить, можно решить двумя способами. Первый метод состоит в том, чтобы заранее создать учетную запись компьютера с помощью оснастки ADUC. Запустите оснастку и щелкните правой кнопкой мыши внутри организационной единицы Desktops, затем нажмите кнопку New и выберите элемент Computer. Укажите имя компьютера и предоставьте членам группы Service Desk Users разрешения на присоединение системы к домену, как показано на экране 5.

Экран 5. Диалоговое окно New Computer

Второй метод предусматривает добавление системы к домену с помощью средства командной строки netdom; имя надлежащей организационной единицы указывается при этом в качестве составной части команды. Чтобы включить систему TEST-PC02 в состав организационной единицы Desktops, расположенной в корневом каталоге домена contoso.com, введите следующую команду:

netdom add test-pc02/domain: contoso
   . com/userd:"contoso\john.doe"
   /passwordd:*/OU:"ou=desktops, dc
   =contoso, dc=com"

Вы получите приглашение ввести пароль для учетной записи John.Doe. Если вы хотите использовать смарт-карту, добавьте переключатель /Secure-PasswordPrompt.

Сначала упражнения

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

Внутри абстракций ACL

Удалять абстракции из списка ACL можно с помощью редактора безопасности в программе LDP. Данный интерфейс не отличается особым удобством и весьма непрост в использовании, но он дает возможность получать более основательные результаты. Если вы хотите испытать его на практике, выполните следующие действия.

  1. Запустите программу LDP; для этого нужно в меню Start выбрать пункт Run и ввести с клавиатуры имя ldp.exe.
  2. Откройте меню Connection, выберите пункт Bind, а затем укажите учетные данные пользователя (если это необходимо).
  3. В меню View выберите пункт Tree, после чего отыщите нужный домен.
  4. На дереве, расположенном в левой части экрана, правой кнопкой мыши щелкните на объекте, чей список доступа хотите просмотреть; в раскрывшемся меню выберите пункт Advanced, а затем Security Descriptor. Нажмите кнопку ОК в диалоговом окне, которое появится на экране. Если вы установите флажок SACL, то сможете к тому же увидеть, какие настройки аудита предусмотрены для этого объекта.

Более подробные сведения будут отображаться на экране дескриптора безопасности, если дважды щелкнуть на соответствующей записи (экран А). Отметим, что в версиях LDP, выпускавшихся до выхода системы Windows Server 2008, текст выводится из списков ACL в формате «только для чтения».

 

Экран A. Редактор дескрипторов безопасности LDP

Брайан Десмонд (brian@briandesmond.com) — старший консультант компании Moran Technology Consulting (Чикаго). Имеет сертификат Directory Services MVP, ведет блог www.briandesmond.com