Логическая структура Active Directory

После того как вы установили Active Directory в свою сетевую среду и начали реализовывать проект службы, подходящий для ваших деловых целей, вы будете работать с логической структурой Active Directory. Она является моделью службы каталога, которая определяет каждого участника безопасности на предприятии, а также организацию этих участников. База данных Active Directory содержит следующие структурные объекты:

• разделы;
• домены;
• деревья доменов;
• леса;
• сайты;
• организационные единицы.

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

Разделы Active Directory

Как вы уже знаете, база данных Active Directory хранится в файле на жестком диске каждого контроллера домена. Она разделена на несколько логических разделов, каждый из которых хранит различные типы информации. Разделы Active Directory называются контекстами именования (NC - naming contexts). Просмотреть их можно с помощью инструмента Ldp.exe или ADSI Edit.

Рис. 2-4. Просмотр разделов Active Directory с помощью инструмента ADSI Edit

Раздел домена каталога

В разделе домена происходит большая часть действий. Он содержит всю информацию домена о пользователях, группах, компьютерах и контактах: все, что можно просмотреть с помощью инструмента администрирования Active Directory Users And Computers (Пользователи и компьютеры Active Directory).

Раздел домена автоматически реплицируется на все контроллеры в домене. Информация, которая в нем содержится, требуется каждому контроллеру домена для подтверждения подлинности пользователей.

Раздел конфигурации каталога

Раздел конфигурации содержит информацию о конфигурации леса, например, информацию о сайтах, связях сайта и подключениях репликации. В нем хранят информацию многие прикладные программы. Приложения Exchange Server 2000, Microsoft Internet Security And Acceleration (ISA) Server помещают свою конфигурационную информацию в раздел конфигурации каталога Active Directory, а не в свою собственную службу каталога. Когда вы устанавливаете первый ISA-сервер в свою организацию, вы можете сконфигурировать массив, который будет хранить всю конфигурационную информацию ISA в Active Directory. Затем легко устанавливаются дополнительные ISA-серверы, использующие эту же конфигурацию, которая читается из службы Active Directory.

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

Раздел схемы каталога

Раздел схемы содержит схему для всего леса. Как вы уже знаете, схема представляет собой набор правил о том, какие типы объектов можно создавать в Active Directory, а также правила для каждого типа объектов. Раздел схемы реплицируется на все контроллеры домена в лесу. Однако только один контроллер домена, хозяин схемы, хранит перезаписываемую копию раздела схемы каталога. Все изменения к схеме осуществляются на контроллере - хозяине схемы, а затем реплицируются на другие контроллеры домена.

Раздел глобального каталога

Раздел глобального каталога GC не является разделом в полном смысле. Он хранится в базе данных подобно другому разделу, но администраторы не могут вводить информацию в него напрямую. Раздел GC предназначен только для чтения на всех GC-серверах, он построен из содержимого баз данных домена. Каждый атрибут в схеме имеет булевое значение с именем isMemberOfPartialAttributeSet. Если оно установлено на true (истина), атрибут копируется в каталог GC.

Разделы приложений каталога

Последний тип раздела в службе Active Directory Windows Server 2003 - это раздел приложений каталога. Только один тип раздела приложений каталога создается в Active Directory по умолчанию — это раздел, предназначенный для службы сервера доменной системы имен (DNS - Domain Name System). При установке первой интегрированной (integrated) зоны Active Directory создаются прикладные разделы каталога ForestDnsZones и DomainDnsZones. Раздел приложений каталога может хранить любой тип объекта Active Directory, кроме участников безопасности. Кроме того, разделы приложений каталога создаются для управления процессом репликации данных, и ни один из объектов раздела приложений каталога не может реплицироваться в раздел GC.

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

