Какое поле использовать при аутентификации в Active Directory?

Пользовательские объекты Active Directory включают в себя ряд полей, которые можно считать идентификатором. Ниже перечислены некоторые из них с их меткой в ​​ADUC и именем их атрибута:

• Полное имя - сп
• ? - имя
• Вход пользователя sAMAccountName - sAMAccountName
• Пользователь UPN Logon: userPrincipalName
• ? - Отличительное имя

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

Кто-нибудь еще выбрал один, чтобы использовать постоянно, и что повлияло на вас в этом решении? Любая документация, которая проясняет проблему?

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. Вы можете заметить, что у вас возникли проблемы, если в вашей организации есть два человека по имени Райан Райс, и вам нужно будет сделать SamAccountName для второго примерно таким rries2.

DN (отличительное имя) не подходит для входа в систему, потому что кто хочет войти в систему с именем пользователя вроде CN=ryan,OU=Texas,DC=brazzers,DC=com? Хотя использование DN однозначно и однозначно идентифицирует пользователя, раздражает необходимость вводить его. Это такая же концепция между относительными и абсолютными путями в файловой системе. Это также означает, что вы точно знаете, где в структуре каталогов находится объект, без необходимости его поиска. Что вы часто не делаете.

Это называется разрешением неоднозначных имен (ANR) - поиск пользователя в каталоге, когда у вас нет его отличительного имени.

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

Microsoft говорит: Смысл UPN состоит в том, чтобы объединить пространства имен электронной почты и входа в систему, чтобы пользователю было необходимо запомнить только одно имя. UPN является предпочтительным именем входа для пользователей Windows. Пользователи должны использовать свои UPN для входа в домен. Во время входа в систему имя участника-пользователя проверяется сначала путем поиска в локальном домене, а затем в глобальном каталоге. Невозможность найти UPN в локальном домене или GC приводит к отклонению UPN. UPN может быть назначен, но не обязателен , когда создается учетная запись пользователя.

Имейте в виду, что «не требуется» в конце при разработке ваших приложений.

SamAccountName также хорош, потому что SamAccountName должен быть уникальным для всех в домене (но не в лесу). Кроме того, SamAccountNames короткие. Большинство людей входят в систему с помощью 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

Если вы ссылаетесь на имя пользователя как на то, что кто-то вводит для входа в систему, я бы порекомендовал либо одно sAMAccountName, которое будет уникальным в сочетании с именем домена, либо то userPrincipalName, которое будет уникальным в лесу.

Что касается имени пользователя в качестве уникального идентификатора, Windows использует SID для всех записей управления доступом и предоставляет полный набор методов для преобразования в SID из имен пользователей. SID совпадают с метафорой пользователя в течение всего срока действия учетной записи, поскольку переименование и перемещение в домене не имеют никакого эффекта, но удаление и повторное создание приводит к созданию нового SID.

С этой целью, я бы назвал LookupAccountName, которая принимает строку , представляющую имя пользователя и возвращает sAMAccountName, в SIDи доменное имя домена пользователь был найден в.

Затем пользователь может использовать любой синтаксис, поддерживаемый окнами, для входа в систему, и дополнительное обучение не требуется.

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