Назначение службы каталогов Active Directory

Доменная модель

В доменной модели существует единая база данных служб каталогов, доступная всем компьютерам сети. Для этого в сети устанавливаются специализированные серверы, называемые контроллерами домена, которые хранят на своих жестких дисках эту базу. На рис. 6.2. изображена схема доменной модели. Серверы DC-1 и DC-2 — контроллеры домена, они хранят доменную базу данных учетных записей (каждый контроллер хранит у себя свою собственную копию БД, но все изменения, производимые в БД на одном из серверов, реплицируются на остальные контроллеры).

Рис. 6.2.

В такой модели, если, например, на сервере SRV-1, являющемся членом домена, предоставлен общий доступ к папке Folder, то права доступа к данному ресурсу можно назначать не только для учетных записей локальной базы SAM данного сервера, но, самое главное, учетным записям, хранящимся в доменной БД. На рисунке для доступа к папке Folder даны права доступа одной локальной учетной записи компьютера SRV-1 и нескольким учетным записям домена (пользователя и группам пользователей). В доменной модели управления безопасностью пользователь регистрируется на компьютере ("входит в систему") со своей доменной учетной записью и, независимо от компьютера, на котором была выполнена регистрация, получает доступ к необходимым сетевым ресурсам. И нет необходимости на каждом компьютере создавать большое количество локальных учетных записей, все записи созданы однократно в доменной БД. И с помощью доменной базы данных осуществляется централизованное управление доступом к сетевым ресурсам независимо от количества компьютеров в сети.

Терминология

Служба каталогов системы Windows Server построена на общепринятых технологических стандартах. Изначально для служб каталогов был разработан стандартX.500, который предназначался для построения иерархических древовидных масштабируемых справочников с возможностью расширения как классов объектов, так и наборов атрибутов (свойств) каждого отдельного класса. Однако практическая реализация этого стандарта оказалась неэффективной с точки зрения производительности. Тогда на базе стандарта X.500 была разработана упрощенная (облегченная) версия стандарта построения каталогов, получившая названиеLDAP ( Lightweight Directory Access Protocol ). Протокол LDAP сохраняет все основные свойства X.500 (иерархическая система построения справочника, масштабируемость, расширяемость), но при этом позволяет достаточно эффективно реализовать данный стандарт на практике. Термин " lightweight " ("облегченный ") в названии LDAP отражает основную цель разработки протокола: создать инструментарий для построения службы каталогов, которая обладает достаточной функциональной мощью для решения базовых задач, но не перегружена сложными технологиями, делающими реализацию служб каталогов неэффективной. В настоящее время LDAP является стандартным методом доступа к информации сетевых каталогов и играет роль фундамента во множестве продуктов, таких как системы аутентификации, почтовые программы и приложения электронной коммерции. Сегодня на рынке присутствует более 60 коммерческих серверов LDAP, причем около 90% из них представляют собой самостоятельные серверы каталогов LDAP, а остальные предлагаются в качестве компонентов других приложений.

Протокол LDAP четко определяет круг операций над каталогами, которые может выполнять клиентское приложение. Эти операции распадаются на пять групп:

• установление связи с каталогом;
• поиск в нем информации;
• модификация его содержимого;
• добавление объекта;
• удаление объекта.

Кроме протокола LDAP служба каталогов Active Directory использует также протокол аутентификации Kerberos и службу DNS для поиска в сети компонент служб каталогов (контроллеры доменов, серверы глобального каталога, службу Kerberos и др.).

Домен

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

Имена доменов Active Directory формируются по той же схеме, что и имена в пространстве имен DNS. И это не случайно. Служба DNS является средством поиска компонент домена — в первую очередь контроллеров домена.

Контроллеры домена — специальные серверы, которые хранят соответствующую данному домену часть базы данных Active Directory. Основные функции контроллеров домена:

• хранение БД Active Directory (организация доступа к информации, содержащейся в каталоге, включая управление этой информацией и ее модификацию);
• синхронизация изменений в AD (изменения в базу данных AD могут быть внесены на любом из контроллеров домена, любые изменения, осуществляемые на одном из контроллеров, будут синхронизированы c копиями, хранящимися на других контроллерах);
• аутентификация пользователей (любой из контроллеров домена осуществляет проверку полномочий пользователей, регистрирующихся на клиентских системах).