Схема именования прикладных разделов каталога идентична другим разделам каталога Active Directory. Например, DNS-имя для конфигурационного раздела каталога в лесу Contoso.com - dc=Configuration, dc=Contoso, dc=com. Если вы создаете раздел приложений каталога по имени AppPartitionl в домене Contoso.com, его DNS-имя будет dc=AppPartition1, dc=Contoso, dc=com. Разделы приложений каталога достаточно гибки по отношению к месту создания, или, более точно, к контексту именования. Например, можно создать дополнительный раздел приложений каталога в разделе AppPartitionl. Это приведет к тому, что раздел будет иметь имя dc=AppPartition2, dc=AppPartition1, dc=Contoso, dc=com. Возможно создание раздела приложений каталога с DNS-именем, не смежным ни с одним доменом в лесу. Вы можете создать раздел приложений в домене Contoso.com, который имеет DNS-имя dc=AppPartition, таким образом, будет создано новое дерево в лесу.

Примечание:
Выбор DNS-имени для пространства имен приложения никак не влияет на функциональные возможности раздела приложений. Единственное различие будет состоять в конфигурировании LDAP-клиента, который обращается к разделу. Разделы приложений каталога предназначены для доступа LDAP, поэтому клиент должен быть сконфигурирован так, чтобы делать поиск на сервере в правильном пространстве имен.

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

Совет. Обычно разделы приложений каталога создаются в процессе инсталляции приложения, для которого требуется использование раздела каталога. Инсталляционная процедура приложения должна разрешать создание дополнительных реплик на других контроллерах домена. Вы можете создать каталог приложений с помощью утилиты Ntdsutil, но в среде предприятия это обычно не используется. Процедуры управления разделами приложений каталога описаны в справке Windows Server 2003 Help And Support Center (Центр справки и поддержки Windows Server 2003). Для получения детальной информации о разделах приложений каталога, о том, как обращаться к ним программно, сделайте поиск фразы «Using application directory partitions» на сайте msdn.microsoft.com.

Как только раздел приложений каталога с несколькими репликами создан, управление репликацией раздела осуществляется так же, как для других разделов. Дополнительную информацию о репликации Active Directory см. в главе 4.

Домены

Домен является основным строительным блоком в модели службы Active Directory. Устанавливая Active Directory на своем компьютере, работающем под управлением Windows Server 2003, вы создаете домен. Домен служит в качестве административной границы, он определяет и границу политик безопасности. Каждый домен имеет, по крайней мере, один контроллер домена (оптимально иметь два или более).

Домены Active Directory организованы в иерархическом порядке. Первый домен на предприятии становится корневым доменом леса, обычно он называется корневым доменом или доменом леса. Корневой домен является отправной точкой для пространства имен Active Directory. Например, первый домен в организации Contoso — Contoso.com. Первый домен может быть назначенным (dedicated) или неназначенным (non-dedicated) корневым доменом. Назначенный корневой домен, называемый пустым корнем, является пустым доменом-заменителем, предназначенным для запуска Active Directory. Этот домен не будет содержать никаких реальных учетных записей пользователя (группы) и использоваться для назначения доступа к ресурсам. Единственные учетные записи, которые содержатся в назначенном корневом домене — это учетные записи пользователей и групп, заданных по умолчанию, таких как учетная запись Administrator (Администратор) и глобальная группа Domain Admins (Администраторы домена). Неназначенный корневой домен - это домен, в котором создаются учетные записи фактических пользователей и групп. Причины выбора назначенного или неназначенного корневого домена леса обсуждаются в главе 5.

Остальные домены на предприятии существуют или как равные по положению (peers) по отношению к корневому домену, или как дочерние домены. Равные по положению домены находятся на том же иерархическом уровне, что и корневой домен. На рисунке 2-5 показана модель доменов, равных по положению.

Рис. 2-5. Домены Active Directory, организованные как равные по положению

