ฟิลด์ใดที่จะใช้เมื่อตรวจสอบสิทธิ์กับ Active Directory


12

วัตถุผู้ใช้ Active Directory มีจำนวนฟิลด์ที่สามารถพิจารณาเป็นตัวระบุได้ รายการต่อไปนี้แสดงรายการบางส่วนพร้อมป้ายกำกับของพวกเขาใน ADUC และชื่อแอตทริบิวต์ของพวกเขา:

  • ชื่อเต็ม - cn
  • ? - ชื่อ
  • การเข้าสู่ระบบของผู้ใช้ sAMAccountName - sAMAccountName
  • การเข้าสู่ระบบของผู้ใช้ UPN: userPrincipalName
  • ? - ชื่อที่แตกต่าง

ฉันกำลังพยายามให้นักพัฒนาของเราสร้างมาตรฐานให้ใช้หนึ่งในนั้นเมื่อเขียนโค้ดที่กำหนดเองซึ่งรับรองความถูกต้องกับโฆษณา - ปัญหาคือฉันไม่แน่ใจว่าเป็น "ขวา" หรือว่าแตกต่างกันเป็นรหัสที่แตกต่างกัน พฤติการณ์ ฉันไม่แน่ใจว่าควรใช้ฟิลด์ใด ๆ ข้างต้น!

มีใครอีกบ้างที่เลือกใช้อย่างสม่ำเสมอและอะไรที่มีอิทธิพลต่อคุณในการตัดสินใจ เอกสารใดที่ชี้แจงปัญหา


ฉันพบบางแอปพลิเคชั่น (ทั้งที่พัฒนาภายในและสิ่งที่คนอื่นทำ) ซึ่งรับรองความถูกต้องผ่าน LDAP โดยใช้ฟิลด์ cn ฟิลด์นี้จะได้รับการอัปเดตโดยอัตโนมัติใน AD Admin Center (ชื่อเต็ม) หากคุณเปลี่ยนฟิลด์ชื่อหรือนามสกุลหมายความว่าคุณไม่สามารถถือว่าฟิลด์ cn ถือเป็นฟิลด์ชื่อผู้ใช้ นักพัฒนาซอฟต์แวร์เหล่านี้ใช้ฟิลด์ที่ไม่ถูกต้องหรือ Microsoft แตก cn หรือไม่?
dunxd

คำตอบ:


18

CN (ชื่อสามัญ) ไม่ดีสำหรับการเข้าสู่ระบบเนื่องจาก CN เพียงอย่างเดียวไม่ได้ระบุผู้ใช้โดยเฉพาะ ฉันสามารถมี

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

และฉันก็สามารถมี

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

CN ของผู้ใช้นั้นเป็น RDN (ชื่อจำเพาะที่สัมพันธ์กัน) พวกเขามี CN เดียวกัน แต่ DN ต่างกัน คุณอาจจะสังเกตเห็นว่าคุณทำงานเป็นปัญหาถ้าคุณมีคนสองคนในองค์กรของคุณชื่อไรอัน Ries และคุณจะต้องทำให้ samAccountName rries2สำหรับสองสิ่งที่ชอบ

DN (ชื่อจำเพาะ) ไม่ดีสำหรับการเข้าสู่ระบบเพราะใครต้องการที่จะเข้าสู่ระบบด้วยชื่อผู้ใช้เช่นCN=ryan,OU=Texas,DC=brazzers,DC=com? ในขณะที่ใช้งาน DN จะระบุตัวตนของผู้ใช้อย่างชัดเจนและไม่ซ้ำใคร มันเป็นแนวคิดแบบเดียวกันระหว่างพา ธ สัมพัทธ์กับพา ธ สัมบูรณ์บนระบบไฟล์ นอกจากนี้ยังบอกเป็นนัยว่าคุณทราบอย่างแน่ชัดว่าอยู่ที่ไหนในโครงสร้างไดเรกทอรีที่วัตถุอยู่โดยไม่ต้องค้นหา ซึ่งคุณมักจะทำไม่ได้

สิ่งนี้เรียกว่าการแก้ปัญหาชื่อกำกวม (ANR) - ค้นหาไดเร็กทอรีสำหรับผู้ใช้เมื่อคุณไม่มีชื่อจำเพาะของเขาหรือเธอ

UPN (ชื่อผู้ใช้หลัก) ค่อนข้างดีเพราะดูเหมือนที่อยู่อีเมลพวกเขาสามารถเหมือนกับที่อยู่อีเมลองค์กรของผู้ใช้จดจำได้ง่ายและต้องการลงชื่อเข้าใช้ด้วยเพราะจะค้นหาชื่อ ในโดเมนท้องถิ่นก่อนก่อนค้นหาในฟอเรสต์