Настоятельно рекомендуется в каждом домене устанавливать не менее двух контроллеров домена — во-первых, для защиты от потери БД Active Directory в случае выхода из строя какого-либо контроллера, во-вторых, для распределения нагрузки между контроллерами.

Дерево

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

Пример дерева Active Directory изображен на рис. 6.3. В данном примере домен company.ru является доменом Active Directory верхнего уровня. От корневого домена отходят дочерние домены it.company.ru и fin.company.ru. Эти домены могут относиться соответственно к ИТ-службе компании и финансовой службе. У домена it.company.ru есть поддомен dev.it.company.ru, созданный для отдела разработчиков ПО ИТ-службы.

Корпорация Microsoft рекомендует строить Active Directory в виде одного домена. Построение дерева, состоящего из многих доменов необходимо в следующих случаях:

• для децентрализации администрирования служб каталогов (например, в случае, когда компания имеет филиалы, географически удаленные друг от друга, и централизованное управление затруднено по техническим причинам);
• для повышения производительности (для компаний с большим количеством пользователей и серверов актуален вопрос повышения производительности работы контроллеров домена);
• для более эффективного управления репликацией (если контроллеры доменов удалены друг от друга, то репликация в одном может потребовать больше времени и создавать проблемы с использованием несинхронизированных данных);
• для применения различных политик безопасности для различных подразделений компании;
• при большом количестве объектов в БД Active Directory.

Рис. 6.3.

Лес

Наиболее крупная структура в Active Directory. Лес объединяет деревья, которые поддерживают единую схему ( схема Active Directory — набор определений типов, или классов, объектов в БД Active Directory). В лесу между всеми доменами установлены двухсторонние транзитивные доверительные отношения, что позволяет пользователям любого домена получать доступ к ресурсам всех остальных доменов, если они имеют соответствующие разрешения на доступ. По умолчанию, первый домен, создаваемый в лесу, считается его корневым доменом, в корневом домене хранится схема AD.

Новые деревья в лесу создаются в том случае, когда необходимо построить иерархию доменов с пространством имен, отличным от других пространств леса. В примере на рис. 6.3 российская компания могла открыть офис за рубежом и для своего зарубежного отделения создать дерево с доменом верхнего уровняcompany.com. При этом оба дерева являются частями одного леса с общим "виртуальным" корнем.

При управлении деревьями и лесами нужно помнить два очень важных момента:

• первое созданное в лесу доменов дерево является корневым деревом, первый созданный в дереве домен называется корневым доменом дерева ( tree root domain );
• первый домен, созданный в лесу доменов, называется корневым доменом леса ( forest root domain ), данный домен не может быть удален (он хранит информацию о конфигурации леса и деревьях доменов, его образующих).

Организационные подразделения (ОП).

Организационные подразделения ( Organizational Units, OU ) — контейнеры внутри AD, которые создаются для объединения объектов в целях делегирования административных прав и применения групповых политик в домене. ОП существуют только внутри доменов и могут объединять только объекты из своего домена. ОП могут быть вложенными друг в друга, что позволяет строить внутри домена сложную древовидную иерархию из контейнеров и осуществлять более гибкий административный контроль. Кроме того, ОП могут создаваться для отражения административной иерархии и организационной структуры компании.

Глобальный каталог

Глобальный каталог является перечнем всех объектов, которые существуют в лесу Active Directory. По умолчанию, контроллеры домена содержат только информацию об объектах своего домена. Сервер Глобального каталога является контроллером домена, в котором содержится информация о каждом объекте (хотя и не обо всех атрибутах этих объектов), находящемся в данном лесу.

Именование объектов

В службе каталогов должен быть механизм именования объектов, позволяющий однозначно идентифицировать любой объект каталога. В каталогах на базе протокола LDAP для идентификации объекта в масштабе всего леса используется механизмотличительных имен ( Distinguished Name, DN ). В Active Directory учетная запись пользователя с именем User доменаcompany.ru, размещенная в стандартном контейнере Users, будет иметь следующее отличительное имя: "DC=ru, DC=company, OU=Users, CN=User".

