Страницы: 1 .. 8 9 10 11 12 .. 16

Глава 9. Делегирование администрирования службы Active Directory
Как говорилось в предыдущих главах, служба Active Directory операционной системы Microsoft Windows Server 2003 больше не поддерживает единое неструктурированное пространство имен, которое использовалось в доменах Microsoft Windows NT. Вместо этого она обеспечивает иерархическое представление каталога, сначала через иерархию доменной системы имен (DNS) множества доменов, а затем через структуру организационных подразделений (OU) в пределах доменов. Эта иерархия создает важную административную возможность: делегирование административных разрешений. В доменах Windows NT такой возможности не было. Разрешения, полученные в одной части домена, действовали повсюду в домене. Теперь это полностью изменилось. Служба Active Directory Windows Server 2003 имеет мощные опции для управления разрешениями и делегирования административных задач в пределах домена.
Данная глава построена на обсуждении безопасности Active Directory, начатой в главе 8. Глава начинается с повторного рассмотрения защиты Active Directory с целью уточнения списков управления доступом (ACL) на объектах Active Directory. После этого в главе обсуждается делегирование прав. Для делегирования разрешений вы можете напрямую обращаться к спискам ACL индивидуальных объектов. Для назначения разрешений служба Active Directory Windows Server 2003 имеет.также Delegation Of Control Wizard (Мастер делегирования управления).
Разрешения объектов службы Active Directory
Как описано в главе 8, когда пользователь входит в сеть Windows Server 2003, ему предоставляется лексема доступа. Лексема доступа включает идентификаторы защиты (SID) для учетной записи пользователя, а также SID для всех групп, к которым принадлежит пользователь. Как только пользователь вошел, он пытается обратиться к сетевому ресурсу, ко-
торый включает объект Active Directory. Каждый сетевой ресурс или объект Active Directory имеет список ACL, хранящийся в его атрибуте NTSecurityDescriptor, который состоит из одной или более записей управления доступом (АСЕ), определяющей, какие права на данный объект имеет каждый идентификатор SID. Дескриптор защиты содержит владельца объекта, а также список управления разграничительным доступом (DACL) и список управления системным доступом (SACL). Список DACL определяет разрешения на объект, которые имеют все участники безопасности. Список SACL определяет параметры настройки аудита объекта.
Примечание. Каждый объект в Active Directory имеет список ACL, т.е. разрешения на этом объекте можно изменять. Это справедливо для объектов, отражаемых как через инструменты Active Directory Users And Computers (Пользователи и компьютеры Active Directory), Active Directory Sites And Services (Сайты и службы Active Directory), ADSI Edit или Ldp.exe. Основное внимание в этой главе будет уделено объектам, отображаемым через Active Directory Users And Computers, потому что почти все администрирование защиты выполняется с помощью этого инструмента. Однако многие из концепций и процедур, обсуждаемых здесь, могут применяться и к другим инструментальным средствам администрирования Active Directory. Например, вы можете использовать тот факт, что каждый объект имеет список ACL, чтобы изменить разрешения для объектов сайтов в инструменте Active Directory Sites And Services. Можно использовать также Delegation Of Control Wizard, который будет обсуждаться позже в этой главе.
Есть множество различных инструментов, которые могут использоваться для просмотра дескриптора защиты любого объектов Active Directory. Обычно используется инструмент Active Directory Users And Computers. Он может давать несколько различных представлений списков ACL. Это связано с тем, что разрешения на доступ к объектам Active Directory разбиты на две категории: стандартные (standard) и специальные (special). Просмотр информации о защите через Active Directory Users And Computers осложняется, если вы можете предоставлять разрешения объектам внутри контейнерного объекта или атрибутам объекта.
Стандартные разрешения
Чтобы просмотреть стандартные разрешения для любого объекта Active Directory в разделе домена каталога, обратитесь к вкладке Security (Безопасность) в окне Properties (Свойства) нужного объекта в инструменте Active Directory Users And Computers. (Если вкладка Security не видна, выберите Advanced Features (Дополнительные функции) в меню View (Вид), повторно выберите объект и откройте окно Properties). Вкладка Security(Безопасность) показывает стандартные разрешения, которые доступны для каждого объекта (см. рис. 9-1).