Microsoft กล่าวว่า: จุดประสงค์ของ UPN คือการรวมเนมสเปซอีเมลและการเข้าสู่ระบบเพื่อให้ผู้ใช้ต้องการเพียงชื่อเดียวเท่านั้น UPN เป็นชื่อเข้าสู่ระบบที่ต้องการสำหรับผู้ใช้ Windows ผู้ใช้ควรใช้ UPN ของพวกเขาเพื่อเข้าสู่ระบบโดเมน ณ เวลาเข้าสู่ระบบ UPN จะได้รับการตรวจสอบความถูกต้องก่อนโดยการค้นหาโดเมนท้องถิ่นจากนั้นจึงทำการแคตตาล็อกส่วนกลาง ความล้มเหลวในการค้นหา UPN ในโดเมนท้องถิ่นหรือผลลัพธ์ของ GC ในการปฏิเสธ UPN สามารถกำหนด UPN แต่ไม่จำเป็นเมื่อสร้างบัญชีผู้ใช้

โปรดจำไว้ว่าบิต "ไม่จำเป็น" ในตอนท้ายเมื่อออกแบบแอปพลิเคชันของคุณ

SamAccountName ก็ดีเช่นกันเพราะ SamAccountName ต้องไม่ซ้ำกันสำหรับทุกคนในโดเมน (แต่ไม่ใช่ฟอเรสต์) นอกจากนี้ SamAccountNames ยังสั้น คนส่วนใหญ่เข้าสู่ระบบด้วย SamAccountNames แม้ว่าพวกเขาจะไม่ระบุตัวคุณใน AD Forest โดยเฉพาะซึ่งเป็นสาเหตุที่คุณต้องระบุชื่อโดเมนที่จะไปพร้อมกับ SamAccountName ของคุณเพื่อให้ระบบรู้ว่าคุณกำลังพยายามเข้าสู่ระบบโดเมนใด .

นี่คือเอกสารที่ยอดเยี่ยมเกี่ยวกับปัญหาสำหรับการอ่านเพิ่มเติม:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms677605(v=vs.85).aspx

http://msdn.microsoft.com/en-us/library/windows/desktop/ms680857(v=vs.85).aspx


4

หากคุณอ้างถึงชื่อผู้ใช้ว่าเป็นสิ่งที่ใครบางคนจะพิมพ์เพื่อเข้าสู่ระบบฉันจะแนะนำอย่างใดอย่างหนึ่งsAMAccountNameซึ่งจะไม่ซ้ำกันรวมกับชื่อโดเมนหรือuserPrincipalNameซึ่งจะไม่ซ้ำกันภายในฟอเรสต์

เท่าที่ชื่อผู้ใช้เป็นตัวระบุที่ไม่ซ้ำกัน Windows จะใช้ SID สำหรับรายการการควบคุมการเข้าถึงทั้งหมดและมีชุดวิธีการแปล SID จากชื่อผู้ใช้ทั้งหมด SID ตรงกับคำอุปมาของผู้ใช้สำหรับอายุการใช้งานของบัญชีเนื่องจากการเปลี่ยนชื่อและย้ายภายในโดเมนนั้นไม่มีผลกระทบใด ๆ แต่การลบและสร้างผลลัพธ์ใหม่ใน SID ใหม่

ด้วยเหตุนี้ฉันจะโทรหาLookupAccountNameซึ่งใช้สตริงที่แสดงชื่อผู้ใช้และส่งกลับsAMAccountNameชื่อSIDและและชื่อโดเมนของโดเมนที่ผู้ใช้พบ

ผู้ใช้สามารถใช้ไวยากรณ์ที่ได้รับการสนับสนุนโดย windows เพื่อเข้าสู่ระบบและไม่จำเป็นต้องมีการฝึกอบรมเพิ่มเติม


LookupAccountName ยอมรับ UPN หรือ sAMAccountName หรือ DOMAIN \ sAMAccountName ที่ผ่านการรับรองโดยสมบูรณ์หรือทั้งหมดข้างต้นหรือไม่ ไม่ชัดเจนจากเอกสารที่คุณเชื่อมโยงไปถึง
dunxd

เอกสารรายการรูปแบบที่สนับสนุน: DOMAIN\Account, DOMAIN.COM\Account, ,Account Account@DOMAIN.COMมันบอกว่าชื่อที่ผ่านการรับรองนั้นเร็วกว่า แต่ชื่ออื่น ๆ ก็ยังใช้ได้
Mitch

0

ฉันจะแนะนำให้ผู้ใช้เลือกรูปแบบของชื่อที่เขาต้องการใช้และกำหนดอินพุตของผู้ใช้ในด้านแอปพลิเคชัน ตัวอย่างเช่น: หากผู้ใช้พิมพ์: username@domain.com - ให้ถือว่าเป็น UPN และค้นหา UPN ในโฆษณา หากผู้ใช้ประเภท: ชื่อผู้ใช้ - พิจารณาว่าเป็น samAccountName สำหรับโดเมนเริ่มต้นที่กำหนดไว้ล่วงหน้าและแน่นอนหากผู้ใช้ประเภทโดเมน \ ชื่อผู้ใช้ - พิจารณาว่าเป็น samAccountName จากโดเมนที่ระบุ ดึง SID ของผู้ใช้และกำหนดสิทธิ์ทั้งหมดให้กับ SID เสมอเนื่องจากผู้คนแต่งงานแล้วและชื่อผู้ใช้สามารถเปลี่ยนได้

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.