Обозначения:

• DC (Domain Component) — указатель на составную часть доменного имени;
• OU (Organizational Unit) — указатель на организационное подразделение (ОП);
• CN (Common Name) — указатель на общее имя.

Если отличительное имя однозначно определяет объект в масштабе всего леса, то для идентификации объекта относительно контейнера, в котором данный объект хранится, существует относительное отличительное имя ( Relative Distinguished Name, RDN ). Для пользователя User из предыдущего примера RDN-имя будет иметь вид " CN=User ".

Кроме имен DN и RDN, используется основное имя объекта ( User Principal Name, UPN ). Оно имеет формат <имя субъекта>@<суффикс домена>. Для того же пользователя из примера основное имя будет выглядеть как [email protected].

Имена DN, RDN могут меняться, если объект перемещается из одного контейнера AD в другой. Для того чтобы не терять ссылки на объекты при их перемещении в лесу, всем объектам назначается глобально уникальный идентификатор ( Globally Unique Identifier, GUID ), представляющий собой 128-битное число.

Планирование пространства имен AD

Планирование пространства имен и структуры AD — очень ответственный момент, от которого зависит эффективность функционирования будущей корпоративной системы безопасности. При этом надо иметь в виду, что созданную вначале структуру в процессе эксплуатации будет очень трудно изменить (например, в Windows 2000 изменить имя домена верхнего уровня вообще невозможно, а в Windows 2003 решение этой задачи требует выполнения жестких условий и тщательной подготовки данной операции). При планировании AD необходимо учитывать следующие моменты:

• тщательный выбор имен доменов верхнего уровня;
• качество коммуникаций в компании (связь между отдельными подразделениями и филиалами);
• организационная структура компании;
• количество пользователей и компьютеров в момент планирования;
• прогноз темпов роста количества пользователей и компьютеров.

Рассмотрим вопрос пространства имен AD.

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

Рассмотрим основные варианты.

1. Один домен, одна зона DNS (рис. 6.4).

На рисунке в левой части — внутренняя сеть компании, справа — сеть Интернет, две сети разделены маршрутизатором " R " (кроме маршрутизатора, на границе могут быть также прокси-сервер или межсетевой экран).

Рис. 6.4.

В данном примере используется одна и та же зона DNS (company.ru) как для поддержки внутреннего домена AD с тем же именем (записи DC, SRV-1, SRV-2, WS-1), так и хранения ссылок на внешние ресурсы компании — веб-сайт, почтовый сервер (записи www, mail ).

Такой способ максимально упрощает работу системного администратора, но при этом DNS-сервер, доступный для всей сети Интернет, хранит зону company.ru и предоставляет доступ к записям этой зоны всем пользователям Интернета. Таким образом, внешние злоумышленники могут получить полный список внутренних узлов корпоративной сети. Даже если сеть надежно защищена межсетевым экраном и другими средствами защиты, предоставление потенциальным взломщикам информации о структуре внутренней сети — вещь очень рискованная, поэтому данный способ организации пространства имен AD не рекомендуется (хотя на практике встречается довольно часто).

1. "Расщепление" пространства имен DNS - одно имя домена, две различные зоны DNS(рис. 6.5).

Рис. 6.5.

В данном случае на различных серверах DNS создаются различные зоны с одним и тем же именем company.ru. На внутреннем DNS-сервере функционирует зона company.ru.для Active Directory, на внешнем DNS-сервере — зона с таким же именем, но для ссылок на внешние ресурсы. Важный момент — данные зоны никак между собой не связаны — ни механизмами репликации, ни ручной синхронизацией.

Здесь во внешней зоне хранятся ссылки на внешние ресурсы, а во внутренней на внутренние ресурсы, используемые для работы Active Directory. Данный вариант несложно реализовать, но для сетевого администратора возникает нагрузка управления двумя разными доменами с одним именем.

