Claw.ru | Рефераты по информатике, программированию | Active Directory for Application Mode Active Directory for Application Mode | Категория реферата: Рефераты по информатике, программированию | Теги реферата: тесты онлайн, рефераты помощь | Добавил(а) на сайт: Ipat'ev. Предыдущая страница реферата | 2  3  4  5  6  7  8  9  10  11  12 | Следующая страница реферата  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:

Выполнить этот скрипт можно с помощью утилиты LDIFDE.EXE, как показано ниже.

Особенности использования 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, позволяет передавать по сети первичный идентификатор безопасности.