KnigaRead.com/
KnigaRead.com » Компьютеры и Интернет » Программирование » Симон Робинсон - C# для профессионалов. Том II

Симон Робинсон - C# для профессионалов. Том II

На нашем сайте KnigaRead.com Вы можете абсолютно бесплатно читать книгу онлайн Симон Робинсон, "C# для профессионалов. Том II" бесплатно, без регистрации.
Перейти на страницу:

Интерфейсы службы активного каталога (ADSI)

Интерфейсы службы активного каталога (ADSI) являются программным интерфейсом к службам каталога. ADSI определяет некоторые интерфейсы COM, которые реализуются провайдерами ADSI. Это означает, что клиент может использовать различные службы каталога с одними и теми же программными интерфейсами. Классы среды .NET в пространстве имен System.DirectoryServices используют интерфейсы ADSI.

На следующем рисунке можно видеть некоторых провайдеров ADSI (LDAP, WinNT, NDS), которые реализуют интерфейсы COM, такие как IAD и IUnknown. Сборка System.DirectoryServices использует провайдеров ADSI:

Программирование активного каталога

Чтобы разрабатывать программы для активного каталога, мы используем классы из пространства имен System.DirectoryServices. С помощью этих классов можно запрашивать объекты, просматривать и обновлять свойства, а также вести поиск объектов.

В следующих сегментах кода простое консольное приложение C# демонстрирует применение классов в пространстве имен System.DirectoryServices.

Классы в System.DirectoryServices

Следующая таблица показывает основные классы в пространстве имен System.DirectoryServices:

Класс Описание DirectoryEntry Этот класс является основным классом в пространстве имен System.DirectoryServices. Объект этого класса представляет объект в хранилище активного каталога. Мы используем этот класс для связывания с объектом, просмотра и обновления свойств. Свойства объекта представлены в PropertyCollection. Каждый элемент в PropertyCollection имеет в свою очередь PropertyValueCollection. DirectoryEntries DirectoryEntries является коллекцией объектов DirectoryEntry. Свойство Children объекта DirectoryEntry возвращает список объектов в коллекцию DirectoryEntries. DirectorySearcher Этот класс является основным классом, используемым для поиска объектов со специфическими атрибутами. Чтобы определить поиск, можно использовать класс SortOption и перечисления SearchScope, SortDirection и ReferalChasingOption. Результаты поиска находятся в классе SearchResult или SearchResultCollection. Мы также получаем объекты ResultPropertyCollection и ResultPropertyValueCollection.

Связывание

Чтобы получить значения объекта в активном каталоге, мы должны соединиться с активным каталогом. Процесс соединения называется связыванием. Путь доступа связывания может выглядеть следующим образом:

LDAP://dc01.globalknowledge.net/OU=Marketing, DC=GlobalKnowledge, DC=Com

Во время процесса связывания можно определить следующие позиции:

□ Протокол, определяющий используемого провайдера.

□ Имя сервера контроллера домена.

□ Номер порта серверного процесса.

□ Известное имя объекта для идентификации объекта, к которому требуется доступ.

□ Имя пользователя и пароль, если требуется другой пользователь для доступа к активному каталогу.

□ Можно также определить тип аутентификации, если требуется шифрование.

Протокол

Первая часть пути связывания определяет провайдера ADSI. Провайдер реализован как сервер COM; для идентификации можно найти идентификатор программы прямо в ключе HKEY_CLASSES_ROOT. Провайдеры, которых получают вместе с Windows 2000, перечислены в следующей таблице:

Протокол Описание LDAP Сервер LDAP, такой как каталог Exchange и сервер активного каталога Windows 2000. GC GC применяется для доступа к глобальному каталогу в активном каталоге. Он может использоваться для быстрых запросов. IIS С помощью провайдера ADSI для IIS можно создавать новые web-сайты в каталоге IIS. WinNT Чтобы получить доступ к базе данных пользователей старых доменов Windows NT 4, можно использовать провайдера ADSI для WinNT, Факт, что пользователи NT 4 имеют только несколько атрибутов, остается неизменным. NDS Этот идентификатор программы используется для коммуникации со службами каталогов Novell. NWCOMPAT С помощью NWCOMPAT можно получить доступ к старым каталогам Novell: Novell Netware 3.x.