Общепринято, что домены, устанавливаемые вслед за корневым доменом, становятся дочерними доменами. Дочерние домены используют одно и то же пространство имен Active Directory совместно с родительским доменом. Например, если первый домен в организации Contoso назван Contoso.com, то дочерний домен в этой структуре может называться NAmerica.Contoso.com и использоваться для управления всеми участниками безопасности организации Contoso, находящимися в Северной Америке. Если организация достаточно большая или сложная, то могут потребоваться дополнительные дочерние домены, например, Sales.NAmerica.Contoso.com. На рисунке 2-6 показана родительско-дочерняя иерархия домена для организации Contoso.

Рис. 2-6. Родительско-дочерняя модель домена для корпорации Contoso

Деревья доменов

Домены, которые создаются в инфраструктуре Active Directory после создания корневого домена, могут использовать существующее пространство имен Active Directory совместно или иметь отдельное пространство имен. Чтобы выделить отдельное пространство имен для нового домена, нужно создать новое дерево домена. Независимо от того, используется ли единственное пространство имен или несколько, дополнительные домены в том же самом лесу функционируют совершенно одинаково. Создание дополнительных деревьев доменов связано исключительно с организационными проблемами и проблемами именования, оно никак не затрагивает функциональные возможности. Дерево доменов содержит, по крайней мере, один домен. Даже организация с единственным доменом имеет дерево доменов. Использование нескольких деревьев вместо дочерних доменов влияет на конфигурацию DNS, об этом вы узнаете в главе 3.

Дерево доменов образуется в том случае, когда организация создает домен вслед за созданием корневого домена леса (forest root domain), но не хочет использовать существующее пространство имен. В случае Contoso, если существующее дерево доменов использует пространство имен Contoso.com, может быть создан новый домен, который использует совершенно другое пространство имен, например, Fabrikam.com. Если в дальнейшем потребуется создание доменов, чтобы удовлетворить потребностям единицы Fabrikam, они могут создаваться как дочерние от дерева доменов Fabrikam. На рисунке 2-7 показана схема организации Contoso с несколькими доменными деревьями.

Рис. 2-7. Корпорация Contoso с несколькими доменными деревьями

Леса

Лес представляет собой границу безопасности для предприятия и является самой дальней репликацией. Все домены и доменные деревья находятся в пределах одного или нескольких лесов Active Directory. Лес общий для всех контроллеров домена внутри него. К общим компонентам относятся:

• Общая схема. Все контроллеры домена в лесу используют одну и ту же схему. Единственный способ иметь две разные схемы в одной организации — это создать два отдельных леса.
• Общий раздел конфигурации каталога. Все контроллеры домена в лесу имеют одинаковый конфигурационный контейнер для репликации. Этот раздел активно используется приложениями, поддерживающими Active Directory, такими как Echange Server 2000 и ISA.
• Общий глобальный каталог GC. Он содержит данные обо всех объектах в лесу, что упрощает поиск и позволяет пользователям входить в любой домен леса с использованием своих UPN.
• В корневом домене леса создаются две группы безопасности. Эти группы имеют особые разрешения, недоступные другим пользователям. Группа Schema Admins может изменять схему, а Enterprise Admins выполняет действия на уровне леса, такие как добавление или удаление доменов. Группа Enterprise Admins также входит в каждую локальную группу Administrators на контроллерах домена в каждом домене леса.
• Общая конфигурация доверительных отношений. Все домены в лесу настроены на доверие друг другу. Детали доверительных отношений обсуждаются в следующем разделе.

На рисунке 2-8 показан лес Contoso.

Доверительные отношения

По умолчанию домен является границей доступа к ресурсам в организации. Имея соответствующие разрешения, любой участник безопасности (например, учетная запись пользователя или группы) может обращаться к любому общедоступному ресурсу в том же самом домене. Для получения доступа к ресурсам, которые находятся за пределами домена, используются доверительные отношения службы Active Directory. Доверительные отношения представляют собой опознавательную связь между двумя доменами, с помощью которой участники безопасности могут получать полномочия на доступ к ресурсам, расположенным на другом домене. Есть несколько типов доверительных отношений, включающих:

