Яке поле використовувати під час автентифікації на Active Directory?

12

Об'єкти користувача Active Directory містять ряд полів, які можна вважати ідентифікатором. Далі перелічено деякі з них із їх міткою в ADUC та назвою атрибутів:

Повна назва - cn
? - ім'я
Користувач sAMAccountName вхід - sAMAccountName
Користувач UPN Logon: userPrincipalName
? - відзначився Ім'я

Я намагаюся змусити наших розробників стандартизувати використання лише одного з них під час написання користувальницького коду, який підтверджує автентифікацію проти AD - проблема в тому, що я не впевнений, який є "правильний", або якщо різні - правильний у різних обставини. Я навіть не впевнений, що будь-яке з перерахованих вище полів слід використовувати!

Хто-небудь ще вибрав одну, яку слід використовувати постійно, і що вплинуло на вас у цьому рішенні? Будь-яка документація, яка роз'яснює проблему?

active-directory ldap authentication

— dunxd
джерело

Я стикався з декількома програмами (як внутрішньо розробленими, так і тим, що робили інші люди), які аутентифікуються через LDAP за допомогою поля cn. Це поле тепер автоматично оновлюється в Центрі адміністрування AD (воно позначене повним ім'ям), якщо ви змінюєте поля імені чи прізвища, тобто не можна вважати, що поле 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. Ви можете помітити, що у вас виникли проблеми, якщо у вашій організації двоє людей на ім'я Ryan 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 має бути унікальним для всіх у домені (але не для лісу.) Крім того, SamAccountName є короткими. Більшість людей входять в систему за допомогою SamAccountNames, навіть якщо вони не однозначно ідентифікують вас у лісі AD, тому вам потрібно вказати доменне ім’я, яке буде разом із вашим 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. Це говорить, що повністю кваліфіковані імена швидше, але інші все ще доступні.

— Мітч

0

Я рекомендую дозволити користувачеві вибирати формат імені, яке він хоче використовувати, та визначати вхід користувача на стороні програми. наприклад: Якщо користувач вводить: username@domain.com - розглядайте це як UPN та шукайте UPN в AD. Якщо користувач вводить: ім'я користувача - розгляньте це як samAccountName для заздалегідь визначеного домену за замовчуванням, і, звичайно, якщо користувач вводить домен \ ім'я користувача - вважайте його як samAccountName з вказаного домену. Завжди завантажуйте SID користувача та призначте всі дозволи для SID, оскільки люди одружуються, а ім’я користувача може змінюватися.

— Стен
джерело