Рис. 9-1. Просмотр стандартных разрешений на объекте «пользователь»
Каждый класс объектов в Active Directory имеет свой набор стандартных разрешений. Например, организационная единица (OU) - это контейнерный объект, который может содержать дочерние объекты, поэтому он имеет набор разрешений, применяемых к дочерним объектам, которые не подходят для объектов «пользователь». Однако, некоторые стандартные разрешения, например, Full Control (Полный контроль), Read (Чтение), Write (Запись), Create All Child Objects (Создание всех дочерних объектов) и Delete All Child Objects (Удаление всех дочерних объектов), применимы ко всем объектам.
Некоторые объекты Active Directory имеют стандартные разрешения, которые применяются к сгруппированным наборам свойств. Например, каждый объект «пользователь» имеет несколько наборов свойств типа Public Information (Открытая информация), Personal Information (Личная информация) или Web Information (Веб-информация). Каждый из этих наборов свойств относится к набору атрибутов, так что предоставление доступа к нему обеспечивает доступ к набору атрибутов. Например, набор свойств Personal Information включает атрибуты
homePhone, homePostalAddress, streetAddressи так далее. Использование наборов свойств для назначения доступа к группам атрибутов упрощает процесс назначения разрешений.
Дополнительная информация. Чтобы найти полный список атрибутов, включенных в каждый набор свойства, сделайте поиск выражения "property sets" (включая открывающие и закрывающие кавычки) в Help And Support Center (Центр справки и поддержки). Схема Active Directory определяет то, какие атрибуты являются частью каждого свойства, установленного с помощью значения rightsGuidдля категории свойства (в разделе конфигурации каталога) и значения attributesSecurityGUIDдля объекта схемы. Например, значение rightsGuid для cn=Personal-Information, cn=Extended-Rights, cn=conf iguration, dc=forestname равно значению attributes ecurityGUID для cn=Telephone-Number, cn=Schema, cn=Configuration, dc=forestname. Это означает, что номер телефона включен в набор свойств Personal Information.
В дополнение к стандартным разрешениям вкладка Security показывает некоторые дополнительные права, такие как Receive As, Send As, Send To (все права, связанные с Microsoft Exchange 2000 Server), Change Password и Reset Password. Список разрешений может также включать разрешение Validated Write (Запись с проверкой ее достоверности). Например, объектам Group требуется разрешение Validated Write на то, чтобы добавить/удалить себя как члена. Различие между разрешением Validated Write и обычным Write состоит в том, что Validated Write гарантирует, что записанное значение допустимо. В этом случае пользователь, имеющий разрешение добавлять/удалять себя как члена группы, сможет добавлять к группе только себя самого.
Специальные разрешения
Одна из записей в стандартном списке разрешений на вкладке Security (Безопасность) - Special Permissions (Специальные разрешения). Вы можете предоставлять объектам Active Directory не только стандартные разрешения, но и специальные. Они более детализированы и специфичны, чем стандартные разрешения. Чтобы получить доступ к ним, щелкните на Advanced (Дополнительно) на вкладке Security (рис. 9-2). В таблице 9-1 объясняется назначение столбцов в окне.
Примечание. Кнопка Default (По умолчанию) на вкладке Advanced сбрасывает разрешения, установленные на объекте к разрешениям, заданным по умолчанию.

Рис. 9-2. Просмотр дополнительных параметров настройки защиты Advanced Security Settings для пользовательского объекта
Табл. 9-1. Столбцы конфигурации специальных разрешений

Это окно перечисляет все АСЕ-записи для объекта. Во многих случаях одни и те же участники безопасности могут быть перечислены в нескольких записях АСЕ. Например, группе Authenticated Users (Удостоверенные пользователи) дано разрешение Read Permissions (Читать разрешения), Read General Information (Читать информацию общего характера), Read Personal Information (Читать личную информацию), Read Web Information (Читать веб-информацию) и Read Public Information (Читать открытую информацию) в отдельных записях АСЕ.
Вы можете добавлять и удалять участников безопасности или редактировать текущие разрешения, предоставленные участнику безопасности, используя окно Advanced Security Settings (Дополнительные параметры настройки защиты). Если вы добавляете или редактируете разрешения, предоставленные участнику безопасности, вам дается два способа для назначения разрешений. На рисунке 9-3 показан первый способ назначения разрешений на объект.

Рис. 9-3. Назначение специальных разрешений на доступ к объектам Active Directory
Вкладка Object (Объект) используется для назначения разрешений, которые применяются только к объекту, ко всем дочерним объектам или к определенным дочерним объектам. Например, на уровне OU можно предоставлять разрешения, которые применяются к объекту (OU), к объекту и всем его дочерним объектам, ко всем дочерним объектам или к определенным дочерним объектам (таким как учетные записи пользователя, группы и компьютера). Список разрешений изменяется в зависимости от типа объекта, с которым вы работаете.
Второй способ назначения разрешений предназначен для управления параметрами настройки свойств объекта (см. рис. 9-4).

Рис. 9-4. Конфигурирование разрешений, применяемых к свойствам объектов
Вкладка Properties (Свойства) используется для назначения разрешений на индивидуальные свойства объекта, выбранного в поле Name (Имя) окна Advanced Security Settings (Дополнительные параметры настройки защиты). Например, если вы применяете разрешения к пользовательским объектам, вам предоставляется опция назначения разрешений Read и Write для каждого атрибута, доступного для данного класса объектов.
Примечание. Когда вы увидите эти опции в первый раз, вы, вероятно, отреагируете двумя способами. Первая реакция будет реакцией удовлетворения от того, что, наконец-то, вы сможете назначать разрешения так, как вам всегда хотелось. Другая реакция - недовольство, потому что у вас никогда не было потребности назначать разрешения на таком уровне. Обе реакции отражают существо дела. Так происходит потому, что чаще всего вам не требуется назначать разрешения на таком уровне, но этот уровень является определенно полезным, когда вы сталкиваетесь с очень специфическими требованиями.
Просмотр записей АСЕ с помощью инструмента Ldp.exe
Графический интерфейс пользователя (GUI) является инструментом, который очень удобен для управления огромной совокупностью АСЕ-записей. Чтобы получить возможность по-настоящему оценить значение GUI, потратьте некоторое время на знакомство с инструментом Ldp.exe. Чтобы просмотреть список ACL с помощью Ldp.exe, откройте диалоговое окно Run (Выполнить) и напечатайте ldp. (Если Ldp.exe не был установлен на компьютере, откройте папку \SUPPORT\TOOLS на компакт-диске Windows Server 2003 и дважды щелкнете на файле Suptools.msi, чтобы установить средства поддержки Active Directory.) Выберите раскрывающееся меню Connection (Подключения), затем выберите Connect (Подключиться). Если вы оставите пустым поле сервера, то сервер соединится с локальным компьютером. Вы можете напечатать имя сервера. Как только вы свяжетесь с сервером, выберите раскрывающееся меню Connection (Подключения) и выберите Bind (Связаться). Если вы входите не с учетной записью пользователя, имеющей административные права, введите дополнительные мандаты. Другим способом, оставьте пробелы в полях, предназначенных для информации входа в систему. После подключения к домену щелкните на раскрывающемся меню View (Вид), а затем выберите Tree (Дерево). Чтобы просмотреть весь домен, щелкните на ОК. Структура OU домена будет представлена в левой области окна (см. рис. 9-5).
Чтобы просмотреть список ACL для любого объекТа, найдите объект в дереве в левой области окна. Затем щелкните правой кнопкой мыши на объекте и выберите Advanced (Дополнительно), затем - Security Descriptor (Дескриптор защиты). Список ACL хранится в значении NTSecurityDescriptorкаждого объекта Active Directory. Затем инструмент Ldp.exe запишет каждый АСЕ в правую область окна в зашифрованном формате:

(A;; CCDCLCSWRPWPDTLOCRSDRCWDWO;;; DA)

Каждая пара букв в первом списке АСЕ-записей соответствует определенному разрешению. Например, СС означает, что пользователь имеет право создать все дочерние объекты. Последние две буквы в АСЕ записи относятся к группе или пользователю, который имеет разрешения DA, т.е. относится к группе Domain Admins. Если разрешения назначены пользователю или группе, которая не имеет известного иден-
тификатора SID, то последняя часть каждой записи АСЕ содержит SID пользователя или группы. (Чтобы увидеть полный список всех возможных разрешений, которые могут быть назначены в записях АСЕ, просмотрите справочную информацию для команды DsAcls, сопровождающую инструменты Active Directory. Инструмент командной строки DsAcls может использоваться для назначения или удаления разрешений к любому объекту в Active Directory).

Рис. 9-5. Использование инструмента Ldp.exe для просмотра свойств домена
После строк такого типа информации инструмент Ldp.exe даст более понятное объяснение каждой записи АСЕ. Например, для строки, приведенной выше, это будет выглядеть так:

Асе[О]
Асе Туре: 0x0 - ACCESS_ALLOWED_ACE_TYPE
Асе Size: 36 bytes
Асе Flags: 0x0
Асе Mask: OxOOOfOiff
DELETE
READ CONTROL
WRITE DAC
WRITE_OWNER
ACTRL DS CREATE_CHILD
ACTRL DS DELETE CHILD
ACTRL DS LIST
ACTRL DS SELF
ACTRL DS READ_PROP ACTRL DS WRITE_PROP ACTRL_DS_DELETE_TREE ACTRL_DS_UST_OBJECT ACTRL_DS_CONTROL_ACCESS
Ace Sid: Contoso\Domain Admins S-1 -5-21 -602162358-688789844-1957994488-512

Наследование разрешений
Служба Active Directory Windows Server 2003 использует статическую модель наследования разрешений. Когда изменяется разрешение на контейнерном объекте в структуре Active Directory, то оно рассчитывается и применяется к дескриптору защиты всех объектов, находящихся в этом контейнере. Если изменяются разрешения на высшем уровне и применяются ко всем дочерним объектам, то вычисление нового списка ACL для каждого объекта может быть значительной нагрузкой на процессор. Однако это не означает, что разрешения не должны рассчитываться повторно, когда пользователь или процесс обращаются к объекту.
По умолчанию все разрешения в Active Directory наследуются. Большинство разрешений, установленных на контейнерном уровне, наследуется всеми объектами в пределах этого контейнера, включая другие контейнерные объекты. Например, если пользователь имеет разрешение создавать учетные записи пользователей в OU, он также может создавать учетные записи в любой дочерней OU в пределах этой OU. В большинстве случаев вы, вероятно, примете заданное по умолчанию наследование разрешений. Если вы разработали свою структуру OU с целью делегирования администрирования, то нужно создать OU-структу-ру, в которой на высшем иерархическом уровне предоставляются разрешения администраторам высшего уровня, нуждающимся в разрешениях ко всем объектам Active Directory. По мере продвижения вниз по иерархии вы можете назначать разрешения для других администраторов, которые должны иметь контроль над меньшей частью домена.
В некоторых случаях можно блокировать любые административные разрешения администраторов высокого уровня для определенной дочерней OU. Например, вы создали дочернюю OU для филиала вашей компании и дали локальной административной группе полное управление над этой OU. Возможно, вы не хотите, чтобы эти локальные администраторы имели доступ к учетным записям пользователей, представляющих исполнительную власть в этой OU. Вы можете создать OU Executives (Руководство) в пределах OU-филиала, а затем блокировать наследование разрешений на уровне Executives OU.
Чтобы блокировать наследование разрешений на объекте Active Directory, обратитесь к окну Advanced Security Settings для данного
объекта (см. рис. 9-2). Затем очистите опцию Allow Inheritable Permissions From The Parent To Propagate To This Object And All Child Objects (Разрешить наследованным разрешениям распространяться от родителя к этому объекту и всем дочерним объектам). После очистки этой опции вам будет представлена опция, позволяющая копировать существующие разрешения или удалять разрешения перед явным назначением новых разрешений (см. рис. 9-6).

Рис. 9-6. Выбор опции, позволяющей копировать или удалять разрешения при блокировании наследования разрешений
После блокировки наследования вы можете сконфигурировать разрешения на объектах. Блокировка наследования имеет несколько следствий.

• Разрешения блокируются для объекта и любых дочерних объектов. Вы не можете блокировать наследование разрешений на контейнерном уровне, а затем повторно применять наследование от более высокого контейнера на более низкий уровень.
• Если вы решите копировать разрешения перед модификацией, наследование разрешений начинается там, где вы блокируете разрешения. Если вы измените разрешения на более высоком уровне, разрешения не будут унаследованы в обход блокированных разрешений.
• У вас нет большого выбора того, какие разрешения будут блокированы. Когда вы блокируете разрешения, то все наследованные разрешения также блокируются. Разрешения, которые были назначены на объект или дочерние объекты явно, не блокируются.