• транзитивные доверительные отношения;
• односторонние доверительные отношения;
• доверительные отношения леса;
• доверительные отношения области.

Транзитивные доверительные отношения

Все домены дерева поддерживают транзитивные двухсторонние доверительные отношения с другими доменами в этом дереве. В примере, рассмотренном выше, когда домен NAmerica.Contoso.com создается как дочерний домен корневого домена Contoso.com, автоматически создаются двухсторонние доверительные отношения между доменами NAmerica.Contoso.com и Contoso.com. Через доверительные отношения любой пользователь в домене NAmerica.Contoso.com может обращаться к любому ресурсу в домене Contoso.com, на доступ к которому есть разрешение. Аналогично, если в домене Contoso.com имеются какие-либо участники безопасности (как в неназначенном корневом домене), им можно давать доступ к ресурсам домена NAmerica.Contoso.com.

В пределах леса доверительные отношения устанавливаются или как родительско-дочерние доверительные отношения, или как доверительные отношения корня дерева. Примером родительско-дочерних доверительных отношений являются отношения между доменами NAmerica.Contoso.com и Contoso.com. Доверительные отношения корня дерева - это отношения между двумя деревьями в лесу, например, между Contoso.com и Fabrikam.com.

Все доверительные отношения между доменами леса являются транзитивными. Это означает, что все домены в лесу доверяют друг другу. Если домен Contoso.com доверяет домену NAmerica.Contoso.com и домен Europe.Contoso.com доверяет домену Contoso.com, то транзитивность указывает на то, что домен Europe.Contoso.com также доверяет домену NAmerica.Contoso.com. Поэтому пользователи в домене NAmerica. Contoso.com могут обращаться к ресурсам, имеющимся в домене Europe.Contoso.com, и наоборот. Свойство транзитивности доверительных отношений применимо к доверительным отношениям корня дерева. Домен NAmerica.Contoso.com доверяет домену Contoso.com, и домен Contoso.com доверяет домену Fabrikam.com. Поэтому домен NAmerica. Contoso.com и домен Fabrikam.com также имеют транзитивные доверительные отношения друг с другом.

Односторонние доверительные отношения

В дополнение к двухсторонним транзитивным доверительным отношениям, которые устанавливаются при создании нового дочернего домена, между доменами леса могут быть созданы односторонние доверительные отношения. Это делается для того, чтобы разрешить доступ к ресурсам между доменами, которые не состоят в прямых доверительных отношениях. Односторонние доверительные отношения также используются для оптимизации производительности работы между доменами, которые связаны транзитивными доверительными отношениями. Эти односторонние доверительные отношения называются укороченными доверительными отношениями shortcut trusts. Укороченные доверительные отношения нужны в том случае, когда требуется частый доступ к ресурсам между доменами, которые удаленно связаны через дерево домена или лес. Примером этому является лес Contoso, изображенный на рисунке 2-9.

Рис. 2-9. Доверительные отношения в лесу Contoso

Если группа безопасности в домене Sales.Europe.Contoso.com часто обращается к общему ресурсу в домене Research.NAmerica.Contoso.com, то при наличии только транзитивных доверительных отношения между доменами пользователи в домене Sales.Europe.Contoso.com должны подтверждать подлинность в каждом домене дерева, расположенном между ними и доменом, который содержит ресурс. Такая организация работы неэффективна, если часто возникает потребность доступа к этим ресурсам. Укороченные доверительные отношения являются прямыми односторонними доверительными отношениями, которые дадут возможность пользователям в домене Sales.Europe.Contoso.com эффективно подтверждать подлинность в домене Research.NAmerica.Contoso.com без необходимости пересекать все дерево каталога, чтобы туда добраться. На рисунке 2-10 показаны эти прямые доверительные отношения. Если возникает потребность установить такие же доверительные отношения в другом направлении, можно создать прямые доверительные отношения между этими двумя доменами, взаимно изменив их роли. (Такие двойные прямые доверительные отношения кажутся транзитивными отношениями, но эти исключительные доверительные отношения не простираются за пределы этих двух доменов).

