2010-03-29 24 views
18

Tôi hiện đang cố gắng xác thực qua Dịch vụ Thư mục Họat động bằng cách sử dụng lớp PrincipalContext. Tôi muốn ứng dụng của tôi xác thực với Miền bằng ngữ cảnh Sealed và SSL. Để làm được điều này, tôi phải sử dụng the following constructor of PrincipalContext (link to MSDN page):Dịch vụ thư mục hoạt động: PrincipalContext - DN của đối tượng "vùng chứa" là gì?

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

Cụ thể, tôi đang sử dụng các nhà xây dựng như vậy:

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

MSDN nói về "container":

Thùng chứa trên cửa hàng để sử dụng làm gốc của ngữ cảnh. Tất cả các truy vấn được thực hiện dưới gốc này và tất cả các chèn được thực hiện vào vùng chứa này. Đối với tên miền và loại bối cảnh ApplicationDirectory, thông số này là tên phân biệt (DN) của đối tượng chứa.

DN của đối tượng chứa là gì? Làm cách nào để tìm hiểu đối tượng chứa của tôi là gì? Tôi có thể truy vấn máy chủ Active Directory (hoặc LDAP) cho điều này không?

Trả lời

28

Vâng, tôi cố gắng tìm ra vấn đề:

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

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

Bằng cách xác định ContextOptions trong phương pháp ValidateCredentials (thay vì trong constructor), điều này cho phép tôi để tránh phải chỉ định một DN cho một container vật.

UPDATE:

Mặc dù tôi nên làm rõ rằng sau khi thử nghiệm hơn nữa, tôi thấy rằng bất cứ thắc mắc bắt nguồn từ đối tượng PrincipalContext này diễn ra UN-mã hóa.

Rõ ràng, khi ContextOptions được đặt trong ValidateCredentials, các tùy chọn này chỉ được sử dụng cho cuộc gọi cụ thể của ValidateCredentials. Nhưng đây là nơi nó lạ ...

Vì vậy, tôi muốn có các truy vấn của mình đến máy chủ AD cũng được mã hóa. Ví dụ truy vấn:

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

Mã trên có danh sách tất cả các nhóm mà người dùng thuộc về, nhưng nó xảy ra ở dạng không rõ ràng (không được mã hóa). Vì vậy, sau nhiều khó khăn, tôi phát hiện ra rằng DN không bao giờ cần phải được thiết lập.

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

Tôi thấy rằng tôi có thể đặt đối tượng vùng chứa (DN) thành không. Và điều này hoạt động tốt. Đặt nó thành một chuỗi rỗng ("") dẫn đến một ngoại lệ của một số loại không xác định, vì vậy đừng nghĩ rằng bạn có thể cho nó một chuỗi rỗng.

Và đây là phần lạ. Bạn sẽ nghĩ rằng việc thiết lập tùy chọn SecureSocketLayer trong PrincipalContext có nghĩa là bạn không phải thiết lập rõ ràng nó khi bạn sử dụng VerifyCredentials. Nhưng tôi thấy rằng nếu tôi không đặt nó trong phần VerifyCredentials, xác thực sẽ thất bại, nhưng các truy vấn (như trong ví dụ cho Groups) vẫn diễn ra được mã hóa.

Có lẽ tôi chưa hiểu đầy đủ về xác thực và truy vấn AD, nhưng điều đó có vẻ như hành vi kỳ quặc đối với tôi.

+1

Lời giải thích của bạn cho "phần lạ" là chìa khóa để khắc phục sự chậm trễ 20 giây gọi là "ValidateCredentials'. Cảm ơn! –

+0

Tôi biết điều này là siêu cũ nhưng tôi đang nghiên cứu có hay không sử dụng SSL qua Đăng ký và đi qua bài đăng này. Tôi tin rằng bạn có thể sử dụng 'null' trong constructor. Đó là cách tôi làm điều đó khi tôi muốn chỉ định ContextOptions. Ví dụ: 'var pc = new PrincipalContext (ContextType.Domain, Environment.UserDomainName, null, ContextOptions.Sealing);' – famousKaneis

+0

@nameless: Tôi nghĩ đó là những gì mã hiển thị trong khối mã cuối cùng. (FWIW, tôi hầu như không nhớ điều này là gì, nhưng hãy nhớ rằng thực sự hạnh phúc khi tôi tìm ra nó.) :) – Pretzel

Các vấn đề liên quan