1. Поддомен в пространстве имен DNS для поддержки Active Directory (рис. 6.6).

Рис. 6.6.

В данном примере корневой домен компании company.ru служит для хранения ссылок на внешние ресурсы. В домене company.ru настраивается делегирование управление поддоменом corp.company.ru на внутренний DNS-сервер, и именно на базе домена corp.company.ru создается домен Active Directory. В этом случае во внешней зоне хранятся ссылки на внешние ресурсы, а также ссылка на делегирование управления поддоменом на внутренний DNS-сервер. Таким образом, пользователям Интернета доступен минимум информации о внутренней сети. Такой вариант организации пространства имен довольно часто используется компаниями.

1. Два различных домена DNS для внешних ресурсов и для Active Directory (рис. 6.7.).

Рис. 6.7.

В этом сценарии компания регистрирует в Интернет-органах два доменных имени: одно для публикации внешних ресурсов, другое — для развертывания Active Directory.

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

1. Домен с именем типа company.local.

Во многих учебных пособиях и статьях используются примеры с доменными именами вида company.local. Такая схема вполне работоспособна и также часто применяется на практике. Однако в материалах разработчика системы Windows, корпорации Microsoft, нет прямых рекомендаций об использовании данного варианта.

Установка контроллеров доменов

Теперь перейдем к описанию процедур установки контроллеров доменов Active Directory.

Разберем установку самого первого контроллера самого первого домена самого первого леса в структуре AD.

Установка начинается с запуска из командной строки мастера установки Active Directory — dcpromo (рис. 6.8).

Рис. 6.8.

Нажимаем кнопку "ОК" и видим стартовую страницу мастера (рис. 6.9):

Рис. 6.9.

Далее идет предупреждение, что операционные системы Windows 95, Windows NT 4.0 SP3 и более ранние не смогут функционировать в доменах Windows 2003 (рис. 6.10). Заметим, что в доменах на базе Windows 2000 такой проблемы нет (да и в доменах на базе windows 2003 эта проблема решаема).

Рис. 6.10.

Затем выбираем варианты установки контроллера домена в новом домене (рис. 6.11) и создания нового домена в новом лесу (рис. 6.12):

Рис. 6.11.

Рис. 6.12.

Следующий шаг — выбор имени домена (для Active Directory это будет корневой домен). В нашем примере выберем имя world.ru (рис. 6.13):

Рис. 6.13.

Зададим NetBIOS-имя домена (по умолчанию, будет предложена левая часть полного имени домена, выбранного на предыдущем шаге). В нашем примере — WORLD (рис. 6.14.):

Рис. 6.14.

Далее мастер предложит выбрать место на жестких дисках для размещения базы данных Active Directory, журнала транзакций этой БД (рис. 6.15) и папки системного тома SYSVOL (рис. 6.16). Системный том обязательно должен быть размещен на разделе с файловой системой NTFS.

Рис. 6.15.

Рис. 6.16.

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

Рис. 6.17.

Далее предлагается выбрать уровень разрешений создаваемого домена (рис. 6.18). Заметим, что если мы выберем наиболее высокий уровень, то в таком домене не смогут существовать компьютеры с операционными системами, более ранними, чем Windows 2000.

Рис. 6.18.

Затем задаем пароль администратора при запуске системы в режиме восстановления служб каталогов (рис. 6.19). данный режим используется для восстановления БД Active Directory из резервной копии.

Рис. 6.19.

Затем следует экран со сводкой информации о создаваемом домене и параметрах контроллера домена (рис. 6.20). На этом шаге в случае обнаруженной ошибки в конфигурации можно вернуться назад и исправить ошибку.

Рис. 6.20.

После этого начинается работа по созданию базы данных AD и наполнению ее нужными записями (рис. 6.21).

Рис. 6.21.

Последний шаг — нажать кнопку "Готово" и перезагрузить сервер (рис. 6.22).

Рис. 6.22.

Важное замечание. Если при создании первого контроллера в домене перед запуском мастера в локальной базе SAM данного сервера были какие-либо учетные записи пользователей и групп, то все они импортируются в созданную БД Active Directory с сохранением своих имен и паролей, в том числе и учетная запись администратора сервера, которая становится учетной записью администратора домена (а если самый первый домен в лесу, то и администратором предприятия и администратором схемы).

