ADSI предоставляет набор COM-интерфейсов для работы с ADAM и обеспечивает наиболее широкий набор инструментов.
LDAP “облегченный” протокол доступа, позволяющий изменять содержимое службы каталогов и выполнять поиск по дереву объектов. LDAP может быть использован в приложениях, для которых работа с ADAM-ом не является основной функциональностью.
Пространство имен System.DirectoryServices (SDS) разработано на базе ADSI и предоставляет возможности, схожие с теми, что предоставляет протокол LDAP. SDS можно использовать в приложениях на базе технологии Microsoft.NET.
Провайдер доступа к данным ADsDSOObject предоставляет SQL-подобный интерфейс чтения, изменения и поиска данных в AD. Из всех описанных средств это обладает самой низкой производительностью, но оно может быть использовано в приложениях, выполняющих поиск в ADAM, если скорость работы не является критичной.
Работа с объектами: чтение, изменение и поиск данных
Рассмотрим работу с ADAM на примере, использующем пространство имен System.DirectoryServices.
В примере производится поиск, и в найденных объектах изменяется значение свойства MyAttribute1. Проверка существования значения атрибута не выполняется предполагается, что оно существует. Также не выполняется обработка исключений. Сделано это для того, чтобы не загромождать код примера.
using System;
using System.DirectoryServices;
namespace SDSExample
{
class SDSExample
{
[STAThread]
static void Main(string[] args)
{
//Подключение к ADAM-у
DirectoryEntry deRoot =
new DirectoryEntry(
"LDAP://LOCALHOST:389/CN=Personnel,OU=MyApp,O=MyCompany,C=RU");
//Создание объекта класса DirectorySearcher, выполняющего поиск
DirectorySearcher dSeacher =
new DirectorySearcher(deRoot, "(objectClass=MyClass1)");
//Указание искать по всему поддереву корневого объекта
dSeacher.SearchScope = SearchScope.Subtree;
//Поиск всех объектов, удовлетворяющих условию
SearchResultCollection srEntries = dSeacher.FindAll();
for(int index=0; index<srEntries.Count; index++)
{
//Вывод значений атирбутов объекта
SearchResult srEnrty = srEntries[index];
Console.WriteLine(index);
Console.WriteLine("distinguishedName ="
+ srEnrty.Properties["distinguishedName"]);
Console.WriteLine("MyAttribute1 ="
+ srEnrty.Properties["MyAttribute1"][0]);
Console.WriteLine();
//Изменение значения атрибута MyAttribute1
DirectoryEntry deEntry = srEnrty.GetDirectoryEntry();
deEntry.Properties["MyAttribute1"].Value =
"new_value_of_Object" + index.ToString();
//Фиксирование изменений
deEntry.CommitChanges();
deEntry.Close();
}
deRoot.Close();
}//Main()
}//class SDSExample
}//namespace SDSExampleРабота с пользователями
Для некоторых приложений может потребоваться возможность управления пользователями ADAM (не Windows). Работу с пользователями из приложения демонстрирует следующий пример. В нем создается новый пользователь с именем CN=Vasiliy_Pupkin,CN=Users,OU=MyApp,O=MyCompany,C=RU и добавляется в группу CN=USER_GROUP,OU=MyApp,O=MyCompany,C=RU.
using System;
using System.DirectoryServices;
namespace ADAMUserExample
{
class ADAMUser
{
[STAThread]
static void Main(string[] args)
{
DirectoryEntry deUserRoot =
new DirectoryEntry(
"LDAP://LOCALHOST:389/CN=Users,OU=MyApp,O=MyCompany,C=RU");
//Создание пользователя
DirectoryEntry deNewUser = deUserRoot.Children.Add(
"CN=Vasiliy_Pupkin", "User");
deNewUser.Properties["displayName"].Value = "Vasiliy Pupkin";
deNewUser.CommitChanges();
//назначение пароля
deNewUser.Properties["userpassword"].Value = "Vasiliy_Password_1";
deNewUser.CommitChanges();
//активирование пользователя
deNewUser.Properties["msds-useraccountdisabled"].Value = false;
//отмена срока действия пароля
deNewUser.Properties["msds-userdontexpirepassword"].Value = true;
deNewUser.CommitChanges();
DirectoryEntry deUserGroup =
new DirectoryEntry(
"LDAP:// LOCALHOST:389/CN=USER_GROUP,OU=MyApp,O=MyCompany,C=RU");
deUserGroup.Properties["member"].Add(
deNewUser.Properties["distinguishedName"].Value);
deUserGroup.CommitChanges();
deUserGroup.Close();
deNewUser.Close();
deUserRoot.Close();
}//Main
}//class ADAMUser
}Однако если попытаться выполнить данный пример, используя конфигурацию ADAM по умолчанию, возникнет ошибка в момент применения пароля пользователя. Это произойдет потому, что конфигурация по умолчанию запрещает смену пароля с использованием незащищенного канала (в примере используется порт 389 порт незащищенного канала, предлагаемый при установке ADAM). Возможны два варианта решения проблемы. Первый настроить защищенный канал (порт защищенного канала, предлагаемый при установке, 636, использует SSL для шифрования канала) и подключаться к ADAM через него. Второй настроить ADAM так, чтобы изменение пароля через незащищенное соединение было разрешено. Для этого необходимо установить тринадцатый символ атрибута dSHeuristics объекта конфигурации с полным именем CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,CN={идентификатор раздела конфигурации ADAM-а} в 1. По умолчанию значение этого атрибута в ADAM-е не установлено.
LDF-скрипт изменяющий соответствующим образом конфигурацию ADAM:
dn: CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=X
changetype: modify
replace: dSHeuristics
dSHeuristics : 0000000001001
-Выполнить этот скрипт можно с помощью утилиты LDIFDE.EXE, как показано ниже.
c:\windows\adam\ldifde.exe -i -f config.ldf -s localhost.ldf -j . -c "CN=Configuration,DC=X" #configurationNamingContext -kОсобенности использования ADAM в многопользовательских распределенных приложениях
Работа с ADAM из многопользовательских приложений имеет один нюанс, который необходимо учитывать на этапе проектирования системы. Нюанс этот касается возможности идентификации (authentication) пользователя ADAM. По какой-то причине подключение к ADAM, как и к AD, возможно только при наличии первичного контекста безопасности (primary security token) в процессе, обращающемся к ADAM. Рассмотрим два случая: первый когда приложение работает от имени пользователя, информация о котором хранится в ADAM, и второй когда приложение работает от имени текущего пользователя Windows. В первом случае идентификатор пользователя и пароль вводятся при запуске приложения. Обладая этой информацией, приложение может подключиться к ADAM под первичным контекстом безопасности в любой свой части (очень важно для распределенных приложений). Сложности возникают во втором случае. Заключаются они в том, что получить первичный контекст безопасности можно только на том компьютере, где запущено клиентское приложение, с которым работает пользователь. Этим приложением может быть как Windows-клиент, работающий с сервером приложений, так и Internet Explorer в случае Web-приложений. В обоих случаях приложению неизвестен пароль пользователя. Из-за этого возникает необходимость в передаче контекста безопасности с клиента на сервер. Сделать это можно с помощью функций WinAPI InitializeSecurityContext и AcceptSecurityContext, которые позволяют зашифровать данные о контексте безопасности пользователя, передать их в процесс сервера (возможно, на другом компьютере) и восстановить контекст безопасности в процессе сервера. В этом случае для передачи контекста безопасности необходимо использовать механизм идентификации Kerberos, что не всегда возможно из-за сложности настройки и прочих причин, таких, как соединение клиента и сервера через Proxy-сервер. Использовать именно Kerberos нужно потому, что этот механизм, в отличие от NTLM и Digest, позволяет передавать по сети первичный идентификатор безопасности.
Рассмотрим для примера ASP.NET-приложение. Здесь существует возможность использовать интегрированную систему безопасности Windows для идентификации пользователя на сайте. После идентификации серверный код можно запустить под опознанным пользователем так называемое имитирование (impersonation) контекста безопасности пользователя. Однако добиться таким образом желаемого результата подключения к ADAM под пользователем приложения не удастся. Подключение к ADAM из-под сымитированного контекста безопасности пользователя не возможно необходим первичный контекст безопасности. В англоязычной литературе данная проблема носит название double-hop issue, что можно перевести как проблема двойного скачка. Она возникает всякий раз, когда необходимо передать контекст безопасности от одного процесса другому через процесс-посредник. В случае с ASP.NET-приложением процессом-источником является Internet Explorer, процессом-приемником ADAM-а, а посредником является процесс ASP.NET.
Таким образом, при проектировании архитектуры приложения, в котором предполагается использовать ADAM, необходимо на раннем этапе позаботиться о способах подключения к ADAM и методах идентификации пользов