Примечание. Одна из возможных проблем с блокированием унаследованных разрешений состоит в том, что можно создать «осиротевший» объект, к которому никто не имеет разрешений. Например, в организационной единице OU можно блокировать все наследование разрешений к ней и назначить разрешения только для административной группы. Вы можете даже удалить группу Domain Admins из списка ACL этой OU, чтобы группа Domain Admins не имела никаких разрешений при нормальных обстоя-
тельствах, и в OU не будет групп с административным управлением. В этом случае группа Domain Admins всегда может взять объект в собственность и повторно назначить разрешения.
Фактические разрешения
Как описано в этой главе к настоящему моменту, пользователь может получить разрешения к объекту в Active Directory несколькими способами.

• Учетной записи пользователя можно предоставить явные разрешения на доступ к объекту.
• Одной или более группам, к которым принадлежит пользователь, можно предоставить явные разрешения на доступ к объекту.
• Учетной записи пользователя или группам, к которым принадлежит пользователь, могут быть даны разрешения на уровне контейнерного объекта и разрешения, унаследованные объектами низшего уровня.

Все разрешения суммируются, т.е. пользователю предоставляется самый высокий уровень разрешений от любой из этих конфигураций. Например, если пользователю явно дано разрешение Read (Чтения) к определенному объекту, при этом он принадлежит к группе с разрешением Modify (Изменять) и группе с разрешением Full Control (Полное управление) на контейнерном уровне, то этот пользователь будет иметь разрешение Full Control. Когда пользователь обращается к объекту, подсистема защиты исследует все записи АСЕ, которые прикреплены к объекту. Они оцениваются, и устанавливается самый высокий уровень разрешения. В дополнение к записям АСЕ, которые предоставляют разрешения, Active Directory поддерживает также блокирование разрешений. Блокирование разрешений может применяться на двух уровнях.

• Пользовательскому объекту или группе, к которой принадлежит пользователь, может быть блокировано разрешение на доступ к определенному объекту явно.
• Пользовательскому объекту или группе, к которой принадлежит пользователь, может быть блокировано разрешение на контейнерном уровне, и оно может быть унаследовано объектами низшего уровня.