Кратко опишем процесс установки дополнительного контроллера в уже созданном домене.

Если у нас есть второй сервер, который мы хотим сделать дополнительным контроллером домена, то вначале желательно включить его в домен в качестве сервера–члена домена. Кнопка "Пуск" — Панель управления — Система — Закладка "Имя компьютера" — Кнопка "Изменить". Далее в поле "Является членом домена" ввести имя домена, нажать ОК, ввести имя и пароль администратора домена, снова нажать ОК и перезагрузить сервер (рис. 6.23).

Рис. 6.23.

После перезагрузки входим в систему с учетной записью администратора домена и запускаем мастер установки Active Directory — команда dcpromo. Выбираем вариант "Добавочный контроллер в существующем домене" (рис. 6.24).

Рис. 6.24.

Указываем учетные данные администратора домена (рис. 6.25):

Рис. 6.25.

Снова указываем имя домена — world.ru. Начинается процесс импорта БД Active Directory на создаваемый контроллер (рис. 6.26):

Рис. 6.26.

По окончании процесса — снова нажать кнопку "Готово" и перезагрузить сервер.

Важное замечание. При добавлении дополнительного контроллера в домене существовавшая на сервере локальная база SAM с сервера удаляется.

Опишем процесс установки дополнительного контроллера домена из резервной копии AD существующего контроллера.

Сначала создадим резервную копию AD. Запустим на существующем контроллере домена утилиту ntbackup, выберем архивацию состояния системы (System State), укажем путь для создания файла с резервной копией и нажмем кнопку "Архивировать" (рис. 6.27):

Рис. 6.27.

На следующем шаге — нажать кнопку "Дополнительно" (рис. 6.28):

Рис. 6.28.

В открывшейся панели — убрать галочку у поля "Автоматически архивировать защищенные системные файлы вместе с состоянием системы" (рис. 6.29):

Рис. 6.29.

После создания резервной копии AD файл с резервной копией желательно скопировать на жесткий диск того сервера, который будет преобразовываться в контроллер домена. Затем надо разархивировать резервную копию утилитой ntbackup. При этом обязательно надо указать, что восстанавливать данные надо в альтернативное размещение и указать папку для размещения восстановленных данных (рис. 6.30):

Рис. 6.30.

Теперь на сервере, который преобразуем из простого сервера в контроллер домена, запускаем утилиту dcpromo с параметром "/adv" (рис. 6.31):

Рис. 6.31.

На этапе выбора источника БД Active Directory — выбрать вариант "используя файлы из архива" и указать путь к папке, в которую разархивировали резервную копию (рис. 6.32):

Рис. 6.32.

По окончании процесса — перезагрузить сервер.

Репликация внутри сайта

Репликация изменений в AD между контроллерами домена происходит автоматически, каждые 5 минут. Топологию репликации, т.е. порядок, в котором серверы опрашивают друг друга для получения изменений в базе данных, серверы строят автоматически (эту задачу выполняет компонента служб каталогов, называемаяKnowledge Consistency Checker, или KCC, вариант перевода данного термина — " наблюдатель показаний целостности "). При достаточно большом количестве контроллеров KCC строит кольцевую топологию репликации, причем для надежности образует несколько колец, по которым контроллеры передают данные репликации. Наглядно увидеть топологию репликации можно с помощью административной консоли " Active Directory - сайты и службы ". Если в этой консоли раскрыть последовательно контейнеры Sites, Defauit-First-site-Name, Servers, далее — конкретный сервер (например, DC1) и установить на узле NTDS Settings, то в правой половине окна видно, что сервер DC1 запрашивает изменения с сервера DC2 (рис. 6.35):

Рис. 6.35.

Возможностей управления репликацией у администратора сети в данном случае немного. Можно лишь вызвать принудительную репликацию в той же консоли "Active Directory - сайты и службы ". Если в правой части того же окна консоли, изображенного на рис. 6.35, щелкнуть правой кнопкой мыши на имени DC2 и выбрать вариант " Реплицировать сейчас ", то контроллер DC1 получит изменения в базе данных AD с контроллера DC2 (рис. 6.36):

