Книги, научные публикации
Pages: | 1 | 2 | 3 | 4 | ... | 18 | Distributed Systems Guide Microsoft Windows 2000 Server Microsoft Press Распределенные системы Книга 1 Microsof Windows 2000 ...
-- [ Страница 2 ] --У объекта NTDS Settings есть многозначный атрибут hasMasterNCs, в котором ука заны разделы каталога, хранимые на данном контроллере домена (здесь NC озна чает naming context синоним термина раздел каталога}:
контекст именования три полные и модифицируемые разделы каталога домена, схемы и конфигура ции. Если данный контроллер домена является глобальным каталогом, то в другом многозначном атрибуте объекта NTDS Settings, hasPartialReplicationNCs, перечис лены вес разделы каталогов домена леса, и именно с этими разделами он обмени вается изменениями по механизму репликации.
Поскольку объект NTDS Settings находится в разделе конфигурации, реплицируе мого во все контроллеры домена леса, то у всех контроллеров доменов имеются одинаковые сведения о серверах глобального каталога.
Подробнее о назначении компьютера сервером глобального каталога Ч в справоч ной системе Microsoft Windows 2000 Server.
Глобальный каталог и процедура входа в домен Наличие сервера глобального каталога необходимо для входа в домен основного режима, поэтому в каждом из сайтов рекомендуется иметь хотя бы один такой сер вер. Тем не менее, если в каком-то из них глобального каталога нет, для входа мо жет использоваться сервер глобального каталога удаленного сайта. Если глобаль ных каталогов нет или они недоступны, то для входа в систему используется ин формация из кэша.
Примечание Члены группы Domain Admins (Администраторы домена) могут ус пешно войти в систему (без использования кэша), даже если глобальный каталог недоступен.
Логическая структура Active Directory ГЛАВА 1 Членство в универсальных группах Необходимость наличия глобального каталога вызвана тем, что сведения о член стве в универсальных группах (universal group) хранится не на всех контроллерах доменов, а полный список таких членов реплицируется только на серверы глобаль ного каталога.
Примечание Универсальные группы существуют только в доменах основного режима.
В процессе входа в систему с пользователем ассоциируется маркер безопасности, содержащий указание на группы, к которым он принадлежит. Если в списке управ ления доступом (access control list, ACL) для определенного объекта указана запись управления доступом (access control entry, АСЕ) универсальной группы, то для зап рещения или предоставления доступа необходимо, чтобы маркер безопасности со держал эту универсальную группу (но членство в универсальной группе может под твердить только сервер глобального каталога). Иначе (на основе членства в другой группе) пользователь мог бы получить доступ к объекту, доступ к которому ему как члену универсальной группы запрещен. Обратное также верно: пользователь мо жет не получить доступ к ресурсам, к которым допущен как член универсальной группы.
Примечание Запрещение доступа обрабатывается до разрешения, поэтому, если в соответствии с членством в одной группе доступ запрещен, а в другой Ч разрешен, то получить доступ пользователю не удастся.
Основное имя пользователя и поддержка входа в систему с глобальным каталогом Войти в домен Windows 2000 пользователь может по своему основному имени (user principal name) или имени учетной записи SAM (
Формат основного имени пользователя (
Поиск и глобальный каталог Поскольку глобальный каталог хранит сведения обо всех объектах леса, его можно использовать для поиска таких объектов без переадресации на другие серверы. Если запрос на поиск послать в порт 389 (стандартный порт протокола LDAP), то про сматривается только один раздел каталога (а также разделы схемы и конфигура ции), после чего (в случае неудачи) он переадресуется на контроллер другого до мена, выбираемый на основе составного имени искомого объекта. Если же послать запрос в порт 3268 (стандартный порт глобального каталога), то за один раз сервер глобального каталога просматривает все разделы леса. Если в запросе дополнитель Служба каталогов Active Directory 36 ЧАСТЬ но указать атрибуты из набора атрибутов глобального каталога, то результат мо жет быть получен без перенаправления в контроллеры других доменов.
Подробнее о перенаправлении в LDAP-поиске и поиске в глобальном каталоге Ч в главе 3 Разрешение имен в Active Directory.
Подразделения Active Directory позволяет администраторам создавать иерархическое пространство имен внутри каждого домена. Для этого существует organizationalUnit Ч класс-кон тейнер общего назначения, позволяющий создавать группы администрирования из объектов большинства других классов. Подразделение (organizational unit, OU) в Active Directory аналогично каталогу в файловой системе: это контейнер, способ ный содержать другие объекты.
Административная иерархия Подразделения можно вкладывать друг в друга, образуя внутридоменную иерархию и создавая логические административные единицы для пользователей, групп и объектов ресурсов, таких, как принтеры, компьютеры, приложения и общие фай лы. В каждом из доменов создается собственная иерархия подразделений, и эти структуры никак не связаны друг с другом. Однако внутреннюю иерархию доме нов, управляемых из единого центра, можно строить по заданному образцу. Внут ридоменная структура чрезвычайно гибка, и предприятие вправе построить любую среду, отражающую административную структуру самой организации, независимо от степени ее централизации.
Подробнее о планировании и реализации иерархии подразделений Ч в книге Mic rosoft Windows 2000 Server Deployment Planning Guide (Microsoft Press, 2000).
Групповая политика Для подразделений можно задавать групповую политику, которая определяет пол номочия отдельных групп компьютеров и пользователей этих единиц: от полного запрещения доступа до выделения пользователям довольно широких полномочий.
При этом можно указать доступность для группы определенных приложений, (а также возможность выполнения определенных функций этих приложений на ука занном компьютере), задать места хранения документов и порядок доступа пользо вателей к ним, определить время, место и порядок обновления приложений и опе рационной системы, а также выполнения определенных сценариев.
Параметры групповой политики хранятся в объектах групповой политики Active Directory, которые, в свою очередь, могут ассоциироваться с одним или более кон тейнерами Active Directory, такими, как сайты, домены, или подразделения.
Подробнее о групповой политике в главах 21, 22 и 23 книги Распределенные системы. Книга 2. Ресурсы Microsoft Windows 2000 (Русская Редакция, 2001).
Делегирование управления В объектно-ориентированной модели безопасности Windows 2000 управление дос тупом по умолчанию распространяется вниз по иерархии определенного поддерева контейнерных объектов. Такой порядок применяется для задания условий безопас ности для всей группы объектов, относящихся к определенному подразделению, что позволяет эффективно делегировать полномочия вниз по иерархии вплоть до от Логическая структура Active Directory ГЛАВА дельных пользователей. В таких условиях оптимальное решение это организа ция иерархии в соответствии с задачами администрирования.
Примечание Поскольку Active Directory индексируется, нет никакой потребности создавать для наглядности дерево, призванное облегчить просмотр, поскольку это может противоречить целям администрирования.
Полномочия административного управления объектами каталога разрешается при менять (или делегировать) к подразделениям средствами механизма управления доступом. (Подробнее об административном управлении Ч в разделе Делегирова ние административных полномочий далее в этой главе.) Безопасность объектов При проверке подлинности учетных записей пользователей, входящих в домен Windows 2000, выясняется, действительно ли пользователь является тем, за кого себя выдает, а также имеется ли соответствующая учетная запись в данном или до веренном домене. При положительном результате проверки подлинности служба каталогов Active Directory выполняет авторизацию, то есть определяет порядок доступа пользователя к объектам. Авторизация осуществляется средствами управ ления доступом.
Примечание Здесь кратко описан механизм безопасности службы каталогов Active Directory. Подробнее о безопасности в Active Directory Ч в главах части 2 Безо пасность в распределенных системах.
Управление доступом Все объекты Active Directory защищены списками управления доступом (access control list, ACL). B ACL определено, кто может видеть объект и какие действия над объектом каждому из пользователей разрешены. Если пользователю не разре шено видеть данный объект, то у него и нет никаких средств, чтобы узнать о его существовании.
Список управления доступом состоит из записей управления доступом (access control entries, ACEs). B Windows 2000 список ACL хранится в двоичном формате в дескрипторе безопасности. (Security Descriptor). Каждая запись АСЕ содержит идентификатор зйциты (security identifier, SID), который однозначно указывает на участника безопасности (security principal) Ч им может быть отдельный пользова тель или группа пользователей, и содержит информацию о том, какой тип доступа к объекту разрешен или запрещен записью АСЕ.
Списки ACL содержат записи, относящиеся к объекту Active Directory в целом, и записи, относящиеся к отдельным атрибутам объекта. Это позволяет администра тору не только указывать, какие пользователи могут видеть данный объект, но и то, какие свойства этого объекта будут видны пользователям. Например, всем пользователям может быть разрешено чтение таких атрибутов, как телефонные но мера и адреса электронной почты других пользователей, но доступ к параметрам безопасности данных открыт только членам группы администраторов система.
Отдельным пользователям может быть разрешена запись в их личные атрибуты, например внесение исправлений в номера их телефонов или адреса электронной почты.
Служба каталогов Active Directory 38 ЧАСТЬ Подробнее об управлении доступом Ч в главе 12 Управление доступом*. Подроб нее о встроенной безопасности объектов Ч в главе 2 Хранение данных в Active Directory*. Подробнее об анонимном доступе для чтения Ч в главе 3 Разрешение имен в Active Directory.
Делегирование административных полномочий Делегирование (delegation) Ч одно из наиболее важных средств безопасности дан ных в Active Directory. Передача полномочий позволяет администратору системы, имеющему более высокий приоритет, передавать определенные права по управле нию контейнерами и поддеревьями отдельным пользователям или группам. Деле гирование избавляет администратора домена от необходимости управлять целыми подмножествами огромной совокупности пользователей.
Записи АСЕ могут предоставлять четко определенные права доступа к объектами в контейнере отдельным пользователям или группам. Эти права распространяются на определенные операции над определенными классами объектов через записи АСЕ списка ACL соответствующего контейнера. Например, чтобы передать пользо вателю с именем James Smith права администрирования в подразделении Corporate Accounting (Бухгалтерия), в список управления доступом ACL контейнера Cor porate Accounting нужно добавить ЛСЕ-записи, указанные в таблице 1-2.
Таблица 1-2. Пример списка управления доступом подразделения АСЕ-запись Участник безопасности Разрешения К каким объектам применяется Allow James Smilh Create, Delete User objects Только данный объект (Создание и удаление (Разрешить) объектов пользователя) Allow James Smith Full control Объект пользователь (Разрешить) (Полный доступ) Allow James Smith Create, Delete User objects Только данный объект (Создание и удаление (Разрешить) объектов пользователя) Allow James Smith Full control Объекты группа* (Полный доступ) (Разрешить) James Smith Set Password Allow Объекты пользователь* (Смена пароля) (Разрешить) Теперь пользователь James Smith получил право создавать новые объекты-пользо ватели и объекты-группы в контейнере Corporate Accounting, а также устанавли вать пароли для уже зарегистрированных пользователей. Однако он не может со здавать объекты других классов и изменять параметры пользователей в других кон тейнерах (если, конечно, в ACL-списках других контейнеров нет соответствующих АСЕ-записей).
Подробнее о делегировании административных полномочий Ч в главе 12 Управ ление доступом. Подробнее о применении делегирования Ч в справочной системе Microsoft Windows 2000 Server.
Логическая структура Active Directory ГЛАВА Наследование Принцип наследования (inheritance) АСЕ-записей позволяет распространять влия ние записей определенного контейнера на все его объекты. Наследование можно совмещать с делегированием и таким образом в одной операции передавать адми нистративные права целому поддереву каталога. Подробнее о наследовании в главе 12 Управление доступом.
Дополнительные материалы Подробнее о DNS Ч в книге Paul Albitz и Cricket Liu DNS and BIND 3-е изд., 1998, Sebastopol, CA: O'Reilly & Associates.
Подробнее о RFC-спецификациях и проектах документов Интернета (Internet Drafts) на Web-странице с/ webresources Ч по ссылке на IETF.
ГЛАВА Хранение данных в Active Directory Служба каталогов состоит из хранилища каталога (directory store) Ч системы хра нения данных каталога - и механизма поиска и выборки данных. Служба катало гов Active DirectoryЩ в Microsoft'81 Windowsо 2000 хранит объекты, которые содер жат сведения о таких реально существующих объектах сети предприятия, относя щихся к одному или более доменам, как пользователи и их группы, компьютеры, приложения, службы, файлы и списки рассылок. Active Directory предоставляет эти сведения пользователям и приложениям.
В этой главе Архитектура Active Directory Храпение данных Установка Active Directory Удаление Active Directory Автоматическая установка и удаление Active Directory См. также Х Подробнее об иерархии Active Directory, системе именования в DNS, розыске контроллеров домена, структуре деревьев и леса Ч в главе 1 Логическая струк тура Active Directory.
Х Подробнзе о межсайтовой и впутрисайтовой репликации Ч в главе 6 Реплика ция Active Directory.
Х Подробнее о строении и модификации схемы Active Directory Ч в главе 4 Схе ма Active Directory*.
Х Подробнее о системе доменных имен DNS Ч в книге Сети TCP/IP. Ресурсы Microsoft Windows 2000 Server (Русская Редакция, 2001).
Хранение данных в Active Directory ГЛАВА Архитектура Active Directory Чтобы понять, как хранятся и обрабатываются данные Active Directory, необходи мо представлять себе, как взаимодействуют отдельные компоненты этой службы каталогов. Первый шаг на этом пути изучение взаимосвязей Active Directory с остальными элементами операционной системы Microsoft Windows 2000 Server.
Active Directory и архитектура Windows Для предоставления приложениям служб операционной системы в Windows используются и комбинируются отдельные модули и режимы. В частности, для от деления платформо-зависимых низкоуровневых процессов от процессов более вы сокого уровня, а также для изоляции приложений от различий аппаратной реали зации и предотвращения прямого доступа из приложений к системному коду и дан ным в Windows 2000 существуют два режима пользовательский (user) и режим ядра (kernel). Все приложения (включая службы) выполняются в отдельном моду ле в пользовательском (непривилегированном) режиме, а системные службы дог тупны им только через интерфейс прикладного программирования (application programming interface, API), предоставляющий ограниченный доступ к системнь м данным. Переход прикладного процесса из пользовательского режима в режим ядра возможен только в отдельных, строго оговоренных защищенной средой операцион ной системы случаях. Завершив работу в режиме ядра, процесс немедленно возвра щается в пользовательский режим. Служба каталогов Active Directory выполняет ся в подсистеме безопасности (security subsystem) пользовательского режима. Мо нитор безопасности (security reference monitor), который выполняется в пользова тельском режиме, представляет собой основной орган, контролирующий соблюде ние правил защиты в подсистеме безопасности. На рис. 2-1 показано место Active Directory в общей структуре Windows 2000.
Тесная связь службы каталогов и служб подсистемы безопасности играет ведущую роль в реализации распределенных систем на базе Windows 2000. Доступ ко всему каталогу возможен только после проверки подлинности (authentication), выполняе мой компонентами подсистемы безопасности, а затем авторизации (authorization) - проверки прав и разрешений на доступ, осуществляемой подсистемой безопас ности совместно с монитором безопасности. Монитор безопасности управляет дос тупом к объектам Active Directory.
Подробнее об операционной системе Windows 2000 Ч в статье Overview of Net working in Windows 2000 Professional (Обзор сетевых технологий в Windows Professional) из Microsoft Windows 2000 Professional Resource Kit. В ней рассмат риваются технологии, лежащие в основе операционных систем Windows 2000 Pro fessional и Windows 2000 Server. Подробнее о проверке подлинности Ч в главе ' Проверка подлинности. Подробнее о разрешениях - и глане 12 Управление до ступом.
ЧАСТЬ 1 Служба каталогов Active Directory Приложение л.Ар. Подсистема /г, ^ Win32 J **"] безопасности [Active i f N U Directory Подсистема !
1 Д^ спетчер РпР Х^w* v_ ^^ у 1 Win Ч_ А Пользовательский t режим ^ Режим ядра ' Исполнительные службы Диспетчер Диспетчер Монитор Диспетчер Диспетчер )тчер Диспетчер Диспетчер Дисп вызова ввода/ безопас- питания окон ити процессов рпр внутренних вывода ности процедур (IPC) Драйверы Файловые графических Диспетчер объектов системы Драйверы устройств Микроядро Аппаратно-зависимый уровень (HAL) Оборудование Рис. 2-1. Место Active Directory в общей структуре операционной системы Windows Архитектура подсистемы безопасности Модель безопасности Windows 2000 состоит и;
? нескольких компонентов безопас ности, которые следят за тем, чтобы приложения не получили доступ к ресурсам без предварительной проверки подлинности и авторизации. Компоненты подсис темы безопасности выполняются в контексте процесса Lsass.exe. Они перечислены далее:
Х администратор локальной безопасности (Local Security Authority, LSA);
Х служба Net Logon (Сетевой вход в систему);
Х служба SAM (Диспетчер учетных записей безопасности);
Х служба LSA Server (служба сервера LSA);
Х протокол SSL (Secure Sockets Layer);
Х протоколы проверки подлинности Kerberos v5 и NTLM.
Подсистема безопасности контролирует политику безопасности и учетные записи в системе. Подсистема безопасности контроллера домена компьютера, на кото ром выполняется служба каталогов Active Directory Ч управляет политиками и учетными записями всего домена. Данные политик и учетных записей хранятся в базе данных Active Directory.
Хранение данных в Active Directory ГЛАВА 2 Администратор локальной безопасности (Local Security Authority, LSA) Ч это за щищенная подсистема, которая поддерживает сведения обо всех параметрах локаль ной безопасности системы (в совокупности они и составляют политику локальной безопасности) и предоставляет службы, ответственные за прямое и обратное пре образование имен и идентификаторов.
В общем случае LSA выполняет следующие функции:
Х управляет политикой локальной безопасности;
Х поддерживает службы интерактивной проверки (то есть действующей при вхо де в локальную систему) подлинности пользователей;
Х создает маркеры, содержащие сведения о пользователях и их группах, а также информацию об их привилегиях. После входа в систему пользователи различа ются по идентификаторам безопасности (security ID, SID) и маркерам доступ;
!;
Х управляет политикой аудита и ее параметрами. LSA отвечает за регистрацию в соответствующем системном журнале сообщений аудита, инициированных мо нитором безопасности, В политике локальной безопасности определены следующие параметры:
Х каким доменам доверяется проверка подлинности при входе в систему;
Х кто допущен к доступу в систему и порядок этого доступа (например, в инте рактивном режиме, по сети, или как служба);
Х кому предоставляются привилегии;
Х каков порядок аудита безопасности;
Х каковы выделяемые но умолчанию квоты памяти (выгружаемый и невыгружае мый пулы памяти).
На рис. 2-2 показано взаимодействие Active Directory и подсистемы локальной бе зопасности безопасности LSA (Lsass.exe). Подсистема безопасности LSA предостав ляет службы, работающие как в режиме ядра, так и в пользовательском режиме и выполняющие проверку допустимости доступа к объектам, привилегий пользова телей и генерацию сообщений аудита.
Далее перечислены компоненты LSA.
Netlogon.dll. Служба Net Logon (Сетевой вход в систему), обеспечивающая безо пасный капал между компьютером и контроллером домена. Она передает по безо пасному каналу на контроллер домена идентификационные данные пользователя и возвращает его доменные идентификаторы безопасности и права. В Windows для разрешения доменных имен в IP-адреса служба Net Logon использует систему DNS. Net Logon Ч это протокол репликации основных и резервных контроллеров домена под управлением Microsoft Windows NT версии 4.0.
Msvl_0.dll. Протокол NTLM, применяемый для проверки подлинности клиентов, не поддерживающих Kerberos.
Scharmel.dll. Протокол SSL (Secure Sockets Layer), позволяющий проводить про верку подлинности через безопасное закрытое, а не небезопасное открытое соеди нение путем создания защищенного канала обмена.
Kerberos.dll. Протокол проверки подлинности Kerberos v5.
Служба каталогов Active Directory 44 ЧАСТЬ Kdcsvc.dll. Служба центра распространения ключей (Key Distribution Centre, KDC) и протоколе Kcrbcros v5, ответственная за предоставление клиентам билетов TGT.
Lsasrv.dll. Служба сервера LSA, проводящая в жизнь политику безопасности.
Samsrv.dll. Диспетчер учетных записей безопасности (SAM), который хранит учет ные записи локальной безопасности, реализует локальную политику безопасности и поддерживает API-интерфейсы.
Ntdsa.dll. Модуль службы каталогов, поддерживающий протокол репликации Windows 2000 и протокол LDAP (Lightweight Directory Access Protocol) и управ ляющий разделами данных.
Secur32.dll. Поставщик многосторонней проверки подлинности, объединяющий все остальные компоненты подсистемы безопасности.
Подробнее о LSA и его компонентах Ч в главе 11 Проверка подлинности. Под робнее об управлении доступом Ч в главе 12 Управление доступом.
Для компьютеров, не являющихся контроллерами доменов SSL KDC NTLM Kerberos Schannel.dll Kdcsvc.dll Msv1 O.dll Kerberos.dll I LPC-вшовГ Secur32.dl RPC Netlogon RPC LSASRV Lsasrv.dll Netlogon.dll RPC Диспетчер учетных записей безопасности Samsrv.dl Для компьютеров, не яаляющихся Служба каталогов Ntdsa.dll контроллерами доменов Реестр Подмножество реплицируемых данных Рис. 2-2. Взаимодествие Active Directory и подсистемы локальной безопасности LSA (Lsass.exe) Архитектура службы каталогов Службу каталогов A c t i v e Directory можно представить в виде многоуровневой структуры, в которой отдельные урошш состоят из процессов сервера, предостав ляющих службы каталогов клиентским приложениям. Active Directory состоит из трех уровней служб и нескольких интерфейсов и протоколов, которые в совокун Хранение данных в Active Directory ГЛАВА 2 ности и предоставляют полный спектр служб каталогов. Три уровня служб содер жат все данные, необходимые для нахождения записей в базе данных каталога.
Выше уровней служб в этой архитектуре находятся протоколы и API-интерфейсы, которые обеспечивают взаимодействие между клиентами и службами каталогов или при репликации между службами каталогов, На рис. 2-3 показаны уровни служба Active Directory и их интерфейсы и протоко лы. Стрелками отмечены способы доступа клиентов к Active Directory. Клиенты LDAP и Messaging A P I (MAPI) обращаются к каталогу, вызывая функции [одно сторонние стрелки в направлении агента системы каталогов (directory system agent, DSA)]. SAM существует в виде отдельной динамически подключаемой биб лиотеки (DLL) и может вызывать только точки входа, экспортируемые DLL-биб лиотекой агента системы каталогов Ч Ntdsa.dll. Все другие компоненты, за исклю чением ядра базы данных Extensible Storage Engine (Esent.dll), расположены в си мой Ntdsa.dll и связаны с вызываемыми ими функциями. Таким образом, все три DLL-библиотеки связаны между собой и находятся в постоянном взаимодействии.
Репликация резервного Транспорты Функции Net контроллера Клиенты ЮАР, Клиенты репликации API-интерфейса домена ADSI MS Outlook [RPC, SMTP, IP) в Windows NT 4.0 Windows NT 4. или MS Outlook Агент системы каталогов (DSA) Уровень базы данных Extensible storage engine (ESE) NTFS Рис. 2-3. Уровни служб и агенты интерфейсов Active Directory Далее перечислены основные службы-компоненты Active Directory.
Х Агент системы каталогов формирует иерархию каталога на основе отношений родитель Ч потомок* и обеспечивает API для запросов на доступ к каталогу Х Уровень базы данных Ч это уровень абстрагирования между базой данных и приложениями. Прикладные программы никогда не обращаются напрямую к базе данных только через уровень базы данных.
Х Extensible storage engine (ESE) ядро базы данных Active Directory, работаю щее непосредственно с отдельными записями хранилища каталога, различает объекты но атрибуту относительного составного имени.
Х Хранилище данных (файл базы данных Ntds.dit). С ним работает только ядро базы данных Ч ESE. Обращаться напрямую к этому файлу можно посредством Служба каталогов Active Directory 46 ЧАСТЬ служебной программы командной строки Ntdsutil. (Чтобы наладить доступ к Netdom, Вам придется установить служебные программы, хранящиеся в папке Support\Tools на компакт-диске с операционной системой Windows 2000 Server. Для этого достаточно дважды щелкнуть значок Setup. Подробнее об установке и исполь зовании служебных программ Windows 2000 и справочной системы служебных про грамм Microsoft Windows 2000 - в файле Sreadme.doc в этой же папке.) Подробнее об использовании служебной программы Ntdsutil Ч в приложении В Ntdsutil.exe Ч служебная программа диагностики Active Directory и в главе Выявление и устранение неполадок, а также восстановление Active Directory, а также Ч в справочной системе служебных программ Windows 2000.
Клиенты получают доступ к Active Directory по одному из перечисленных далее и предоставляемых Active Directory механизмов.
Х LDAP/ADSI. Клиенты, поддерживающие протокол LDAP, используют его для доступа к агенту системы каталогов. LDAP также применяется в ядре ESE, встроенном в Microsoft Exchange Server версии 5.5 (и более ранних) и исполь зуемом утим приложением для обмена сообщениями между клиентами и серве ром и для обеспечения коллективной работы. Active Directory поддерживает LDAPvS (RFC 2251) и LDAPv2 (RFC 1777). Клиенты под управлением Win dows 2000 (а также под управлением Microsoft Windows 98 или Microsoft Windows 95 с установленным компонентом клиентского доступа к Active Direc tory) подключаются к агенту системы каталогов по протоколу LDAPv3. Интер фейсы службы каталогов Active Directory (Active Directory Service Interfaces, ADSI) служат для абстрагирования от LDAP API, предоставляя СОМ-интер фейсы для взаимодействия с Active Directory. Однако нужно иметь в виду, что в Active Directory используется только LDAP. LDAP API является частью WIdap32.dll.
Х MAPI. При обмене сообщениями и коллективной работе клиенты Microsoft Outlook подключаются к агенту системы каталогов по механизму вызова уда ленных процедур MAPI через интерфейс средства доступа к Адресной книге (Address Book).
Х SAM. Клиенты под управлением Windows NT 4.0 или более ранних версий под ключаются к агенту системы каталогов (directory system agent, DSA) через ин терфейс SAM. Репликация данных с резервных контроллеров в домене смешан ного режима также выполняется через интерфейс SAM.
Х REPL (репликация). В процессе репликации каталогов агенты систем катало гов Active Directory взаимодействуют через специальный RPC-интерфейс.
Агент системы каталогов Агент системы каталогов (directory system agent, DSA) Ч это процесс, который обеспечивает доступ к хранилищу - физическому месту хранения базы данных службы каталогов на жестком диске. DSA процесс сервера, который запускает экземпляр службы каталогов. После подключения (привязки) к DSA через один из доступных интерфейсов клиенты могут проводить поиск, считывать или записы вать объекты и их атрибуты в Active Directory.
Пространство имен Active Directory разбито на разделы. Это позволяет отдельным контроллерам домена не хранить полный каталог. Каждый DSA содержит по край ней мере один раздел каталога Windows 2000 с данными своего домена (такими, как ГЛАВА 2 Хранение данных в Active Directory учетные записи пользователей, групп и подразделений) и два внедоменных раздела каталога с данными, относящимися ко всему лесу, а именно схему и конфигурацию.
Далее перечислены и описаны функции, выполняемые уровнем DSA, Идентификация объектов. У каждого объекта Active Directory есть постоянный, уникальный в глобальном масштабе идентификатор (GUID), который связан с не сколькими формами строкового представления имени объекта (имя учетной зате ей безопасности в SAM, основное имя пользователя, составное имя), а также с иден тификатором безопасности. Эти имена объекта и идентификатор безопасности не постоянны и могут изменяться, поэтому для создания постоянных ссылок на объект применяется GUID. Имя объекта служит для его отображения в графическом ин терфейсе и представления его места в иерархии;
идентификатор безопасности ну жен для управления доступом. Агент системы каталогов (DSA) поддерживает вза имосоответствие между GUID объекта и его именем и идентификатором безопас ности при их изменении.
Реализация изменений схемы. В среде с несколькими хозяевами изменение объек та схемы в одной реплике способно вызвать его несогласованность с уже существу ющим объектами этой же реплики, а также с объектами других реплик. В Win dows 2000 изменение схемы выполняется в монопольном режиме как операция оди ночного хозяина, поэтому, если изменение не вызывает конфликта в данной репли ке, оно считается приемлемым и для всех остальных реплик. По этой причине в процессе репликации изменений никакая проверка схемы не проводится и не нуж но ждать завершения репликации перед созданием экземпляра нового класса или атрибута, Реализация управления доступом. Агент системы каталогов контролирует огра ничения безопасности в каталоге. Значения идентификаторов безопасности (SID) в маркере доступа считываются на уровне DSA.
Поддержка репликации. DSA перехватывает уведомления репликации. Для кор ректной работы службы каталогов требуется, чтобы абсолютно все изменения объектов в обязательном порядке проходили через соответствующую процедуру службы каталогов.
Перенаправление. DSA управляет информацией об иерархии каталогов (иногда ее называют знание), которую он получает от уровня базы данных. Агент системы каталогов отвечает за перекрестные ссылки на объекты домена Active Directory вверх и вниз по иерархии, а также на другие иерархии доменов.
Уровень базы данных Уровень базы данных (database layer) обеспечивает объектное представление инфор мации базы данных в соответствии с семантикой схемы, таким образом скрывая от вышележащих уровней службы каталогов строение системы базы данных. Уровень базы данных является внутренним интерфейсом, и запросы на доступ к базе дан ных никогда не попадают непосредственно в ESE они обязательно проходят чс рез уровень базы данных, Active Directory поддерживает иерархическое пространство имен, в котором объек ты идентифицируются по их составным именам (distinguished name). Индивидуаль ный атрибут именования, или относительное составное имя (relative distinguished name, RID), унржалсн в пределах родительского контейнера объектов. Составное имя объекта создается на основе его относительного составного имени и цепочь.и Служба каталогов Active Directory 48 ЧАСТЬ имен последовательности родительских объектов. В базе данных хранятся относи тельные составные имена каждого из объектов вместе со ссылкой на родительский объект. Передвигаясь но этим ссылкам, уровень базы данных объединяет инди видуальные имена и формирует составное имя.
Данные, полностью описывающие объект, существуют в виде набора атрибутов, хранимых в столбцах базы данных. Уровень базы данных обеспечивает создание, поиск и удаление записей, отдельных атрибутов и их значений. Для получения све дений об атрибутах он использует кэш схемы (структуру в памяти* в составе аген та системы каталогов). Подробнее о кэше схемы Ч в главе 4 Схема Active Direc tory. Подробнее о составных именах и относительных составных именах - в гла ве 1 Логическая структура Active Directory.
Extensible Storage Engine Работа Active Directory основана на механизме индексно-последовательного досту па (Indexed Sequential Access Method, ISAM) Ч версии базы данных ESE, исполь зуемой для обмена сообщениями и автоматизации коллективной работы R Mic rosoftо Exchange Server версии 5.5. В Windows 2000 эта база данных находится в файле Escnt.dll.
В ESE хранятся все объекты Active Directory. Ядро ESE способно поддерживать базу данных объемом до 16 Тб, то есть многие миллионы объектов в расчете на домен.
Примечание При тестировании базы данных количество объектов достигало 40 мил лионов па домен.
Далее перечислены характеристики ESE, которые позволили использовать его для хранения данных Active Directory:
Х использование ESE в службе каталогов и хранилище данных в Exchange Server версии 5.5;
Х поддержка индексации;
Х поддержка многозначных атрибутов;
Х поддержка механизма транзакций, обеспечивающего устойчивость и целостнос ти данных при сбоях;
Х поддержка горячего архивирования во время работы контроллера домена;
Х поддержка разреженных (sparse) строк Ч то есть таких, в которых у многих свойств нет значений.
В схеме Active Directory определены все обязательные и дополнительные атрибуты объектов. При хранении объектов ESE резервирует память только для атрибутов, имеющих определенное значение, а не для всех допустимых атрибутов объекта. На пример, если в схеме определено, что у объекта пользователь Ч 50 атрибутов, а у реально существующего объекта этого типа заданы значения только четырех атрибу тов, то память выделяется только для хранения этих четырех значений, а дополни тельный объем памяти будет выделяться по мере появления новых значений.
В Esent.dll реализованы поиск и просмотр результатов поиска в базе данных. Кро ме того ESE может хранить атрибуты со многими значениями. Например, не нуж но создавать дополнительные атрибуты, если Вы указываете несколько номеров телефонов для определенного пользователя.
Хранение данных в Active Directory ГЛАВА Протоколы и интерфейсы Active Directory На схеме архитектуры Active Directory (рис. 2-3) показаны четыре способа доступа к A c t i v e Directory: LDAP/ADSI (Lightweight Directory Access Protocol, Active Directory Service Interfaces), REPL (репликация), SAM (Security Accounts Manager) и MAPI (Messaging API). В них используются различные наборы протоколов и функций API-интерфейсов для связи со службой каталогов. В таблице 2-1 пере числены API-интерфейсы, поддерживаемые Active Directory, которые разработчи ки могут использовать, для взаимодействия с Active Directory и ее ресурсами.
Таблица 2-1. API-интерфейсы Active Directory Описание Имя API LDAP С API В соответствии с документом RFC 1823 для LDAPv3, LDAPC API что API-интерфейс языка С для протокола LDAP ADSI СОМ-интерфейс с Active Directory, который скрывает подробности протокола LDAP. ADST предоставляет доступ к службам и данным Active Directory из поддерживающих каталоги приложений. ADSI поддерживает многие языки программирования, в том числе Microsoft" V i s u a l Basic", С и Microsoft"' Visual C++"". ADSI также дос тупен из сервера сценариев Windows (Windows Script Host, WSH) MAPI API-интерфейс обмена сообщениями, поддерживаемый для совмести мости г клиентскими приложениями Microsoft' Kxchangt? Client и Адресной к н и г и Outlook (Outlook Address Book) Windows NT 4.0 Функции сетевого API системы Windows NT 4.0 (Net API), использ\ с мыс клиентами под управлением Windows NT 4,0 для доступа к A c t i v e Directory через SAM SAM API-интерфейсы взаимосвязи с интерфейсами прикладного програм мирования DSA Для взаимодействия с Active Directory эти A P I применяют способы доступа, опи санные в таблице 2-2.
Таблица 2-2. Способы доступа к Active Directory Способ доступа Описание LDAP Основной протокол, поддерживаемый Active Directory, о п и с а н н ы й и RFC 2251 (LDAPv3) и RFC 1777 (LDAPv2) MAPI RFC RPC-HHiH^^efifbi, применяемые MAPI-провайдером Адресной книги RFC-pen л икания RPC-интерфейсы, используемые для репликации Active Directory nn IP-транспорту внутри и между сайтами Протокол репликации, применяемый в Active Directory для реплика Репликация по протоколу SMTP ции на базе сообщений но IP-транспорту только между сайтами (Simple Mail Transfer Protocol) Подробнее об удаленном вызове процедур (RPC) Ч в книге Сети TCP/IP. Ресур сы Microsoft Windows 2000 Server (Русская Редакция, 2001), LDAP LDAP (Lightweight Directory Access Protocol) - это одновременно и протокол, и API, что обусловлено как моделью клиент-серверного механизма службы катало гов, так и информационной моделью, которая определяет природу объектов служ бы каталогов на базе LDAP Служба каталогов Active Directory 50 ЧАСТЬ L D A P - основной протокол Active Directory, точнее, это единственный протокол обмена, который Active Directory поддерживает. Это предпочтительный и наибо лее популярный способ взаимодействия с Active Directory. LDAP API обеспечива ет доступ к протоколу LDAP, a ADSI эти СОМ-интерфейс Active Directory, рабо тающий по протоколу LDAP.
Примечание LDAP Ч это протокол обмена (wire protocol): он управляет инкапсу ляцией и пересылкой запросов между клиентом и сервером.
Протокол LDAP Протокол службы каталогов LDAP определяет способ связи каталогов. Он работа ет поверх TCP/IP или UDP, протоколу без создания соединения. LDAP позволяет клиентам запрашивать, создавать, обновлять и удалять информацию, хранимую в базе данных службы каталогов по TCP-соединению через стандартный порт 389.
Первоначально LDAP применялся в клиентской части каталогов на базе Х.500.
LDAPvS считается промышленным стандартом, он годен для любой службы ката логов, поддерживающей протокол LDAP (в том числе и в Active Directory). Active Directory поддерживает стандарты LDAPv2 (RFC 1777) и LDAPv3 (RFC 2251).
Примечание Active Directory в Windows 2000 не поддерживает протоколы Х. [которые включают Directory Access Protocol (DAP), Directory System Protocol (DSP), Directory Information Shadowing Protocol (DISP) и Directory Operational Binding Management Protocol (DOP)]. LDAP поддерживает наиболее важные фун кции, существующие в DAP, и работает поверх TCP/IP, не создавая дополнитель ных издержек на лупаковку при пересылке по TCP/IP. Эта лупаковка необходи ма для протоколов OS1.
Подробнее о TCP/IP Ч в книге Сети TCP/IP. Ресурсы Microsoft Windows Server (Русская Редакция, 2001).
Модель службы каталогов LDAP Служба каталогов LDAP базируется на модели клиент Ч сервер: данные, из ко торых и состоит дерево каталогов, хранятся на одном или нескольких LDAP-cep верах, к которым обращаются LDAP-клиенты для получения информации или вы полнения определенных операций. В ответ на клиентский запрос сервер может вы полнить затребованные действия или, если это невозможно, перенаправить клиент на другой LDAP-сервер, способный удовлетворить запрос. При подключении к оп ределенному дереву LDAP-каталогов совершенно неважно, с каким сервером LDAP соединился клиент;
имя объекта не зависит от сервера Ч все серверы ссылаются на один и тот же объект [иногда его называют запись (entry) в LDAP]. Это важное свойство глобальной службы каталогов.
Информационная модель LDAP Информационная модель LDAP базируется на записях, которые содержат инфор мацию об объектах (например, пользователях или компьютерах). В Active Directory LDAP-записи называются объектами. Записи, в свою очередь, состоят из атрибу тов, у каждого из которых имеется свой тип и одно или более значений. Форма допустимых значений атрибута определена в его синтаксисе (например, строка сим волов Unicode, двоичное значение, число типа integer и т. п.).
Хранение данных в Active Directory ГЛАВА Далее перечислены основные характеристики протокола LDAP;
Х протокол работает непосредственно поверх TCP в случае транспорта с создани ем соединения (обязательное подтверждение получения данных) или поверх UDP для транспорта без создагтия соединения;
Х большинство передаваемых по протоколу данных имеет вид обычных строк (на пример, составные имена);
Х клиенты могут получать в ответ на свой запрос перенаправления на другие сер веры;
Х для обеспечения дополнительных функций безопасности совместно с LDAP ис пользуются механизмы SASL (Simple Authentication and Security Layer);
Х формат значений атрибутов и составных имен можно привести к стандартному формату, применяя набор из 10 646 символов ISO;
Х протокол разрешено расширять для поддержки новых операций, а для расшире ния существующих операций допустимо применять элементы управления;
Х для клиентов схема публикуется в атрибуте корня rootDSE. (Подробнее о схе ме - - в главе 4 Схема Active Directory. Подробнее о корневом объекте rootDSE Ч в разделе RootDSE далее в этой главе.) Подробнее о протоколе LDAPvS Ч на Web-странице Web Resources по адресу /windows.microsoft.com/windows2000/reskit/webresources, ссылка RFC, далее ссыл ки RFC 2251 Lightweight Directory Access Protocol (v3)>, RFC 2252 Attribu e Syntax Definitions, RFC 2253 UTF-8 String Representation of Distinguished Names*, RFC 225-1 The String Representation of LDAP Search Filters:*, RFC The LDAP URL Format*, RFC 2256 A Summary of the X.500(96) User Schema for Use with LDAPvS и RFC 2247 Using Domains in LDAP/X.500 Distinguished Names. Подробнее об относящихся к LDAP документах RFC Ч в приложении Б Документы RFC, относящиеся к протоколу LDAP.
Различия между LDAPv2 и LDAPvS /[алее перечислены функции, обеспечиваемые LDAPvS, но не поддерживаемые про токолом LDAPv2:
Х использование формата UTF-8 во всех строковых атрибутах для поддержки рас ширенных наборов символов. Ответы на запросы клиентов Active Directory во i вращает в формате UTF-8;
Х наличие операционных (служебных) атрибутов, поддерживаемых каталогом для своих собственных нужд (например, для регистрации даты и времени измене ния другого атрибута);
Х перенаправления (referrals), которые позволяют серверу переадресовать клиент на другой сервер, где может находиться нужная ему информация. LDAP-сервер возвращает клиенту перенаправление, если не в состоянии выполнить запрос, но знает, какой из серверов способен это сделать;
Х публикация схемы в каталоге, что позволяет клиенту узнавать, какие классы объектов и атрибуты поддерживает сервер;
Х дополнительные элементы управления для поиска, в том числе сортировка и по страничный просмотр результатов, а также определяемые клиентом элементы управления поиском и сортировкой;
Служба каталогов Active Directory 52 ЧАСТЬ Х большая степень безопасности, обеспеченная механизмом SASL;
Х расширение перечня поддерживаемых операций бея изменения версии протокола.
LDAPv3 обеспечивает обратную совместимость с LDAPv2. Обязательное требова ние, предъявляемое к серверу LDAPvH поддержка клиентов LDAPv2.
LDAP API В отличие от большинства других протоколов Интернета, протокол LDAP облада ет API-интерфейсом, упрощающим создание приложений для Интернета. LDAP API Ч это интерфейс прикладного программирования на языке С для протокола LDAP. В RFC 1823 описаны интерфейсы LDAP API, которые должен поддерживать клиент, чтобы взаимодействовать со службой каталогов, поддерживающей LDAP, Это набор относительно простых функций, поддерживающих как синхронные, так и асинхронные запросы к серверу.
Microsoft реализовала LDAP API в файле Wldap32.dll, который также называют LDAP С или C-binding LDAP. Приложения, написанные в LDAP, совместимы только со службами каталога LDAP. ADSI-интерфейс, предоставляющий СОМ-ин терфейс к Active Directory, размешен поверх LDAP и представляет собой самый простой в использовании способ доступа к Active Directory по этому протоколу. Тем не менее для обеспечения доступа к каталогам Active Directory также полностью поддерживает LDAP API-функции.
Подробнее о LDAP API и программировании в LDAP Ч на Web-странице Web Resources по адресу webresources, ссылка Microsoft Platform SDK. Подробнее о перенаправлениях LDAP Ч в главе 3 Разрешение имен в Active Directory*. Подробнее о схеме в главе Схема Active Directory*..
ADSI ADSI (Active Directory Service Interfaces) Ч основной и рекомендуемый API-ин терфейс Active Directory. ADSI представляет объекты каталогов Active Directory в виде СОМ-объектов, а управление объектом осуществляется с использованием ме тодов СОМ-интерфейсов. Провайдеры ADSI (ADST providers) представляют объек ты ADSI в соответствующем пространстве имен, то есть они преобразуют вызовы СОМ-интерфейсов к запросам API конкретной службы каталогов.
Провайдер ADSI LDAP Провайдер ADSI LDAP выполняется на клиенте ADSI и обеспечивает доступ к Active Directory и/или другим службам LDAP-каталогов. Он совместим с любыми LDAP-серверами, которые поддерживают по крайней мере LDAPv2. Кроме служ бы каталогов Active Directory в Windows 2000, LDAP-провайдер обеспечивает дос туп к:
Х Netscape Directory Server;
Х Exchange Server 5.x.;
Х Microsoft Commercial Internet System (MCIS) Address Book Server;
Х University of Michigan Stand-alone LDAP Directory (SLAPD) Server;
Х другим серверам каталогов Интернета (например, Ldap.yahoo.com).
Хранение данных в Active Directory ГЛАВА Примечание Провайдер WinNT ADSI поддерживает доступ к каталогам Microsoftо Windows NTо версий 3.x и 4.0, обеспечивая связь с основными и резервными кон троллерами доменов Windows NT 4.0. Другие провайдеры содержат NDS для дис тупа к каталогам Novell Directory Services, NWCOMPAT Ч для дост}-па к катало гам Novell NetWare версий 3.x и 4.x, и IIS Ч для доступа к каталогам данных в Internet Information Services (IIS) no протоколу HTTP.
Подробнее о ADSI на Web-странице Web Resources no адресу rosoft.com/windows2000/reskit/webresources, ссылка Microsoft Platform SDK.
Репликация Active Directory Репликация в Active Directory выполняется по протоколам транспорта репликации, ко торые представлены элементом REPL на схеме архитектуры Active Directory (рис. 2-3).
Для репликации внутри сайта используются транспортные протоколы тина RPC поверх IP, а для межсайтовой репликации применяются два транспортных прото кола: IP (RPC поверх IP) и Simple Mail Transfer Protocol (SMTP поверх IP).
Примечание В экранных формах Windows 2000 оснастки Active Directory Sites and Services (Active Directory Ч сайты и службы) все типы внутрисайтовых подключе ний отображаются как RPC, а межсайтовые подключения Ч как IP (RPC поверх IP) или SMTP (SMTP поверх IP). Такое правило позволяет различать внутри и межсайтовый транспорты типа RPC поверх IP.
Межсайтовую RPC-репликацию разрешается планировать (то есть создавать рис писание репликации), а реплицируемые данные Б этом случае сжимаются. Для реп ликации в пределах сайта всегда используется RPC, а пересылаемые данные не сжимаются. Таким образом, существуют три типа связей для репликации катало гов Windows:
Х надежная быстрая связь (лRPC поверх IP для репликации всех разделов ката логов внутри сайта);
Х синхронная медленная связь типа точка точка (лRPC поверх IP для реп ликации всех разделов каталогов между сайтами);
Х почтовая асинхронная связь (лSMTP поверх IP для репликации только недо менных разделов каталогов между сайтами), На каждом DSA действует отдельный поток, обслуживающий получение (и внесе ние в локальную базу данных) изменений от других серверов по механизму синх ронного (RPC) или асинхронного (для межсайтовых подключений) транспорта.
Выбор транспорта определен в соответствующих объектах подключения (класс nTDS'Connection), автоматически создаваемых службой проверки согласованности знаний (Knowledge Consistency Checker, KCC). Объекты подключения можно со здавать вручную в оснастке Active Directory Sites and Services (Active Directory сайты и службы). И синхронные, и асинхронные транспорты работают по механиз му запрос Ч ответ.
Подробнее о репликации в Active Directory Ч в главе 6 Репликация Active Directory, MAPI Для обмена сообщениями клиенты получают доступ к службе каталогов Exchange Server с помощью MAPI-провайдеров Адресной книги (Address Book). Для обеспе Служба каталогов Active Directory 54 ЧАСТЬ чеиия доступа уже существующим клиентам Active Directory поддерживает для ад ресной книги провайдера MAPI-RFC (например, для нахождения номера телефона пользователя).
Примечание В Windows 2000 MAPI-провайдер адресной книги существует исклю чительно для совместимости с MAPI-клиентами, например с Outlook.
SAM SAM (Security Accounts Manager) Ч это защищенная подсистема, управляющая данными учетных записей пользователей и групп. В Windows 2000 учетные записи безопасности рабочих станций SAM хранит в реестре локального компьютера, а учетные записи безопасности контроллера домена Ч в Active Directory. В Win dows NT'S.О и локальные, и доменные учетные записи безопасности находятся в системном реестре.
Работа SAM в смешанном и основном режимах Windows 2000 поддерживает интерфейсы безопасности Win32 API как в смешан ном, так и в основном режиме.
В доменах смешанного режима, где возможно наличие резервных контроллеров доменов под управлением Windows NT 4.0, клиенты SAM под управлением Mic rosoft Windows NT версий 3.51 или 4.0 подключаются к SAM-серверу через интер фейсы SAM API. Последние используются для репликации и проверки подлинно сти по базе данных диспетчера учетных записей безопасности.
В доменах основного режима нет контроллеров домена под управлением Win dows NT 4.0, но возможны клиенты под управлением Windows 95, Windows 98, Windows NT 3.x или Windows NT -i.O. Такие клиенты иногда применяют эти же ин терфейсы SAM API для проверки подлинности.
Клиент SAM и операции сервера Большинство операций в SAM Ч это чтение и запись свойств. В случае учетных записей рабочей станции это чтение и запись в системный реестр. Операции с учетными записями домена выполняются с объектами Active Directory и их свой ствами, хранимыми в столбцах базы данных каталога. Клиент SAM вызывает от крытые процедуры SAM, которые в свою очередь обращаются к внутренним про цедурам, инкапсулирующим RPC. Основная часть работы на сервере выполняется внутренними процедурами SAM.
В Windows NT 4.0 все операции доступа к учетным записям выполняются через внутренние запросы из процедур SAM к базе данных учетных записей, хранящейся в реестре. Windows 2000 позволяет сериеру SAM весьма эффективно выделять дан ные рабочей станции из полной базы данных об учетных записях на контроллере домена и размещать остальные записи в Active Directory, а не в реестре. Логика управления базой данных участников безопасности в Samsrv.dll определяется ро лью компьютера. На контроллере домена Samsrv.dll хранит данные об участниках безопасности в Active Directory, а на остальных компьютерах под управлением Windows 2000 использует базу данных SAM в реестре.
Доступ к данным учетных записей на контроллере домена Windows 2000 обеспечи вается процедурами, представляющими собой часть процесса DSA на сервере. Они называются процедуры в процессе (in-process) на сервере и обеспечивают поиск, чтение и запись объектов службы каталогов.
Хранение данных в Active Directory ГЛАВА 2 На рис. 2-4 показана схема взаимодействия клиентского и серверного процессов SAM и способ хранения доменных и локальных учетных записей. Здесь для сер верного SAM показаны различные варианты логики Samsrv.dll: логики, применяе мой по отношению к контроллеру домена (API каталога), где все учетные записи доменные, и логики, используемой во всех остальных случаях (API реестра), где все учетные записи локальные для данного компьютера.
Клиент Функции Net API-интерфейса в Windows NT 4. (Открытые процедуры SAM) Сервер Внутренние процедуры SAM, инкапсулирующие RPC Samsrv.dll (Закрытые процедуры SAM) Ntdsa.dll (API каталога) База данных База данных ESE реестра Доменные Локальные учетные учетные записи записи Рис. 2-4. Взаимодействие клиентского и серверного процессов SAM и хранение учетных записей Хранение данных Active Directory храпит данные обо всем лесс, то есть понятия каталог и лес фактически означают одно и то же. Несмотря на то, что каталог Ч единственный, данные хранятся в одном или нескольких доменах;
при этом обеспечивается непро тиворечивость данных леса, относящихся ко всем доменам. Компьютеры, на кото рых выполняется Active Directory, называются контроллерами домена, Кроме того, обеспечивается разбиение на разделы и репликация Active Directory.
Поскольку Active Directory способна поддерживать десятки миллионов объектов, она разбивается на логические сегменты. Для обеспечения доступности и поддержки со тен тысяч клиентов каждый логический раздел реплицирует все свои изменения во все остальные контроллеры доменов леса, содержащие реплики этого раздела.
Одни разделы каталога хранят данные конфигурации и схемы, относящиеся ко все му лесу;
другие Ч данные отдельных доменов, такие, как сведения о пользовате Служба каталогов Active Directory 56 ЧАСТЬ лях, группах и подразделениях. Разделы каталогов с данными домена реплициру ются только на контроллеры этого домена. Разделы каталогов с конфигурацией и схемой реплицируются на контроллеры всех доменов. Таким образом, в Active Directory поддерживается логически централизованная, но физически распределен ная база данных. Поскольку конфигурация и схема каждого контроллера домена относятся ко всему лесу, контроллер одного из доменов может перенаправлять зап росы иа контроллеры в любых других доменах, если затребованной информации у него нет. Кроме того, контроллеры домена, выполняющие роль серверов глобаль ного каталога, содержат полную реплику раздела своего домена и частичные реп лики всех остальных доменов леса. Поэтому на контроллере домена Ч сервере гло бального каталога, можно проводить поиск любого объекта леса.
Примечание Разделы каталога и база данных существенно различаются. База дан ных Active Directory не разбита на разделы Ч на разделы поделено только дерево каталогов, которое является логическим представлением данных на контроллере домена.
Далее мы перечислим основные моменты распределения данных Active Directory в дереве каталогов.
Данные, относящиеся к данному домену Х Данные, относящиеся только к данному домену, хранятся в разделе домена.
Х Полная, доступная для записи реплика раздела домена реплицируется на каж дый контроллер домена, а также на все серверы глобального каталога в этом домене.
Данные, относящиеся ко всему лесу Х Данные, относящиеся ко всему лесу, хранятся в двух разделах каталога Ч кон фигурации и схеме. Контейнер конфигурации Ч это объект наивысшего уровня в разделе конфигурации, а контейнер схемы Ч объект наивысшего уровня в раз деле схемы.
Х Полные, доступные для записи реплики разделов конфигурации и схемы реп лицируются на все контроллеры доменов в лесу.
Х В дополнение к полной, доступной для записи реплике отдельного домена (до мена, для которого данный контроллер является полномочным) па серверах гло бального каталога хранятся частичные (доступные только для чтения) реплики всех остальных разделов домена в лесе. Реплики только для чтения в глобаль ном каталоге называются частичными, потому что в них содержатся лишь от дельные атрибуты каждого из объектов.
Примечание При первичной установке Active Directory на компьютер под управ лением Windows 2000 Server каталог создается (то есть в него реплицируются дан ные) из всех полных и частичных реплик. Далее реплицируются только изменения объектов каталога (изменения атрибутов, а также создание и удаление объектов).
Требования к данным, хранящимся в Active Directory Основные требования к данным службы каталогов обусловлены объемом и латент ностью репликации. Объекты Active Directory не должны быть слишком большими, Хранение данных в Active Directory ГЛАВА 2 чтобы не затруднять репликации), и не должны изменяться слишком часто, чтобы очередной корректив успевал попасть во все реплики в лесу. Поэтому недопустимо хранить в Active Directory объемные неструктурированные, а также чаето изменяю щиеся данные.
В общем случае данные, хранимые в Active Directory, должны соответствовать пе речисленным далее требованиям.
Х Данные, реплицируемые на все контроллеры доменов Active Directory должны представлять глобальный интерес.
Х Данные должны обладать четко определенными атрибутами объектов и их се мантикой.
Х Необходимо, чтобы среднее время жизни данных по крайней мере в два pa.ia превышало максимальное время задержки репликации (латентность) в лесе (при этом также учитываются затраты времени на репликацию данных в глобальный каталог). Общее правило таково: если данные могут устареть до завершения цикла репликации или вскоре после него, то они не должны храниться в Active Directory. Ситуация, когда клиенты не успевают обновить данные во время од ного полного цикла репликации во всем домене, не должна быть критичной для клиентов.
Х Значение данные в расчете на атрибут не должно быть большим, иначе при изводительность снизится. Значение атрибута реплицируется как отдельный блок данных;
поэтому атрибут размером несколько мегабайт потребует при пе редаче столько же места в буферах как передающего, так и принимающего до менов. Повышенные требования к буферам обмена в некоторых случаях отри цательно сказываются на производительности контроллера домена.
Ограничения на объем хранимых данных Теоретически число объектов Active Directory не ограничено. База данных Active Directory тестировалась для 40 миллионов объектов. Как показали измерения, вре мя входа в систему отдельного клиента LDAP одинаково как для 10 000 объектов, так и для 100 000 и 1 000 000 объектов - то есть при увеличении базы данных бы стродействие службы каталогов не падает, по крайней мере, значительно.
Примечание В среде смешанного режима, где имеются резервные контроллеры домена под управлением Windows NT ^.0, рекомендуется ограничивать число объек тов участников безопасности до 40 000 в расчете на домен (суммарное число пользо вателей, групп и компьютеров). Такое ограничение определяется емкостью базы данных SAM в Windows NT 4.0. Подробнее о емкости базы данных SAM Ч в книге Microsoft Windows 2000 Server Deployment Planning Guide (Microsoft Press, 2000), Соотношение размера объектов и максимальной длины записи в базе данных Каждый объект в каталоге представлен отдельной записью (или строкой) в 6;
i3e данных, а атрибуты находятся в ее столбцах. Как исключение, значения некоторых атрибутов хранятся отдельно в виде ссылок. Длина записи базы данных ограничен на 800 нессылочными* значениями атрибутов (то есть ссылочные атрибуты не учитываются). (Подробнее о ссылочных атрибутах - в разделе Ссылочные атри буты* далее в этой главе.) Размер объектов не вызывает проблем, если следовать рекомендациям, перечисленным в разделе Требования к данным, хранящимся в Active Directory ранее в этой главе.
Служба каталогов Active Directory 58 ЧАСТЬ Примечание Для повышения производительности контроллера домена рекоменду ется размещать файлы операционной системы Windows 2000, файл базы данных Active Directory (Ntds.dit) и журналы па различных дисках. (Подробнее о работе с дисками в книге Сопровождение сервера. Ресурсы Microsoft Windows Server (Русская Редакция, 2001). Подробнее о размерах страниц базы данных Ч на Web-странице Web Resources по адресу reskit/webresources, ссылка Microsoft Platform SDK.) Сбор мусора При удалении объекты не удаляются физически из базы данных - служба катало гов удаляет большинство их атрибутов, а затем отмечает объект как захороненный (tombstone). Тэг захоронения информирует партнеры репликации о том, что объект удален. Захороненные объекты переносятся в контейнер Deleted Objects, где они остаются, пока процесс сбора мусора не удалит их окончательно. Таким образом, захоронение используется для репликации удаления объектов.
Сбор мусора (garbage collection) Ч это вспомогательный процесс, выполняющий ся на каждом контроллере домена. Он регулярно (по умолчанию каждые 12 часов) удаляет объекты, ставшие ненужными службе каталотов.
Сбор мусора выполняет следующие задачи:
Х удаляет захороненные объекты;
Х дефрагментирует файл базы данных.
Сбор мусора можно настраивать, задавая два значения. Это - атрибуты объекта rn=Directory Service,cn=Windows NT,cnЩServices,cn=Connguration,dc=
Х время жизни захороненного объекта (tombstone lifetime) определяет время в ча сах, когда объект существует в каталоге в виде захороненного, пока его не унич тожит процесс сбора мусора. Это значение устанавливается в атрибуте tombs tone Lifetime, его значение по умолчанию Ч 60 дней, а наименьшее допустимое значение Ч 2 дня;
Х период сбора мусора (garbage collection interval) задает частоту проверки нали чия и удаления захороненных объектов в базе данных и определяется атрибутом garbageCollPeriod. По умолчанию сбор мусора проводится каждые 12 часов, а минимально допустимое значение этого атрибута 1 час. Период нужно настраи вать так, чтобы обеспечить своевременность репликации удаленных объектов.
Примечание Если значения этих двух атрибутов не задать, система присвоит им значения по умолчанию (начальное состояние системы). При попытке установить значения, меньшие определенных в схеме, система все равно присвоит атрибуту наименьшее допустимое значение.
Очень важно, чтобы время жизни захороненного объекта было существенно боль ше средней латентности репликации. Интервал между циклами удаления захоро ненных объектов должен по крайней мере превышать максимальное время распро странения данных по всему лесу. Поскольку время жизни захороненного объекта отсчитывается от момента его логического удаления, а не от времени получения сервером реплики с удаленным объектом, объект уничтожается процессом сбора Хранение данных в Active Directory ГЛАВА мусора примерно одновременно на всех серверах. Если на какой-то из серверов реплика с захороненным объектом не попала, тот не сможет узнать об удалении и изменить свою базу данных. Аналогично при восстановлении контроллера домена из архива, давность которого превышает время жизни захороненного объекта, на контроллере домена будут отсутствовать записи о некоторых удаленных объектах, что нарушит согласованность баз данных контроллеров домена.
Максимальный интервал сбора мусора равняется 1/3 времени жизни захоронен ного объекта (в часах). Таким образом, если значение tombstoneLifetime равно 'iO дням и garbageCollPeriod 300 часам, то фактический период сбора мусора со ставит всего лишь 10 дней, или 240 часов.
Для просмотра и изменения значения этих атрибутов по умолчанию можно вос пользоваться программой ADS1 Edit. Далее показано, как это сделать.
Примечание Чтобы воспользоваться ADSI Edit, Вам придется установить служеб ные программы, хранящиеся в папке Support\Tools на компакт-диске с операцион ной системой Windows 2000 Server. Для этого достаточно дважды щелкнуть значок Setup в этой папке. Подробнее об установке и использовании служебных программ Windows 2000 и справочной системы служебных программ Microsoft Windows - в файле Sreadme.doc R этой же папке.
^ Просмотр или редактирование значений атрибутов в ADSI Edit 1. В меню Start (Пуск) последовательно выберите Programs (Программы), Win dows 2000 Support Tools, Tools, а затем щелкните ADSI Edit.
2. Если в окне не отображен нужный Вам раздел, щелкните правой кнопкой мыши значок Edit ADSI (корень дерева консоли) и в контекстном меню выберите Connect to.
Если в окне Connection не отображен нужный Вам компьютер, в разделе Com 3.
puter щелкните переключатель Select or type a domain controller и выберите или введите имя компьютера.
4. В разделе Connection Point установите переключатель в положение Naming Context.
В списке Naming Context щелкните нужный раздел каталога и затем - ОК.
5.
Примечание В поле Name отображено название выбранного Вами раздела ката лога. Вы можете заменить его более информативным именем.
6. Перейдите к нужному Вам объекту.
7. В диалоговом окне Properties в поле Select which properties to view выберите со списком одно из значений - Optional, Mandatory или Both.
8. В списке Select a property to view выберите нужный атрибут.
9. Чтобы изменить значение атрибута, введите повое значение в поле Edit Attribute.
ОК.
10. Щелкните Set, а затем При работе со свойствами cn=Directory Service,cn=Windows NT,cn=Serviccs,cn=Con figuration,dc=
ЧАСТЬ 1 Служба каталогов Active Directory Подробнее об архивировании и восстановлении Active Directory - в главе 9 Ар хивирование и восстановление данных Active Directory. Подробнее о репликации Ч в главе 6 Репликация Active Directory.
Дефрагментация базы данных При обновлении файла базы данных система применяет самый быстрый способ, но он не самый эффективный с точки зрения использования места на диске. Оптимиза ция хранения данных обеспечивается механизмом дефрагментации (defragmcntation), который реорганизует и сжимает данные. Дефрагментировать файл базы можно сред ствами служебной программы Ntdsutil, причем как когда компьютер выполняет фун кции контроллера домена (в подключенном состоянии), так и когда компьютер ра ботает как изолированный сервер (в автономном состоянии).
Дефрагментация в подключенном состоянии ESE поддерживает дефрагментацию на компьютерах, работающих в качестве кон троллеров домена. При этом оптимизируется размещение страниц в файле данных, но освобожденное пространство в файловую систему не возвращается. ESE регу лярно запускает механизм дефрагментации после сборка мусора. Такая дефраг мептация освобождает пространство, но не уменьшает размер файла базы данных.
Только Дефрагментация в автономном состоянии позволяет получить полное пред ставление о пространстве, занятом файлом базы данных.
Дефрагментация в автономном состоянии Чтобы вернуть освобожденное пространство в файловую систему, необходимо выпол нить дефрагментацию в отключенном состоянии. Она осуществляется в режиме вос становления служб каталога, когда компьютер перезапускается как изолированный сервер и не выполняет функции контроллера домена. В этом режиме для дефрагмен тации файла Ntds.dit можно воспользоваться утилитой Ntdsutil. В процессе дефраг ментации оптимизированная копия файла базы данных помещается в отдельный ка талог. После этого надо заархивировать оригинал Ntds.dit и перенести дефрагмснти рованную копию в текущий рабочий каталог. (Подробнее об использовании Ntdsutil для выполнения дефрагментации в автономном состоянии - в главе 10 Выявление и устранение неполадок, а также восстановление Active Directory, в приложении В Ntdsutil.exe служебная программа диагностики Active Directory, а также в спра вочной системе Microsoft Windows 2000 Support Tools.) Дефрагментацию в автономном состоянии используют также для изучения увели чения объема базы данных путем сравнения начальной и дефрагментированной копий файла. Например, на вновь установленном контроллере домена после пол ной загрузки объектов и дефрагментации файла базы данных в автономном режи ме разница в объеме этих файлов точно покажет пространство, занятое новыми объектами.
Можно заставить DSA в течение сборки мусора записывать в журнал службы ката логов сведения о том, какой объем дискового пространства освободится при деф рагмептации в отключенном состоянии. Для этого надо изменить значение пара метра Garbage Collection в разделе реестра HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics.
Хранение данных в Active Directory ГЛАВА ^ Включение регистрации сведений об объеме дискового пространства, которое будет освобождено дефрагментацией в авгономном режиме 1. В меню Start (Пуск) щелкните Run (Выполнить).
2. Введите:
regedt32.exe или regedit.exe 3. Щелкните ОК.
4. В редакторе системного реестра найдите раздел HKEY_LOCAL_HACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics.
5. Дважды щелкните параметр Garbage Collection.
6. В Regedt32.exe введите 1 в поле Data (Значение) или в Rcgedit.exe введите 1 в поле Data value (Значение).
7. Щелкните ОК и закройте редактор реестра.
Внимание! Не модифицируйте реестр самостоятельно (с помощью редактора реес тра) делайте это лишь в крайнем случае, когда другого выхода нет. В отличие от инструментов управления редактор реестра обходит стандартные средства защиты, призванные не допускать ввода конфликтующих значений параметров, а также спо собных снизить быстродействие системы или разрушить ее. Не исключено, что по следствия прямого редактирования реестра окажутся не такими, как Вы ожидали, и, возможно, Вам придется переустанавливать Windows 2000. Для настройки и кон фигурирования Windows 2000 рекомендуется использовать Control Panel (Панель управления) или Microsoft Management Console (Консоль управления Microsoft).
Перед изменением реестра рекомендуется делать резервную копию. Подробнее о редактировании параметров реестра Ч в справочной системе редактора реестра.
Подробнее о реестре Ч в техническом руководстве Technical Reference Microsoft Windows 2000 Professional Resource Kit (файл Regentry.chm) Чтобы выполнить дефрагментацшо файла базы данных в автономном состоянии запустите контроллер домена в режиме восстановления службы каталогов.
^ Загрузка контроллера домена в режиме восстановления службы каталогов 1. В процессе начальной загрузки в момент выбора операционной системы нажми те F8, чтобы выбрать дополнительные варианты загрузки.
2. В меню Windows 2000 Advanced Options (Memo дополнительных вариантов загрузки Windows 2000) с помощью клавиш со стрелками выберите Directory Services Restore Mode (Восстановление службы каталогов) и нажмите Enter.
Следуйте перечисленным далее рекомендациям по дефрагментации:
Х пользуйтесь дефрагментацией в автономном режиме, только когда известно, что объем базы данных существенно уменьшился (например, если сервер глобаль ного каталога переводится в ранг обычного контроллера домена) или если тре буется освободить пространство для других целей;
Служба каталогов Active Directory 62 ЧАСТЬ Х сохраняйте исходный файл Ntds.dit до успешной перезагрузки контроллера до мена с дсфрагментированной базой данных и удаляйте его, только убедившись в исправности и непротиворечивости нового файла базы данных.
Подробнее о дефрагментации в автономном состоянии Ч в главе 10 Выявление и устранение неполадок, а также восстановление Active Directory*.
Изучая влияние добавления определенного набора объектов на объем базы данных, имейте в виду следующее:
Х сразу (или спустя непродолжительное время) после добавления новых объек том база данных находится во фрагментированном состоянии, поэтому точно оценить пространство, занимаемое ими невозможно;
Х д с фрагментация в подключенном состоянии не уменьшает размер файла базы данных это происходит только R процессе дсфрагментации в отключенном состоянии;
Х если параметр сбора мусора установлен в единицу, то узнать об объеме, кото рый освободится после дефрагмеитации в автономном состоянии можно в жур нале службы каталогов, открыв его в окне Event Viewer (Просмотр событий).
Оценка увеличения объема базы данных Active Directory при добавлении пользователей и подразделений В этой главе рассказывается об изучении и оценке среднего размера объектов Active Directory. Сначала исследовался размер стандартного файла Ntds.dit сразу после повышения роли сервера до контроллера домена.
Внимание! Ntds.dit увеличивается фиксированными порциями, занимая отдельные страницы, что позволяет избежать их разбиения. Поэтому при добавлении объек тов размер базы данных кажется больше, чем на самом деле.
Размер открытого файла базы данных не обновляется. Так как Active Directory дер жит этот файл постоянно открытым, а также потому что в подключенном состоя нии файл базы данных никогда не сжимается, при перезапуске контроллера доме на сведения о размере файла, предоставляемые Windows 2000, всегда преувеличе ны. Однако сведения о наличии свободного пространства на диске отображаются верно. Таким образом, вычтя его Вы можете узнать фактический размер файла.
Чтобы оценить размер данных вместе с индексами включите в реестре регистрацию в журнале сведений о дисковом пространстве, которое может быть освобождено при дефрагментации (см. инструкции Включение регистрации сведений об объеме дис кового пространства, которое будет освобождено дефрагментацией в автономном ре жиме ранее в этой главе) и воспользуйтесь утилитой Ntdsutil для уплотнения (деф рагмептации) базы данных в автономном состоянии. (Подробнее об использовании Ntdsutil для выполнения дефрагментации в автономном режиме Ч в главе 10 Выяв ление и устранение неполадок, а также восстановление Active Directory и приложе нии В Ntdsutil.exe - служебная программа диагностики Active Directory.) В таблице 2-3 показан средний объем, занимаемый записями пользователей, под разделений и атрибутов. Вам эти числа пригодятся при оценке размера файла базы данных.
ГЛАВА 2 Хранение данных в Active Directory Таблица 2-3. Средний объем дискового пространства, необходимого для хранения отдельных объектов Active Directory Объект Приблизительный объем занимаемого дискового пространства 3,7кб Пользователь Подразделение 1,1 Кб Атрибут (10 байт) 100 байт Исследование размера базы данных каталога Мы исследовали размер базы данных двумя способами. Первый способ таков: в базу данных загружается множество одинаковых объектов и контролируется возраста ние ее объема в зависимости от типа объектов. Во второй серии испытаний загру жалась типовая база данных предприятия, содержащая объекты пользователей и групп и общие файлы;
в дальнейшем в нее добавлялись новые записи порциями но 100 000 объектов, что позволило оценить размер базы данных в небольших, сред них и крупных компаниях.
В большинстве испытаний загрузка проводилась в несколько этапов. Сначала мы создавали пустую базу данных и в нее загружали первую порцию объектов, после чего выполняли дефрагментацию базы данных в автономном режиме. При этом определялся объем фрагментировашюй и дефрагментировапной копий. Следую щую порцию объектов мы загружали во фрагментироваиную копию.
При загрузке одинаковых объектов мы определяли, как увеличивается размер ба !ы данных по мере возрастания длины значений атрибутов. Поскольку ядро базы дан ных (Extensible Storage Engine, ESE) выделяет намять только для атрибутов с ла данными значениями, число таких атрибутов существенно влияет на место, заня тое объектами. В испытаниях с объектами пользователь и подразделение* зна чения присваивались только обязательным атрибутам. Чтобы служба каталогов создала объект, его обязательным атрибутам необходимо задать хотя бы одно зна чение. Ниже показано, как добавление атрибутов влияет на размер объекта.
Поскольку объекты пользователь чрезвычайно важны а развертывании катало гов, необходимо знать насколько увеличится объем базы данных при том или ином числе пользователей. В процессе исследования загружалось 500 000 объек тов пользователь порциями но 100 000 единиц (таблица 2-4).
Таблица 2-4. Рост базы данных по мере добавления новых пользователей сегментированная база данных Дефрагментированная база данных Прирост, Число байт Объем базы Прирост, кб Число байт Объем Число данных, кб прироста в базы объектов прироста в Кб расчете на пользователь, данных, расчете на одного одного шт Кб пользователя пользователя 10256 Ч 0 516064 3 5 179 364 560 354 100000 505 720912 899 088 4551 356 200 000 383 4383 1 079 312 1 294 300 000 395 4262 1 435 664 3 1 675 280 356 400 000 380 1 4 199 356 2 060 500 000 385 Служба каталогов Active Directory 64 ЧАСТЬ Итак, объем растет линейно: приблизительно па 385 000 кб при загрузке очередной порции для фрагментировашюго файла и около 356 000 кб Ч для дефрагментиро ванного. Единственное исключение - загрузка первых 100 000 объектов: размер фай ла увеличивается на существенно большую величину (примерно 516 000 кб).
Между временем первичной загрузки (100 000 объектов пользователь*) и провер кой размера файла на следующий день система провела дефрагментацию в подклю ченном состоянии и оптимизировала объекты базы данных, освободив место для новых объектов, но не сократив размер файла. Поэтому размер фрагментированно го файла намного больше файла с загруженной следующей порцией 100 000 объек тов. Увеличение фрагментированного файла не сильно отличается от увеличения дсфрагментированного.
Для загрузки в базу данных 500 000 пользователей (только с обязательным набором атрибутов) требуется приблизительно 1,8 Гб. Чтобы определить место, занятое од ной пользовательской записью, требуется вычесть свободное пространство, а затем поделить объем занятого дискового пространства на число пользователей. В нашем случае эта величина составила 3 649 байт. Объекты пользователь занимают боль ше места, чем другие объекты, так как содержат много обязательных атрибутов.
Подразделения Поскольку информация в Active Directory организована в виде иерархии подразде лений, мы попытались экспериментально определить, как увеличение числа под разделений влияет на размер базы данных. Результаты, этих испытаний приведены в таблице 2-5.
Таблица 2-5. Росг базы данных по мере добавления новых подразделений Фрагментированная база данных Дефрагментированная база данных Объем Прирост, Объем базы Прирост, кб Число Число байт Число байт объектов базы прироста в данных, кб прироста в Кб данных, расчете на подразде-, расчете на ление, шт. одно подраз- одно подраз Кб деление деление _ - Ч 10256 1025G 12304 10256 2000 2048 1 049 4 4000 1 583 6000 18448 2008 2048 1 311 1 8 000 20496 18448 10000 4096 1 468 1 24 592 12000 26640 2048 1 398 1 22544 14000 28688 1 348 1 2 048 24592 16000 32784 4096 1 442 1 26640 Итак, рост базы данных подразделений также линеен. Объем, занимаемый одним подразделением, равен 1 049 байт.
Добавление атрибутов В следующей серии испытаний в объекты пользователь* добавлялись значения дополнительных строковых атрибутов - от одного до десяти. Длина значений ат рибутов составляла 10 символов, Хранение данных в Active Directory ГЛАВА Испытание проводилось с базой, содержащей 100000 объектов пользователь с набором только обязательных атрибутов. Роль сервера понижали до рядового сер вера, затем снова назначали его контроллером домена, и затем на него повторно загружали 100000 объектов пользователь*-, на сей раз с одним дополнительным атрибутом. Процесс повторяли для двух, трех и т.д. дополнительных атрибутов.
Результаты показаны в таблице 2-6.
Таблица 2-6. Рост базы данных по мере добавления новых дополнительных ат рибутов Фрагментированная база данных Дефрагментированная база данных Число Объем базы Число байт Объем базы Число байт Число байт дополни- данных, кб в расчете на данных, кб в расчете на в расчете на тельных одного одного один атрибут атрибутов пользователя пользователя _ 522 256 364 560 0 1 4 130 364 560 |) 2 364 413712 4 3 3816 485 392 382 405 520 i 6689 663 5 405 520 -;
7045 698 i 407 568 '!
706 576 7 ;
;
704 528 7 108 444 Хч< 8 702 480 7087 444 9 497 680 444 432 4990 497 680 444 !') 444 432 Ч 497 ]!
На отдельных этапах шаг прироста фрагментированной базы данных существенно больше обычного. Это обусловлено тем, что ESE выделяет место для новых стра ниц. В дефрагментированной базе таких скачкой объема данных не наблюдалось, Рост дефрагментированного файла линейный и в этом случае. Один дополнитель ный атрибут длиной 10 символов увеличивает размер объекта примерно на 100 байт.
Подробнее об управлении объемом и емкостью Active Directory - в книге Mic rosoft Windows 2000 Server Deployment P l a n n i n g Guide (Microsoft Press, 2000), a также на Web-странице Web Resources по адресу windows2000/reskit/webresources, ссылка Microsoft Windows 2000 Server.
Хранение данных в SAM Windows В Windows NT 4.0 как контроллеры домена, так и рабочие станции хранят учетные записи участников безопасности в базе данных SAM, который в свою очередь раз мещает постоянные (persistent) данные в реестре. В Windows 2000 такие учетные записи хранятся не в реестре, а в Active Directory;
диспетчер учетных записей бе зопасности сохранен для совместимости с доменами и приложениями, которые в нем нуждаются. SAM также используется на компьютерах под управлением Win dows 2000, не являющихся контроллерами домена и ответственных за хранение дан ных о локальных учетных записях. Таким образом, SAM управляет учетными за писями участников безопасности. На контроллере домена эти данные SAM хранит в Active Directory, а па рабочих станциях, изолированных и рядовых серверах Служба каталогов Active Directory 66 ЧАСТЬ в реестре. Диспетчер учетных записей безопасности (Sarnsrv.dll) обеспечивает про стейшее разрешение имен, механизм небольших транзакций, репликацию и безо пасное храпение базы данных учетных записей безопасности.
В Windows 2000 возможны два типа учетных записей: рабочих станций (workstation accounts) и домена (domain accounts). Диапазон действия учетных записей рабочих станций, которые включают пользовательские и групповые учетные записи на ра бочих станциях, рядовых и изолированных серверах, ограничен одним физическим компьютером, где они расположены. Область видимости учетных записей домена больше и распространяется на все физические компьютеры данного домена. К примеру, администратор рабочей станции обладает административными привиле гиями только на локальном компьютере (рабочей станции или рядовом сервере), а администратор домена на всех компьютерах домена.
В Windows NT 3.51 и 4.0 обе категории учетных записей хранятся в базе данных SAM (в реестре). В Windows 2000 контроллеры домена размещают доменные учетные за писи пользователей, групп и компьютеров только в Active Directory;
рабочие стан ции и рядовые серверы продолжают хранить локальные учетные записи я базе дан ных SAM. На контроллерах доменов Windows 2000 существующая база данных SAM удаляется и заменяется новой ветвью реестра, где расположена сокращенная база данных SAM. Последняя применяется преимущественно в режиме восстановления службы каталогов. При запуске контроллера домена в атом режиме в качестве базы данных участников безопасности используется SAM, a lie Active Directory.
Кроме того, SAM в Windows 2000 поддерживает следующие функции:
Х репликацию учетных записей между контроллерами домена в среде со многими хозяевами;
Х создание и удаление свойств объектов пользователь;
Х чтение, запись и поиск свойств, определенных в продуктах сторонних разработ чиков. (Подробнее о LSA Ч в главе 12 Управление доступом.) Контроллеры домена под управлением Windows 2000 Server полностью совмести мы с контроллерами домена под управлением Windows NT 4.0, то есть клиент под управлением Windows NT 4.0 допускается к проверке подлинности на контроллере домена под управлением Windows 2000, а резервный контроллер домена под управ лением Windows NT 4.0 может обмениваться репликативньтми обновлениями с кон троллерами доменов под управлением Windows 2000. В домене Windows 2000 один контроллер домена под управлением Windows 2000 может выполнять (а точнее, эмулировать) роль основного контроллера домена (выполнять FSMO-роль хозяи на эмулятора РОС).
Подробнее о роли эмулятора PDC контроллером домена под управлением Win dows 2000 Ч в главе 7 лУправление операциями одиночного хозяина и в книге Microsoft Windows 2000 Server Deployment Planning Guide (Microsoft Press, 2000), а также справочной системе Microsoft Windows 2000 Server.
Особенности хранения данных в доменах смешанного режима В смешанном режиме число учетных записей ограничено емкостью базы данных SAM, которая по-прежнему используется для хранения учетных записей домена на резервных контроллерах домена. На резервном контроллере домена под управле нием Windows NT 4.0 можно разместить приблизительно 40 000 учетных записей Хранение данных в Active Directory ГЛАВА 2 участников безопасности (пользователи, группы, т-i компьютеры). При удалении объектов размер базы данных SAM не уменьшается Ч она становится фрагмент и рованной и содержит пустоты. Это свободное пространство заполняется (но не всегда эффективно) по мере добавления новых объектов, таким образом, реальная емкость базы данных уменьшается: база уже не способна хранить теоретически воз можное число учетных записей.
Примечание Применив утилиту Regback к базе данных SAM, Вы освободите сво бодное пространство, но только при условии, что объем физической оперативной памяти компьютера по крайней в два раза превышает текущий размер SAM (это условие продиктовано особенностями работы Regback). Подробнее о способах сжа тия базы данных SAM Ч на Web-странице Web Resources по адресу dows.microsoft.com/windows2000/reskit/webresources, ссылка Knowledge Base (про ведите поиск в Knowledge Base по ключевым словам database и shrink).
Структура SAM И в Windows NT 4.0, и в Windows 2000 SAM хранит доменные учетные записи бе зопасности. Понятие домен в SAM относится либо ко всем учетным записям на отдельном компьютере, либо ко всем учетных записях в домене Windows. Папка Builtin содержит стандартные учетные записи локальных групп [таких, как Admi nistrators (Администраторы), Users (Пользователи) и Guests (Гости)], автоматичес ки предоставляемые Windows 2000 на вновь установленных рабочих станциях, сер верах и контроллерах домена. Она включает основные типы учетных записей, по зволяющих оператору добавлять новые учетные записи в компьютере или домене, Идентификаторы безопасности (S1D) учетных записей в папке Builtin одинаковы во всех копиях Windows 2000 и более ранних систем. Это дает возможность разме щать в списках управления доступом независимые от конкретных доменов стандар тные группы. Поэтому объекты этой папки нельзя изменить.
В Windows 2000 домены содержат такие же объекты, как и в Windows NT 4.0, но у некоторых объектов существуют несколько дополнительных свойств.
Учетные записи SAM на сервере под управлением Windows 2000 Server, назначаемым контроллерам домена В момент установки Active Directory на компьютер под управлением Windows Server, который предполагается назначить контроллером домена, можно создать новый домен либо ввести его в состав уже существующего домена (тогда он будет содержать копию домена). В любом случае ветка реестра, содержащая базу данных SAM, удаляется и заменяется на новую, сокращенную версию SAM, участники бе зопасности которой будут использоваться только при загрузке в режиме восстанов ления службы каталогов.
Размещение участников безопасности в базе данных SAM отличается в каждом из случаев. Далее описаны особенности этого размещения.
Х При создании дополнительного контроллера в существующем домене на серне ре удаляются все учетные записи безопасности существующей базы данных SAM. Учетные записи данного домена реплицируются в Active Directory на но вом контроллере домена.
Служба каталогов Active Directory 68 ЧАСТЬ Х При создании нового домена учетные записи безопасности существующей базы данных SAM сохраняются по следующим правилам:
Х учетные записи пользователей преобразуются в объекты пользователь в Active Directory;
Х локальные группы в доменных учетных записях преобразуются в объекты групп в Active Directory с типом локальная;
Х встроенные локальные группы преобразуются в объекты групп в Active Directory с типом локальная. Эти группы сохраняют свои постоянные идентификаторы безопасности (STD) и хранятся в папке Builtin.
Переход от учетных записей SAM в Windows NT 4.0 к объектам Active Directory Когда контроллер домена под управлением Windows NT 4.0 обновляется до Win dows 2000, учетные записи безопасности SAM преобразуются в объекты Active Directory по следующим правилам:
Х учетные записи л о б ы ч н ы х пользователей (то есть людей) преобразуются в объекты класса User в Active Directory;
Х учетные записи компьютеров |в Windows NT 4.0 они назывались учетными за писями машины (machine accounts)], которые представляют устройства, преоб разуются в объекты класса Computer класса, производного от класса User, Ч и видны клиентам более ранних версий Windows как объекты базового класса user.
(Подробнее о производных и базовых классах в главе 4 Схема Active Direc tory.) По умолчанию после обновления эти учетные записи размещаются в пап ке Computers, хотя нет никак жестких ограничений на их местоположение. Кон трольный флаг в учетной записи пользователя указывает на ее тип сервер или рабочая станция, контроллер домена или обычная учетная запись пользователя.
В Windows 2000 сохраняется принятая в Windows NT 4.0 семантика (флаги, ука зывающие на природу объектов, например компьютер или пользователь) учет ных записей рабочих станций;
Примечание В оснастке Active Directory Users and Computers (Active;
Directory Ч пользователи и компьютеры) свойство (атрибут) Role (Роль) в учетной запи си компьютера указывает на тип учетной записи. Это свойство отображает зна чение флага user Account Control в свойстве machineRole Ч 4096 для сервера или рабочей станции или 8192 для контроллера домена.
Х учетные записи глобальных групп преобразуются в объекты групп в Active Directory;
Х учетные записи локальных групп из доменных учетных записей SAM преобра зуются в объекты групп в Active Directory;
Х учетные записи встроенных локальных групп из домена Builtin SAM (например, группа Administrators (Администраторы)) преобразуются в объекты локальных групп домена в Active Directory в папке Builtin. У группы домена B u i l t i n SAM постоянные идентификаторы безопасности, которые сохраняются н в Active Directory;
Х учетные записи компьютеров резервных контроллеров домена представляются так же, как и учетные записи рабочих станций, за исключением другого значе ния флага, который позволяет их отличить;
Хранение данных в Active Directory ГЛАВА Х объекты учетных записей LSA предоставляют привилегии конкретным учетным записям на рабочей станции. Они хранятся в системном реестре и синхронизи руются между контроллерами домена путем репликации в политику рабочей станции. Но умолчанию политика рабочих станций идентична на всех контрол лерах одного домена, поэтому изменение объекта учетной записи LSA вызывает обновление соответствующей политики рабочих станций на эмуляторе РОС.
Изменения политики рабочей станции реплицируется во все остальные контрол леры домена Windows 2000.
Сводные правила преобразования учетных записей SAM в объекты Active Directory при переходе с Windows NT 4.0 на Windows 2000 перечислены в таблице 2-7.
Таблица 2-7. Преобразование учетных записей SAM в объекты Active Directory при переходе с Windows NT 4.0 на Windows Windows NT 4.0 SAM Windows 2000 Active Directory Объект класса User Обычная учетная запись пользователя Объект класса Computer, в котором флаг учет Учетная запись компьютера ной записи пользователя указывает на учетную запись рабочей станции Объект класса Computer, в котором флаг учет Учетная запись контроллера домена ной записи пользователя указывает на учетную запись сервера Объект класса Group, в котором тип группы ука Глобальная группа в домене зывает на глобальную группу Локальная группа в домене Объект класса Group, в котором тип группы ука зывает на локальную группу Объект класса Group, где тип группы указывает Локальная группа в домене Builtin как на локальную группу, так и па группу B u i l t i n [например Administrators (Администраторы), Backup Operators (Операторы архива) и т. п.] Объект доверенного домена. (Перенимает роли Учетная запись доверенного домена как входящих, так и исходящих доверительных отношений;
для обратной совместимости поддер живается также учетная запись доверенного до мена класса User.) Обновленный объект доверенного домена Объект доверенного домена Подробнее об особенностях перехода па Windows 2000 Ч в книге Microsoft Win dows 2000 Server Deployment Planning Guide (Microsoft Press, 2000).
Модель данных Модель данных Active Directory построена на базе стандарта Х.500 объектов и ат рибутов. Объект (object) Ч это отдельный, поименованный набор атрибутов, пред ставляющий что-то конкретное Ч пользователя, принтер или приложение. Таким образом, в Active Directory содержатся объекты, которые представляют разнообраз ные сущности, описанные с применением атрибутов (их также называют свойства ми). Например, атрибуты объекта пользователь* могут содержать имя, фамилию и адрес электронной почты.
Совокупность объектов, возможных в Active Directory, определена п схеме. Для каждого класса объектов указаны его обязательные атрибуты, которые у экземпля ров данного класса должны быть непременно определены, дополнительные атри Служба каталогов Active Directory 70 ЧАСТЬ буты, задание значений которых не обязательно, а также допустимые родительские классы Ч только объекты таких классов могут быть родителями экземпляров дан ного. В качестве протокола доступа и модификации данных каталогов использует ся LDAP.
Примечание Active Directory не является каталогом Х.500, поэтому он не поддер живает протоколы Х.500.
Объекты-контейнеры и конечные объекты Конечный (или листовой) объект Ч это объект, у которого нет дочерних объектов.
Термин контейнер подразумевает хотя бы одно из двух понятий:
Х объект структурного класса container, Х объект, у которого имеются дочерние объекты.
Выражение контейнер Ч это структурный класс объекта означает, что контейнер ные объекты могут создаваться (и храниться) н Active Directory. В схеме структур ные классы определяют классы, экземплярам объектов которых разрешено суще ствование в Active Directory. Другие объекты считаются контейнерами в общем смысле этого слова (то есть они могут иметь дочерние объекты), по не принадле жат классу container. Например, подразделение Ч это контейнерный объект, хотя и относится к классу organizational Unit, а не container. У объекта подразделения много атрибутов, обеспечивающих функциональные возможности, недоступные обычному контейнеру.
Подробнее о структурных классах - в главе 4 Схема Active Directory*.
Дерево каталогов Дерево каталогов отображает иерархию объектов Active Directory в данном лесе.
Иерархия позволяет использовать имена для передвижения и ориентации среди объектов Active Directory, а также задавать область поиска.
Active Directory хранит информацию (ссылку) о родителе каждого из объектов;
у каждого объекта возможно не более одного родителя. На основании этих ссылок Active Directory формирует иерархию объектов - древовидную структуру, верши ны которой представляют собой элементы каталога (экземпляры классов или объекты), а соединительные линии - родственные отношения (лродитель Ч пото мок) между элементами. Объекты, из которых состоит каталог, организованы в этой древовидной структуре в соответствии с правилами схемы, определяющими порядок родственных отношений. Например, в схеме указано, объекты каких клас сов могут быть потомками определенного класса, а каких Ч не могут, Ниже перечислены некоторые ограничения и требования к архитектуре дерева ката логов.
Х Объекты-контейнеры доменов могут быть потомками только других объектов доменов. Например, домен не может быть потомком подразделения.
Х Корень дерева каталогов называется rootDSE, или корень каталога. RootDSE это мнимый, фигуральный объект, которому не соответствует никакое иерархи ческое имя или класс схемы, по у которого есть набор атрибутов, отображаю Хранение данных в Active Directory ГЛАВА вдих содержание данного контроллера домена. Таким образом, rootDSE Ч пред ставляет корень дерева каталогов с точки зрения текущего контроллера домена.
Х Ниже корня дерева в каждом каталоге находится корневой домен (root domain) Ч первый домен, созданный в данном лесе. У этого домена всегда имеется дочер ний контейнер, называемый конфигурацией. Он содержит сведения о конфигу рации конкретного леса: информацию обо всех службах, сайтах и других доме нах леса. У контейнера конфигурации есть дочерний контейнер схемы. Раздел домена и контейнер конфигурации вместе со своим дочерним контейнером схе мы считаются тремя стандартными разделами каталога Active Directory.
Подробнее об отношениях типа родитель Ч потомок Ч в главе 4 Схема Active Directory и главе 1 Логическая структура Active Directory.
RootDSE RootDSE (особый элемент DSA) представляет вершину логического пространства имен данного контроллера домена и поэтому считается вершиной дерева LDA Р поиска. В данном каталоге есть только один корень, но информация, хранимая в корне, относится именно к контроллеру домена, с которым создается соединение.
Атрибуты rootDSE указывают как па разделы каталогов (домен, схема и конфигу рация) определенного контроллера домена, так и на раздел корневого домена леса.
Таким образом, rootDSE является неким логлавлением* данного контроллера до мена.
RootDSE публикует информацию о LDAP-ссрвере, в том числе сведения о поддер живаемой им версии LDAP, механизмах протокола SASL (Simple Authentication and Security Layer), элементах управления, а также о составном имени атрибута subs chemaSubentry сервера.
Далее перечислены операционные атрибуты объекта rootDSE. Все LD АР-серн еры распознают имена этих атрибутов, но атрибут недоступен, если функция, обозна ченная им, не поддерживается сервером.
subschemaSubentry. Это имя записи подсхемы, которая используется для админи стрирования информации о схеме, в частности о поддерживаемых классах объек тов и типах атрибутов. (Подробнее о subschemaSubentry Ч в главе 4 Схема Active Directory.) namingContexts. Контексты именования (разделы каталога), хозяином которых является данный сервер (хранит доступную для записи реплику), или контексты, хозяином которых данный сервер не является (хранит реплики только для чтения).
Этот атрибут позволяет клиенту выбирать для поиска на сервере подходящие ба зовые объекты.
supported Control. Идентификаторы объектов, указывающие на элементы управ ления LDAP, поддерживаемые сервером. Этот атрибут отсутствует, если сервер не поддерживает никаких элементов управления.
supportedSASLMechanisms. Имена поддерживаемых сервером механизмов SASL, которые обеспечивают выбор процедуры проверки подлинности при создании со единения и (при необходимости) механизма шифрования. Этот атрибут отсутству ет, если сервер не поддерживает ни один из механизмов.
supportedLDAPVersion. Версии LDAP, поддерживаемых сервером.
4 Зак. 402?
Служба каталогов Active Directory 72 ЧАСТЬ supportedExtension. Идентификаторы объектов (известные как ОШ), которые указывают на дополнительные операции, поддерживаемые сервером. Этот атрибут отсутствует, если сервер не поддерживает никаких расширений. Для серверов Active Directory этот атрибут отсутствует но умолчанию.
altServer. Значения этого атрибута Ч это URL-адреса серверов, к которым можно подключаться в случае недоступности текущего сервера. Этот атрибут отсутствует, если серверу неизвестны такие серверы. Для серверов Active Directory этот атри бут отсутствует по умолчанию.
Кроме описанных операционных атрибутов, Active Directory поддерживает допол нительные справочные атрибуты.
currentTime. Текущее время в обобщенном формате времени.
dsServiceName. Параметры настройки KTDS.
defaultNamingContext. Контекст именования по умолчанию (раздела каталога) определенного сервера. Значение этого атрибута Ч составное имя раздела домена, для которого данный контроллер домена является полномочным.
schemaNamingContext. Контекст именования (раздел каталога) схемы леса.
configurationNamingContext. Контекст именования (раздел каталога) конфигура ции леса.
rootDomainNamingContext. Составное имя контекста именования домена (разде ла каталога), который был создан первым в данном лесе. Этот домен выполняет функции корня леса.
supportedLDAPPolicies. Поддерживаемые политики управления LDAP.
highestCommitteclUsn. Максимальный порядковый номер обновления (update se quence number, USN), внесенного в базу данных на данном контроллере домена, (Подробнее о порядковых номерах обновления Ч в главе 6 Репликация Active Directory.) dnsHostName. DNS-имя данного контроллера домена.
serverName. Полное имя (FQDN) данного контроллера домена.
supportedCapabilities. Значение идентификатора объекта (1.2.840.113556,1.4.800), которое указывает на дополнительные возможности сервера Active Directory, на пример динамическое обновление, интегрированные зоны DNS или политики LDAP.
LdapServiceName. Имя основного LDAP-сервера, используемого для взаимной проверки подлинности.
isSynchronized. Булево значение, информирующее о том, завершил или нет кон троллер домена процесс начальной синхронизации с партнерами репликации.
isGlobalCatalogReady. Булево значение, информирующее о том, готов ли контрол лер домена оповещать о себе в качестве глобального каталога.
Подробнее о rootDSE и его атрибутах на Web-странице Web Resources по адресу crosoft.com/wiHdows2000/reskit/webresources, ссылка Request for Comments (RFC) и далее - ссылки RFC 2251 и RFC 2252.
Для просмотра содержания rootDSE контроллера домена применяются служебные программы ADST Edit или Ldp.
Хранение данных в Active Directory ГЛАВА Примечание Чтобы воспользоваться ADSI Edit, Вам придется установить служеб ные программы, находящиеся в папке Support\Tools на компакт-диске с операци онной системой Windows 2000 Server. Для этого достаточно дважды щелкнуть зна чок Setup в этой папке. Подробнее об установке и использовании служебных про грамм Windows 2000 и справочной системы служебных программ Windows 2000 Ч в файле Sreadmc.doc в этой же папке.
^ Просмотр свойств rootDSE с помощью ADSI Edit 1. В ADSI Edit, щелкните правой кнопкой мыши значок Edit ADSI и в контекст ном меню щелкните Connect to.
2. Чтобы подключиться к контроллеру домена, отличному от заданного но умол чанию (контроллер домена, в который Вы вошли), щелкните Select or type a domain or server и введите имя домена или сервера.
3. В разделе Connection Point установите переключатель в положение Naming Context.
4. В поле со списком Naming Context выберите RootDSE и щелкните ОК.
5. Разверните узел Коо№5Е[Имя_сервера\.
G. Щелкните правой кнопкой мыши папку RootDSE и в контекстном меню выбе рите Properties (Свойства).
7. В диалоговом окне RootDSE Properties можно просматривать свойства, выби рая их поочередно в поле со списком Select a property to view.
ADSI Edit позволяет просматривать свойства rootDSE только по одному. Чтобы уви деть полный список свойств и их значений нужно воспользоваться программой Lclp.
Ldp.cxe служебная программа с графическим интерфейсом, позволяющая выпол нять такие операции LDAP, как подключение, привязка, поиск, обновление, добав ление и удаление в любых LDAP-совместимых каталогах, в том числе в Active Directory. При подключении к контроллеру домена Ldp отображает полный список атрибутов rootDSE вместе с их значениями, которые хранятся на этом контролле ре домена.
Примечание Существует несколько способов запуска Ldp: выбрать в меню Win dows 2000 Support Tools пункт Active Directory Administration Tool, в диалоговом окне Run (Выполнить) ввести Ldp или вызвать окно командной строки и ввести команду Ldp.
^ Подключение с помощью Ldp к контроллеру домена и просмотр атрибутов rootDSE 1. В окне Ldp, в меню Connection выберите Connect.
2. В поле Server оставьте имя текущего контроллера домена или введите имя кон троллера домена, к которому требуется подключиться.
3. В поле Port введите номер используемого порта.
По умолчанию LDAP использует порт 389;
порт 3268 стандартный порт гло бального каталога Active Directory.
4. Щелкните ОК.
ЧАСТЬ 1 Служба каталогов Active Directory Ниже показан пример результатов операции подключения Ldp Connect. Сведения RootDSE отображены в правой области окна Ldp.
Id = ldap_open("sea-rk-dc-01", 389);
Established connection to sea-rk-dc-01.
Retrieving base DSA information...
Result <0>: (null) Hatched DNs:
Getting 1 entries:
Dn:
1> currentTime: 10/1/1999 15:49:25 Pacific Standard Time Pacific Daylight Time;
1> subschemaSubentry: CN=Aggregate,CN-Schema,CN=Configuration,DC=reskit,DC=com;
1> dsServiceName: CN=NTDS Settings,CN=SEA-RK-DC-01,CN=Servers,CN=Default-First-Site Name, CN=Sites, CN=Configu ration, DOreskit, DC=com;
3> namingContexts: CN=Schema,CN=Configuration,DC=reskit,DC=com;
CN=Configuration,DC=reskit,DC=com;
DC=reskit,DC=com;
1> defaultNamingContext: DC=reskit,DC=com;
1> schemaNamingContext: CN=Schema,CN=Configuration,DC=reskit,DC=com;
1> configurationNamingContext: CN=Configuration,DC=reskit,DC=com;
1> rootDomainNamingContext: DC=reskit,DC=com;
16> supportedControl: 1.2,840.113556,1.4.319;
1.2.840.113556.1.4.801;
1.2.840.113556.1.4.473;
1.2.840.113556.1.4.528;
1.2.840.113556.1.4.417;
1.2.840.113556.1.4.619;
1,2.840.113556.1.4.841;
1.2.840.113556.1.4,529;
1.2.840.113556.1.4.805;
1.2.840.113556.1.4.521;
1.2.840.113556.1.4.970;
1.2.840.113556.1.4.1338;
1.2.840.113556.1.4.474;
1.2.840.113556.1.4.1339;
1.2.840.113556.1.4.1340;
1.2.840.113556.1.4.1413;
2> supportedLOAPVersion: 3;
2;
11> supportedLDAPPolicies: InitRecvTimeout;
HaxConnections;
MaxConnldleTimei MaxActiveQueries;
MaxNotificationPerConn;
MaxPageSize;
MaxQueryDuration;
MaxTempTableSize;
MaxResultSetSize;
MaxPoolThreads;
MaxDatagramRecv;
1> highestCommittedUSN: 191396;
2> supportedSASLMechanisms: GSSAPI;
GSS-SPNEGO;
1> dnsHostName: SEA-RK-DC-01.reskit.com;
1> IdapServiceName: reskit.com:sea-rk-dc-01$$RESKIT.COM;
1> serverName: CN=SEA-RK-DC-01,CN=Servers,CN=Default-First-Site Nafne,CN=Sites,CN=Configu ration, DC-reskit, DC=com;
1> supportedCapabilities: 1.2.840.113556.1.4.800;
1> isSynchronized: TRUE;
1> IsGlobalCatalogReady: TRUE;
Примечание Значения атрибутов rootDSE можно получить с сервера LDAPv3, за дав базовый поиск с пустым составным именем и с фильтром (objectClass = *).
(Подробнее о LDAP-поиске Ч в главе 3 Разрешение имен в Active Directory.) Подробнее о rootDSE Ч на Web-странице Web Resources по адресу window.s.microsoft.com/wiridows2000/reskit/vvebresources, ссылка Microsoft Platform SDK (выполните поиск по ключевому слову rootDSE).
Дополнительные элементы управления ЮАР Windows 2000 поддерживает несколько элементов управления LDAP, которые рас ширяют функциональные возможности протокола LDAPvS. Они созданы для обо гащения функциональных возможностей Active Directory. Эти элементы управле ния не поддерживаются текущей Персией соответствующих документов RFC. Root DSE указывает все доступные на сервере элементы управления в виде идентифи каторов объектов (Object identifiers, OID) в атрибуте supportedControl.
ГЛАВА 2 Хранение данных в Active Directory Функциональные возможности, предоставляемые дополнительными элементами управления, LDAP пригодятся программистам, которые используют LDAP для выполнения операций с каталогами. К операциям, которые можно выполнить cpi д ствами дополнительных элементов управления, относится удаление деревьев, по страничный просмотр и сортировка результатов поиска, а также отображение уда ленных объектов. (Подробнее об отображении удаленных объектов Ч в главе Разрешение имен в Active Directory.) Подробнее об использовании элементов управления LDAP Ч на Web-странице \Veb Resources по адресу ссылка (выполните поиск но ключевому слову LDAPControl).
Примечание Идентификаторы объектов элементов управления LDAP необходимы только в LDAP API. Большинство разработчиков использует ADSI, в котором для выполнения таких же функций применяются другие механизмы, например флаги поиска. Подробнее об использовании ADSI на Web-странице Web Resources no адресу ссылка Mic rosoft" Platform SDK.
Параметр Range В LDAP многозначный атрибут считывается как единый объект, что иногда созда ет определенные неудобства: при большом числе значений чтение атрибута зани мает много времени или вообще невозможно. В описании атрибута разрешается задать параметр Range, в котором надо указать, что атрибут требуется считывать отдельными порциями. Описание атрибута содержит тип атрибута (например, member) и список параметров, среди которых может быть Range. В сообщении-зап росе searchRequest параметру Range присваивается отсчитываемый от нуля диапа зон элементов (например, 0-9), которые должен возвратить запрос. При определен ном Range и заданном диапазоне запрос возвратит только значения из этого диапа зона.
Чтобы в Ldp извлечь значения только из определенного диапазона, откройте диа логовое окно Search (в меню Browse выберите Search) и в нем щелкните Options.
В поле Attributes введите имя атрибута и параметр Range. Имя атрибута и пара метр Range не забудьте заключить в кавычки (" "). Это обязательное условие.
Например, чтобы считывать имена членов группы порциями по шесть элементов, в качестве базы поиска введите составное имя группы и наберите в поле Attributes следующую строку: "member;
range=0-5". Этот поиск возвратит шесть значений многозначного атрибута member указанного объекта.
Подробнее об использовании параметра Range Ч на Web-странице Web Resources по адресу ссылка Microsoft Platform SDK (выполните поиск по ключевым словам range specifiers- и enumerating groups), Разделы каталога Для обеспечения возможности масштабирования до десятков миллионов объектов лес разбит на домены. Каждому контроллеру домена Active Directory разрешается быть участником одного домена, а всем контроллерам этого домена Ч содержать одинаковую информацию. Контроллеры разных доменов могут иметь одинаковую конфигурацию и схемы, но данные их доменов отличаются. В такой структуре для Служба каталогов Active Directory 76 ЧАСТЬ распределения пространства хранения данных используются разделы каталогов, которые также называют контекстами именования (naming context).
В Active Directory раздел каталога Ч это часть его пространства имен. Каждый раз дел каталога содержит иерархию (поддерево) объектов каталога в дереве катало гов. Один раздел каталога может храниться в виде копий (реплик) на многих кон троллерах домена, при этом копии обновляются посредством репликации.
Поскольку домен задаст как границу управления безопасностью, так и логическую границу администрирования, каждый из доменов отображается в отдельный раз дел каталога, что обеспечивает независимую поддержку и репликацию объектов, принадлежащих различным доменам. Аналогичным образом информация, относя щаяся ко всему лесу, реплицируется отдельно.
Поддеревья разделов каталогов Каждый контроллер домена содержит три раздела каталога.
Конфигурация содержится в контейнере Configuration, где хранятся объекты кон фигурации всего леса в сп=соп.И^\1га1ю1].^\с=<имя_корневого_домена_леса>. Обнов ления этого контейнера, реплицируются во все контроллеры домена в лесе. Объек ты конфигурации содержат данные о сайтах, службах и разделах каталога. Просмат ривать содержание контейнера конфигурации можно средствами служебной про граммы ADSI Edit.
Схема содержится в контейнере Schema, где хранятся определения классов и атрибу тов всех существующих и допустимых объектов Active Directory в cn=schema,cn=con йпга1{оп,Ас=<имя_корпевого_домена_ле,са>. Обновления этого контейнера репли цируются во все контроллеры домена в лесе. Просматривать содержание контейне ра схемы можно в консоли Active Directory Schema (Схема Active Directory).
Домен содержится в контейнере <доменное_ имя> (например, контейнер Reskit.com ), где хранятся сведения о пользователях, компьютерах, группах и других объектах данного домена Windows 2000 (например, домена Reskit.com). Обновления этого контейнера реплицируются только на контроллеры данного домена и на серверы глобального каталога (при изменении атрибутов, реплицируемых в глобальный ка талог). Данный контейнер отображается в консоли Active Directory Users and Computers (Active Directory - пользователи и компьютеры). Просматривать и уп равлять иерархией разделов каталогов домена можно средствами оснастки Active Directory Domains and Trusts (Active Directory домены и доверие).
Каждый раздел каталога представляет собой связанную часть дерева каталогов и начинается в одной точке [она называется заголовок, (head) раздела} и простирает ся либо вплоть до оконечных (ллистьев) узлов (в схеме и конфигурации), либо к заголовкам других, подчиненных разделов каталога (в домене). Поэтому для каж дого раздела каталога существует один раздел каталога, расположенный непосред ственно над ним в дереве (за исключением раздела каталога домена в корне леса, выше которого находится только rootDSE), и, возможно, несколько разделов ката лога, расположенных непосредственно под ним. Для разделов каталога домена этот порядок проявляется в иерархической инфраструктуре, рассмотренной в главе Логическая структура Active Directory.
Примечание Переименовать объект самого верхнего уровня в разделе каталога не возможно, другими словами запрещено переименовывать домен и контейнеры схе мы и конфигурации.
Хранение данных в Active Directory ГЛАВА Иерархия разделав каталога Физическое хранилище раздела каталога и его логическое место в дереве катало гов не одно и то же, причем различие существенно. На физическом уровне все объекты хранятся в единой таблице базы данных независимо от раздела каталога, к которому они отнесены на основании имен. На логическом уровне заголовок раз дела каталога представлен в иерархии именования объектом верхнего уровня -- как контейнеры домена, конфигурации и схемы, у каждого из которых имеется состав ное имя, указывающее на его место в иерархии. Разделы каталогов содержат объек ты, называемые заголовками: раздел домена содержит объект Ас=<и.мя_домена>, раздел конфигурации объект cn=configuration4c=<шfя_кo^шeeoгo_д(шeнд>_лecд и раздел схемы Ч cn=schema,cn=configuration,dc=<г^.'Ия_кopнeвoгo_(')o.лйwя_лet7a>, На рис. 2-5 показана блок-схема иерархии деревьев каталогов вместе с корнем ка талога (rootDSE) и стандартными разделами каталога ниже корня каталога. Во всех лесах Active Directory разделы конфигурации и схемы расположены именно в этом месте.
О Корень каталога (rootDSE} Раздел домена в корневом домене леса Деревья доменов Рис. 2-5. Стандартные разделы каталога Active Directory Каждый контроллер домена в лесе содержит полную копию (реплику) конфигура ции и схемы, которые копируются на компьютер в момент повышения его роли до контроллера домена. Все изменения конфигурации и схемы реплицируются во все контроллеры домена в лесе. Таким образом поддерживается непротиворечивость данных о сайтах, службах, доменах и схеме во всем лесс.
Корневой домен леса Поскольку корневым в лесе становится первый созданный в нем домен, он счита ется корнем иерархии пространств имен доменов. Объект конфигурации представ ляет собой потомка объекта корневого домена леса только в иерархии именования.
Этот факт отражен в составном имени контейнера конфигурации (cn=configura 1{оп,Ас=<имя_корневого_домена_леса>).
Хотя составное имя контейнера конфигурации и подразумевает, что он потомок объек та корневого домена леса, конфигурация физически не относится к каталогу корнево го домена, а является отдельным разделом каталога, реплицируемым во все контрол леры доменов леса. В отличие от конфигурации, раздел домена корневого домена леса реплицируется только на контроллеры этого домена. Точно так же объект верхнего Служба каталогов Active Directory 78 ЧАСТЬ уровня схемы считается потомком контейнера конфигурации. Составное имя контей нера схемы (cn=schema,cn=configuration,dc=
Подробнее о репликации разделов каталога Ч в главе 6 Репликация Active Directory*.
Раздел конфигурации Раздел конфигурации создается в момент формирования первого домена Win dows 2000 при установке Active Directory;
далее он реплицируется во все контролле ры домена в лесу. Когда создается дочерний домен или новый корневой домен дере ва в лесе, а также при добавлении дополнительного контроллера домена в существу ющий домен, раздел конфигурации копируется на новый контроллер домена.
Просмотр контейнера конфигурации Просматривать содержимое контейнера конфигурации можно средствами служеб ной программы ADSI Edit. При запуске ее в окне отображается контейнер конфи гурации леса, к которому относится текущий домен, а также разделы домена и схе мы (рис. 2-6).
4)51 Edi;
i i jjjj DomMiNC [MHlLLpeANZ.iam.reskit torn] i 3 g ConliguratEn Centner [MHCUrtW.noar CrfeE*isntJed-Rqhts,OJ-u:orv'iguiacBn,DC=res*,DC=c В3| ;
*3 2 СЧ-Ois^aySDecifie Ш CN=Partl:rani crcisRefConUine 3TB.OJ=i:onFlguaBon,Cл:=reil*,D(>Hm tl <_J CN=Extaided-Righ aJ ;
N-№vsical Location;
prr.-sicall_ocal:iDn. al LotMiors.CM-ConFiouiation.DC-iKkit.K-cDm LJ CN=?er/ttei Х es CN-Conf iguratmn, DC-re*t.OC-e эт LJ C4=Parhtioni LJ CN-fltes. C4-Ccnligjratioii,DC=re*t,DC=com 'i Llj CN^tiyilcal Locations 123 CN-We*iww1 Se-.unrv PmcipJs i Security Principals,СN-ecnhgura:!on,DC=i(sljt,DC :*s C3 CN-Ser'Aes IS' CJ CM-WsJKnown Secirty Piincpals +! t Schema [MHLL4AM2 noam.tesl* com] | Рис. 2-6. Контейнер конфигурации в окне программы ADSI Edit Далее перечислены контейнеры-потомки контейнера конфигурации.
DisplaySpecifiers содержит объекты, которые определяют различные пользователь ские интерфейсы для каждого класса объектов в схеме, нуждающегося в графичес ком интерфейсе (например, контекстные меню и страницы свойств). Эти данные система спецификаторов экрана использует для отображения различных интерфей сов для администраторов и конечных пользователей. Один набор элементов, таких, как страницы свойств, контекстные меню и т. п., можно связать с приложениями администратора, а другой Ч с приложениями конечного пользователя. Например.
спецификаторы экрана определяют, что видит администратор в окне ADSI Edit, a пользователь Ч в интерфейсе системы. Причем вид и содержание окон отличается, даже если отображаются одни и те же объекты. Система спецификаторов экрана Хранение данных в Active Directory ГЛАВА хранит информацию о страницах свойств, контекстных меню, значках, мастерах и локализованных именах классов и атрибутов.
Контейнер DisplaySpecifiers содержит другие контейнеры, соответствующие регио нам (locale), поддерживаемым данной версией Windows 2000. Регион Ч это отдель ный язык или язык, указанный для конкретной страны или области. Windows поддерживает свыше 150 регионов, среди которых French (Belgium) [Французский (Бельгия)], Arabic (Saudi Arabia) (Арабский (Саудовская Аравия)] и другие. Име на контейнеров региона Ч это гаестнадцатеричные представления идентификато ров региона (LCID). Например, контейнеру региона English (United States) [Анг лийский язык (США)] соответствует идентификатор 409.
Объекты спецификатора экрана (класс display Specifier) создаются добавлением строки л-Display в конец экранного LDAP-имепи объекта класса. Например, клас су user соответствует объект спецификатора экрана user-Display. Таким образом, отображая объект определенного класса, административная служебная программа Active Directory представляет его в соответствии с информацией, извлеченной из объекта спецификатора экрана, имя которого содержится в имени соответствующе го класса в контейнере текущего региона.
Поскольку в Active Directory схему разрешается изменять, добавляя новые классы и атрибуты или корректируя существующие, то в соответствии с изменениями схе мы можно модифицировать объекты спецификаторов экрана для отображения лю бых новых элементов интерфейса пользователя. Подробнее о спецификаторах эк рана Ч на Web-странице Web Resources по адресу win do ws2000/reskit/web resources, ссылка Microsoft Platform SDK и далее Ч ссылка Windows 2000 Active Directory Programmer's Guide.
Extended-Rights содержит множество дополнительных прав в лесе, хранимых в виде объектов класса controlAccessRight. Управление доступом определяет, кому разрешено выполнение тех или иных операций над объектами Active Directory. Доступ к стандар тным действиям или операциям управляется двумя основными типами разрешений на доступ: к контейнерным операциям и доступ на основе атрибутов. Семантика других операций может не привязываться к определенным атрибутам, но такие операции иног да также нуждаются в управлении доступом. Например, классу user можно предоста вить право Send As (Отправить как) на Exchange Server, в Outlook или в любой дру гой программе электронной почты, позволяющее одним пользователям отправлять со общения от имени других. Чтобы добавить дополнительное право в Active Directory, нужно создать объект класса controlAccessRight в контейнере Extended-Rights. Подроб нее о дополнительных правах Ч в главе 12 Управление доступом. Подробнее о со здании объектов дополнительных прав на Web-странице Web Resources но адресу ссылка Microsoft Plat form SDK и далее Ч ссылка Windows 2000 Active Directory Programmer's Guide.
LostAndFoundConfig храпит объекты глобальной конфигурации, создаваемые в контейнерах, которые в это же время удаляются в другом месте сети. Если объект был создан или перемещен в место, которое после репликации не существует, та кой потерянный объект помещается в контейнер LostAndFoundConfig. Такой же контейнер имеется в каждом разделе домена и обслуживает объекты, относящиеся только к данному домену.
Partitions хранит перекрестные ссылки всех разделов каталога леса, в том числе и разделы конфигурации и схемы, а также разделы доменов. При LDAP-поиске эти Служба каталогов Active Directory 80 ЧАСТЬ перекрестные ссылки служат для перенаправления на другие домены. Разделы до мена можно просматривать и управлять в оснастке Active Directory Domains and Trusts (Active Directory Ч домены и доверие).
Physical Locations. В текущей версии Windows 2000 этот контейнер не реализован и зарезервирован для использования в будущем.
Sites содержит все сайты сети предприятия, контроллеры доменов в этих сайтах и топологию репликации. Они хранятся в виде транспортов между сайтами, подсетя ми и первым созданным сайтом, который по умолчанию называется Default-First Site-Name. Содержание этого контейнера просматривают и модифицируют в осна стке Active Directory Sites and Services (Active Directory Ч сайты и службы). Под робнее об объектах контейнера Sites Ч в главе 6 Репликация Active Directory.
Services хранит общесетевую информацию о службах, используемых приложения ми для подключения к службам в лесе, независимо от того, где они выполняется.
Сведения касаются системных томов и сетевых служб, а также служб маршрутиза ции и удаленного доступа. Содержание этого контейнера просматривают и моди фицируют в оснастке Active Directory Sites and Services (Active Directory - сайты и службы). Подробнее об объектах контейнера Services Ч в главе 5 Публикация служб в Active Directory и справочной системе Windows 2000 Server.
WellKnown Security Principals содержит известные типы участников безопаснос ти, определенные в системе безопасности Windows 2000, такие, как Everyone (Все), Local System (Локальная система) и Authenticated User (Прошедшие проверку).
В контейнере конфигурации могут храниться и другие данные, но они должны удовлетворять следующим условиям:
Х данные должны действительно представлять глобальный интерес (например, конфигурация и политики по умолчанию для всех экземпляров данной службы в предприятии);
Х данные должны быть настолько доступны, что ссылки на информацию в другом домене недостаточно;
Х данные должны редко изменяться;
Х объем данных должен быть очень небольшим.
Примечание Желательно, чтобы глобальные данные хранились в виде потомка од ного из двух контейнеров: Services или объекта-сайта.
Управление данными конфигурации Для управления данными конфигурации можно воспользоваться одним из трех служебных программ администрирования в Windows 2000, которые находятся в подменю Administrative Tools (Администрирование) раздела Programs (Програм мы) общего меню Start (Пуск).
Х Средства оснастки Active Directory Sites and Services (Active Directory Ч сайты и службы) позволяют управлять объектами в контейнерах cn=sites,cn=con Иига1\оп,6с=<имя_корневого_домена_леса> и cn=services,cn=cont'iguration,dc= <имя_корневого_домена_леса>.
Примечание По умолчанию узел Services скрыт в Active Directory Sites and Services (Active Directory Ч сайты и службы). Чтобы сделать его видимым, щел Хранение данных в Active Directory ГЛАВА кните правой кнопкой мыши корневой значок Active Directory Sites and Ser vices (Active Directory - - сайты и службы) и в контекстном меню выберите View (Вид), а затем Ч Show Services Node (Показать узел служб).
Х Средства оснастки Active Directory Domains and Trusts (Active Directory до мены и доверие) позволяют управлять отношениями доверия между разделами домена, представленными в контейнере cn=partitions,en=configuration,dc= i
Х Средства оснастки Active Directory Schema (Схема Active Directory) позволяют управлять объектами>). Оснастка Ac tive Directory Schema (Схема Active Directory) устанавливается в ММС в меню Console (Консоль). Однако при установке этой оснастки надо соблюдать требо вания, отличные от требований, предъявляемым к обычным оснасткам ММС.
Подробнее о том, как устанавливать в ММС оснастку Active Directory Schema, об управлении схемой, Ч в главе 6 Репликация Active Directory и в главе Выявление и устранение неполадок, а также восстановление Active Directory.
Подробнее об управлении данными конфигурации в главах 6 Репликация Active Directory и 10 Выявление и устранение неполадок, а также восстановление Active Directory.
Pages: | 1 | 2 | 3 | 4 | ... | 18 | Книги, научные публикации