Работа с объектами: чтение, изменение и поиск данных
Рассмотрим работу с 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=Xchangetype: modifyreplace: dSHeuristicsdSHeuristics : 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 и методах идентификации пользователей в случае многопользовательского приложения.
Из всего выше сказанного можно сделать вывод, что ADAM является мощным инструментом, позволяющим использовать в приложении возможности Active Directory. Отчасти это так – ADAM позволяет расширять схему, создавать объекты этих классов, организовывать их в иерархии, а также выполнять поиск этих объектов. Гибкая система управления пользователями и контролем доступа предоставляет большие возможности для использования ADAM в приложениях, оперирующих конфиденциальной информацией. Механизмы архивирования и репликации позволяют создавать надежные отказоустойчивые системы.
Слабая эргономичность средств администрирования и некоторые трудности применения в многопользовательских приложениях несколько портят картину. Однако при грамотном проектировании использование ADAM может стать отличным выбором для широкого спектра программных систем.