Службы Active Directory: PrincipalContext - что такое DN объекта-контейнера - PullRequest
Новая
       52

Службы Active Directory: PrincipalContext - что такое DN объекта-контейнера

19 голосов
/ 29 марта 2010

В настоящее время я пытаюсь пройти аутентификацию через Active Directory Services с использованием класса PrincipalContext.Я хотел бы, чтобы мое приложение проходило аутентификацию в Домене с использованием контекстов Sealed и SSL.Для этого мне нужно использовать следующий конструктор PrincipalContext (ссылка на страницу MSDN) : 

public PrincipalContext(
    ContextType contextType,
    string name,
    string container,
    ContextOptions options
)

В частности, я использую конструктор так: 

PrincipalContext domainContext = new PrincipalContext(
    ContextType.Domain, 
    domain, 
    container, 
    ContextOptions.Sealing | ContextOptions.SecureSocketLayer);

MSDN говорит о «контейнере»:

Контейнер в хранилище, используемый в качестве корня контекста.Все запросы выполняются под этим корнем, и все вставки выполняются в этот контейнер.Для типов контекста Domain и ApplicationDirectory этот параметр является отличительным именем (DN) объекта-контейнера.

Что такое DN объекта-контейнера?Как мне узнать, что мой контейнерный объект?Могу ли я запросить об этом сервер Active Directory (или LDAP)?

1 Ответ

30 голосов
/ 29 марта 2010

Ну, мне удалось выяснить вопрос: 

PrincipalContext domainContext = new PrincipalContext(ContextType.Domain,domain);

domainContext.ValidateCredentials(userName, password, 
    ContextOptions.Negotiate | ContextOptions.SecureSocketLayer);

Указав ContextOptions в методе ValidateCredentials (а не в конструкторе), это позволило мне избежать необходимости указывать DN для объекта контейнера.

UPDATE:

Хотя я должен пояснить, что после дальнейших экспериментов я обнаружил, что любые запросы, полученные из этого объекта PrincipalContext, выполняются в зашифрованном виде.

Очевидно, что когда ContextOptions установлены в ValidateCredentials, эти параметры используются только для этого конкретного вызова ValidateCredentials. Но вот где это становится странным ...

Итак, я хотел, чтобы мои запросы к серверу AD также проходили в зашифрованном виде. Пример запроса: 

UserPrincipal p = UserPrincipal.FindByIdentity(
    domainContext, IdentityType.SamAccountName, userName);
var groups = p.GetGroups();
foreach (GroupPrincipal g in groups) { /* do something */ }

Приведенный выше код получает список всех групп, к которым принадлежит пользователь, но это происходит в незашифрованном виде. Поэтому, после долгих хлопот, я обнаружил, что DN никогда не нужно устанавливать. 

PrincipalContext domainContext = new PrincipalContext(ContextType.Domain,domain,
    null,ContextOptions.Negotiate | ContextOptions.SecureSocketLayer);

Я обнаружил, что могу установить для объекта контейнера (DN) значение null. И это прекрасно работает. Установка его в пустую строку ("") приводит к исключению некоторого неизвестного типа, поэтому не думайте, что вы можете дать ему пустую строку.

А вот и странная часть. Можно подумать, что установка параметра SecureSocketLayer в PrincipalContext будет означать, что вам не нужно явно устанавливать его при использовании VerifyCredentials. Но я обнаружил, что если я не установлю его в части VerifyCredentials, аутентификация будет неудачной, но запросы (как в примере с группами) все равно будут выполняться в зашифрованном виде.

Возможно, я просто еще не полностью понимаю аутентификацию и запросы AD, но мне это кажется странным.

...