Рис. 6.36.

Репликация между сайтами

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

Вернемся к сетевой структуре, изображенной на рис. 6.34, и обсудим понятия и термины, играющие важную роль в управлении репликацией между сайтами.

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

Для репликации между сайтами используется тот или иной межсайтовый транспорт — это либо IP ( RPC ), либо SMTP. Для каждого вида межсайтового транспорта определяется " соединение сайтов " ( site link ), с помощью которого строится управление репликацией между двумя и более сайтами. Именно для соединения ("линка") задаются такие параметры как " Расписание репликации " и " Стоимость ". На рис. 6.34. соединение Link-1 связывает в единую цепочку сайты Сайт-1,Сайт-3, Сайт-4 и Сайт-2, соединение Link-2 связывает два сайта — Сайт-1 и Сайт-2. В данном примере репликация между сайтами Сайт-1 и Сайт-2 будет проходить либо по соединению Link-1, либо по соединению Link-2 — в зависимости от расписания, стоимости соединения и его доступности (при доступности обоих соединений преимущество будет иметь соединение с более низкой стоимостью). На рис. 6.37 изображено созданное автоматически соединение для транспорта IP (RPC ) — DEFAULTIPSITELINK. Если открыть Свойства этого соединения (рис. 6.38), то можно управлять списком сайтов, относящихся к этому соединению, назначать стоимость соединения (значение по умолчанию — 100), интервал репликации (по умолчанию — каждые 3 часа), а если нажать кнопку " Изменить расписание ", то можно более тонко определить дни и часы, в которые будет производиться репликация.

Контейнер Subnets консоли " Active Directory - сайты и службы " служит для описания подсетей, входящих в тот или иной сайт.

Рис. 6.37.

Рис. 6.38. Функциональные уровни домена и леса

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

Для Windows 2003 имеются 4 уровня функционирования (в Windows 2000 — 2 уровня):

Windows 2000 смешанный (Windows 2000 mixed)

В данном режиме в домене могут существовать резервные контроллеры домена под управлением системы Windows NT Server. Этот режим рассматривается как переходный в процессе модернизации служб каталогов с Windows NT на Windows 2000/2003. В этом режиме отсутствует ряд возможностей Active Directory — универсальные группы, вложенность групп. Кроме того, наличие контроллеров домена под управлением Windows NT накладывает ограничение на размер БД Active Directory (40 мегабайт).

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

Windows 2000 основной (Windows 2000 native)

В данном режиме контроллерами домена могут быть серверы под управлением Windows 2000 и Windows 2003. В данном режиме появляется возможность использования универсальных групп, вложенность групп, и ликвидируется ограничение на размер БД Active Directory.

Windows 2003 промежуточный (Windows 2003 interim)

Данный уровень возможен только в том случае, когда контроллеры домена работают под управлением Windows NT и Windows 2003 (не может быть контроллеров с системой Windows 2000). Этот уровень доступен только тогда, когда производится установка Windows 2003 поверх контроллеров домена с Windows NT. Ограничения этого режима аналогичны смешанному режиму.

Windows 2003

Это наивысший уровень функционирования домена, в котором есть контроллеры с Windows 2003, причем все контроллеры обязаны быть с системой Windows 2003.

Изменять уровень функционирования домена можно только в сторону его повышения. Сделать это можно с помощью административных консолей " Active Directory – домены и доверие " или " Active Directory – пользователи и компьютеры ". Если в какой-либо из этих консолей щелкнуть правой кнопкой мыши на имени домена и выбрать в контекстном меню пункт " Изменение режима работы домена ", то появится панель, изображенная на рис. 6.39:

Рис. 6.39.

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

Для всего леса в целом также можно определять функциональные уровни. Это делается с помощью консоли " Active Directory – домены и доверие ". Только правой кнопкой мыши надо щелкнуть не на имени домена, а на надписи " Active Directory – домены и доверие ".