Доверительные отношения леса

Доверительные отношения леса являются новой функцией в Windows Server 2003. Они представляют собой двухсторонние транзитивные доверительные отношения между двумя отдельными лесами. С помощью доверительных отношений леса участнику безопасности, принадлежащему одному лесу, можно давать доступ к ресурсам в любом домене совершенно другого леса. Кроме того, пользователи могут входить на любой домен обоих лесов, используя одно и то же имя UPN.

• Доверительные отношения леса не являются транзитивными по отношению к другим лесам. Например, если Forest 1 имеет доверительные отношения леса с Forest2, и Forest2 имеет доверительные отношения леса с Forest3, то Forest1 не имеет автоматических доверительных отношений леса с Forest3.
• Доверительные отношения леса делают возможной только идентификацию между лесами, они не обеспечивают другие функциональные возможности. Например, каждый лес будет иметь уникальный каталог GC, схему и раздел конфигурации каталога. Информация между этими двумя лесами не копируется, доверительные отношения леса просто делают возможным назначение доступа к ресурсам между лесами.
• В некоторых случаях вам потребуется установить доверительные отношения между всеми доменами одного леса и всеми доменами другого леса. Для этого вы можете устанавливать односторонние, не транзитивные доверительные отношения между индивидуальными доменами в двух отдельных лесах.

На рисунке 2-11 показаны доверительные отношения леса компании Contoso.

Рис. 2-11. Доверительные отношения леса компании Contoso соединяют домены Contoso.com и NWTraders.com, находящиеся в разных лесах

Доверительные отношения области

Последний тип доверительных отношений — это доверительные отношения области (Realm Trusts). Они устанавливаются между доменом или лесом Windows Server 2003 и не Windows-реализацией области Kerberos v5. Защита Kerberos основана на открытом стандарте, имеются другие системы сетевой защиты, основанные на протоколе Kerberos. Доверительные отношения области можно создать между любыми Kerberos-областями, которые поддерживают стандарт Kerberos v5. Доверительные отношения области могут быть односторонними или двухсторонними, их можно также сконфигурировать как транзитивные и не транзитивные.

Сайты

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

Active Directory

Сайты обеспечивают соединение между логическими компонентами Active Directory и физической сетевой инфраструктурой. Сайт представляет область сети, где все контроллеры домена связаны быстрым, недорогим и надежным сетевым подключением. В большинстве случаев сайт содержит одну или более подсетей с протоколом интернета (IP), связанных локальной сетью (LAN) или быстродействующей глобальной сетью (WAN), подключенных к остальной части сети через более медленные WAN-подключения.

Основная причина для создания сайтов состоит в том, чтобы иметь возможность управлять любым сетевым трафиком, который должен использовать медленные сетевые подключения. Сайты используются для управления сетевым трафиком в пределах сети Windows Server 2003 тремя различными способами.

