Разрешения объектов службы Active Directory

🕛 20.01.2009, 17:06

Как описано в главе 8, когда пользователь входит в сеть Windows Server 2003, ему предоставляется лексема доступа. Лексема доступа включает идентификаторы защиты (SID) для учетной записи пользователя, а также SID для всех групп, к которым принадлежит пользователь. Как только пользователь вошел, он пытается обратиться к сетевому ресурсу, ко
торый включает объект Active Directory. Каждый сетевой ресурс или объект Active Directory имеет список ACL, хранящийся в его атрибуте NT Security Descriptor, который состоит из одной или более записей управления доступом (АСЕ), определяющей, какие права на данный объект имеет каждый идентификатор 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. Столбцы конфигурации специальных разрешений

Столбец

Объяснение

Туре (Тип)

Значение устанавливается для разрешений Allow (Разрешить) или Deny (Запретить). Обычно разрешения отсортированы так, что сначала перечисляются все разрешения Deny (Запретить). Порядок сортировки может быть изменен щелчком на любом заголовке столбца. Независимо от порядка появления в этом столбце сначала всегда оцениваются разрешения Deny (Запретить).

Name (Имя)

Имя участника безопасности, к которому применяется запись АСЕ.

Permission (Разрешение)

Столбец перечисляет уровень разрешения, предоставленного участнику безопасности. Уровни разрешений могут быть стандартными, например Full Control, специальными, например, Create/Delete User Objects (Создавать/Удалять пользовательские объекты), или только Special (Специальный). Доступные типы разрешений зависят от типа объекта.

Inherited From (Унаследованный от)

Столбец указывает место, в котором установлено это разрешение.

Apply To (Применяется к)

Столбец определяет глубину применения разрешение. Она имеет разнообразные параметры настройки, включая This Object Only (Только этот объект), This Object And All Child (Этот объект и все дочерние объекты) или Only Child Objects (Только дочерние объекты).

Это окно перечисляет все АСЕ-записи для объекта. Во многих случаях одни и те же участники безопасности могут быть перечислены в нескольких записях АСЕ. Например, группе 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 хранится в значении NT Security Descriptor каждого объекта 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 не может определять разрешения, предоставленные пользователю на основании принадлежности к этим типам групп. Кроме того, он может определять разрешения, используя только разрешения человека, выполняющего инструмент. Например, если пользователь, который выполняет инструмент, не имеет разрешения читать состав некоторых групп, к которым принадлежит интересующий его пользователь, то инструмент не способен точно определить разрешения.