Имя сервера

Имя сервера следует за протоколом в строке соединения. Имя сервера является не обязательным, если вы зарегистрировались в домене активного каталога. Без имени сервера происходит связывание без сервера; это означает, что Windows 2000 пытается получить "лучший" контроллер домена в домене, который ассоциирован с пользователем, выполняющим связывание. Если внутри сайта нет сервера, будет использоваться первый найденный контроллер домена.

Связывание без сервера может выглядеть следующим образом: LDAP://OU=Sales, DC=GlobalKnowladge, DC=Com.

Номер порта

После имени сервера можно определить номер порта серверного процесса, используя синтаксис :xxx. По умолчанию для сервера LDAP используется номер порта 389: LDAP://dc01.globalknowledge.net:389. Сервер Exchange использует тот же самый номер порта, что и сервер LDAP. Если сервер Exchange установлен на той же системе, например, как контроллер домена активного каталога, то можно сконфигурировать другой порт.

Известное имя

Четвертая часть, которую мы должны определить в пути доступа,— это известное имя (DN — Distinguished Name). Известное имя является гарантированным уникальным именем, идентифицирующим объект, к которому требуется доступ. В активном каталоге для определения имени объекта можно использовать синтаксис LDAP, который основывается на X.500.

Известное имя

CN=Christian Nagel, OU=Trainer, DC=GlobalKnowledge, DC=com

определяет общее имя (CN) Christian Nagel в организационной единице (OU) Trainer в компоненте домена (DC) GlobalKnowledge домена GlobalKnowledge.com. Часть, которая определена самой правой является корневым объектом домена. Имя должно следовать иерархии дерева объектов.

Спецификацию LDAP для строкового представления известных имен можно найти в RFC 2253: www.ietf.org/rfc/rfc2253.txt.

Относительное известное имя

Относительное известное имя (RDN) используется для ссылки на объект внутри контейнерного объекта. Для RDN спецификации OU и DC не требуются, будет достаточно общего имени. CN=Christian Nagel является относительным известным именем внутри организационной единицы. Относительное известное имя может использоваться, если мы уже имеем ссылку на объект контейнера и хотим получить доступ к объектам-потомкам.

Используемый по умолчанию именующий контекст

Если известное имя не определено в пути доступа, процесс связывания будет выполняться в используемом по умолчанию именующем контексте. Можно считать используемый по умолчанию именующий контекст с помощью rootDSE. LDAP 3.0 определяет rootDSE как корень дерева каталогов на сервере каталога.

LDAP://rootDSE или LDAP://servername/rootDSE

Перечисляя все свойства rootDSE, можно получить информацию о defaultNamingContext, который будет использоваться, когда не определено никакое имя. schemaNamingContext и configurationNamingContext определяют требуемые имена, которые будут использоваться для доступа к схеме и конфигурации в хранилище активного каталога.

Следующий код используется для получения всех свойств rootDSE. Речь идет о связывании с помощью класса DirectoryEntry:

using (DirectoryEntry de = new DirectoryEntry()) {

 de.Path = "LDAP://celtlcrain/rootDSE";

 de.Username = @"sentinelchris";

 de.Password = "mausemaus3";

 PropertyCollection props = de.Properties;

 foreach (string prop in props.PropertyNames) {

  PropertyValueCollection values = props[prop];

  foreach (string val in values) {

   Console.Write(prop + ": ");

   Console.WriteLine(val);.

  }

 }

}

Помимо других свойств результат вывода этой программы показывает defaultNamingContext DC=eichkogelstrasse, DC=local, контекст, который можно использовать для доступа к схеме: CN=Schema, CN=Configuration, DC=eichkogelstrasse, DC=local и именующий контекст конфигурации: CN=Configuration, DC=eichkogelstrasse, DC=local:

Идентификатор объекта

Каждый объект имеет уникальный идентификатор — GUID. GUID является уникальным 128-битовым числом. Мы можем с соединиться с объектом, используя GUID. Таким образом, мы всегда получаем тот же самый объект, даже если объект был перемещен в другой контейнер. GUID генерируется при создании объекта и всегда остается тем же самым.

Перейти на страницу:
Прокомментировать
Подтвердите что вы не робот:*