• Репликация. Одним из важнейших способов, которым сайты пользуются для оптимизации сетевого трафика, является управление трафиком репликации между контроллерами доменов и GC-серверами. В пределах сайта любое изменение, сделанное в каталоге, будет копироваться в течение приблизительно пяти минут. Графиком репликации между сайтами можно управлять так, чтобы репликация происходила во время нерабочих часов. По умолчанию трафик репликации между сайтами сжат для сохранения пропускной способности сети, в пределах сайта трафик репликации не сжимается. (В главе 4 представлена более детальная информации относительно различий между внутрисайтовой и межсайтовой репликациями.)
• Идентификация. Когда пользователь входит в домен Windows Server 2003 с клиента, на котором работает система Windows 2000 или Microsoft Windows XP Professional, компьютер клиента пробует подключить контроллер домена, находящийся в том же самом сайте, где находится клиент. В главе 3 будет обсуждаться, как каждый контроллер домена регистрирует записи указателя служб (SRV), специфические для сайта. Когда компьютер клиента пытается найти контроллер домена, он всегда запрашивает записи сайтов у DNS-серверов. Это означает, что трафик входа клиента в систему останется в пределах сайта. Если домен работает на функциональном уровне Windows 2000 native (основной) или Windows Server 2003, то клиент будет пытаться найти каталог GC во время входа в систему. Если на сайте имеется GC-сервер, клиент соединится с этим сервером. (Роль сайтов в поиске контроллеров домена подробно обсуждается в главе 3.)
• Сетевые службы, учитывающие наличие сайтов. Третий способ, который позволяет сайтам сохранять высокую пропускную способность, состоит в ограничении клиентских подключений к сайту только теми приложениями и службами, которые учитывают наличие сайтов. Например, используя распределенную файловую систему (DFS - Distributed File System), вы можете создавать несколько реплик папки на различных сайтах в сети. Поскольку система DFS спроектирована так, что она учитывает конфигурацию сайта, компьютеры клиента всегда пробуют обратиться к DFS-реплике на своем собственном сайте, прежде чем использовать связи WAN-сети, чтобы получить доступ к информации на другом сайте.

Примечание.
Клиентские компьютеры, на которых работает система Windows NT 4 SP6a, могут регистрироваться на контроллерах домена Active Directory, если они установили службу Directory Services Client (Клиент служб каталога), которая доступна для загрузки на сайте http://www.microsoft.com/ Windows 2000/server/evaluation/news/bulletins/adextension.asp. Для тех клиентов, которые не были модернизированы с Windows 95 или Windows 98, программное обеспечение Directory Services Client доступно на компакт-диске Windows Server 2000.

Каждый компьютер в сети Windows Server 2003 назначен сайту. При установке службы Active Directory в среде Windows Server 2003 создается сайт по умолчанию, названный Default First Site Name, и все компьютеры леса назначаются этому сайту, если не созданы дополнительные сайты. При создании дополнительных сайтов они ассоциируются с IP-подсетями. Если сервер на Windows Server 2003 становится контроллером домена, он автоматически назначается сайту, связанному с IP-адресом этого компьютера. При необходимости контроллеры домена можно перемещать между сайтами с помощью инструмента Active Directory Sites And Services.

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

Примечание: Если у контроллера домена или клиентского компьютера IP-адрес не связан с конкретным сайтом, он будет отнесен к сайту Default First Site Name. Каждый компьютер в домене Windows Server 2003 должен быть привязан к сайту.

Как упоминалось ранее, нет прямой связи между сайтами и другими логическими элементами Active Directory. Один сайт может включать несколько доменов, и один домен может быть связан с несколькими сайтами. На рисунке 2-12 показано, что сайт Seattle содержит два домена: Contoso.com и NAmerica.Contoso.com. Домен NWTraders.com распределен по разным сайтам.

Примечания:
Сайты рассматриваются в других главах. В главе 3 подробно рассказывается о роли DNS и сайтов для клиентских входов. Глава 4 посвящена роли сайтов в репликации и настройке сайтов. В главе 5 представлена подробная информация о проектировании оптимальной конфигурации сайта для леса Active Directory.

Организационные единицы

Путем реализации нескольких доменов в лесу в виде одного или нескольких деревьев служба Active Directory Windows Server 2003 может масштабироваться так, чтобы обеспечить услуги каталога для сети любого размера. Многие из компонентов Active Directory, такие как глобальный каталог и автоматические транзитивные доверительные отношения, предназначены для того, чтобы сделать использование и управление каталогом предприятия эффективным, независимо от того, насколько большим становится каталог.

