Книги, научные публикации
Pages: | 1 | ... | 3 | 4 | 5 | 6 | 7 | ... | 18 | Distributed Systems Guide Microsoft Windows 2000 Server Microsoft Press Распределенные системы Книга 1 Microsof Windows 2000 ...
-- [ Страница 5 ] --Структура каталога и состав классов В схеме определены правила, регулирующие структуру и содержимое Active Di rectory. При добавлении, удалении или изменении объектов проверяется, соответ ствуют ли предпринимаемые изменения правилам схемы, что позволяет поддержи вать целостность каталога. Правила структуры (structure rules) определяют допус тимую структуру дерева. При создании объекта правила структуры определяют, су ществует ли класс, определенный для нового объекта. Невозможно создать объект, принадлежащий несуществующему классу: прежде надо создать этот класс. С дру гой стороны, эти правила не позволят удалить или изменить уже удаленный объект.
В Active Directory структурные правила полностью определены атрибутами possSuperiors и systemPossSuperiors - обязательными атрибутами всех объектов клас са dassSchema. Эти атрибуты указывают классы, которые могут быть родительски ми для данного объекта. Другими словами, значения атрибутов possSuperiors и systemPossSuperiors определяют классы объектов и, следовательно, место в дереве DIT, где допустимо создавать объекты данного класса, Правила состава класса (content rules) определяет обязательные и дополнительные атрибуты объектов этого класса, хранимых в каталоге. Необходимо, чтобы новые объекты содержали все обязательные атрибуты, указанные в соответствующем объекте класса dassSchema в схеме, кроме того, они могут содержать любые допол нительные атрибуты. В Active Directory правила состава определенного класса пол ностью выражены следующими атрибутами его описания: mustHave, mayHave, mayContain, systemMustContain и systemMayContain. Кроме того, некоторые особые атрибуты обладают дополнительными ограничениями, задаваемыми диспетчером Security Account Manager (SAM). Объекты SAM только для чтения содержат следующие атрибуты:
revision, objectSID, domainReplica, creationTime modifiedCount, modifiedCount AtLast.Promotion, nextRID, serverState, samAccountType, isCriticalSystemObject, dbcsPwd, ntPwdtiistory, ImPwdHistory, lastLogon, lastLogoff, badPasswordTime, badPwdCount, logonCount и supplementalCredentials.
Ниже перечислены некоторые другие атрибуты, которые SAM проверяет особо:
Х sAMAccountName Ч уникальность в рамках домена, без поправки на задержку репликации, для пользовательских объектов длина не должна превышать символов (не относится к группам);
Х member Ч соответствие правилам членства в группах Windows 2000;
Х userWorkstatwns Ч допустимость имен компьютеров;
Схема Active Directory ГЛАВА Х primary Group ID Ч для учетной записи пользователя или компьютера должен указывать на группу, причем эта учетная запись обязательно должна входить в эту группу;
и группа, и пользователь должны быть в одном домене. Если компь ютер Ч контроллер домена, основная группа в обязательном порядке является группой контроллеров домена;
Х lockoutTime Ч для объекта пользователь или компьютер. Единственное до пустимое значение, которое разрешается записать в этот атрибут Ч 0, для очис тки учетной записи;
Х обычно этот атрибут записывает система. Существуют lockoutPasswordLastset два специальных значения, используемые для указания завершения срока дей ствия пароля (0) или отмены окончания срока действия пароля (-1).
Подробнее об этих атрибутах Ч па Web-странице Web Resources по адресу windows.microsoft.com/windows2000/reskit/webresources, ссылка Microsoft Platform SDK.
Кэш схемы Все изменения, выполняемые в Active Directory, прежде всего сверяются со схемой.
Для ускорения операций поиска кэш схемы размещается в оперативной памяти контроллера домена. Эта отображенная в памяти версия (in-memory version) схе мы называется кэшем схемы (schema cache) и обновляется автоматически при об новлении версии на диске. Кэш схемы обеспечивает взаимосоответствие между та кими идентификаторами атрибутов, как идентификатор столбца базы данных или MAPI-идентификатор, и структурами в памяти, которые описывают эти атрибуты.
Кэш схемы также обеспечивает поиск идентификаторов классов для получения ото браженных в памяти структур, описывающих эти классы.
При запуске компьютера кэш схемы загружается из базы данных и в дальнейшем автоматически обновляется при каждом изменении дисковой версии схемы. После внесения изменений в схему ее кэш автоматически обновляется за период не более пяти минут после внесения первого изменения. До отображения обновлений схе мы в кэш объекты, ссылающиеся па новый или измененный класс или атрибут, до бавить невозможно. Такой механизм обеспечивает целостность схемы, однако пя тиминутная задержка при обновлении способна привести пользователя в замеша тельство, поскольку изменения не видны, пока кэш не обновится, даже если кор рективы уже сохранены на диске.
Существует также механизм обновления кэша схемы по запросу. Его стоит ис пользовать при изменении схемы. Для этого следует добавить в rootDSE атрибут schema UpdateNow со значением 1. Само значение не используется, по действует, как триггер, или операционный атрибут, вызывая немедленную перезагрузку кэша, В особой записи rootDSE агента DSA содержатся атрибуты локального контролле ра домена, в том числе сведения о разделах каталога, имени сервера и номере под держиваемой версии LDAP. Атрибут schemaUpdateNow это операционный атри бут и применяется только для администрирования сервера каталогов. Это фигу ральный атрибут, отсутствующий в схеме и не хранящийся в постоянной памяти.
Обычно запись значения в операционный атрибут вызывает выполнение опреде ленного действия на сервере.
Служба каталогов Active Directory 178 ЧАСТЬ Добавление атрибута schemaUpdateNow влечет немедленное обновление кэша схе мы. Этот вызов блокирующий, поэтому если он выполняется без ошибок, схема полностью обновлена и все ее коррективы готовы к использованию. Возврат ошиб ки информирует о неудаче обновления кэша. Создавая приложения, использующие возможность обновления кэша, рекомендуется учитывать блокирующую запись, на пример для информирования пользователя о результатах работы интерактивной программы или сценария.
Внимание! Принудительное обновление кэша схемы рекомендуется зг пускать толь ко один раз и только после завершения всех необходимых корректировок схемы, поскольку для загрузки кэша требуется большой объем оперативной памяти.
Стандартная конфигурация безопасности объектов Active Directory Стандартный дескриптор безопасности объектов Active Directory указан в схеме.
По сути, существуют две области конфигурации стандартной безопасности Active Directory (под конфигурацией безопасности мы подразумеваем предоставляемые по умолчанию права доступа к объектам каталога):
Х параметры безопасность объектов, заданные при установке Active Directory;
Х применение стандартных параметров безопасности для вновь создаваемых объек тов после установки Active Directory Подробнее о стандартных дескрипторах безопасности объектов Active Directory на Web-странице Web Resources по адресу reskit/webresources, ссылка Microsoft Platform SDK. Подробнее о разрешениях и дескрипторах безопасности в главе 12 Управление доступом.
Примечание Существуют особые случаи, когда стандартные параметры безопасности не применяются ко вновь создаваемым объектам. Подробнее о таких ситуациях Ч на Web-странице Web Resources по адресу reskit/webresources, ссылка Microsoft Platform SDK.
Стандартная конфигурация безопасности раздела домена Объект раздела каталога домена относится к классу domainDNS, поэтому его пара метры безопасности по умолчанию те же, что и для класса domainDNS.
Стандартный дескриптор безопасности раздела домена содержит:
Х разрешение Full Control (Полный доступ) для групп Domain Administrators (Ад министраторы домена) и System (SYSTEM), а также разрешения Read (Чтение) для группы Authenticated Users (Прошедшие проверку);
Х разрешение Read (Чтение) для всех свойств для группы Everyone (Все). Это разрешение обеспечивает обратную совместимость с API-интерфейсами;
Х разрешения Replicating Directory Changes (Репликация изменений каталога), Replication Synchronize (Синхронизация репликации) и Manage Replication Topology (Управление топологией репликации) для группы Enterprise Domain Controllers (Контроллеры домена предприятия). Эти разрешения позволяют Схема Active Directory ГЛАВА членам группы Enterprise Domain Controllers автоматически управлять репли кацией;
Х разрешения Replicating Directory Changes, Replication Synchronize и Manage Replication Topology для встроенной группы Administrators (Администраторы).
Администраторы отдельных контроллеров домена используют эти разрешения для устранения неполадок репликации;
Х наследуемое разрешение Full Control (Полный доступ) для группы Enterprise Administrators (Администраторы предприятия). Эта группа, по определению, имеет полный доступ ко всем доменам;
Х наследуемое разрешение List Contents (Список содержимого) для группы Рге Windows 2000 Compatible Access (Пред-Windows 2000 доступ);
Х наследуемые разрешения Read RAS Information (Чтение Информация удален ного доступа). Read General Information (Чтение Общие сведения), Read Membership (Чтение Членство в группах), Read User Account Restrictions (Чте ние Ограничения учетной записи) и Read User Logon (Чтение Информация о входе) по отношению ко всем разрешениям объектов пользователь для груп пы Рге-Windows 2000 Compatible Access (Пред-Windows 2000 доступ);
Х наследуемое разрешение Read (Чтение) по отношению ко всем объектам группа;
Х наследуемое разрешение аудита успехов и отказов для операций записи Ч Writes (Запись всех свойств) ЧХ для группы Everyone (Все).
Активизация политики аудита гарантирует, что операции записи в каталог (для любого объекта) регистрируются автоматически, без вмешательства пользовате.'Ш.
Наследуемая запись управления доступом (access control entry, АСЕ) предоставля ет удобный способ удаления политики аудита.
Стандартная конфигурация безопасности раздела конфигурации Стандартный дескриптор безопасности контейнера Configuration содержит:
Х разрешение Full Control (Полный доступ) для групп Domain Admins (Админис траторы домена) и System (SYSTEM), а также разрешения Read (Чтение) для группы Authenticated Users (Прошедшие проверку);
Х разрешения Replicating Directory Changes (Репликация изменений каталога), Replication Synchronize (Синхронизация репликации) и Manage Replication Topology (Управление топологией репликации) для группы Enterprise Domain Controllers (Контроллеры домена предприятия). Эти разрешения позволяют контроллерам домена в лесу выполнять взаимную репликацию данных и авто матически перестраивать топологию репликации в зависимости от задержек и латентности репликации раздела конфигурации;
Х разрешения Replicating Directory Changes (Репликация изменений каталога), Replication Synchronize (Синхронизация репликации) и Manage Replication Topology (Управление топологией репликации) для встроенной группы Ad ministrators (Администраторы). Эти разрешения позволяют администраторам отдельных контроллеров домена синхронизировать репликацию и управлять то пологией раздела конфигурации;
Служба каталогов Active Directory 180 ЧАСТЬ Х наследуемое разрешение Full Control (Полный доступ) для группы Enterprise Admins (Администраторы предприятия). Это разрешение дает членам группы Enterprise Admins (Администраторы предприятия) исключительное право уп равления контейнером Configuration. Оно необходимо для управления этим кон тейнером в границах всего леса;
Х наследуемый аудит операций записи Ч Writes (Запись всех свойств), выполня емых членами группы Everyone (Все). Активизация политики аудита гаранти рует, что операции записи в каталог (для любого объекта) проверяются автома тически, без вмешательства пользователя. Наследуемая запись АСЕ обеспечи вает удобный способ удаления политики аудита.
Стандартная конфигурация безопасности раздела схемы Стандартный дескриптор безопасности контейнера Schema содержит:
Х разрешение Write fSMORoleOvvner (Запись fSMORoleOwner) для группы Schema Administrators (Администраторы схемы). Оно позволяет членам этой группы принудительно перемещать роль хозяина схемы на контроллер домена, где вы полнены изменения схемы;
Х разрешение Change Schema Master (Смена хозяина схемы) для группы Schema Administrators (Администраторы схемы). Оно позволяет членам этой группы перемещать роль хозяина схемы (по FSMO-протоколу) на контроллер домена, где выполнены изменения схемы;
Х наследуемое разрешение Full Control (Полный доступ) для группы Schema Administrators (Администраторы схемы). По умолчанию это единственная груп па с правами записи для всего контейнера Schema. Объекты схемы не обладают особыми индивидуальными параметрами безопасности и наследуют их от роди тельской папки контейнера Schema;
Х разрешения Replicating Directory Changes (Репликация изменений каталога), Replication Synchronize (Синхронизация репликации) и Manage Replication Topology (Управление топологией репликации) для группы Enterprise Domain Controllers (Контроллеры домена ). Они позволяют членам этой группы авто матически управлять репликацией схемы в лесе;
Х разрешения Replicating Directory Changes (Репликация изменений каталога), Replication Synchronize (Синхронизация репликации) и Manage Replication Topology (Управление топологией репликации) для группы Administrators (Ад министраторы) позволяют администраторам отдельных контроллеров домена устранять неполадки репликации;
Х разрешения Read (Чтение) для группы Authenticated Users (Прошедшие провер ку) позволяет членам этой группы просматривать схему;
Х аудит операций записи Ч Writes (Запись всех свойств), выполняемых группой Everyone (Все). Активизация политики аудита гарантирует, что операции запи си в каталог (для любого объекта) проверяются автоматически, без вмешатель ства пользователя. Наследуемая запись АСЕ обеспечивает удобный способ уда ления политики аудита.
ГЛАВА 4 Схема Active Directory Стандартные параметры безопасность атрибутов и классов Все атрибуты и классы наследуют списки ACL контейнера Schema. Это обеспечи вает согласованность и однородность схемы с точки зрения системы безопасности.
Примечание В стандартной конфигурации безопасности только группе Schema Administrators предоставлены права записи в контейнер Schema.
Расширение схемы Если существующие описания классов и атрибутов в схеме не отвечают требовани ям Вашей организации, Вы вправе расширить схему путем добавления или изме нения ее объектов. Допускается также динамическое расширение схемы Active Directory Ч когда сразу же после создания новых атрибутов и классов приложение немедленно использует эти дополнения. Обновление схемы заключается в созда нии или изменении объектов в контейнере схемы. Таким образом, создаваемые объекты доступны во всем предприятии.
Примечание Как и все объекты Active Directory, объекты схемы защищены списка ми ACL, поэтому изменять схему разрешено только пользователю, обладающему соответствующими правами. (Подробнее об ACL - в главе 12 Управление досту пом^.) Добавление или изменение определений класса или атрибутов в схеме подразуме вает добавление или изменение соответствующих объектов класса dassSchema или attribute Schema, При этом выполняются те же операции, что и при добавлении или изменении любого объекта в Active Directory. Единственное исключение - провер ка дополнительных условий, которая позволяет гарантировать, что изменения не вызовут нарушения согласованности или сбои в схеме.
Когда следует расширять схему Обновление схемы Ч это чрезвычайно важный шаг, влияющий на весь каталог, по* этому мы не рекомендуем его без особой необходимости. Многие коррективы в схе ме нельзя отменить, поэтому прежде тщательно планируйте их. Несогласованность схемы может вызвать серьезные неполадки и даже повредить или вывести из строя Active Directory. Очень часто ошибки обновления схемы обнаруживаются не сразу.
Прежде чем приступить к изменению схемы, следует тщательно изучить стандарт ную схему Active Directory, поставляемую с Windows 2000, дабы удостовериться, что имеющиеся классы или атрибуты не позволяют решить поставленную задачу.
Следует четко понимать какие типы изменений допустимы, а какие Ч нет. Далее перечислены допустимые изменения схемы:
Х создание классов;
Х изменение существующих классов;
Х создание атрибутов;
Х изменение имеющихся атрибутов;
Х отключение классов и атрибутов.
Служба каталогов Active Directory 182 ЧАСТЬ Существует три способа эффективного добавления новых классов:
Х расширение имеющегося класса путем добавления атрибутов или дополнитель ных допустимых родителей;
Х порождение нового подкласса от имеющегося класса, Такой подкласс: содержит все атрибуты исходного класса, а также любые указанные Вами дополнитель ные атрибуты;
Х создание абсолютно нового класса с любыми необходимыми атрибутами.
Расширение класса необходимо, если выполняются следующие условия:
Х имеющемуся классу требуются дополнительные атрибуты, но в остальном он отвечает вашим потребностям. Например, Вы можете добавить атрибут purchasingLimit (ограничение на объем приобретений) в класс user и создать на его основе объект, соответствующий пользователю, который является менедже ром центра затрат и отвечает за покупки;
Х не обязательно идентифицировать расширенный класс как отличный от исходно го. То есть при расширении класса нет необходимости создавать новый класс достаточно расширить старый;
Х обеспечьте возможность управления дополнительными атрибутами объектов средствами консоли Active Directory Users and Computers (Active Directory пользователи и компьютеры). Для этого следует расширить страницы свойств для таких объектов.
Создавать подкласс существующего класса следует, если выполняются следующие условия:
Х имеющемуся классу требуются дополнительные атрибуты, но в остальном он отвечает Вашим требованиям;
Х требуется определить расширенный класс и отделить его от исходного класса;
Х для управления расширенными атрибутами надо использовать существующую консоль Active Directory Users and Computers.
Как расширить схему Приступать к расширению схемы следует только после тщательного планирования всех будущих изменений. Поскольку изменение схемы Ч крайне важная операция, способная повлечь серьезные последствия, в Windows 2000 предусмотрено три фун кции безопасности, или перекрестные блокировки, которые контролируют измене ния схемы.
Х По умолчанию изменение схемы запрещено на всех контроллерах домена. Раз решите обновление схемы на отдельном контроллере посредством консоли Active Directory Schema.
Х Объект схемы защищен механизмом безопасности Windows 2000: для редакти рования схемы администраторы должны иметь явно заданные разрешения или принадлежать к группе Schema Admins (Администраторы схемы).
Х Обновление схемы возможно только на одном контроллере домена на предпри ятии Ч владельце роли хозяина схемы. Это одна из FSMO-ролей, Схема Active Directory ГЛАВА Установка расширений схемы Рекомендуется строго контролировать обновления схемы па всех сайтах клиентов.
Если определенная служба нуждается в установке расширений схемы, Вы должны устанавливать их по отдельности одним из следующих методов:
Х расширить схему средствами сценариев LDIF. Это позволяет клиентам обновлять схему независимо и выполнять эту операцию перед продолжением установки;
Х расширить схему программными средствами.
Помимо процедуры раздельной установки расширений схемы рекомендуется тща тельно документировать все расширения. В документации необходимо регистриро вать следующие сведения:
Х центр сертификации, в котором получен префикс кода объекта;
Х описание новой иерархии классов, содержащей новые классы;
Х значения стандартного дескриптора безопасности и дескриптора безопасности Windows NT (при необходимости);
Х относительное составное имя (си), отображаемое имя LDAP (iDAPDisplayName), код объекта, описание каждого нового класса и атрибута, а также способы его предполагаемого использования. Кроме того, следует дать ответы на следующие вопросы:
Х реплицируется ли атрибут на серверы глобального каталога;
Х индексирован ли атрибут;
Х каковы ожидаемая частота обновления и ожидаемый размер атрибута. Это позволит оценить влияние расширения на репликацию;
Х каков диапазон допустимых значений атрибута (rangeLower и rangeUpper).
Программа установки расширений схемы должна позволять пользователю завер шить работу без внесения каких-либо изменений в схему.
Определение атрибута Schema-ID-GUID При создании атрибутов или классов в Active Directory задавайте атрибут schemalDGUID. В нем указывается глобально уникальный идентификатор (GU1D) класса или атрибута. В отличие от кода объекта, получаемого в центре сертифика ции, для создания GUID применяется специальный алгоритм. Атрибуты schemalDGUID используются в списках ACL для предоставления индивидуальных привилегий для отдельных классов или атрибутов.
Именование При изменении схемы следует придерживаться указанных ниже правил, касающих ся значений атрибутов относительного составного имени объекта (сн) и отобража емого имени LDAP (iDAPDisplayName), Относительное составное имя (Common-Name - ел) Х Сначала следует префикс компании. Эта часть состоит из зарегистрированного доменного DNS-имени компании и четырех цифр текущего года, разделенных дефисом (-).
Х Следующий символ в си Ч дефис (-).
ЧАСТЬ 1 Служба каталогов Active Directory Х Далее расположен префикс, уникальный для продукта, Эта часть имени должна кратко характеризовать продукт, быть уникальной для организации и начинать ся с прописной буквы. Для регистра остальных букв префикса никаких ограни чений не предусматривается.
Х Следующий символ в сп Ч дефис (-).
Х Далее следует подставить в си имя атрибута или класса.
Отображаемое имя LDAP (IDAPDisplayName) т Для создания отображаемого имени LDAP используется сп.
Первым символом IDAPDisplayName должна быть строчная буква.
т Х Буквы после дефисов (-) должны быть прописными.
Х Удалите все дефисы в части префикса, расположенной после уникального пре фикса продукта, но не удаляйте дефис, который стоит сразу после него.
Таблица 4-6 иллюстрирует правила именования в отношении относительных со ставных имен и отображаемых имен LDAP.
Таблица 4-6. Правила именования Отображаемое имя LDAP (IDAPDisplayName) Относительное составное имя (со) Microsoft-Corn-1999-MQ-Attribute-l Microsoft-Com-1999-mQAttributeI Micmsoft-Com-1999-EXCHANGE- Microsoft-Com-1999-exchangeattribute Attribute- Обновление схемы Средствами консоли Active Directory Schema (Схема Active Directory) на соответ ствующем контроллере домена разрешите изменения схемы.
Примечание Поскольку изменения схемы выполняются редко и чреваты серьезны ми последствиями, оснастка Active Directory Schema не устанавливается по умол чанию вместе с Windows 2000 Server. Чтобы она появилась в списке доступных ос насток ММС, ее DLL-библиотеку следует зарегистрировать, выполнив команду Regsvr32 Schmmgmt.dll из командной строки.
^ Снятие запрета на изменения схемы 1. Откроите консоль Active Directory Schema (Схема Active Directoiy).
2. В дереве консоли щелкните правой кнопкой мыши Active Directory Schema (Схема Active Directory) и выберите команду Operations Master (Хозяин опе раций).
3. Установите флажок The Schema may be modified on this server (Схема может быть изменена на этом контроллере домена) и щелкните кнопку ОК.
Положение флажка The Schema may be modified on this server сохраняется в пара метре реестра Schema Update Allowed в разделе HKEY_LOCAL_MACHJNE\ SYSTEM\CurrentControISet\Services\NTDS\Parameters. Active Directory добавля ет этот параметр в реестр, когда Вы изменяете значение по умолчанию средствами консоли Active Directory Schema.
Схема Active Directory ГЛАВА Внимание! Не модифицируйте реестр самостоятельно (с помощью редактора реес тра) Ч делайте это лишь в крайнем случае, когда другого выхода нет. В отличие от инструментов управления редактор реестра обходит стандартные средства защиты, призванные не допускать ввода конфликтующих значений параметров, а также спо собные снизить быстродействие системы или разрушить ее. Не исключено, что по следствия прямого редактирования реестра окажутся не такими, как Вы ожидали, и, возможно, Вам придется переустанавливать Windows 2000. Для настройки и кон фигурирования Windows 2000 рекомендуется использовать Control Panel (Панель управления) или Microsoft Management Console (Консоль управления Microsoft).
Перед изменением реестра рекомендуется делать резервную копию. Подробнее о редактировании параметров реестра Ч в справочной системе редактора реестра.
Подробнее о реестре Ч в техническом руководстве Technical Reference Microsoft Windows 2000 Professional Resource Kit (файл Regcntry.chm) Группа Schema Administrators Правом изменения схемы обладают члены группы Schema Admins (Администрато ры схемы). По умолчанию единственный член этой группы безопасности Ч учет ная запись Administrator (Администратор) в корневом домене предприятия. Дру гие администраторы схемы надо создавать явным образом.
Внимание! Количество членов группы Schema Admins следует строго ограничить, дабы предотвратить несанкционированный доступ к схеме.
Состав группы Schema Admins можно просмотреть и отредактировать в консоли Active Directory Users and Computers (Active Directory Ч пользователи и компью теры).
^ Добавление учетной записи в группу Schema Admins 1. Откройте консоль Active Directory Users and Computers (Active Directory пользователи и компьютеры).
2. Дважды щелкните название домена, в котором расположена учетная запись.
3. Дважды щелкните папку Users, 4. Щелкните группу безопасности Schema Admins (Администраторы схемы) пра вой кнопкой и выберите команду Properties (Свойства).
5. Перейдите на вкладку Members (Члены группы).
6. Если учетной записи в этом списке нет, щелкните кнопку Add (Добавить).
7. В открывшемся окне выберите или введите имя учетной записи.
8. Щелкните кнопку Add (Добавить), а затем Ч ОК.
Роль хозяина схемы Для предотвращения конфликтов служба Active Directory выполняет обновления схемы в режиме одиночного хозяина операций. Один из контроллеров домена пред приятия, позволяющий выполнять обновления схемы, в данное время называется хозяином схемы (schema master). Исполнение роли хозяина схемы и обновление объектов схемы в каждый момент времени возможно только на одном из контрол леров домена во всем предприятии.
Служба каталогов Active Directory 186 ЧАСТЬ Примечание Для обновления схемы контроллер домена, выполняющий роль хозя ина схемы, должен быть подключен к сети.
Роль хозяина схемы можно передать другому контроллеру домена. Текущий хозя ин схемы предприятия идентифицируется по значению атрибута fSMORoleOwner контейнера Schema. По умолчанию хозяином схемы становится первый контрол лер домена, установленный на предприятии.
Хотя вносить изменения в схему уполномочен только контроллер домена, выпол няющий роль хозяина схемы, для обновления схемы подключаться к этому кон троллеру не обязательно. Текущий контроллер домена, не обладающий данной ро лью, автоматически возвратит перенаправление на действительного хозяина схемы.
При необходимости перемещение роли хозяина схемы на другой контроллер домена выполняется средствами консоли Active Directory Schema (Схема Active Director}').
>Х Просмотр и перемещение роли текущего хозяина схемы средствами консоли Active Directory Schema 1. Откройте ММС и установите оснастку Active Directory Schema (Схема Active Directory).
2. В дереве консоли щелкните правой кнопкой мыши Active Directory Schema (Схема Active Directory) и в контекстном меню выберите команду Operations Master (Хозяин операций).
3. В открывшемся окне в области Current Operations Master (Текущий хозяин операций) отображаются сведения о текущем хозяине схемы.
Чтобы оставить хозяина схемы без изменений, щелкните кнопку ОК.
Чтобы передать роль хозяина схемы другому контроллеру, щелкните кнопку Change (Сменить).
Если текущий контроллер домена, имя которого отображается в поле Current Focus (Текущее местоположение), в данный момент является хозяином опера ций, необходимо сперва средствами консоли Active Directory Domains and Trusts (Active Directory Ч домены и доверие) подключиться к другому контроллеру домена. Нельзя, подключившись к текущему хозяину операций, передать его FSMO-роль другому контроллеру.
Подробнее об использовании консоли Active Directory Schema Ч в разделе Рас ширение схемы ранее в этой главе.
Для перемещения FSMO-роли также используют утилиту командной строки Ntdsutil.
Она расположена в папке %Systemroot%\System32. Подробнее о переносе FSMO-роли средствами Ntdsutil Ч в главе 7 Управление операциями одиночного хозяина*.
^ Перемещение роли хозяина схемы средствами служебной программы Ntdsutil 1. Запустите Ntdsutil, выполнив в командной строке команду ntdsutil. [Заметьте, что в любой момент Вы можете получить контекстную справку, если введете в приглашении данной программы вопросительный знак (?)].
2. В приглашении ntdsutil.exe введите:
roles 3. В приглашении fsmo maintenance введите:
connections ГЛАВА 4 Схема Active Directory 4. Для просмотра информации о текущем соединении в приглашении server con nections введите:
info При необходимости для подключения к серверу, который станет хозяином cxi. мы, введите соответствующую команду. Для получения дополнительных сведе ний введите вопросительный знак (?).
5. Чтобы вернуться в приглашение fsmo maintenance, введите:
quit 6. Чтобы передать роль хозяина схемы, введите:
t r a n s f e r schema master Перемещение роли хозяина схемы также выполняется программно из приложения.
Перед изменением схемы приложение должно явно проверить, является ли теку щий контроллер домена хозяином схемы, и при отрицательном результате Ч явло запросить операцию перемещения роли.
Для иллюстрации процесса перемещения рассмотрим сценарий, в котором комть ютер А Ч текущий владелец роли хозяина схемы, а компьютеру В требуется рас ширить схему. Чтобы запросить перемещение FSMO-роли от компьютера А програм ма должна добавить операционный атрибут becomeSchemaMaster со значением 1 в объект rootDSE (то есть в объект с пустым составным именем) на компьютере В.
Этот операционный атрибут никогда не определяется в схеме и не хранится базе данных, а служит только для того, чтобы немедленно начать определенные действия в каталоге.
В данном случае сервер (компьютер В) отправит запрос компьютеру А на переме щение роли. Последний, получив этот запрос, изменит значение атрибута /SMQ RoleOwner своего контейнера схемы на имя компьютера В и возвратит новое значе ние атрибута на компьютер В. Кроме того, при необходимости компьютер А воз вратит все изменения схемы, выполненные на нем, но еше не распространившиеся на компьютер В. (Несогласованность может возникнуть по причине задержки реп ликации). Получив ответ от А, компьютер В внесет все изменения и станет теку щим хозяином схемы.
Примечание Компьютер В, новый хозяин схемы, в итоге получит все предыдущие обновления схемы предприятия и, следовательно, самую последнюю версию схемы.
Если старый хозяин схемы недоступен или вышел из строя, можно принудительно передать роль хозяина схемы и выполнить изменения схемы на новом хозяине опе раций. Однако прибегать к таким мерам стоит только в крайнем случае. При при нудительной передаче роли хозяина схемы последние изменения схемы, выполнен ные на старом хозяине, теряются, кроме того, высока вероятность появления кон фликтующих изменений на других контроллерах в лесе. В последнем случае пс. на добится очистить каталог, предварительно отключив его от сети.
Внимэние! Принудительное перемещение роли хозяина схемы радикальная мера, предпринимать которую следует, лишь когда текущий хозяин схемы не способен выполнять свои функции или не подлежит восстановлению. Перед принудитель ным перемещением роли хозяина схемы отключите текущий хозяин от сети. Убе дитесь, что будущий владелец роли получил все последние обновления схемы.
Служба каталогов Active Directory 188 ЧАСТЬ ^ Принудительное перемещение роли хозяина схемы средствами Ntdsutil 1. Запустите Ntdsutil, выполнив в командной строке команду ntdsutil. [Заметьте, что в любой момент Вы можете получить контекстную справку, если введете в приглашении данной программы вопросительный знак (?)].
2. В приглашении ntdsutil.exe введите:
roles В приглашении fsmo maintenance введите:
3.
connections 4. Для просмотра информации о текущем соединении в приглашении server con nections введите:
info При необходимости для подключения к серверу, который станет хозяином схе мы, введите соответствующую команду. Для получения дополнительных сведе ний введите вопросительный знак (?).
5. Чтобы вернуться в приглашение fsmo maintenance, введите:
quit 6. Чтобы принудительно передать роль хозяина схемы, введите:
seize schema master Подробнее о перемещении FSMO-роли средствами Ntdsutil Ч в главе 7 Управле ние операциями одиночного хозяина.
Порядок расширения схемы При расширении схемы посредством программы или сценария следует выполнять операции в описанной далее последовательности.
1. Найдите и подключитесь к хозяину схемы. Создайте привязку к схеме на кон троллере - - хозяине схемы. Не перемещайте роль хозяина схемы между контрол лерами домена без особой нужды. В любой момент времени выполнять такую важную операцию, как обновление схемы, разрешается только одному контрол леру домена Ч хозяину схемы. Если в сети несколько серверов под управлени ем Windows 2000, следует убедиться, что обновления будут выполняться имен но на хозяине FSMO-роли.
2. Проверьте наличие у Вас полномочий аа обновление схемы. Для этого проверь те значение атрибута allowedCkildClassesEffecfive контейнера схемы. Если в дан ном атрибуте нет значений attribitteSchema и>
4. Добавьте новые атрибуты.
5. Добавьте новые классы.
6. Добавьте атрибуты в классы. На все новые атрибуты обязательно ссылаться по коду объектов, так как их имена еще не загружены в кэш. До перезагрузки кэша после добавления новых атрибутов использовать имена новых атрибутов нелыш.
7. Все контроллеры домена обновляют свой кэш схемы спустя 5 минут после ее изменения. Если изменения нужно внести быстрее, обновите кэш вручную.
8. Если для добавления новых классов или атрибутов Вы создали защитную бло кировку, рекомендуется после корректировки восстановить ее, 9. Убедитесь, что программная установка расширения схемы (средствами сценария или ADS1) выделена в отдельную процедуру, то есть Вы должны иметь возмож ность установить расширение независимо от программы.
10. Перед созданием программы, расширяющей схему, изучите сведения на Wrb странице Web Resources по адресу reskit/webresourcc, ссылка Microsoft Platform SDK, далее Ч ссылки Active Di rectory Programmer's Guide и Schema Extensibility.
Примечание Обновлять кэш не обязательно, если внесенные изменения схемы не требуется использовать немедленно. Время переноса корректив в кэш схемы состав ляет примерно 5 минут и зависит от нагрузки на систему.
Добавление и изменение объектов схемы Поскольку объект схемы Ч такой же объект каталога, как и другие, для его добав ления или изменения применяются аналогичные методы. Эти операции выполня ются средствами консоли Active Directory Schema (Схема Active Directory), постав ляемой в составе Windows 2000 и обладающей удобным пользовательским интер фейсом. Кроме того, не возбраняется изменять схему и программными средствами.
Добавление атрибута Рекомендуется по возможности использовать стандартные атрибуты. Но если Вы все-таки решили создать новый атрибут, придерживайтесь определенных правил.
Х В качестве атрибута пате используйте сп (относительное составное имя);
это имя по умолчанию для большинства классов, в том числе для прямых потомков класса top. Поскольку сп - индексированный атрибут, объект легко удастся най ти по имени.
Х Старайтесь избегать использования больших многозначных атрибутов, для хра нения и поиска которых требуется много ресурсов. В Active Directory реализо ван элемент управления LDAP для последовательного чтения таких атрибутов, но не все LDAP-клиенты поддерживают его.
Х Помните, что атрибуты плоские: у них нет подструктуры. Все атрибуты клас са должны относиться напрямую к экземплярам данного класса, так что Вам предоставляется возможность попрактиковаться в нормализации данных.
Служба каталогов Active Directory 190 ЧАСТЬ Для добавления нового атрибута в схему необходимо создать новый объект атри бута. Сначала создайте параметр блокировки Active Directory, как описано в разде ле Как расширять схему ранее в этой главе. Затем выполните перечисленные ниже операции.
1. Выберите имя для атрибута.
2. Получите действительный код объекта в центре сертификации.
3. Задайте синтаксис атрибута.
4. Определите тип атрибута Ч одно- или многозначный.
5. Определите необходимость и способ индексации атрибута.
6. Определите необходимость репликации атрибута в глобальный каталог.
В любом, определенном Вами атрибуте часть атрибутов обязательны, а остальные Ч дополнительные. Список тех и других приведен в таблицах 4-7 и 4-8.
Таблица 4-7. Обязательные атрибуты новых объектов класса schemaAttribute Обязательный атрибут Значение по умолчанию He определено Ч имя задает администратор Не определено Ч администратор обязан присвоить значение objectClass attributeSchema Не определено Ч администратор обязан присвоить значение иден attributelD тификатора объекта Не определено Ч администратор обязан задать один из синтакси attributeSyntax сов, определенных в Active Director}' Не определено Ч администратор обязан присвоить значение oMSyntax oMSyntax, соответствующее синтаксису атрибута Если значение не указано, по умолчанию генерируется програм schemalDGUID мой uuidgen Определяется значением атрибута defaultSecurityDescriptor класса n TSecurityDescriptor attributeSchema FALSE, то есть по умолчанию атрибут Ч однозначный isSingleValued Если значение НУ указано, по умолчанию присваивается значение сп IDAPDisplayName Таблица 4-8. Дополнительные атрибуты новых объектов класса schemaAttribute Дополнительный атрибут Значение по умолчанию rangeLower He определено Ч значение присваивается администратором rangeUpper Не определено Ч значение присваивается администратором FALSE isMemberOfPartialReplicaSet Не определено. На данный момент определено 4 бита: 1 Ч searchFlags индексировать только атрибут;
2 Ч индексировать контей нер и атрибут;
4 Ч добавить данный атрибут в набор не однозначного разрешения имен (Ambiguous Name Resolution, ANR) (используется совместно с 1);
8 - сохра нять этот атрибут при логическом удалении объекта (атри бут должен быть доступным после захоронения объекта каталога) Схема Active Directory ГЛАВА Предположим, Вы хотите добавить новый атрибут с именем userName. Каждый его экземпляр должен занимать одну строку символов Unicode длиной от 1 до символов. Такой атрибут определяется следующим образом:
Х сп = userName;
Х objectClass = attribute Schema', Х attributelD = 1.2.567.8901234.5.6.879 (действительное значение кода объекта);
Х attributeSyntax = 2.5.5.12 (код синтаксиса строки Unicode);
Х oMSyntax = 64 (код синтаксиса строки Unicode);
Х isSingleValued = TRUE (однозначный атрибут);
Х rangeLower = 1 (минимальная длина строки);
Х rangeUpper = 1000 (максимальная длина строки).
Изменение атрибута Чтобы изменить атрибут, следует изменить объект, его описывающий. Для обеспече ния согласованности и безопасности некоторым атрибутам каждого объекта класса schemaAttribute присваивается статус системный. Системные атрибуты объектов класса schemaAttribute изменить нельзя Ч даже для новых, созданных Вами атрибу тов. Признаком системного атрибута является значение TRUE атрибута systemOnly.
Далее перечислены системные атрибуты объектов класса schemaAttribute.
Х attributelD;
Х sckemalDGUID;
Х attributeSyntax;
Х oMSyntax;
Х isSingleValued;
Х extendedCharsAllowed;
Х systemOnly;
Х objectClass;
Х instanceType.
Добавление класса Чтобы создать новый класс, нужно добавить в схему новый объект класса dassSchema со всеми требуемыми атрибутами. Снимите блокировку безопасности Active Directory, как описано в разделе Как расширить схему ранее в этой главе, и перед добавлением класса выполните операции, описанные ниже.
1. Присвойте имя классу.
2. Получите действительный код объекта в центре сертификации.
3. Задайте категорию класса.
4. Укажите класс, которому наследует создаваемый Вами класс.
У каждого класса есть обязательные и дополнительные атрибуты. Их значения по умолчанию описаны в таблицах 4-9 и 4-10.
Служба каталогов Active Directory 192 ЧАСТЬ Таблица 4-9. Обязательные атрибуты новых объектов класса schemaClass Обязательный атрибут Значение по умолчанию Не определено Ч имя задает администратор сп Класс 88, поскольку этот класс не относится ни к одной катего objectClassCategpry рии. Другие допустимые значения: структурный (Structural), лабстрактный* (Abstract) или дополнительный (Auxiliary) Не определено Ч администратор обязан присвоить значение иден governsID тификатора объекта Не определено Ч администратор обязан указать структурный класс possSuperiors или допустимых родителей объектов создаваемого класса He определено Ч администратор обязан указать значение suhClassOf Автоматически генерируется системой sckemalDGUID Определяется значением атрибута defaultSecmityDescriptor класса nTSecurityDescriptor attributeSchema Если значение не указано, по умолчанию присваивается значение сп IDAPDisplayName Таблица 4-10. Дополнительные атрибуты новых объектов класса schemaClass Дополнительный атрибут Значение по умолчанию Если не указан дескриптор безопасности по умолчанию, defaultSecurityDescriptor используется дескриптор непосредственного надкласса Список дополнительных классов, которым наследует дан auxiliaryС'lass ный класс Для любого нового класса обязательно определить атрибуты сп, objectClass и governsID.
Впрочем, чтобы создание класса имело практический смысл, следует также опре делить некоторые из атрибутов mustContain, may Contain и possSuperiors. Любые ат рибуты, которые Вы указываете при создании нового класса, должны существовать.
Таким образом, прежде чем приступить к созданию нового класса с новыми атри бутами надо добавить в схему эти атрибуты.
Идентификатор объекта governsID нового класса должен быть уникален не только в рамках предприятия, но и глобально.
Допустим, Вы хотите добавить новый класс Friend, предназначенный для хранения информации о друзьях. Объекты этого класса должны содержать имя друга и, при необходимости, его адрес или номер телефона. Так как друг Ч это человек, Вы за планировали, что объекты класса Friend должны иметь такие же обязательные и до полнительные атрибуты и родительские объекты, что и у объектов стандартного класса Person, который Вы определили ранее. В этом случае следует добавить сле дующее описание класса:
Х сп = Friend', Х objectClass =>
Х subClassOf = Person;
Х governsID = 1.2.345.678901.2.3.45 (допустимое значение идентификатора объекта);
Х mustContain = givenName, sn;
Х таг/Contain = Address, phone-number.
CxeMaActive Directory ГЛАВА Изменение класса Чтобы изменить свойства класса, следует изменить объект, его описывающий. Для обеспечения согласованности и безопасности некоторым атрибутам каждого объекта класса schemaClass присваивается статус системный. Системные атрибуты объек тов класса schemaClass изменить нельзя Ч даже для новых, созданных Вами классов.
Признаком системного атрибута является значение TRUE атрибута systemOnly.
Далее перечислены системные атрибуты объектов класса schemaClass.
Х governsID', Х schemalDGUID\ т rDNAttID;
Х subClassOf] Х systemMustContain;
Х systemMay'Contain;
Х systemPossSuperiors;
Х system Auxiliary>
Х objectClassCategory;
Х systemOnly;
Х objectClass;
Х instanceType.
Проверка системой выполнения определенных условий и ограничений на изменение схемы При добавлении или изменении классов и/или атрибутов Active Directory прове ряет некоторые параметры - соблюдение логической целостности и конфигурацию безопасности.
Проверка целостности При изменении класса или атрибута система проверяет уникальность значений атрибутов IDAPDisplayName и schemalDGUID, а также корректность значения ЮЛ PDisplayName.
Добавление в схему нового объекта класс? успешно только при выполнении всех перечисленных далее условий (кроме обычных ограничений на расширение схемы):
Х значение атрибута govemsID уникально;
Х все атрибуты, указанные в systemMay Contain, таг/Contain, systemMust Contain и mustContain, существуют;
Х все классы, указанные в атрибутах subClassOJ, systemAitxiliary>
Х значение атрибута objectClassCategory всех классов, указанных в атрибуте sya tem Auxiliary>
Служба каталогов Active Directory 194 ЧАСТЬ Х значение атрибута objectClassCategory всех классов, указанных в атрибуте system PossSuperiors и possSuperiors, соответствует либо категории класс 88, либо ка тегории структурных классов;
Х классы в списке subClassOf соответствуют определенным спецификациям Х. для наследуемых иерархий: абстрактные классы наследуют другим абстрактным классам, дополнительные классы никогда не наследуют структурным, а струк турные классы не наследуют дополнительным;
Х атрибут, указанный в атрибуте rDNAttID, однозначен и обладает синтаксисом строки символов Unicode.
При изменении атрибута должны соблюдаться следующие условия:
Х значение attributelD уникально;
Х значение mAPUD (если задано) уникально;
Х в паре атрибутов mngeLower и rangeUpper (если эти атрибуты заданы) значение range Lower меньше range-Upper, Х значения attributeSyntax и оМSyntax соответствуют друг другу, как указано в таб лице 4-11;
Х если у атрибута синтаксис объекта oMSyntax = 127, ему соответствует коррект ный номер oMObjectClass согласно таблице 4-12;
Х значение linkID (если задано) уникально. Кроме того, обратной ссылке должна соответствовать определенная прямая ссылка. (Подробнее о ссылках Ч в главе Хранение данных в Active Directory).
Примечание Полное описание синтаксиса содержит атрибуты attributeSyntax и oMSyntax. Следовательно, всякий раз, когда вместе с attributeSyntax может исполь зоваться более одного oMSyntax, надо указать корректное значение oMSyntax.
Таблица 4-11. Значения attributeSyntax и соответствующих им синтаксисов Значение attributeSyntax^ Соответствующее значение синтаксиса oMSyntax Номер синтаксиса Object(DN-Binary) (Двоичное DN) 2.5.5.1 2.5.5.2 String(Objcct-Identifier) (Идентификатор объекта) 2.5.5.3 Case-Sensitive String (Строка с учетом регистра) 2.5.5.4 CaselgnorcString(Teletex) (Строка без учета регистра) 2.5.5.5 String(Printable), String(IA5) (1А5-строка) String(Numeric) (Числовая строка) 2.5.5. 2.5.5.7 Object(OR-Name) (ИЛИ имя) или Object(DN-Binary) (Двоичное DN).
Отличие в значении oMObjectClass 2.5.5.8 Boolean (Логическое) ' 2.5.5.9 Integer (Целое), Enumeration 2, (Перечисление) 2.5.5.10 String(Octet) (Строка октета) String(UTC-Time) (Время UTC), String 2.5.5.11 23, (Generalized-Time) (Обобщенное время) Схема Active Directory ГЛАВА Таблица 4-11. (продолжение) Соответствующее значение синтаксиса oMSyntax Номер синтаксиса 2.5.5.12 String(Unicode) (Строка Юникода) 2.5.5.13 Object(Presentation-Address) (Адрес) 2.5.5.14 Object (Access-Point) (Точка доступа) или Object(DN-String) (Строка различающегося имени). Отличие в значении oMObjectClass 2.5.5.15 String(NT-Sec-Desc) (Дескриптор безопасности NT) 2.5.5.16 Largelnteger (Длинное целое) 2.5.5.17 String(Sid) (SID) i Для облегчения выбора синтаксиса oMSyntax для каждого имени указан номер синтаксиса.
Для атрибутов со значением oMSyntax = 127 необходимо также корректно указать oMObjectClass, соответствующий атрибуту attribute Syntax. К атрибутам с любым другим значением oMSyntax это не относится, значение атрибута oMObjectClass раз решается не задавать. Поскольку oMObjectClass Ч двоичное значение, его иногда неудобно задавать. Кроме того, в большинстве случаев существует однозначное со ответствие между attributeSyntax и oMObjectClass, и атрибуту oMObjectClass присва ивается значение по умолчанию, если иное не указано пользователем. Впрочем, иногда это соответствие неоднозначно, тогда этому атрибуту присваивается наибо лее популярное значение. В таблице 4-12 перечислены значения oMObjectClass, ко торые соответствуют разным attributeSyntax для атрибутов с oMSyntax равным 127.
Таблица 4-12. Значения attributeSyntax и соответствующие им значения oMObjectClass Значение attributeSyntax Значения oMQblectGlass^ 2.5.5.1 \х2ВОС0287731СООЙ54А [Object(DN-Binary)] 2.5.5.7 \х56060102050ВШ [Object(OR-Name)] или \x2A864886F7140101010B fObject(DN-Binary)]. По умолчанию равно Object(OR-Name), если пользователь не указал иное 2.5.5.13 \x2BOC0287731C00855C Object(Presentation-Address)] 2.5.5.14 \x2BOC0287731C00853E [Object(Access-Point)] или \x2A864886F7140101010C [Object(DN-Strmg)] По умолчанию равно Object(Access-Point), если пользователь не указал иное Для удобства в квадратных скобках указаны имена синтаксисов.
Проверка конфигурации безопасности Проверка конфигурации безопасности позволяет снизить вероятность одновремен ного изменения схемы пользователями или приложениями. Такая проверка обяза тельна, так как к описанию схемы могут совместно обращаться несколько прило жений, Существуют определенные ограничения на изменение стандартных объектов схе мы Active Directory. В ряде случаев эти ограничения определяются тем, является ли объект стандартным или добавлен позже. В этом смысле объекты схемы подраз деляются на категории 1 и 2.
Объекты первой категорий (Category I objects) Ч это объекты стандартной схемы, поставляемой с Windows 2000. Объекты второй категорий (Category 2 objects) Служба каталогов Active Directory 196 ЧАСТЬ добавлены в схему администратором или приложениями после установки Active Directory. Категория объекта определяется значением второго бита (начиная с младшего) в значении атрибута systemFlags. Если этот бит установлен в 1 (соответ ствующий флаг - FLAG_SCHEMA_BASE_OBJECT), объект является частью стандартной схемы и относится к категории 1. В обратном случае (бит установлен в 0 или атрибут отсутствует), объект относится к категории 2.
На обе категории объектов схемы налагаются следующие ограничения:
Х нельзя добавлять новые значения атрибута mustContain в класс напрямую либо через наследование посредством добавления дополнительного класса;
Х нельзя добавлять или удалять значения атрибута класса mustContain напрямую либо через наследование.
Следующие ограничения налагаются на объекты первой категории:
Х нельзя изменить значения rangeLoweru rangeUpper атрибута;
Х нельзя изменять значение atributeSecurity GUID атрибута;
Х нельзя отключить класс или атрибут;
Х нельзя изменить значение IDAPDisplayName класса или атрибута;
Х нельзя переименовать класс или атрибут;
Х нельзя изменить значение defaultObjectCategory класса;
Х нельзя изменить значение ohjectCtassCategory экземпляров класса.
Отключение объектов схемы Нельзя отключить стандартные объекты схемы Active Directory. Это разрешается только для добавленных объектов.
Иногда необходимо удалить классы или атрибуты схемы, которые не нужны Ва шей организации, однако эта операция иногда чревата серьезными проблемами.
Например, что произойдет с другими объектами схемы, которые используют уда ляемый класс или атрибут? Поскольку на проверку и очистку каталога в рамках предприятия требуется много времени и затрат, Active Directory не поддерживает физического удаления объектов схемы. Вместо этого в службе каталогов реализо ван механизм их отключения, после чего объект схемы просто не используется в работе каталога, что более корректно, чем удаление.
Класс или атрибут отключается путем присвоения логическому атрибуту isDefunct объекта схемы значение TRUE. Существует множество способов определить состо яние (отключен или активен) объектов схемы: из программы для этого выполняет ся поиск объектов схемы со значением атрибута isDefunct равным TRUE (или, если значение атрибута isDefunct определенного объекта схемы равен TRUE, можно про верить, отключен ли объект). Найти отключенные объекты схемы можно, восполь зовавшись функцией поиска Search программы Ldp с фильтром (isDefunct = TRUE).
Подробнее о программе Ldp Ч в главе 10 Выявление и устранение неполадок, а также восстановление Active Directory.
Примечание На данный момент просмотреть отключенные объекты схемы средства ми пользовательского интерфейса нельзя. Для этого придется задействовать один из описанных методов.
Схема Active Directory ГЛАВА Как и при добавлении или модификации, при отключении класса или атрибута система выполняет проверку некоторых условий. Это необходимо для сохранения логической целостности схемы. В частности при попытке отключить класс Active Directory проверяет, есть ли на него ссылки в атрибутах subClassOf, auxiliary>
Отключенный объект схемы можно включить, то есть снопа сделать активным, уда лив атрибут isDefunct из объекта либо присвоив этому атрибуту значение FALSE. Это выполняется средствами консоли Active Directory Schema. Поскольку восстановле ние отключенного объекта схемы аналогично добавлению объекта, Active Directory выполняет проверку тех же условий, что и при добавлении объекта схемы.
^ Отмена отключения класса или атрибута средствами консоли Active Directory Schema 1. Откройте консоль Active Directory Schema (Схема Active Directory).
Дважды щелкните папку>
2.
3. Щелкните правой кнопкой мыши требуемый класс или атрибут и в контекст ном меню выберите команду Properties (Свойства).
4. Сбросьте флажок Deactivate this>
2. Щелкните правой кнопкой мыши ADSI Edit и выберите команду Connect to.
Откроется диалоговое окно Connection (рис. 4-3).
ХPath;
f Ccmect№ Point ;
.! f" Bissingwishbd M ХPgfaull (Dj^mato 01 server that you logged in I Рис. 4-3. Диалоговое окно Connection консоли ADSI Edit Служба каталогов Active Directory 198 ЧАСТЬ 3. Убедитесь, что в области Connection Point выбран переключатель Naming Context.
В списке Naming Context выберите Schema. Б поле Name введите описатель 4.
ное имя соединения, значение этого поля по умолчанию - Schema. Щелкните ОК 5. В дереве консоли дважды щелкните значок нового соединения, чтобы отобра зить папку Schema.
6. Дважды щелкните папку Schema.
Через несколько секунд в области сведений отобразится список всех атрибутов и классов.
7. Щелкните правой кнопкой мыши класс или атрибут и выберите команду Pro perties (Свойства).
8. В поле со списком Select which properties to view выберите Optional, затем в поле со списком Select a property to view Ч isDefunct.
9. В поле Edit Attribute введите FALSE (рис. 4-4).
10. Щелкните кнопку Set, а затем - кнопку ОК.
JQpliond Рис. 4-4. Диалоговое окно свойств атрибута Test Attribute Снять отключение объекта схемы разрешается в любой момент времени. Един ственное ограничение: в вызове на такое обновление должен присутствовать толь ко атрибут isDefunct. Это обеспечивает чистоту семантики.
Единственное изменение, допустимое для отключенного объекта, Ч его активиза ция, то есть изменение значения атрибута isDefunct. Другие обновления отключен ных классов или атрибутов запрещены, Ведь отключенные объекты не участвуют в обновлениях, и нет никакого смысла их изменять.
ГЛАВА 4 Схема Active Directory Отключение существующих классов и атрибутов Существуют определенные ограничения на отключение существующих классов и атрибутов:
Х нельзя отключить класс или атрибут первой категории;
Х нельзя отключить атрибут активного класса, поскольку атрибут может оказать.ся обязательным для этого класса, и его отключение не позволит создавать объекты данного класса.
Для отключения атрибута надо присвоить атрибуту isDefunct объекта attributeSchema значение TRUE. Это предотвращает создание новых экземпляров данного атрибу та в каталоге. Для восстановления атрибута присвойте атрибуту isDefunct значение FALSE.
Для отключения класса надо присвоить атрибуту isDefunct объекта>
Влияние отключения объекта схемы на остальные объекты После отключения определенного класса создание новых объектов этого класса или модификация существующих невозможны. Система ведет себя так. как будто этот класс полностью удален, то есть Вы получите те же коды ошибок, что и при ОТСУТ СТВИИ класса. Как и при отключении класса, отключеный атрибут считается несу ществующим;
это касается всех попыток создания новых объектов или модифика ции значения данного атрибута у существующих объектов.
Тем не менее операции поиска и удаления объектов будут выполняться, как обыч но, за единственным исключением: объекты схемы удалять нельзя. Так, пользо ватель может найти и удалить все объекты определенного класса или отдельный атрибут Ч из всех объектов, содержащих его. Таким образом обеспечивается воз можность удаления объектов отключенного класса. Предположим, администратор решил, что определенный класс больше не нужен, и отключил его. Теперь этот класс не удастся изменить. Далее администратор выполняет очистку Active Directory:
удаляет все существующие объекты отключенного класса. Автоматически такая очистка после отключения класса в Active Directory не выполняется.
После отключения атрибута сохраняется возможность удаления его из объектов.
Следует иметь в виду, что удалить разрешается только атрибут целиком, а не его значение. Таким образом, у многозначного атрибута не удастся удалить одно или несколько из его значений Ч только весь атрибут. И это понятно: при удалении от ключенных атрибутов нет причин не удалять атрибут полностью.
Влияние отключения объекта на обновление схемы Отключение объекта схемы влияет не только на существующие объекты каталога, но и на последующие обновления схемы. Это обусловлено тем, что в отличие от остальных объектов каталога обновления схемы подлежат проверке особых усло вий. Далее описано влияние отключения класса или атрибута па последующие об новления схемы.
Х Запрещено любое изменение отключенных классов или атрибутов. Единствен ное отступление от правил Ч это изменение атрибута isDefunct отключенного класса для отмены отключения. Это условие определяется тем, что отключен ные классы или атрибуты не используются при обновлениях схемы.
К Зак Служба каталогов Active Directory 200 ЧАСТЬ Х При проверке различных условии в процессе добавления нового класса или ат рибута, а также при изменении существующего класса или атрибута считается, что отключенные объекты вовсе не существуют. Например, попытка изменить существующий активный класс В путем добавления отключенного атрибута А (mat/Contain = А) не увенчается успехом, поскольку система этот атрибут не найдет - точнее, посчитает его несуществующим. По этой же причине не удаст ся добавить новый подкласс (subClassOf = А) отключенного класса А. Особо обрабатывается попытка создать или модифицировать класс или атрибут, атри буты которого (имя, код объекта, атрибуты iDAPDisplayName, mAPIID или schemalDGUID) отличны от атрибутов активных классов, но совпадают со свой ствами отключенного класса. Такой объект схемы создать не удастся. Для обес печения согласованности схемы система в такой ситуации считает отключенный класс активным.
Отключение объектов схемы чрезвычайно полезно. Оно позволяет легко избавить ся от устаревших объектов схемы, а затем и удалить созданные ранее соответству ющие объекты каталога. С другой стороны, если эти объекты схемы вновь потребу ются, их легко вернуть к активно]'! жизни, просто изменив значение атрибута isDefunct. Этот механизм защищает от случайного удаления объекта схемы, ведь отключение обратимо, причем без каких-либо побочных эффектов. Обратите вни мание, что, поскольку после отключения объекта схемы Active Directory ничего не удаляет, все ранее созданные объекты сохраняются и после восстановления вновь становятся обычными действующими объектами.
Вероятные неполадки, вызываемые изменением схемы При обновлении схемы следует учитывать три основных момента: влияние на реп ликацию, контроль параллельно выполняемых операций и появление объектов не существующих классов.
Репликация Репликация схема на все контроллеры домена в лесе гарантирует, что все ее изме нения на отдельном контроллере распространяются на весь лес, и схема остается согласованной на этом пространстве. Однако вследствие задержки репликации иногда возникает временная несогласованность схемы.
Допустим, на сервере X создается новый класс А и объект этого класса В. Объект В не удастся реплицировать на сервер Y, если при репликации этих изменений объект В реплицируется раньше, чем соответствующий классу А объект схемы. Это вызва но тем, что в реплике схемы сервера Y на тот момент еще нет никаких сведений о классе А.
Подобные неполадки устраняются службой каталогов Active Directory автомати чески Ч явной репликацией контейнера схемы с исходного сервера. Кроме того, репликация схемы вызывает немедленное обновление кэша схемы на сервере-при емнике. После этого повторяется копирование неудачно реплицированного объек та. В предыдущем примере повторная репликация доставит объект-определение класса А и внесет его в кэш схемы на сервере Y. Теперь повторная попытка репли кации объекта В будет удачной.
Контроль параллельно выполняемых операций Active Directory должна предотвращать одновременное выполнение противоречи вых изменений в схеме разными потоками программ (например, когда один поток ГЛАВА 4 Схема Active Directory удаляет атрибут, а другой вносит этот атрибут в список mayContain какого-либо класса).
Для этого каждый поток при выполнении транзакции расширения схемы, автома тически записывает специальный атрибут в контейнер Schema. (Active Directory автоматически вынуждает поток записать этот атрибут, поэтому в тексте програм мы этого отражать не нужно.) В определенный момент времени этот атрибут раз решается записывать только одному потоку. Этот метод гарантирует согласован ность схемы, но при этом неизвестно, какое из обновлений окажется успешным. Об этом следует помнить при обновлении схемы в пакетном режиме, например при установке приложений, использующих Active Directory.
Допустим, что две использующих Active Directory программы, А и В, устанавлива ются одновременно и каждая создает несколько новых объектов схемы. Поскольку Active Directory создает отдельный поток для каждой операции изменения объек та, возможно, что добавление одних объектов схемы, создаваемых программами А и В, завершится успехом (если внутренние потоки не пересекаются), а других нет (когда создающий объект поток программы А пересекается с аналогичным по током программы В и добавление терпит неудачу).
Предположим, что установить программу А не удалось. Повторная установка не возможна, так как некоторые из создаваемых ею объектов уже присутствуют в схе ме, и попытка их повторного создания приведет к ошибке. Вот почему не рекомен дуется одновременно запускать программы, изменяющие схему. Исключение со ставляют программы, которые перед внесением изменений в схему проверяют уже существующие в ней классы и атрибуты.
Объекты, ставшими недействительными из-за изменения схемы Изменения схемы способны сделать недействительными объекты определенного класса. Допустим, объект X Ч это экземпляр класса Y, а тот, в свою очередь, в атри буте mayContain содержит значение, соответствующее атрибуту Z. Таким образом, объекту X разрешается иметь атрибут Z. Предположим, что у объекта X атрибут Z определен и при следующем обновлении схемы атрибут Z удаляется из списка mayContain класса Y. В результате объект X становится недействительным, посколь ку содержит атрибут Z, который отсутствует в новом определении класса Y (объек том которого он является). Active Directory не удаляет такие ставшие недействитель ными объекты из каталога и следит, чтобы они не вызывали неполадок в остальной части схемы. Автоматической очистки недействительных объектов не происходит, но они остаются доступными для поиска, и их разрешается удалять вручную.
Способы расширения схемы В Windows 2000 существует несколько способов расширения схемы. Объекты им портируются и экспортируются в пакетном режиме посредством следующих средств администрирования: служебных программ LDIFDE (LDIF Directory Exchange) и CSVDE (CSV Directory Exchange), а также сценариев ADSI (Active Directory Service Interfaces). Эти средства, автоматически устанавливаемые на все серверы Windows 2000, позволяют выполнять массовые административные дей ствия - добавлять или изменять большое число объектов (таких, как пользовате ли, контакты, группы, серверы, принтеры) за одну операцию. Эти служебные прс граммы позволяют экспортировать объекты из Active Directory в приложения и на оборот - импортировать в Active Directory из других источников. Для расширения Служба каталогов Active Directory 202 ЧАСТЬ схемы также разрешается использовать консоль ADS1 Edit или осиасгку Active Directory Schema (Схема Active Directory).
Формат LD1F обмена данными Для обмена данными в формате LDIF (LDAP Data Interchange Format) в Win dows 2000 предусмотрена служебная программа командной строки LDIFDE (LDIF Data Exchange), позволяющая создавать, изменять и удалять объекты каталога. Ее можно запустить как на сервере, так и па рабочей станции под управлением Win dows 2000, но на рабочих станциях ее нет, и сначала придется ее скопировать.
LDIFDE позволяет расширять схему, экспортировать информацию о пользователях и группах из Active Directory в другие приложения и службы, а также пополнять Active Directory данными из других служб каталогов.
LDIF Ч это стандарт Интернета для формата файлов импорта и экспорта данных в/из LDAP-каталогов средствами сценариев. LDIF-файл состоит из записей, раз деленных символами перевода строки. Каждая запись (record) содержит информа цию либо об отдельном элементе каталога, либо о наборе модификаций для такого элемента и состоит из одной или нескольких строк.
Использование программы LDIFDE Программа LDIFDE запускается из командной строки. Вот справка по ее парамет рам:
LDIFDE [-i] [-f ] [-s] [-C] [-v] [-t] [-d] [-г] [-р] [-1] [-0] [-m] [-n] [-J] [-g] [-k] [-a] [-b] [-?] [-u] [-y] Примечание Дефис (-) обязателен перед каждым параметром.
В таблице 4-13 описаны значения параметров служебной программы LDIFDE.
Таблица 4-13. Основные параметры LDIFDE Параметр Значение, которое Описание _ следует указать _ -i Режим Включение режима импорта. По умолчанию используется режим экспорта -f Имя файла Указывает имя входного или выходного файла -s Имя сервера Задает контроллер домена для выполнения опе рации импорта или экспорта. Если этот параметр не задан, выполняется привязка к текущему конт роллеру домена, к которому подключен пользователь -с Старая строка составного Заменяет все старые строки на новую. Обычно имени и новая строка используется при переносе данных из одного составного имени домена в другой и замены имени старого домена па имя нового -t Номер порта Задает номер порта. По умолчанию LDAP использует порт 389 (номер порта глобального каталога Ч 3268) -v Задает режим отображения подробной информа ции об операциях экспорта и импорта. По умол чанию этот режим отключен Отображение справочной информации Схема Active Directory ГЛАВА 4 Таблица 4-14. Параметры операций экспорта LDIFDE Значение, которое Описание Параметр следует указать I Составное имя Задает составное имя для базы поиска экспортируемых данных. Значение по умолчанию Ч составное имя кор базы поиска невого домена LDAP-фильтр Задает фильтр поиска. Например, для экспорта всех пользователей с фамилией Yoursurname можно исполь зовать такой фильтр:
-г "(&(objectClass=user)(sn=yoursumame))".
Значение по умолчанию Ч (objectClass^*).
Подробнее о фильтрах поиска LDAP Ч в главе Разрешение имен в Active Directory Задает область поиска и принимает значения: Base, Область поиска OneLevel или SubTree (по умолчанию). Подробнее об области поиска Ч в главе 3 Разрешение имен в Active Directory Задает список атрибутов, возвращаемых в результате Список атрибутов запроса на экспорт. Если параметр опушен, возвраща LDAP ются все атрибуты. Например, чтобы получить только составное имя, относительное составное имя, имя и фа милию, а также телефон объекта, задайте следующий список атрибутов:
-I "dbtinguishedXame, en, givenName, sn, telephone" (Примечание: выделять список кавычками не обязательно) Список атрибутов, исключаемых из результатов запроса Атрибуты, исключа на экспорт. Если параметр опущен, возвращаются все емые из результатов атрибуты. Применяется при экспорте объектов из Active запроса Directory для импорта в другой LDAP-совместимый каталог, который не поддерживает некоторые атрибуты.
Например, для исключения атрибутов whenCreated и whenChanged надо задать:
-о "whenChanged, whenCreated". (Примечание:
выделять список кавычками не обязательно) Исключает особые атрибуты, применяемые только в Атрибуты Active Active Director}', такие как objectGVID (глобально уни Directory кальный идентификатор), objectSID (идентификатор безопасности), pwdLastSet (последний заданный пароль) и samAccountType. По умолчанию этот параметр отключен.
Главное назначение этого параметра Ч экспортировать элементы, предназначенные для повторного импорта в Active Directory. Он также активизирует режим ссылоч ных атрибутов, в котором в конец файла добавляются значения атрибутов, связанных с данным объектом. На пример, если у родительского объекта есть ссылочные атрибуты па дочерний объект, соответствующие записи размещаются в конце файла экспорта. (Примечание:
некоторые атрибуты в Active Directory доступны только для чтения и поэтому не могут повторно импортиро ваться;
параметр -т снимает атрибут только для чтения на время экспорта, чтобы данный файл удалось повторно импортировать) Отменяет экспорт указанных двоичных значений.
Двоичные данные По умолчанию этот режим отключен, ^^j c Х.
204 ЧАСТЬ 1 Служба каталогов Active Directory Таблица 4-14. (продолжение) Описание Параметр Значение, которое следует указать Задает местоположение файла журнала. Значение по Путь умолчанию - текущая папка Отменяет поиск с постраничным просмотром. По умол Поиск по страницам чанию выполняется именно такой поиск (некоторые серверы не поддерживают поиск с постраничным просмотром) Включает поддержку кодировки Unicode. При операции Unicode экспорта генерируется файл в кодировке Unicode, при операции импорта Ч входной файл трактуется как файл Unicode Включает режим отложенной фиксации транзакций (lazy commit) в базе данных каталога для повышения быстродействия Таблица 4-15. Параметры операций импорта LDIFDE Параметр Значение, которое Описание следует указать -k Действие в случае Пропускает ошибки типа нарушение ограничения и ошибки лобъект уже существует* при импорте и продолжает обработку. По умолчанию импорт останавливается при следующих ошибках:
LDAP_ALREADY_EXISTS LDAP_CONSTRAINT_VIOLATION LDAP_ATTRIBUTE_OR_VALUE_EXISTS LDAP_NO_SUCH_OBJECT ERROR_MEMBER_IN_ALIAS Также игнорируются все объекты без атрибутов.
Подробнее об этих ошибках Ч на Web-странице Web Resources по адресу webresources, ссылка Microsoft Platform SDK Таблица 4-16. Параметры реквизитов пользователя, применяемые в LDIFDE Параметр Значение,которое Описание следует указать Запуск программы от имени другого пользователя с Имя пользователя и пароль или * другим паролем. Например:
-а "<:п=<имяпо.гъзовате ля>,Ас=<название_оргаиизацш>,6.с=сот <паролъ>", Ч режим скрытия пароля.
По умолчанию LDIFDE запускается под учетной запи сью текущего пользователя - Имя пользователя, Запускает программу от имени пользователя другого домен и пароль или домена.
* Ч режим скрытия пароля Примечание Перед созданием и модификацией объектов следует убедиться, что все необходимые атрибуты существуют. Например, для создания объекта пользова тель необходимы: distinguishedName, objectClass и samAccountName.
ГЛАВА 4 Схема Active Directory Экспорт и повторный импорт объектов Ссылочные атрибуты содержат информацию о ссылках на текущий объект. В сеансе обычного экспорта родительский объект разрешается экспортировать раньше объек та-потомка. Если при повторном импорте родительский объект добавляется раньше объекта-потомка, произойдет ошибка, так как последнего еще пет в каталоге.
Чтобы исключить эту возможность, применяется параметр -т, который вынуждает во время экспорта и повторного импорта в Active Directory все записи, содержа щие ссылочные атрибуты, размещать в конце файла экспорта. Более того, в этом режиме добавление ссылок отделено от операции создания основного объекта, так что сбой при добавлении ссылки не препятствует созданию объекта.
Свойства объектов, доступные только для чтения В Active Directory есть свойства, относящиеся к диспетчеру учетных записей бе зопасности (Security Accounts Manager, SAM). Они доступны толъко для чтения, так как задаются самой системой в момент создания объекта. Если указать параметр -т во время экспорта и повторного импорта, все атрибуты SAM игнорируются. Таким образом, повторный импорт таких записей окажется успешным, ведь они не содер жат информации SAM.
Пример импорта LDIF-файла Далее приведен листинг файла import.Idf, предназначенного для добавления объек та класса user в домен myDomain.microsoft.com.
dn: CN=sampleUs0r,CN=Users,DC=myDomain,DC=microsоft,DC=com changetype: add en: sampleUser description: Пример импорта объекта-пользователя средствами LDIFDE objectClass: user sAMAccountName: sampleUser Чтобы внести указанные в import.Idf изменения в схему, следует выполнить команду:
Idifde -i -f import,Idf -v Управление данными в LDIF-файле экспорта Рекомендуемый способ для экспорта составных имен (disfinguishedName) средства ми LDIFDE Ч использовать параметр -с. Применение- этого параметра с парамет ром -т позволяет импортировать большую группу пользователей из одного домена в другой.
Примечание При необходимости перед импортом можно средствами текстового ре дактора изменить нужным образом значения атрибутов в файле экспорта.
Формат CSV Массовый импорт и экспорт данных в/из Active Directory выполняется с примене нием файлов с расширением.csv, информация в которых хранится в виде значений, разделенных запятыми (comma-separated value, CSV). Формат CSV-файлов под держивается множеством приложений, в том числе Microsoft Excel, которое спо собно считывать и сохранять данные в этом формате. Средства администрирова ния Microsoft Exchange Server поддерживают импорт и экспорт данных в формате CSV. Для обмена данными в формате CSV в Windows 2000 предусмотрена програм ма командной строки CSVDE. Она способна толъко добавлять новые объекты.
ЧАСТЬ 1 Служба каталогов Active Directory CSVDE работает как на сервере, так и на рабочей станции под управлением Win dows 2000, в последнем случае ее придется скопировать с сервера, так как в составе рабочих станций CSVDE не поставляется.
Данные в формате CSV образуют одну или несколько строк, значения в которых разделены запятыми. Первая строка (иногда ее называют заголовком) файла CSV содержит имена всех атрибутов в том же порядке, что и данные в любой последую щей строке.
Использование программы SCVDE Программа CSVDE запускается из командной строки. Параметры CSVDE анало гичны параметрам LDTFDE. Однако в отличие от LDIFDE, CSVDE создает файлы, понятные не только серверам LDAP, но и другим приложениям. Например, при необходимости отобразить список всех пользователей Active Directory в виде отче та Excel можно экспортировать средствами CSVDE данные каталога в файл фор мата CSV, который затем открыть и отредактировать в Excel.
Программа CSVDE запускается из командной строки. Вот справка по ее парамет рам:
CSVDE [-i] [-f] [-s] [-с] [-v] [-t] [-d] [-r] [-p] [-1] [-0] [-m] [-п] [-е] [-J] [_g] [-k] [-a] [-b] [-?] [-u] Описания этих параметров приведены в таблицах 4-13, 4-14 и 4-15.
Примечание Служебную программу CSVDE нельзя использовать для модификации или удаления объектов - она поддерживает только добавление объектов каталога.
Перед каждым параметром обязательно ставить дефис (-).
Просмотр CSV-файла В CSV-файле значения многозначных атрибутов отделяются друг от друга вторым, определяемым пользователем, разделительным символом (по умолчанию Ч $). Зна чения атрибута перечисляются в списке слева направо в порядке их перечисления в первой записи файла. Значения атрибутов определяются их позицией в записи, и каждое значение соответствует атрибуту, указанному в первой записи файла, как показано в следующем примере:
dn.cn,firstName,surname,description,objectClass,sAMAccountname "cn=John Smith,cn=Users,dc=myDomain,dc=microsoft,dc=com",John Smith,John,Smith,Manager,user,jsmith "cn=Jane Smith, cn=Users,dc=myDomain, dc=microsoft,(Jc=com1', Jane Smith,Jane,Smith,President,user,janes Каждый объект в CSV-файле самостоятелен и не зависит от контекста других объектов, что упрощает чтение и запись файлов и позволяет в одном файле хра нить объекты разных классов.
В следующем примере показан формат CSV-файла с заголовком, который содер жит отображаемые LDAP имена свойств (латрибуты): составное имя, класс объек та, относительное составное имя, имя. фамилию, номер телефона, улицу, город, страну/регион и sAMAccountName.
dn,objectClass,en,givenName,sn,telephoneNumber, street,!,c,sAMAccountName ГЛАВА 4 Схема Active Directory "cn=James Smith, cn=Users,dc=ntyDomain, dc=microsoft,dc=com", user, James Smith,James,Smith,,203-223-2233, 15 Woodbine St.,Fenwick.US,jsmith Все данные представлены в виде строк. Числовые значения Ч в виде цифровых строк, двоичные в виде шестнадцатеричных строк, начинающихся символом X и одинарной кавычкой ('), затем следует шестнадцатеричная строка, которая закан чивается еще одним символом одинарной кавычки ('). Вот пример шестнадцатерич ной строки:
X'01050000000000051500000079e3fc535729024c235f636bf Сведения о синтаксисе хранится в схеме каталога-приемника. Программы, поддер живающие импорт в форме CSV-файлов, определяют порядок обработки значений на основе схемы каталога-приемника.
Отсутствующее или неподдерживаемое значение атрибута оформляется пустой по зицией в строке. Например, в этой строке значение третьего атрибута в записи от сутствует:
firstvalue.secondvalue,,fourthvalue Значения многозначных атрибутов отделяются точкой с запятой (;
). Если среди трех атрибутов второй Ч многозначный, это выглядит так:
Istvalue,2ndvalue1;
2ndvalue2;
2ndvalue3,3rd value Зарезервированные символы, указываются в строке свойств после управляющего символа - обратной косой черты (\). К зарезервированным символам относятся:
Х обратная косая черта (\);
Х точка с запятой (;
);
специальный символ для представления шестпадцатеричных данных (х1).
Х Если значение содержит обратную косую черту, ее необходимо предварять допол нительной обратной косой чертой (\\). Символ точка с запятой (;
) отделяет значе ния. Если само значение содержит точку с запятой, то ее также предваряют симво лом обратной косой черты (\;
). То же касается и символа шестнадцатеричного пре фикса (\х'). Существуют два других символа, которые обрабатываются особым об разом. Это символ занятой (,) и символ двойные кавычки ("). Запятая (,) в форма те CSV зарезервирована для разделения значений. Если значение содержит запя тую (,), формат предписывает, чтобы данное значение было заключено в двойные кавычки, например значение строку valuel,value2 обязательно записывают в виде "valueI,value2". Если значение содержит как пару двойных кавычек, так и запятую, кавычки в выражении заключаются в другой набор двойных кавычек, например:
"valuer 1,"value2" представляется в виде ""valuel"",""value2"", value1"value2 представляется а виде "valuel""value2" Вот пример CSV-файла, предназначенного для добавления объектов подразделе ние, пользователь и компьютер:
dn,en,givenName,sn,description,objectClass,sAMAccountname "ou=sampleOU,dc=myDomain,dc=microsoft,dc=com",,,.Sample Organizational Unit,organizationalUnit, "cn=John Smith,ou=sampleOU,dc=myDofnain,dc=microsoft,dc=com",John Smith,John,Smith,Sample User,user,jsmith "cn=sampleComputer,ou=sampleOU,dc=myDomain,dc=microsoft,dc=coni",sampl eComputer,,.Sample Computer,computer,computer!
ЧАСТЬ 1 Служба каталогов Active Directory Примечание В CSV-файлах поддерживаются обе кодировки текста Ч ANSI и Unicode.
Использование LDIFDE и CSVDE для изменения схемы LDIFDE и CSVDE работают с файлами, содержащими данные каталога в соответ ствующих форматах. Эти файлы импортируются или экспортируются на серверы LDAP-каталогов для создания или изменения объектов в каталоге. Поскольку схе ма Active Directory реализована в виде набора объектов каталога, для ее расшире ния разрешается применять любую из этих программ.
Примечание В настоящее время CSVDE позволяет только добавлять объекты в ка талог, но не модифицировать его.
Использование LDIF-файлов Формат LDIF применяется для выполнения групповых операций в LDAP-катало гах. Он годится как для добавления новых объектов в каталог, так и для изменения или удаления существующих. Запись (record) файла LDIF состоит из набора строк, описывающих элемент каталога или набор изменений для отдельного каталога.
Данный формат поддерживает все операции LDAP.
Изменять схему средствами консоли Active Directory Schema (Схема Active Di rectory) рекомендуется на тестовой системе, изолированной от сети предприятия.
В дальнейшем используется LDIFDE для экспорта изменений в файл, который за тем применяется для обновления действующей системы. Вот фрагмент LDIF-фай ла, в котором выполняется добавление нового атрибута в Active Directory.
dn: CN=New-Attribute-Name,CN=Schema,CN=Configuration, DC=microsoft,DC=com changetype: add objectClass: attributeSchema IdapDisplayName: newAttributeName adfninDisplayName: New-Attribute-Name adminDescrtption: New-Attribute-Name attributeld: 1.2.840.113556.1.4.8000.1 <-этот идентификатор должен быть уникальным attributeSyntax: 2.5.5. omSyntax: isSingLeValued: TRUE systemOnly: FALSE searchFlags: showInAdvancedVlewOnly: TRUE А вот LDIF-файл для принудительного обновления каша схемы:
dn:
changeType: modify add: schemalipdateNow schemaUpdateNow: Подробнее о формате LDIF и использовании LDIFDE Ч на Web-странице Web Resources no адресу ссылка Microsoft Platform SDK.
Использование CSV-файлов CSV-файлы характеризуются простым форматом, главное преимущество которого - удобство использования. Каждая строка в нем представляет отдельный объект каталога с его атрибутами, разделенными запятыми. Первая строка файла всегда Схема Active Directory ГЛАВА 4 содержит имена атрибутов. Все последующие строки представляют разные элемен ты каталога. Значения многозначных атрибутов отделяются точкой с запятой (;
).
Данный формат совместим с форматом CSV в Microsoft Excel и позволяет вывести информацию каталога в таблицу Excel или импортировать данные из таблицы в Active Directory. Вот пример CSV-файла добавления нового пользователя:
dn,objectClass,cn.sn,givenName,teiephoneNumber,street,1,c,sAMAccountName "CN=John Doe, DC=fnyDomain,DC=rnicrosoft, DC=com", User,John Doe,Doe,John, 555-456-7890,123 Magnolia Ave.,Redmond,US,jdoe В обеих программах Ч CSVDE и LDIFDE есть справочная информация, кото рую можно просмотреть, набрав имя команды без параметров в окне командной строки. Обе программы позволяют импортировать и экспортировать данные, но используют их в разных случаях.
Миграция на Active Directory. Средства любой из этих программ позволяют им портировать в Active Directory данные из других служб каталогов. Это применимо к любому LDAP-каталогу при условии соблюдения соответствия имен атрибутов.
Публикация информации из каталога. Любая из этих программ позволяет экспор тировать данные каталога в другое приложение, понимающее формат LDIF или CSV. Также поддерживается экспорт данных в другую LDAP-совместимую службу каталога при условии соблюдения соответствия имен атрибутов.
Добавление ресурсов в каталог. Помимо консолей Active Directory Users and Computers (Active Directory Ч пользователи и компьютеры) и ADS1 Edit, для до бавления объектов в каталог администраторы вправе использовать эти программы, С точки зрения простоты использования и гибкости программы CSVDE и LDIFDE находятся где-то посередине между указанными консолями и другими средствами работы с каталогами. Поскольку схема Active Directory реализована в виде набора объектов каталога, для добавления в нее новых или изменения существующих объектов возможно задействовать LDIFDE или CSVDE. В общем случае, если Ва шему приложению требуется изменение схемы, лучший способ - распространять вместе с приложением импортируемые в схему LDIF и/или CSV-файлы.
Рис. 4-5 иллюстрирует использование LDIF для расширения схемы Active Directory, Каталог А Стандартный текстовый LDIF-файл Изменение посредством сценария или в редакторе Каталог В Измененный текстовый LDIF-файл Рис. 4-5. Расширение Active Directory с применением LDIF-файла Служба каталогов Active Directory 210 ЧАСТЬ Использование интерфейсов службы Active Directory и сценариев Visual Basic Использование LD1F и CSV-файлов имеет свое преимущество: достаточно просмот реть их, чтобы понять, как они расширяют схему. Но у программного расширения схемы также есть свои преимущества:
Х расширение из программы нельзя изменить: это просто исполняемый файл Windows. В отличие от LDIF или CSV-файлов, двоичный файл нельзя случай но или преднамеренно испортить;
Х в программе можно предусмотреть выявление и устранение ошибок, а также предоставление при этом пользователю внятных сообщений;
Х программы работают с кодировкой Unicode, им не требуется формат Base (Unicode использует набор 16-битных символов, содержащий все символы, не обходимые в обработке данных);
Х программы способны использовать API-функции установщика Windows;
Х подлинность программы возможно подтвердить цифровой подписью.
В Active Directory существует набор интерфейсов, предоставляющий доступ из про грамм к объектам каталога, в том числе к объектам схемы. В ADS1 определена мо дель службы каталога и набор СОМ-интерфейсов, используемых в самых различ ных языках программирования. ADSl-интерфейсы соответствует спецификации модели Component Object Model и поддерживают стандартные СОМ-функпии.
Microsoft Visual Basic Script и ADSI-иптерфейсы позволяют легко писать сценарии изменения каталога, в том числе расширения схемы. Расширение схемы поддержи вается специальными ADSI-интерфейсами.
lADsContainer Для создания новых объектов классов dassSchema и aUrihuteSchema применяется функция !ADsContainer::Create.
IADs Ч Для чтения атрибутов объектов классов dassSchema и attributedkhema при меняется функция IADs::Get (или GetEx), а для присвоения значений Ч функция IADs::Put (или PutEx). Функция PutEx оказывается чрезвычайно полезной при манипулировании значениями атрибутов mustContain и migktContain, поскольку поддерживает работу с многозначными атрибутами.
Вот приведен пример сценария, добавляющего в Active Directory объект пользо ватель.
Dim oDomain Dim oUser Set oOomain=GetObject("LDAP://OU=Marketing,DC=antipodes,DC=coin") Set oUser = oDomain.Create("user","cn=John Smith") oUser,Put "samAccountName","JSmith" oUser.Put "givenName","John" oUser,Put "sn","Smith" oUser,Put "userPrincipalName",jsmith@antipodes.com oUser,Setlnfo MsgBox "User created " & oUser.Narne Set oDomain = Nothing MsgBox "Finished" WScript.Quit ГЛАВА 4 Схема Active Directory Примечание Подробнее об ADSI и ADSI-интерфейсах - на Web-странице Web Resources по адресу ссылка Microsoft Platform SDK.
Использование консоли Active Directory Schema Консоль Active Directory Schema (Схема Active Directory) позволяет членам груп пы Schema Admins (Администраторы схемы) управлять схемой в графическом ин терфейсе. Средствами этой консоли создают и изменяют классы и атрибуты, а так же указывают порядок их индексирования и репликации в глобальный каталог.
Первое, в чем необходимо убедиться после запуска консоли схемы Active Di rectory, - что она подключена к хозяину схемы Вашего предприятия.
Примечание Оснастка Active Directory Schema (Схема Active Directory) не устанав ливается по умолчанию вместе с Windows 2000 Server. Чтобы она появилась в спис ке действующих оснасток, необходимо установить пакет средств администрирова ния (Adminpak.msi), После этого необходимо зарегистрировать DLL-библиотеку оснастки Schema. Для этого откройте папку % SystemRoot%\System32 и в команд ной строке выполните команду Regsvr32 Schmmgmt.dll.
^ Просмотр или изменение текущего хозяина схемы средствами консоли Ac tive Directory Schema (Схема Active Directory) 1. Откройте ММС и установите оснастку Active Directory Schema (Схема Active Directory).
2. Правой кнопкой мыши щелкните Active Directory Schema (Схема Active Di rectory) и в контекстном меню выберите команду Operations Master (Хозяин операций).
3. В открывшемся окне в области Current Operations Master (Текущий хозя! п операций) отображается текущий хозяин схемы.
4. Щелкните ОК, чтобы оставить прежнего хозяина или щелкните кнопку Change (Сменить), чтобы передать роль хозяина схемы другому контроллеру домена.
При перемещении роли следует подключиться к контроллеру, которому эта роль передается.
Убедившись, что консоль подключена к хозяину схемы. Вы можете приступить к добавлению, изменению или отключению атрибутов и классов. Помните: Ваша учетная запись должна являться членом группы Schema Admins и на сервере необ ходимо разрешить модификацию схемы.
Примечание Нельзя отключить стандартные объекты схемы.
ГЛАВА Публикация служб в Active Directory Active Directory в Windows 2000 - это распределенное сетевое хранилище инфор мации о компьютерах, пользователях, службах и приложениях. Службы и прило жения, поддерживающие службу каталогов, публикуют в Active Directory полезную информацию, например свойства служб и сведения об их доступности. Интерфейс управления и пользовательский интерфейс Active Directory позволяет админист раторам и клиентским процессам при необходимости находить и подключаться к поддерживающим каталоги службам.
Лицам, ответственным за доступность сетевых ресурсов, надо знать основные прин ципы и процедуры публикации служб в Active Directory. Знание архитектуры и основных типов служб, публикуемых в Active Directory, необходимо для публика ции служб и ее применения для управления службами в распределенной сети.
Для понимания механизма публикации служб Бы должны иметь общее представ ление об архитектуре Active Directory.
В этой главе Основные сведения Инфраструктура каталога для публикации служб Поиск и просмотр сведений о службе в Active Directory Служба RFC Name Service в Windows 2000 и интеграция г Active Directory Безопасность служб Основные сведения Служба - это процесс на сервере, выполняющий особую системную функцию и зачастую предоставляющий другим процессам API-интерфейс вызовов. В процессе на сервере выполняется один или несколько потоков, обслуживающих запросы кли ентских процессов. Процесс на сервере реализует набор служб и предоставляет их клиентам, выполняющимся на компьютерах распределенной сети. Хотя службы Windows 2000 и поддерживают удаленный вызов процедур (remote procedure call, RPC), то есть их API-процедуры могуч' вызываться удаленными компьютерами, RPC им не требуется.
Публикация служб в Active Directory ГЛАВА 5 Публикация службы подразумевает создание, храпение и поддержку информации в хранилище Active Directory. Клиенты и администраторы сети могут использовать информацию из Active Directory для поиска, подключения и управления служба ми. Кроме того, Active Directory позволяет клиентам и администраторам просмат ривать распределенную сеть в виде набора служб, а не набора отдельных компью теров.
Типы сведений о службах В Active Directory описаны способы создания экземпляров служб и привязки кли ентов. Для клиентов наиболее важны сведения о привязке, позволяющие им осу ществлять подключение к доступной в сети службе. Информация о привязке со держит данные многих типов.
В таблице 5-1 перечислены типы данных, которые поддерживающие каталог служ бы хранят в Active Directory.
Таблица 5-1. Сведения о службах, хранимые в Active Directory Тип информации Описание Клиентские привязки Имя службы и способы доступа к ней клиентов Административные привязки Имя службы и способы доступа к ней административ ных приложений для выполнения административных действий. Одну привязку разрешается использовать д ;
[я выполнения как клиентских, так и административных функций Данные конфигурации Хранение в каталоге постоянных конфигурационных данных службы позволяет использовать возможности защиты и репликации в Active Directory. Например, служба базы данных способна хранить в Active Directo ry свою стандартную конфигурацию для серверов баз данных. Динамическое обращение к конфигурационным сведениям при установке нового экземпляра службы база данных позволяет упростить установку и обеспе чить согласованность конфигураций Другая информация о службе Расширения схемы Active Directory и классов объектов, относящиеся к службам и представляющие интерес для клиентов или администраторов Объекты-службы Объект - это отдельный поименованный набор атрибутов, представляющий, напри мер, пользователя, принтер или приложение сервера. Объекты Active Directory представляют элементы, которые, но мнению клиентов, наиболее интенсивно ис пользуются в сетевой среде. Active Directory содержит спецификации следующих типов объектов: пользователь, группа, контейнер службы каталогов, -луправ ление печатью, схема и луправление службой.
Для подключения к службе клиентского процесса и административного приложе ния системы под управлением Microsoft Windows NT версии 4.0 или более ранней требуется имя или IP-адрес компьютера, на котором установлена эта служба. В про тивоположность этому в Active Directory клиентские процессы и средства админи стрирования способны подключаться к службе, указывая атрибут keywords. Этот ат Спужба каталогов Active Directory 214 ЧАСТЬ рибут позволяет клиенту получить DNS-имя узла (dnsHostName), на котором вы полняется служба.
Подробнее об атрибуте keywords - в разделе Поиск и просмотр сведений о служ бах в Active Directory этой главы. Подробнее о dnsHostName Ч в главе 3 <Разре шение имен в Active Directory.
Active Directory позволяет находить и подключаться к поддерживающим работу с каталогом службам по атрибутам, отличным от имени или IP-адреса компьютера с искомой службой. Для поиска таких служб, как DHCP (Dynamic Host Configuration Protocol), Active Directory использует прочие атрибуты объектов, например отобра жаемое имя службы. Подробнее о структуре базы данных Active Directory и отдель ных объектах-службах Ч в разделе Инфраструктура каталога для публикации служб далее в этой главе.
Привязка служб Для публикации в Active Directory служба, поддерживающая работу с каталогом, должна, по крайней мере, записать информацию о своей привязке. Эти данные, а именно имя и местоположение службы, используются клиентом для подключения, или привязки, к экземпляру данной службы. Например, браузер создает привязку к Web-серверу, обращаясь к нему но URL.
В таблице 5-2 перечислены примеры привязки служб.
Таблица 5-2. Примеры привязки служб Служба Привязка File Service UNC-имя общего ресурса в формате \\<сервер>\-<имя_общего_ресурса> Web Service URL-адрес, например RPC Service [Удаленный вызов RPC-привязка Ч зашифрованная информация, исполь процедур (RPC)] зуемая для подключения к RFC-серверу, например ncacti_]p_tcp:server.microsoft.com. Для преобразования RFC-привязок в строковое представление и обратно используются API-интерфейсы RPC Публикация отдельных экземпляров служб Иногда данные о конкретной службе публикуются в нескольких местах Active Directory. Каждый экземпляр службы, выполняющийся на компьютере (компьюте рах) сети, может создавать в Active Directory объекты Ч точки подключения. Точ ка подключения представляет один или несколько доступных в сети экземпляров службы.
Например, если службы Microsoft Certificate Services (Службы сертификации) ус тановлены и выполняются на двух компьютерах сети, возможны две точки подклю чения - по одной для каждого экземпляра службы. Аналогично служба, несколько экземпляров которой установлено на одном компьютере, способна создавать отдель ные объекты Ч точки подключения для каждого из этих экземпляров. Кроме того, вероятна ситуация, когда несколько экземпляров реплицируемой службы публи куют сведения о себе в Active Directory в одной точке подключения. В этом случае точка подключения содержит информацию, позволяющую клиенту выбирать и со здавать привязку к одной из реплик службы.
ГЛАВА 5 Публикаций служб в Active Directory Примечание Атрибуты possSuperiors и systemPossSuperiors каждого из классов объек тив Active- Directory содержат список классов объектов, способных содержать эк земпляры объектов данного класса, то есть типы контейнеров, в которых можно создать этот объект. У существующих классов атрибут systemPossSuperiors изменять нельзя: разрешается только добавлять, но не удалять значения атрибута possSuperiors. Например, можно создать объект класса service ConnectionPoint как до черний объект класса Computer, Container или Organization-Unit. Подробнее об ат рибутах possSuperiors и systemPossSuperiors Ч в главе 4 Схема Active Directory.
Инфраструктура каталога для публикации служб Объекты Active Directory расположены согласно иерархии. Стандартная иерархия Active Directory содержит информацию, необходимую для установки и запуска Windows 2000 и самой службы каталогов. Стандартная структура содержит контей неры, специально предназначенные для поддержки публикации служб.
На рис. 5-1 показана структура Active Directory по умолчанию.
<домен> Configuration System Services Sites WinsocKServices RPCservices Рис. 5-1. Структура Active Directory по умолчанию для публикации служб Иерархия домена содержит все объекты данного домена (например, пользователи, компьютеры и принтеры) и реплицируется па все контроллеры этого домена.
Иерархия конфигурации содержит все объекты, относящиеся ко всему лесу доме нов, и реплицируется па каждый контроллер домена этого леса. Папки Services и Sites - прямые потомки раздела конфигурации.
Точки подключения Объект класса connectionPoint (точка подключения) представляет один или не сколько доступных в сети экземпляров службы. В схеме Active Directory определе но множество классов объектов, которых можно использовать при публикации служб. Все объекты, представляющие ресурсы и способные принимать подключе ния, являются производными от класса connectionPoint. Его иерархия показана на рис. 5-2.
Далее приведены примеры объектов (способных принимать соединения) классов производных от класса connectionPoint.
Print Queue и Volume Ч объекты этих классов стандартные точки подключения, используемые службами печати и файловыми службами соответственно.
Служба каталогов Active Directory 216 ЧАСТЬ Service Instance RPC Entry Service Volume Print Queue Connection Point Service Administration Point Рис. 5-2. Иерархия класса connectionPoint RPC Entry Windows 2000 поддерживает два сетевых API-интерфейса, обеспечи вающих независимый от транспорта обмен информацией: Microsoft Windows Sockets и RPC. Интерфейс RPC предоставляет механизм вызова функций в других процес сах, в том числе на удаленных компьютерах в сети. RPC поддерживает модель по токов, предоставляет службу сопоставления (mapping) конечных точек (сокетов, каналов или портов) и взаимодействует со службой имен. В настоящее время для публикации в Active Directory служб средствами API-интерфейса RPC Name Service (RpcNs) применяются объекты класса RPC-Entry и других классов объек тов RPC.
Service Instance для публикации в Active Directory служб Windows Sockets, пуб ликующих сведения о себе средствами API-интерфейсов разрешения и регистра ции (registration and resolution, RnR), применяются объекты класса Service-Instance.
Service Connection Point объекты этого класса используют службы, не поддер живающие существующие уровни абстрагирования, такие, как RPC Name Service или RnR, и поэтому нуждающиеся в явной публикации в Active Directory.
Служба, использующая точку подключения Service-Connection-Point, должна обес печивать уровень абстрагирования, скрывающий от клиентских приложений све дения о размещении службы. Этот уровень абстрагирования реализуется в виде DLL-библиотеки или как составная часть клиентского приложения. Уровень абст рагирования запрашивает в Active Directory объект точка подключения, пред ставляющий запрошенную клиентским приложением службу, и использует содер жащиеся в нем сведения о привязке для подключения приложения к службе.
Клиентское приложение запрашивает в Active Directory объекты - точки подклю чения, которые представляют необходимые ему службы. Клиент выбирает один или несколько найденных объектов и использует получаемую из объектов информацию о привязках для подключения к службе. В случае с RpcNs и RnR запрос выполня ется уровнем абстрагирования;
запрос объектов класса service ConnectionPomts осу ществляется клиентом самостоятельно.
Публикация служб в Active Directory ГЛАВА 5 Примечание Службы па основе СОМ не применяют объекты семейства классов Connection Point для оповещения о себе, а публикуются в хранилище классов (class store) Windows 2000. Это хранилище сведений обо всех приложениях, интерфейсах и API, применяемых для публикации и назначения приложений, основано на ката логе.
Подробнее о хранилище классов \Vindows2000 и службах на основе СОМ Ч на Web-странице Web Resources по адресу res kit/web resource, ссылка MSDN, Выбор места публикации Принимая решение о месте публикации службы в Active Directory, учтите следую щие рекомендации:
Х служба должна публиковать информацию о себе в разделе домена, но никогда не в конфигурации;
Х служба должна создавать относящиеся к ней объекты в том же домене, где рас положен компьютер, на котором она выполняется. Необходимо, чтобы места публикации было удобно для администрирования службы и поддержки ее объек тов. Мы рекомендуем располагать объекты служб в объекте компьютера, на ко тором они установлены.
Если клиент обладает доступом к компьютеру, на котором выполняется служба, ему также должна быть доступна и реплика домена, содержащего данный компьютер.
Примечание Лишь в редких случаях клиент может определить компьютер, на ко тором выполняется служба. Обычно клиент находит службу по значению атрибута keywords, который, как правило, содержит GUIDf относящийся к поставщику и при ложению. Для этого служба, публикующая информацию, обязана публиковать и ат рибут keywords.
Подробнее об атрибуте keywords на странице Web Resources по адресу windows.microsoft.coni/wmdows2000/rcskit/webresources, ссылка Microsoft Platform SDK. _^^ Таким образом, вполне достаточно опубликовать информацию о службе в домене, содержащем компьютер, на котором эта служба выполняется. Публикация сведе ний о службе в разделе конфигурации не упрощает доступ к службе и ее использо вание, а создает дополнительный трафик репликации. Не рекомендуется публико вать информацию о службе в разделе конфигурации, чтобы не снижать производи тельность системы.
Для поиска объектов клиенты запрашивают каталог. Если клиент выполняет по иск не в своем домене, а во всем лесе, то ему потребуется глобальный каталог. Но в любом случае для клиента несущественно, где расположен объект-служба. Поэто му от клиента никак не зависит место публикации объекта-службы. Более того, главное, что надо учесть при публикации, Ч удобство администрирования службьт.
В иерархии доменов Active Directory относящиеся к службам объекты разрешен') размещать в трех контейнерах:
Служба каталогов Active Directory 218 ЧАСТЬ Х в объекте компьютер (Computer);
Х в объекте подразделение (Organizational-Unit);
Х в папке System (или в одном из его дочерних контейнеров).
Примечание В Active Directory (как и во многих других службах каталогов) любой объект можно сделать действительным родителем, преобразовав в контейнер. Это позволяет создавать интуитивно попятную структуру каталога. Например, объекты, относящиеся к отдельному компьютеру, отображаются в каталоге как сто дочерние объекты, Ч это наиболее вероятное место, где их будет искать администратор, Объект-компьютер Публикуя службы, установленные на компьютере, создавайте объекты служб как дочерние объекты, соответствующего ему объекта компьютер.
Для упрощения установки многие службы создают свои объекты в стандартном месте;
хотя большинство служб позволяет перемещать созданные объекты. Объект компьютер, на котором установлена служба, удобное и интуитивно понятное место для таких объектов, поскольку при перемещении этого объекта на новое ме сто Active Directory автоматически перемещает вместе с ним и все объекты-служ бы. Кроме того, если объект-компьютер удаляется или присоединяется к другому домену, объекты-службы также удаляются. Таким образом, снижается вероятность появления потерянных (orphaned) объектов-служб. Процесс, выполняющийся на компьютере Ч члене домена, всегда может найти объект-компьютер в каталоге.
Примечание Действительные объекты компьютер существуют в каталоге лишь для компьютеров-членов домена.
Иерархия контейнеров подразделений Active Directory позволяет создавать иерархию контейнеров, соответствующую по требностям Вашей организации. Для построения таких иерархий применяется класс organizationalUnit Ч контейнер общего назначения, который нужен для груп пирования большинства классов объектов для удобства администрирования, в том числе и объектов-компьютеров. Для удобства администрирования иногда требует ся сгруппировать относящиеся к службам объекты. Active Directory позволяет за давать разрешения для всех объектов в контейнере или поддереве в одном списке управления доступом (access control list, ACL). B Windows 2000 применяется модель разрешений, позволяющая весьма точно управлять доступом к объектам в каталоге и делегировать административные полномочия другим пользователям.
Все стандартные классы объектов, относящихся к службам, Ч допустимые дочер ние объекты класса organizationalUnit, поэтому службе не требуется размещать свои объекты в фиксированном месте каталога.
Пример кода, который создает объект-службу, сохраняет его атрибут objectGUID и затем обнаруживает созданный объект-службу по этому атрибуту Ч на Web-стра нице Web Resources ссылка MSDN.
ГЛАВА 5 Публикация служб в Active Directory Контейнеры Users и Computers При обновлении Windows NT до Windows 2000 учетные записи пользователей, групп и компьютеров помещаются в контейнеры Users и Computers. Объекты пользователи и объекты-группы хранятся в контейнере Users, а объекты-компью теры - в контейнере Computers. Windows NT и API-функции (такие как функции семейства Net*), которые создают учетные записи пользователей, групп и компью теров, а также применяют служебные программы, автоматически создающие упо мянутые объекты в соответствующих контейнерах.
Не перемещайте относящиеся к службе объекты в эти контейнеры напрямую и не создавайте в них новые контейнеры. Впрочем, службы публикуют дочерние объек ты объекта-компьютера независимо от того, где последний размещен Ч в Computer's или в другом месте. Создавайте объекты точек подключения к службам в контей нере компьютера, на котором установлена служба.
Контейнер System Контейнер System содержит сведения, используемые для поддержки текущей ра боты домена, в том числе данные о стандартной локальной политике безопасности, об изменившихся связях файлов, о сетевых конференциях и контейнерах для то чек подключения к RPC и Windows Sockets (Winsock). По умолчанию контейнер System скрыт, что делает его удобным местом для хранения объектов, нужных ад министраторам, а не пользователям.
Службы, оповещающие о себе средствами API-интерфейсов Winsock RnR или RpcNs, создают все необходимые объекты в контейнерах WinsockServices и RpcServices автоматически. Никогда не- создавайте явно объекты в этих контейне рах и не перемещайте объекты в них.
Службы, создающие объекты служб в контейнере System, должны выполнить сле дующие действия:
Х создать подконтейнер в контейнере, хранящем объекты данного класса и явля ющемся прямым потомком контейнера System, и дать ему имя, четко указываю щее на его принадлежность к службе;
Х опубликовать относящиеся к службе объекты в контейнере System. Например, приложение Microsoft Net Meeting публикует объекты сетевых конференций в контейнере Meetings. При публикации объектов нескольких приложений-служб одного поставщика для каждой службы следует создавать отдельный контейнер в контейнере - непосредственном потомке контейнера System, носящем имя этого поставщика.
Служба, слабо связанная с конкретным компьютером, например NetMeeting, пуб ликуется в дочернем контейнере контейнера System.
Публикация служб в Active Directory При публикации служб придерживайтесь следующих рекомендаций:
Х при установке служб создавайте объекты Ч точки подключения таким образом, чтобы пользователю с достаточными привилегиями удавалось без особых про блем установить опубликованную службу с помощью этой точки подключения;
Х настройте службу так, чтобы она могла во время работы обновлять существую щие объекты точек подключения.
Служба каталогов Active Directory 220 ЧАСТЬ Независимо от выбранного способа публикации обязательно учтите ограничения доступа к каталогу Ч как в процессе установки служб, так и при их работе. API интерфейсы RpcNs и RnR создают точки подключения в контейнерах RpcScrvices и WinsockServices соответственно, расположенных в контейнере System каждого домена. Объекты класса Service-Connection-Point следует создавать как дочерние объекта-компьютера, па котором установлена служба.
Чтобы создать объект, процесс должен обладать разрешением на создание потомка соответствующего класса и контейнера, где размещается новый объект. Для удале ния объекта процесс должен обладать разрешением на удаление потомка этого клас са и контейнера, в котором размещается объект, а также иметь разрешение на уда ление самого объекта. Обновление точки подключения возможно только при нали чии у процесса разрешения на запись свойств объекта.
Иногда при установке службы выясняется, что этих разрешений у учетной записи компьютера или службы нет. В этом случае установку выполняет администратор или другое полномочное лицо. При установке публикуемой службы предоставьте самой службе доступ на изменение параметров точки подключения во время вы полнения, независимо от того, под какой учетной записью она выполняется. Это позволит ей управлять точкой подключения даже при олицетворении учетной за писи с минимальными привилегиями.
Подробнее о публикации служб Ч на Web-странице Web Resources по адресу ссылка MSDN.
Класс Service Connection Point (SCP) - это базовый класс объектов, используемый для публикации и поиска служб. SCP предназначен для публикации клиентских привязок. Свойства этого класса позволяют службе публиковать информацию, не обходимую клиенту для привязки к экземпляру службы. Клиенты службы должны уметь интерпретировать и применять атрибуты привязки;
порядок использования этих атрибутов в Active Directory не определен. Службы, которым требуется опуб ликовать дополнительную информацию о себе, могут расширить схему путем со здания подклассов (subclassing) класса SCP и назначения им легко узнаваемых имен.
Подробнее о расширении схемы -- в главе 4 Схема Active Directory.
Программа установки (или процедура создания службы в процессе установки дру гого приложения) создает службу и при необходимости Ч учетную запись и точку подключения службы. В начале своей работы служба проверяет, содержит ли объект Ч точка подключения Ч корректные сведения о привязке.
В сети иногда представлено несколько экземпляров службы с разными возможнос тями. Например, на нескольких серверах баз данных может храниться совершенно разная информация, хотя все серверы относятся к службе одного типа или к одно му классу служб.
Кроме того, службы поддерживают репликацию. Реплицируемая служба состоит из нескольких экземпляров с идентичными возможностями. Клиент вправе подклю читься к любому экземпляру такой службы, при этом вид и состав полученных им услуг никак не зависит от экземпляра. Например в Active Directory все контролле ры одного домена содержат идентичные данные и предоставляют одинаковые служ бы. При создании точки подключения службы следует обеспечить пользователям возможность поиска службы. При наличии нескольких экземпляров службы поза ботьтесь о поддерживаемом клиентом механизме поиска и о том, чтобы клиент мог выбрать экземпляр службы с требуемыми возможностями.
ГЛАВА 5 Публикация служб в Active Directory Атрибуты класса serviceConnectionPoint Атрибуты класса serviceConnectionPoint позволяют службе публиковать всю Инфор мацию, необходимую клиенту для привязки к экземпляру службы. Многозначный атрибут keywords этого класса содержит строковые значения (ключевые слова), по зволяющие клиентским приложениям находить объекты точек подключения для кон кретного типа службы. Этот атрибут индексируется и реплицируется на сервер гло бального каталога. Служба, публикующая объект класса service Connection Point, добав ляет ключевые слова как отдельные значения многозначного атрибута keywords.
Подробнее о ключевых словах и о публикации объектов точек подключения служб - на Web-странице Web Resources по адресу windows2000/reskit/webresources, ссылка MSDN.
Публикация средствами API-интерфейса RpcNs Для публикации сведений о себе в определенном пространстве имен службы RPC обращаются к функциям интерфейса RpcNs (RPC Name Service). Функции API интерфейса RpcNs в Windows 2000 публикуют записи RPC в Active Directory.
Службы создают привязки RPC и публикуют их в пространстве имен Active Direc tory как обладающие атрибутами именованные записи RPC Server. К атрибутам относятся известные клиентам уникальный идентификатор интерфейса и GUID.
Клиенты получают возможность выполнять поиск серверов RPC, предоставляющих желаемый интерфейс, импортировать привязку и подключаться к серверу.
Подробнее об интерфейсе RPC Name Service и Active Directory Ч в разделе Служба RFC Name Service Б Windows 2000 и интеграция с Active Directory далее в этой главе.
Публикация средствами API-интерфейса RnR Службы Windows Sockets используют функции API-интерфейса RnR ( W i n dows Sockets Registration and Resolution) для публикации и поиска служб. Публи кация средствами RnR выполняется в два этапа. Сначала устанавливается класс службы, связывающий GUID с именем службы. Класс может содержать относящи еся к службе конфигурационные сведения. Затем службы публикуют сведения о себе как экземпляры класса службЧ клиенты получают возможность средствами RnR искать в Active Directory экземпляры служб данного класса и выбирать эк земпляры для привязки. Ставшие ненужными классы удаляются.
Поиск и просмотр сведений о службе в Active Directory Контейнер Services Ч это прямой потомок контейнера Configuraion. Если относя щиеся к службам объекты Ч прямые потомки класса serviceConnectionPoint, поиск опубликованных служб выполняется средствами ADSI (Active Directory Service Interface). Для этого найдите объекты, атрибут objectCategory или objectClass кото рых равен serviceConnectionPoint. Атрибут keywords содержит относящийся к постав щику и приложению GUID. Для поиска по категории используйте атрибут ob jectCategory, а не ObjectClass.
Если относящиеся к службам объекты экземпляры класса, производного от serviceConnectionPoint, то при поиске средствами ADSI следует искать объекты, ат рибут object Category которых равен serviceConnectionPoint, a objectClass соответствует Вашей точке подключения.
Служба каталогов Active Directory 222 ЧАСТЬ Примечание Атрибут objectCategory индексируется, a objectClass Ч нет. Поэтому объект рекомендуется искать по категории, так как поиск по индексированным ат рибутам выполняется быстрее.
Для прииязки клиенту необходима информация атрибута sennceBindinglnformation и, возможно, атрибутов serviceDNSName и serviceDNSNameType.
Служба RFC Name Service в Windows и интеграция с Active Directory Для поиска экспортированных (exported) серверов RPC клиентские процессы ис пользуют функции API-интерфейса службы RPC Name Service. Сервер RPC экс портирует сведения о себе средствами API-интефейса RpcNs. Для подключения к RPC-серверу клиенту необходима привязка, предоставляющая интерфейс нужной ему версии и обладающая необходимым набором протоколов. Для поиска совмес тимых привязок клиент использует функции интерфейса RpcNs. Служба RPC Name Service предоставляет привязки, необходимые RPC-клиентам для удаленного вы зова процедур и взаимодействия с RPC-серверами.
Хотя функции интерфейса RpcNs и не поддерживают списки ACL, Active Directory эти списки поддерживает и разрешает сопоставлять их записям RPC Name Service.
Реализация RPC Name Service для Windows 2000 поддерживает списки ACL в Active Directory и предотвращает неавторизованный экспорт. Кроме того, служба управляет полномочиями клиентов на импорт на основе списков ACL.
Описываемые механизмы применения списков ACL используют внешние (out-of band) данные, передаваемые вне обычного потока данных между процессами. На пример, сокеты потоков позволяют пересылать поток байт между процессами. Пе редаваемые таким способом данные называются вложенными (inline). Впрочем, иногда приложению на любом из концов канала требуется передать данные друго му приложению, не нарушая обычных правил передачи вложенных данных. Для этого используется пересылка внешних данные - они передаются получателю на тот же сокет, что и вложенные данные, но с более высоким приоритетом. Преиму щество очевидно: вложенные данные передаются отправителем непосредственно получателю, которому не приходится ожидать завершения входящего потока. Да лее перечислены некоторые методы настройки списков ACL, позволяющие процес сам передавать внешние данные:
Х при установке контроллера домена создается контейнер RpcServices. По умол чанию все записи службы RPC Name Service, созданные в контейнере RpcServices, наследуют списки ACL данного контейнера. Присвоение стандарт ного списка управления доступом данному контейнеру гарантирует применение ACL ко всем записям службы RPC Name Service в домене;
Х оснастка Active Directory Users and Computers (Active Directory Ч пользовате ли и компьютеры) позволяет настраивать списки АСЬдля любых объектов Active Directory;
Х компонент RPC Locator (Локатор RPC) олицетворяет дочерний процесс [то есть использует его идентификатор безопасности (security identifier, SID)] при об ращении к службе каталогов для обеспечения проверки списка ACL. Экспорти рованные сведения доступны локально, но не на постоянной основе. Они види Публикация служб в Active Directory ГЛАВА 5 мы только при использовании способа, совместимого с Windows NT 4.0, напри мер при широковещании, рассмотренном в следующем разделе, Примечание В процессе поиска службой RFC Name Server отказы в доступе по при чине списков управления доступом обрабатываются как отсутствие соответствую щей записи.
Работа службы Windows 2000 RFC Name Service Все записи создаются как объекты Active Directory. В каждом домене Windows существует корневой контейнер службы RFC Name Service (Служба имен RPC) с составным именем:
CN=RpcServices,CN=System, CN=Configuration, О На рис. 5-3 проиллюстрирована роль службы RPC Name Service в Windows при взаимодействии сервера, клиентского компьютера и Active Directory.
5. Клиентский локатор Процесс возвращает ! RPC-сервера клиентскому RpcNs.dll - 2. Локатор в процессу Rpcss создает описатель поиска' 1 "::=::Х ' постоянную экспортирует запись в каталоге интерфейс Active Directory д ч.,;
Locator.dll R css e xe щ [ P -...
/Ль Сервер Клиент Пространство имен Active Directory L 4. Клиентский локатор, не найдя контроллера домена имя компьютера в своем кэше, Windows 2000 выполняет поиск в каталоге и находит запись Рис. 5-3. Роль службы RPC Name Service в Windows Широковещание Не обнаружив запись в кэше, локатор RPC выполняет поиск в Active Directory.
Потерпев неудачу, локатор RPC применяет широковещание, используемое в Win dows NT 4.0, извещая все узлы в сети о своем существовании. Широковещание таь же важно для обеспечения взаимодействия между Windows 2000 и Windows NT 4.0, поскольку компьютеры Windows NT 4.0 не обращаются к Active Directory, их мож но обнаружить лишь посредством широковещания. Если экспортирующий сервер работает под управлением Windows 2000, а контроллер домена, с которым этот сер вер взаимодействует, под управлением Windows NT -1.0, данные об экспортируе мом сервере RPC не сохраняются в Active Directory.
Таким образом, широковещание необходимо для нормальной работы. В среде Windows 2000 основного режима со всеми контроллерами домена, работающими Служба каталогов Active Directory 224 ЧАСТЬ иод управлением Windows 2000, неразумно рассылать широковещательные сообще ния при каждой неудачной попытке поиска, поэтому здесь поддержку широкове щательного метода следует отключить.
Чтобы локатор RPC поддерживал Windows NT 4.0, найдите в контейнере RpcServices атрибут NameSemice Flags и присвойте BitFlags значение 1. Поддержка широковещательного метода включена по умолчанию.
Примечание Компьютеры под управлением Windows 2000 не инициируют широко вещательный поиск, если поддержка локатора Active Directory включена, а широ ковещание отключено.
Настройка на стороне клиента Если в домене есть компьютеры под управлением Windows NT 3.51 или более по здней версии, следует выполнить настройку поиска средствами RPC Name Service.
Порядок поиска в Windows 2000 определяется средствами оснастки Active Directory Users and Computers (Active Directory Ч пользователи и компьютеры). Кроме того, ради совместимости с Windows NT 4.0 для широковещательного поиска использу ется протокол NetBIOS.
Активизация поиска средствами службы RPC Name Service в оснастке Active Directory Users and Computers Откройте оснастку Active Directory Users and Computers (Active Directory Ч поль зователи и компьютеры) и отметьте в меню View (Вид) команду Advanced Features (Дополнительные функции), если она не была отмечена ранее. Раскройте узел System, щелкните контейнер RpcServices правой кнопкой мыши и выберите в кон текстном меню команду Properties (Свойства). В открывшемся окне свойств RpcServices на вкладке General (Общие) установите флажок Enable RPC Name Service lookups for pre-Windows 2000 computers (Разрешить службе имен RPC вы полнение поиска для пред-Windows 2000 компьютеров). Но умолчанию служба имен RPC выполняет поиск для компьютеров под управлением Windows NT 4.0 и более ранних версий.
Использование локатора RPC и NetBIOS При работе почтовых ящиков локатора RPC применяется протокол NetBIOS. Ло катор RPC использует их для широковещательных рассылок, а их соответствую щие отклики - для уведомления в рамках домена. Данная функция реализована лишь для совместимости с Windows NT 4.0. Windows 2000 по умолчанию поддер живает NetBIOS поверх TCP/IP. NetBIOS можно отключить для отдельных ком пьютеров или при настройке DHCP (Dynamic Host Configuration Protocol).
Примечание Подробнее об отключении NetBIOS поверх TCP/IP Ч в книге Сети TCP/IP. Ресурсы Microsoft Windows 2000 Server (Русская Редакция, 2001).
Безопасность служб Служба выполняется в одном из двух контекстов безопасности:
Х в контексте учетной записи LocalSysteni;
Х в контексте учетной записи домена Windows 2000 (эта запись также называется учетной записью службы).
Публикация службе Active Directory ГЛАВА 5 Контекст безопасности, в котором выполняется служба, влияет на ее права доступа к компьютеру и сети.
Служба может выполняться в контексте учетной записи LocalSystem или учетной записи службы. LocalSystem - специальная стандартная локальная учетная запись без пароля, которую разрешается использовать лишь системным процессам.
На компьютерах под управлением Windows NT 4.0 и более ранних версий служба, выполняющаяся в контексте LocalSystem, наследует контекст безопасности диспет чера Service Control Manager (Диспетчер служебных программ). Такая служба не связана с какой-либо учетной записью зарегистрированного в системе пользовате ля, и у нее нет реквизитов для проверки подлинности (имя домена, имя и пароль пользователя), Она обладает ограниченным доступом к ресурсам сети, таким, как общие папки и каналы, поскольку у нее нет необходимых реквизитов и она под ключается но нулевому сеансу.
На компьютерах под управлением Windows 2000 служба, выполняющаяся в контек сте LocalSystem, применяет для доступа к ресурсам сети реквизиты компьютера и обладает полным доступом к локальным ресурсам системы. Служба, выполняюща яся в контексте LocalSystem па контроллере домена, обладает полным доступом к ресурсам каталога, поскольку на контроллере домена хранится реплика каталога, а LocalSystem обладает доступом ко всем локальным ресурсам.
В общем случае в любой системе служба должна выполняться под отдельной учет ной записью (независимо от ее роли), в том числе на контроллерах домена. При установке службы следует создать ее учетную запись и настроить списки управле ния доступом, предоставив этой учетной записи необходимые права.
Pages: | 1 | ... | 3 | 4 | 5 | 6 | 7 | ... | 18 | Книги, научные публикации