Trường nào sẽ được sử dụng khi xác thực với Active Directory?


12

Các đối tượng người dùng Active Directory bao gồm một số trường có thể được coi là định danh. Sau đây liệt kê một số trong số này với nhãn của họ trong ADUC và tên thuộc tính của họ:

  • Họ và tên
  • ? - Tên
  • Người dùng đăng nhập sAMAccountName - sAMAccountName
  • Đăng nhập người dùng UPN: userPrincipalName
  • ? - biệt danh

Tôi đang cố gắng để các nhà phát triển của chúng tôi chuẩn hóa chỉ sử dụng một trong số này khi viết mã tùy chỉnh xác thực chống lại AD - rắc rối là tôi không chắc cái nào là "đúng", hoặc nếu các mã khác nhau là đúng thì khác hoàn cảnh. Tôi thậm chí không chắc chắn bất kỳ trường nào ở trên nên được sử dụng!

Có ai khác chọn một người để sử dụng liên tục, và điều gì ảnh hưởng đến bạn trong quyết định đó? Bất kỳ tài liệu làm rõ vấn đề?


Tôi đã gặp một vài ứng dụng (cả được phát triển nội bộ và những thứ người khác đã làm) xác thực thông qua LDAP bằng trường cn. Trường này hiện được cập nhật tự động trong Trung tâm quản trị quảng cáo (được gắn nhãn Họ và tên) nếu bạn thay đổi trường tên hoặc họ, nghĩa là bạn không thể cho rằng trường cn có thể được coi là trường tên người dùng. Những nhà phát triển này đã sử dụng sai trường, hay Microsoft đã phá vỡ cn?
dunxd

Câu trả lời:


18

Một CN (tên chung) không tốt để đăng nhập, vì một mình CN không xác định duy nhất một người dùng. Tôi có thể có một

CN=Ryan Ries,OU=Dallas,DC=Domain,DC=com

và tôi cũng có thể có một

CN=Ryan Ries,OU=New York,DC=Domain,DC=com

CN của người dùng cũng là một RDN (tên phân biệt tương đối.) Họ có cùng CN, nhưng các DN khác nhau. Bạn có thể nhận thấy rằng bạn gặp phải vấn đề nếu bạn có hai người trong tổ chức của mình tên là Ryan Ries và bạn sẽ phải tạo SamAccountName cho người thứ hai giống như vậy rries2.

Một DN (tên phân biệt) không tốt để đăng nhập, bởi vì ai muốn đăng nhập vào hệ thống với tên người dùng như thế CN=ryan,OU=Texas,DC=brazzers,DC=comnào? Trong khi sử dụng một DN xác định duy nhất và dứt khoát một người dùng, thật khó chịu khi phải loại ra. Đó là cùng một loại khái niệm giữa các đường dẫn tương đối và đường dẫn tuyệt đối trên một hệ thống tệp. Nó cũng ngụ ý rằng bạn biết chính xác vị trí trong cấu trúc thư mục mà đối tượng được đặt mà không phải tìm kiếm nó. Mà bạn thường không làm.

Đây được gọi là Độ phân giải tên mơ hồ (ANR) - tìm kiếm thư mục cho người dùng khi bạn không có tên phân biệt của người đó.

UPN (Tên chính của người dùng) khá tốt vì chúng trông giống như địa chỉ email, chúng có thể giống với địa chỉ email công ty của người dùng, chúng dễ nhớ và được ưu tiên đăng nhập vì tên này sẽ được tìm kiếm trong miền địa phương đầu tiên, trước khi tìm kiếm nó trong rừng.

Microsoft cho biết: Quan điểm của UPN là hợp nhất các không gian tên đăng nhập và email để người dùng chỉ cần nhớ một tên duy nhất. UPN là tên đăng nhập ưa thích cho người dùng Windows. Người dùng nên sử dụng UPN của họ để đăng nhập vào miền. Tại thời điểm đăng nhập, UPN được xác thực trước tiên bằng cách tìm kiếm tên miền cục bộ, sau đó là danh mục toàn cầu. Việc không tìm thấy UPN trong miền cục bộ hoặc GC dẫn đến từ chối UPN. UPN có thể được chỉ định, nhưng không bắt buộc , khi tài khoản người dùng được tạo.

Hãy nhớ rằng bit "không bắt buộc" ở cuối khi thiết kế các ứng dụng của bạn.

SamAccountName cũng tốt vì SamAccountName cần là duy nhất cho tất cả mọi người trong miền (nhưng không phải là rừng.) Ngoài ra, SamAccountNames ngắn. Hầu hết mọi người đăng nhập bằng SamAccountNames, mặc dù họ không nhận dạng duy nhất bạn trong rừng AD, đó là lý do tại sao bạn phải chỉ định một tên miền đi cùng với SamAccountName để hệ thống biết bạn đang đăng nhập tên miền nào .

Đây là một số tài liệu tuyệt vời về vấn đề này để đọc thêm:

http://msdn.microsoft.com/en-us/l Library / windows / desktop / ms677605 (v = vs85) .aspx

http://msdn.microsoft.com/en-us/l Library / windows / desktop / ms680857 (v = vs85) .aspx


4

Nếu bạn đang đề cập đến tên người dùng như một cái gì đó mà ai đó sẽ nhập để đăng nhập, tôi sẽ khuyên bạn nên sAMAccountName, đó là duy nhất kết hợp với một tên miền hoặc tên miền userPrincipalNameduy nhất trong một khu rừng.

Theo như tên người dùng là định danh duy nhất, Windows sử dụng SID cho tất cả các mục kiểm soát truy cập và cung cấp một bộ phương thức đầy đủ để dịch sang SID từ tên người dùng. SID khớp với phép ẩn dụ của người dùng trong suốt thời gian của tài khoản, vì việc đổi tên và di chuyển trong một miền không có hiệu lực, nhưng xóa và tạo lại kết quả trong SID mới.

Cuối cùng, tôi sẽ gọi LookupAccountName, trong đó có một chuỗi đại diện cho tên người dùng, và trả về sAMAccountName, các SIDvà tên miền của miền người dùng được tìm thấy trong.

Sau đó, người dùng có thể sử dụng bất kỳ cú pháp nào được hỗ trợ bởi các cửa sổ để đăng nhập và không cần đào tạo bổ sung.


Tra cứuAccountName có chấp nhận UPN hoặc sAMAccountName hoặc DOMAIN \ sAMAccountName đủ điều kiện hoặc tất cả các mục trên không? Nó không rõ ràng từ các tài liệu bạn liên kết đến.
dunxd

Danh mục tài liệu các định dạng nó hỗ trợ: DOMAIN\Account, DOMAIN.COM\Account, Account, Account@DOMAIN.COM. Nó nói tên đủ điều kiện là nhanh hơn, nhưng những cái khác vẫn có sẵn.
Mitch

0

Tôi sẽ khuyên bạn nên cho phép người dùng chọn định dạng của tên mình muốn sử dụng và xác định đầu vào của người dùng ở phía ứng dụng. ví dụ: Nếu người dùng gõ: username@domain.com - hãy xem nó là UPN và tìm kiếm UPN trong AD. Nếu người dùng gõ: tên người dùng - hãy coi nó là samAccountName cho tên miền mặc định được xác định trước và tất nhiên nếu người dùng nhập tên miền \ tên người dùng - hãy coi đó là samAccountName từ tên miền được chỉ định. Luôn lấy SID của người dùng và gán tất cả các quyền cho SID vì mọi người kết hôn và tên người dùng có thể thay đổi.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.