Организационные единицы (OU - Organizational Unit) предназначены для того, чтобы облегчить управление службой Active Directory. OU используются для того, чтобы сделать более эффективным управление единственным доменом, вместо того чтобы иметь дело с управлением несколькими доменами службы Active Directory. OU служат для создания иерархической структуры в пределах домена. Домен может содержать сотни тысяч объектов. Управление таким количеством объектов без использования определенных средств организации объектов в логические группы затруднено. Организационные единицы выполняют именно эти функции. На рисунке 2-13 показан пример структуры OU в корпорации Contoso.

Рис. 2-13. Пример структуры организационных единиц

OU являются контейнерами объектов, содержащими несколько типов объектов службы каталога:

• компьютеры;
• контакты;
• группы;
• inetOrgPerson;
• принтеры;
• пользователи;
• общедоступные папки;
• организационные единицы.

Организационные единицы используются для группировки объектов в административных целях. Они могут делегировать административные права и управлять группой объектов как отдельным подразделением.

Использование организационных единиц для делегирования административных прав

Организационные единицы могут использоваться для делегирования административных прав. Например, пользователю могут быть даны права на выполнение административных задач в определенной OU. Это могут быть права высокого уровня, когда пользователь имеет полный контроль над подразделением, или очень ограниченные и специфические (например, только возможность сбрасывания паролей пользователей в этом подразделении). Пользователь, который имеет административные права на доступ к организационной единице, по умолчанию не имеет никаких административных прав вне OU.

Организационные единицы имеют гибкую структуру назначения прав на доступ к объектам внутри OU. Во многих диалоговых окнах Windows и во вкладках Properties (Свойства) они называются разрешениями. Сама организационная единица OU имеет список управления доступом (ACL — Access Control List), в котором можно назначать права на доступ к этой OU. Каждый объект в OU и каждый атрибут объекта имеет ACL-список. Это означает, что вы можете очень точно контролировать административные права, данные кому-либо в этом подразделении. Например, вы можете дать группе Help Desk (Справочная) право изменять пароли пользователей в OU, не изменяя любые другие свойства учетных записей пользователя. Можно дать отделу Human Resources (Отдел кадров) право изменять личную информацию, касающуюся любой учетной записи пользователя в любом OU, но не давать им никаких прав на другие объекты.

Использование организационных единиц для управления группами объектов

Одной из функций OU является объединение объектов в группы так, чтобы этими объектами можно было одинаково управлять. Если вы хотите одинаково управлять всеми компьютерами в отделе (например, вводя ограничения на то, какие пользователи имеют право входа в операционную систему), вы можете сгруппировать компьютеры в OU и установить разрешение Logon Locally (Локальный вход в систему) на уровне OU. Это разрешение будет установлено для всех компьютеров в данной OU. Другим примером группировки объектов в административных целях является ситуация, когда совокупность пользователей нуждается в одинаковой стандартной конфигурации рабочего стола компьютера и одинаковом наборе приложений. В этом случае пользователи объединяются в одну OU, и используется групповая политика (group policy) для конфигурирования рабочего стола и управления инсталляцией приложений.

В многих случаях объекты в OU будут управляться через групповую политику. Group Policy Object Editor (Редактор объектов групповой политики) представляет собой инструмент, который может использоваться для управления рабочей средой каждого пользователя. Групповые политики могут использоваться для блокировки пользовательских рабочих столов, для придания им стандартного вида, обеспечения сценариев входа в систему и выхода из нее, перенаправления папок. В таблице 2-3 дается краткий список типов параметров настройки, доступных в редакторе Group Policy Object Editor.

Табл. 2-3. Типы параметров настройки групповой политики

Групповые политики чаще назначаются на уровне OU. Это облегчает задачу управления пользователями, так как можно назначить один объект групповой политики (GPO — Group Policy Object), например, политику инсталляции программного обеспечения организационной единице, которая затем распространится на всех пользователей или компьютеры в OU.

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