Существуют 3 уровня функционирования леса:

• Windows 2000 (с контроллерами под управлением Windows NT, 2000 и 2003);
• Windows 2003 interim (с контроллерами под управлением только Windows NT и 2003);
• Windows 2003 ( все домены всего леса — с контроллерами под управлением только Windows 2003).

Самый высокий уровень функционирования леса позволяет выполнять две очень важные задачи:

• переименование доменов;
• установление доверительных отношений между двумя не связанными друг с другом лесами с использованием Kerberos в качестве протокола аутентификации (без такого режима доверительные отношения могут устанавливаться только между отдельными доменами, а не целыми лесами, при этом будет использоваться менее защищенный протокол аутентификации NTLM).

Сервер глобального каталога

Напомним, что Глобальный каталог ( global catalog ) — это перечень всех объектов леса Active Directory. По умолчанию, контроллеры домена содержат только информацию об объектах своего домена. Сервер Глобального каталога является контроллером домена, в котором содержится информация о каждом объекте (хотя и не обо всех атрибутах этих объектов), находящемся в данном лесу.

Сервер глобального каталога выполняет две очень важные функции:

• поиск объектов в масштабах всего леса (клиенты могут обращаться к глобальному каталогу с запросами на поиск объектов по определенным значениям атрибутов; использование сервера глобального каталога — единственный способ осуществлять поиск объектов по всему лесу);
• аутентификация пользователей (сервер глобального каталога предоставляет информацию о членстве пользователя в универсальных группах, universal groups ; поскольку универсальные группы со списками входящих в них пользователей хранятся только на серверах глобального каталога, аутентификация пользователей, входящих в такие группы, возможна только при участии сервера глобального каталога).

По умолчанию самый первый контроллер домена в лесу является сервером глобального каталога. Однако администратор сети может назначить любой контроллер домена сервером глобального каталога. Это делается с помощью административной консоли " Active Directory – сайты и службы ", в свойствах узла " NTDS Settings" выбранного контроллера (рис. 6.41):

Рис. 6.41.

Для эффективной работы службы каталогов Active Directory необходимо, чтобы в каждом сайте AD был либо сервер глобального каталога, либо контроллер домена, кэширующий у себя списки членов универсальных групп. Кэширование универсальных групп также настраивается в консоли " Active Directory – сайты и службы " в свойствах узла " NTDS Settings " для каждого сайта Active Directory. Для включения кэширования нужно поставить галочку у поля " Разрешить кэширование членства в универсальных группах " и указать, из какого сайта данный сайт будет получать списки универсальных групп в поле " Обновлять кэш из:" (рис. 6.42):

Рис. 6.42.

Локальные учетные записи

Каждый компьютер с операционными системами Windows NT/2000/XP/2003 (если это не сервер, являющийся контроллером домена) имеет локальную базу данных учетных записей, называемую базой данных SAM. Эти БД обсуждались при описании модели безопасности "Рабочая группа". Локальные пользователи и особенно группы используются при назначении прав доступа к ресурсам конкретного компьютера даже в доменной модели безопасности. Общие правила использования локальных и доменных групп для управления доступом будут описаны ниже.

Правление группами

Учетные записи групп, как и учетные записи пользователей, могут быть созданы либо в локальной базе SAM компьютера (сервера или рабочей станции), либо в доменной базе данных Active Directory.

Локальные группы простого сервера-члена домена или рабочей станции могут включать в себя и локальные учетные записи данного компьютера, и глобальные учетные записи любого пользователя или компьютера всего леса, а также доменные локальные группы "своего" домена и глобальные и универсальные группы всего леса.

Рассмотрим подробнее, какие группы могут создаваться в Active Directory.

В Active Directory группы различаются по типу (группы безопасности и группы распространения) и по области действия (локальные в домене, глобальные и универсальные).

Типы групп

• Группы безопасности — каждая группа данного типа, так же как и каждая учетная запись пользователя, имеетидентификатор безопасности ( Security Identifier, или SID ), поэтому группы безопасности используются для назначения разрешений при определении прав доступа к различным
  Предыдущая1234567Следующая