Блокирование разрешения (Deny) всегда отменяет разрешение (Allow). Например, если пользователь является членом группы, которая имеет разрешение Modify для объекта Active Directory, и если разрешение Modify к этому объекту явно блокировано для данного пользователя, то он не сможет изменять объект. Это происходит потому, что записи АСЕ, которые блокируют разрешения, оцениваются перед оценкой записей АСЕ, которые позволяют разрешения. Если одна из записей АСЕ блокирует разрешение участнику безопасности, то другие записи АСЕ для данного объекта не оцениваются.
Ситуация, в которой разрешения отменяют блокирование разрешения, возникает тогда, когда разрешения Deny унаследованы, а разрешения Allow назначены явно. Например, вы можете блокировать пользователю разрешение изменять любые учетные записи пользователя в контейнере. Но если вы явно позволите разрешение Modify для объекту в пределах контейнера, то данная учетная запись пользователя будет иметь разрешение Modify для этого объекта.
Блокирование разрешения: используйте осторожно
Использование блокирования разрешения может привести к тому, что работать с моделью защиты вашей службы Active Directory будет очень трудно. Есть множество различных сценариев, в которых вы можете предусмотреть блокировку разрешения. Один из них состоит в том, что вы можете использовать Deny (Запретить) для удаления некоторых унаследованных разрешений. Например, вы можете предоставить разрешения Modify на контейнерном уровне, но заменить его на Read-Only (Только для чтения) далее вниз по иерархии. В этом же сценарии вы можете блокировать разрешение Write на любых объектах или свойствах далее вниз по иерархии.
Еще одним сценарием, в котором можно было бы использовать Deny, является создание контейнера, требующего более высокой защиты. Например, имеется контейнер для всех должностных лиц, и нужно сделать так, чтобы обычный пользователь не смог читать свойства учетных записей должностных лиц. Вы можете блокировать разрешение Read для контейнера, используя группу Domain Users (Пользователи домена). В результате пользователям будет запрещено читать объекты каталога, включая администраторов. Из-за осложнений, которые может вызвать использование Deny, вы должны применять эту опцию с осторожностью.
В большинстве случаев вместо блокировки разрешений можно удостовериться, что пользователю или группе не были даны эти разрешения. Если пользователь при этом не является членом группы, которой были предоставлены разрешения, он не будет иметь доступа к объектам. Вам не обязательно блокировать разрешение для предотвращения доступа пользователей к объектам Active Directory.
Один из немногих сценариев, в которых выгодно использовать Deny, состоит в том, что группа должна иметь определенные разрешения, а один или более пользователей этой же группы должны иметь разрешения более низкого уровня. Например, вы можете создать группу по имени Account Admins, которая отвечает за управление всеми учетными записями пользователей в домене. Некоторые члены этой группы могут быть временными служащими, которые должны управлять всеми учетными записями пользователей в домене, но не имеют права изменять свойства учетных записей должностных лиц. В этом случае вы можете назначить группе Account Admins разрешение управлять учетными записями
пользователей в домене, затем создать OU для учетных записей должностных лиц и группу для временных членов группы Account Admins. Затем можно заблокировать право временных пользователей изменять какие-либо учетные записи пользователей в OU должностных лиц.
Таким образом, конфигурирование защиты объектов Active Directory может затрагивать большое количество взаимосвязанных переменных. Многие компании могут начинать с довольно простого проекта защиты, в котором маленькой группе администраторов предоставляются все разрешения в Active Directory. В большинстве случаев начальная конфигурация защиты Active Directory ясно задокументирована. Однако со временем она становится более запутанной. Иногда другой группе администраторов предоставляется набор разрешений для выполнения определенной задачи в течение определенного периода времени. Предоставить разрешение просто, но часто случается так, что впоследствии разрешения забывают удалить. Часто модификации защиты, сделанные после начального развертывания Active Directory, не документируются.
Для любой структуры Active Directory существует возможность того, что текущая конфигурация защиты окажется более сложной, чем первоначально разработанная конфигурация. Иногда это кончается тем, что пользователи имеют больше разрешений, чем следует. К счастью, в Windows Server 2003 есть инструмент, который может использоваться для определения фактических разрешений, представленных участнику безопасности для доступа к объектам Active Directory.
Обратитесь к свойствам объекта через соответствующий инструмент администрирования Active Directory. Выберите вкладку Security (Безопасность), щелкните на Advanced (Дополнительно), а затем выберите вкладку Effective Permissions (Фактические разрешения). На рисунке 9-7 показано окно инструмента Active Directory Users And Computers. Чтобы определить фактические разрешения для определенной учетной записи пользователя или группы, щелкните Select (ВыборХ а затем найдите имя группы или пользователя. Выбрав имя, щелкните на ОК. Окно Effective Permissions (Фактические разрешения) отображает все разрешения, которые предоставлены выбранному участнику безопасности для доступа к данному объекту Active Directory.
Примечание. Данный инструмент имеет некоторые ограничения, которые могут влиять на отображаемые фактические разрешения. Инструмент определяет фактические разрешения, основанные на наследовании и явно определенных разрешениях для учетной записи пользователя и его группы. Однако пользователь может также получить некоторые разрешения на основании того, как он входит в систему и соединяется с объектом. Например, в Windows Server 2003 вы можете назначать разрешения для группы Interactive (членом этой группы становится каждый, кто cделал вход на компьютер) или группы Network Login (каждый, кто обращается к информации по сети). Описанный выше инструмент Active Directory не может определять разрешения, предоставленные пользователю на основании принадлежности к этим типам групп. Кроме того, он может определять разрешения, используя только разрешения человека, выполняющего инструмент. Например, если пользователь, который выполняет инструмент, не имеет разрешения читать состав некоторых групп, к которым принадлежит интересующий его пользователь, то инструмент не способен точно определить разрешения.

Рис. 9-7. Отображение фактических разрешений для объекта Active Directory

Право собственности на объекты Active Directory
Каждый объект в Active Directory должен иметь владельца. По умолчанию пользователь, создавший объект, является его владельцем. Владелец объекта имеет право изменить разрешения на доступ к объекту, что означает, что даже если владелец не имеет полного управления объектом, он всегда может изменить разрешения на доступ к объекту. В большинстве случаев владельцем объекта является определенная учетная запись пользователя, а не учетная запись группы. Единственное исключение - это когда объект создан членом группы Domain Admins. В этом случае владельцем объекта назначается группа Domain Admins. Если владелец объекта является членом локальной группы Administrators, a не членом группы Domain Admins, то владельцем объекта назначается группа Administrators.
Чтобы определить владельца объекта Active Directory, обратитесь к свойствам объекта, используя соответствующий инструмент Active Directory. Выберите вкладку Security (Безопасность), щелкните на Advanced (Дополнительно), а затем выберите вкладку Owner (Владелец). На рисунке 9-8 показано окно инструмента Active Directory Users And Computers.

Рис. 9-8. Просмотр владельца объекта Active Directory
Если вы имеете разрешение Modify Owner (Модификация владельца) для объекта, вы можете использовать это окно для изменения владельца объекта. Вы можете назначить владельцем свою собственную учетную запись, учетную запись другого пользователя или группу. Эта последняя возможность уникальна для Active Directory Windows Server 2003. В Active Directory системы Microsoft Windows 2000 вы сами можете стать владельцем или назначать владельцем другого участника безопасности.
Административные привилегии
Административные разрешения являются специфическими для объектов Active Directory и определяют, какие действия администратор может выполнять с этими объектами. Разрешения, которые обсуждались до сих пор, основаны на списках ACL, приложенных к каждому объекту Active Directory. Пользовательские привилегии отличаются тем, что они применяются к учетным записям пользователя. Пользовательские привилегии пользователь получает за то, кем он является, а не за то, что он имеет разрешения изменять специфический объект Active Directory. Например, есть два способа дать пользователю (или группе) право добавлять рабочие станции к домену. Один способ состоит в том, чтобы дать пользователю (или группе) разрешение Create Computer Objects (Создание компьютерных объектов) на уровне OU или контейнера Computers (Компьютеры). Это позволит пользователю добавить необходимое количество рабочих станций к домену в указанном контейнере.
Другой способ состоит в том, чтобы дать пользователю привилегию добавления компьютеров к домену. Она является частью политики Default Domain Controllers Policy (Заданная по умолчанию политика контроллеров домена). Любой пользователь, имеющий эту привилегию, может добавить к домену до десяти рабочих станций. По умолчанию это разрешение предоставляется группе Domain Users (Пользователи домена).
Аудит использования административных разрешений
Важным аспектом обеспечения безопасности службы Active Directory является создание тщательно спланированной конфигурации защиты всего домена. Этот план должен ясно и точно определить, какие разрешения должна иметь каждая административная группа. Другим существенным компонентом защиты домена является аудит использования этих разрешений. Аудит служит достижению двух целей. Во-первых, он обеспечивает свидетельство изменений, которые были сделаны к каталогу. Если в каталоге были сделаны изменения, вы должны проследить, кто их сделал. Это особенно важно, если в информации домена произведены неправильные или злонамеренные изменения. Второй целью аудита является обеспечение дополнительной проверки административных прав, применяемых по всему домену. Периодически исследуя регистрационные журналы аудита, вы сможете определить, применяет ли административные права тот, кто не должен их иметь.
Включение аудита изменений, сделанных для объектов Active Directory, состоит из двух шагов. Первый шаг состоит во включении аудита на уровне OU Domain Controllers (Контроллеры домена). Это делается с помощью инструмента администрирования Domain Controller Security Policy (Политика безопасности контроллера домена). На консоли Microsoft Management Console (ММС) выберите оснастку File>Add/ Remove (Файл>Добавление/Удаление), щелкните на кнопке Add (Добавить), а затем добавьте Group Policy Object Editor (Редактор объектов групповой политики). В Group Policy Wizard (Мастер групповой политики), щелкните на кнопке Browse (Просмотр), затем трижды щелкните на Domain Controllers.domainname.com (где domainname — имя домена, в котором вы включаете аудит). На рисунке 9-9 показана заданная по умолчанию конфигурация аудита в Active Directory Windows Server 2003.

Рис. 9-9. Конфигурирование аудита в организационных единицах Default Domain Controllers
Если нужно производить аудит изменений для объектов Active Directory, вы должны гарантировать, что включена функция Audit Account Management (Аудит управления учетными записями). В этом случае все модификации, сделанные для объектов Active Directory, могут быть проверены. Вы можете делать аудит успешных изменений к Active Directory, а также неудавшихся попыток изменения Active Directory.
По умолчанию служба Active Directory Windows Server 2003 сконфигурирована для проведения аудита всех успешных действий по управлению учетными записями.
Разрешение аудита на уровне OU контроллера домена является первым шагом в предоставлении аудита. Это дает возможность сконфигурировать аудит для реальных объектов, расположенных в пределах данного домена. Чтобы разрешить аудит объекта Active Directory, обратитесь к окну Properties (Свойства) этого объекта через соответствующий инструмент Active Directory. Затем выберите вкладку Security (Безопасность), щелкните на Advanced (Дополнительно) и выберите вкладку Auditing (Аудит). На рисунке 9-10 показано окно инструмента Active Directory Users And Computers и заданная по умолчанию установка для аудита OU в Active Directory.

Рис. 9-10. Конфигурирование аудита объектов Active Directory
Чтобы добавить больше записей для аудита, щелкните на кнопке Add (Добавить) и выберите пользователей или группы, действия которых вы хотите контролировать. В большинстве случаев вы должны выбрать группу Everyone, чтобы модификации, сделанные любым пользователем, подвергались аудиту. Затем вы можете выбрать, какие действия вы хотите подвергать аудиту. Вы можете делать аудит всех модификаций, сделанных для любого объекта в контейнере, для определенного типа объектов или для определенных свойств объектов. Вы можете допустить аудит всех успешных модификаций, всех неудавшихся попыток модификации или оба варианта. Если вы включите аудит всех успешных модификаций, вы будете отслеживать все изменения, сделанные к каталогу. Если вы включите аудит неудавшихся попыток модификаций, вы сможете контролировать любые незаконные попытки изменить информацию каталога. Как только аудит включен, все контрольные события записываются в файле регистрации Security, доступном через инструмент Event Viewer (Средство просмотра событий).
Разрешение аудита делается просто. Управлять аудитом гораздо сложнее. Если вы разрешаете аудит всех модификаций каталога на уровне OU контроллера домена, то файл регистрации Security будет расти очень быстро. Почти все события будут законными изменениями, и не будут представлять для вас никакого интереса, кроме как отслеживание событий. Однако среди законных изменений может быть разбросано несколько изменений, о которых вы должны знать. Проблема состоит в том, чтобы среди большого количества обычных событий найти несколько интересных контрольных событий. В некоторых компаниях одному администратору каждый день поручают просмотр зарегистрированных событий. Наилучший способ справиться с этой проблемой состоит в том, чтобы создать некоторый автоматизированный способ анализа файлов регистрации событий. Другой путь состоит в использовании инструмента Microsoft Operations Manager (Менеджер операций) (отдельно продаваемый продукт) для фильтрации событий и вынесения предупреждений только в случае интересных событий.
Дополнительная информация. Если вы хотите больше узнать о продукте Microsoft Operations Manager (MOM), посетите веб-сайт http://www.microsoft.com/mom. MOM обеспечивает большое количество функциональных возможностей, которые выходят далеко за пределы проблемы контроля журналов безопасности.
Делегирование административных задач
В этой главе мы имеем дело с гарантией безопасности объектов Active Directory. Все сказанное до сих пор являлось подготовкой к данному разделу, который посвящен использованию опций защиты для делегирования административных задач. Поскольку все объекты в Active Directory имеют ACL-список, вы можете управлять административным доступом к любому свойству любого объекта. Это означает, что вы можете предоставлять другим администраторам Active Directory очень точные разрешения, чтобы они могли выполнять только делегированные им задачи.
Хотя при делегировании административных прав можно очень сильно их детализировать, необходимо поддерживать равновесие между сохранением максимально возможной простоты вещей и удовлетворением требований безопасности. В большинстве случаев делегирование административных разрешений в Active Directory подпадает под один из следующих сценариев.

• Назначение полного управления одной OU. Довольно типична ситуация, когда компания имеет несколько офисов с локальным администратором в каждом офисе, который должен управлять всеми объектами локального офиса. Этот вариант может также использоваться компаниями, которые слили домены ресурсов Windows NT в OU одного домена Active Directory. Прежним администраторам доменов ресурсов можно дать полное управление всеми объектами, расположенными в определенной OU. Использование этой опции означает, что можно практически полностью децентрализовать администрирование вашей организации, имея единственный домен.
• Назначение полного управления определенными объектами в OU. Это разновидность первого сценария. В некоторых случаях компания может иметь несколько офисов, но локальные администраторы должны управлять только определенными объектами в OU данного офиса. Например, можно позволить локальному администратору управлять всеми объектами пользователей и групп, но не компьютерными объектами. В ситуации, когда домены ресурсов стали организацион-ньши единицами (OU), вы, возможно, захотите, чтобы администраторы OU управляли всеми компьютерными учетными записями и локальными группами в OU, но не пользовательскими объектами.
• Назначение полного управления определенными объектами всего домена. Некоторые компании имеют высоко централизованное администрирование пользователями и группами, когда только одна группа имеет разрешение добавлять и удалять учетные записи групп и пользователей. В этом сценарии данной группе можно давать полное управление объектами пользователей и групп независимо от того, где в пределах домена расположены объекты. Этот сценарий довольно типичен для компании с централизованной группой администрирования компьютерами и берверами. Компьютерной группе можно дать полное управление всеми компьютерными объектами в домене.
• Назначение прав на модификацию только некоторых свойств объектов. В некоторых случаях можно предоставить группе административное разрешение управлять поднабором свойств объекта. Например, устанавливать пароли для всех учетных записей пользователя, но не иметь других разрешений. Отделу кадров можно дать разрешение на модификацию личной и открытой информации, касающейся всех учетных записей пользователя в домене, но не давать разрешение на создание или удаление учетных записей пользователя.

Можно использовать эти опции и любую их комбинацию в Active Directory Windows Server 2003. Один из способов конфигурирования делегированных разрешений состоит в прямом обращении к списку ACL для объекта и конфигурировании разрешений. Это может быть достаточно сложным из-за большого числа доступных опций и реальной возможности сделать ошибку.
Чтобы сделать эту задачу более легкой, Active Directory Windows Server 2003 включает Delegation Of Control Wizard (Мастер делегирования управления).
Чтобы использовать Delegation Of Control Wizard, выполните следующие действия.

1. Откройте инструмент Active Directory Users And Computers и найдите родительский объект, которому нужно делегировать управление. В большинстве случаев делегировать управление можно на уровне OU, домена или контейнера, например, на уровне контейнеров Computers (Компьютеры) или Users (Пользователи). Щелкните правой кнопкой мыши на родительском объекте и выберите Delegate Control (Делегировать управление). Щелкните на кнопке Next (Далее).
2. На странице Users Or Groups (Пользователи или группы) выберите пользователей или группы, которым вы хотите делегировать управление. Щелкните на кнопке Add (Добавить), чтобы просмотреть Active Directory для поиска соответствующих пользователей или групп.
3. Затем выберите задачи, которые вы хотите делегировать. Окно (рис. 9-11) дает вам возможность выбрать задачи из списка обычных или создать собственную задачу для делегирования.

Рис. 9-11. Использование Delegation Of Control Wizard (Мастер делегирования управления) для выбора обычной задачи или создания собственной задачи для делегирования

4. Если вы выберите создание собственной задачи, можете задать тип объектов, которым вы хотите делегировать административные разрешения (рис. 9-12).

Рис. 9-12. Выбор типа объектов, которым будут делегированы разрешения

5. Можно выбрать уровни разрешений, которые вы хотите применить к объекту: полный контроль над объектом или доступ к определенным свойствам (рис. 9-13).

Рис. 9-13. Выбор специфических разрешений для делегирования
Delegation Of Control Wizard значительно облегчает делегирование управления по сравнению с конфигурированием разрешений через ACL-списки. Однако эффект от применения обоих методов одинаков, т.е. ACL-списки объектов изменяются для обеспечения соответствующего уровня доступа.
Настройка инструментов для делегирования администрирования
Служба Active Directory Windows Server 2003 обеспечивает мощные способы делегирования административных задач и назначения очень точных разрешений, которые пользователи должны иметь при необходимости выполнить специфические задачи. В дополнение к этим способам Active Directory облегчает развитие административных средств, которые соответствуют конкретной задаче пользователя. Например, если вы делегируете право устанавливать пароли для отдельной OU, вы можете воспользоваться простым инструментом администрирования, который может использоваться только для этой задачи. Windows Server 2003 имеет два способа создания специально настроенных инструментов. Вы можете настроить внешний вид средств обычных консолей ММС или создать панель задач (taskpad), которая является полностью настроенным инструментом администрирования.
Настройка консоли управления Microsoft
Первый вариант разработки инструмента администрирования состоит в настройке консоли управления Microsoft (ММС - Microsoft Management Console) с помощью одной из заданных по умолчанию оснасток.
Предостережение. Простое создание настроенной ММС-консо-ли не предоставляет и не ограничивает права пользователя на выполнение административных задач. Перед созданием настроенного административного интерфейса нужно делегировать правильный уровень разрешений. Например, если вы даете пользователю право создания учетных записей пользователя на уровне домена, а затем создаете ММС-консоль, которая дает возможность пользователю рассматривать только одну OU, то он сможет создавать учетные записи пользователя в любой OU. Если пользователь загружает обычный инструмент администрирования Active Directory Users And Computers или садится за другой рабочий стол с другой ММС-консолью, он сможет создать учетную запись где угодно.
Для создания настроенной ММС-консоли откройте диалоговое окно Run (Выполнить) и напечатайте ттс. Будет открыта пустая ММС-консоль. Из меню File (Файл) добавьте нужную оснастку инструмента Active Directory. Если вы создаете собственную консоль ММС, используя оснастку Active Directory Users And Computers, разверните домен и найдете
контейнерный объект, которому вы делегировали разрешения. В левой области окна щелкните правой кнопкой мыши на контейнерном объекте  и выберите New Window From Here (Отсюда новое окно).
Откроется новое окно, в котором будут видны только контейнерный объект и все дочерние объекты. Затем вы можете переключиться назад к окну, которое отображает весь домен, и закрыть окно. Далее сохраните инструмент администрирования и предоставьте его пользователям, которые будут управлять только частью домена, видимого в ММС-консо-ли. Консоль ММС может быть предоставлена пользователю несколькими способами. Например, вы можете установить консоль ММС на рабочий стол пользователя или создать ярлык к инструменту администрирования на сетевом ресурсе.
Чтобы быть уверенным, что администраторы контейнера не изменят ММС-консвль, можно изменить опции ММС-консоли, выбирая Options в меню File. Вы можете сконфигурировать ММС-консоль так, чтобы она сохранялась в режиме User Mode (Режим пользователя), и изменить разрешения на ММС, чтобы конечный пользователь не мог сохранять изменения ММС-консоли. На рисунке 9-14 показан соответствующий интерфейс. Для уточнения деталей настройки ММС-консолей смотрите Help And Support Center (Центр справки и поддержки).

Рис. 9-14. Конфигурирование собственной ММС-консоли для предотвращения возможных ее изменений
Создание панели задач для администрирования
Собственная ММС-консоль полезна в том случае, когда пользователю требуется полное административное управление специфической OU.
Однако если разрешения пользователя ограничены выполнением определенных задач в контейнере, то панель задач обеспечивает более простой инструмент управления.
Создание панели задач состоит из двух шагов. Сначала создается вид панели задач, а затем назначаются задачи, которые пользователь может выполнять на объектах. Чтобы создать панель задач, создайте настроенную ММС-консоль, содержащую административную оснастку, которую вы хотите использовать. Найдите контейнер, в который вы делегировали административные разрешения, затем щелкните правой кнопкой мыши и выберите New Taskpad View (Новый вид панели задач). Запустится мастер New Taskpad View Wizard. Мастер предоставит вам опции для выбора типа объектов, отображаемых на панели задач, и информации, отображаемой на экране. После создания вида панели вы можете добавлять задачи с помощью мастера новых задач. Мастер определит, какие типы задач могут быть выполнены пользователями панели задач. Список доступных задач зависит от типов объектов, которые видны на панели задач. Например, если вы выберите просмотр OU, которая содержит учетные записи пользователей, вы получите опцию назначения задач, которые могут быть выполнены с учетными записями пользователя. Закончив создание панели задач, можно также сконфигурировать ее параметры настройки, чтобы она содержала очень простой интерфейс.
На рисунке 9-15 показана панель задач, которая может использоваться администратором для установки паролей в определенной OU. Чтобы использовать этот инструмент, администратор просто выбирает учетную запись пользователя, а затем щелкает Reset Password (Заново установить пароль).

Рис. 9-15. Панель задач для сброса пользовательских паролей
Планирование делегирования администрирования
Active Directory Windows Server 2003 предоставляет средства, предназначенные для делегирования административных разрешений в вашем домене. Однако вместе с положительными сторонами делегирования разрешений вы получаете риск назначения неправильных разрешений. Пользователям можно предоставить слишком большое количество разрешений, позволяющее им делать в Active Directory то, что им делать не положено. Пользователям можно предоставить слишком малое количество разрешений, не позволяющее делать то, что они должны делать. Создание структуры делегирования, которая обеспечит пользователей точными разрешениями, в которых они нуждаются, требует серьезного планирования. Ниже приведены некоторые советы, помогающие это сделать.

• Тщательно документируйте административные требования для всех потенциальных администраторов. В большинстве компаний вы обнаружите, что имеются различные группы, которые нуждаются в некоторых административных разрешениях в домене. Если компания использовала Windows NT, многие из этих пользователей могли быть членами группы Domain Admins. Документируя административные задачи, которые эти пользователи должны выполнять, вы обнаружите, что на самом деле они нуждаются в гораздо более низком уровне доступа. Часто единственный способ документирования уровня административных разрешений, в которых нуждается каждая группа, состоит в документировании всей административной работы, которую они делают каждый день. Документируя действия, которые администраторы должны выполнять, вы смбжете разработать точные разрешения, которые для этого следует иметь.
• Перед тем как сделать какие-либо изменения в производственной среде, проверьте все модификации защиты в испытательной среде. Создание неправильной конфигурации защиты может иметь серьезные последствия для вашей сети. Используйте испытательную лабораторию для гарантии того, что модификации разрешений отвечают необходимым требованиям, но не дают разрешений, которые не являются необходимыми.
• Используйте Effective Permissions (Фактические разрешения) в окне Advanced Security Settings (Дополнительные параметры настройки защиты) для мониторинга и проверки разрешений, которые имеют пользователи. Окно Effective Permissions является отличным новым инструментом службы Active Directory Windows Server 2003, который может использоваться для определения точных разрешений пользователя или группы. Используйте этот инструмент в испытательной среде для гарантии того, что ваша конфигурация точна, а затем используйте его в производственной среде, чтобы удостовериться, что ваша реализация соответствует плану.
• Документируйте все разрешения, которые вы назначаете. Из всех задач, возложенных на сетевых администраторов, документирование изменений, сделанных в сети, относится к самым неприятным, потому что это очень утомительно и кажется не особо важным. В результате документация часто оказывается неполной или устаревшей. Единственный путь эффективного управления конфигурацией защиты вашей сети состоит в том, чтобы документировать начальную конфигурацию, а затем взять обязательство обновлять документацию всякий раз, когда один из первоначальных параметров настройки изменен.

Резюме
Возможность делегирования административных разрешений в Active Directory Windows Server 2003 дает большую гибкость в управлении вашим доменом. Оно основано на модели безопасности Active Directory, в которой все объекты и все атрибуты объектов имеют список ACL, контролирующий разрешения на доступ к объекту для различных участников безопасности. Согласно этой модели по умолчанию все разрешения наследуются от контейнерных объектов к объектам, находящимся в пределах контейнера. Эти особенности модели защиты подразумевают, что вы можете назначить любой уровень разрешений на доступ к любому объекту Active Directory. Такая гибкость может привести к увеличению сложности, если защита Active Directory не поддерживается настолько простой, насколько это возможно. В этой главе был дан краткий обзор разрешений защиты, делегирования административных прав в Active Directory и некоторых из инструментальных средств, которые могут использоваться для этой работы.

1 .. 8 9 10 11 12 .. 16