Пользовательские объекты Active Directory включают ряд полей, которые можно рассматривать как идентификатор. Ниже перечислены некоторые из них с их метками в ADUC и именами атрибутов:
Я пытаюсь заставить наших разработчиков стандартизировать использование только одного из них при написании пользовательского кода, который аутентифицируется по 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 сначала проверяется путем поиска в локальном домене, а затем в глобальном каталоге. Неспособность найти 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 из имен пользователей. Идентификаторы безопасности соответствуют метафоре пользователя на протяжении всего срока действия учетной записи, поскольку переименование и перемещение внутри домена не имеют никакого эффекта, но удаление и повторное создание приводит к получению нового идентификатора безопасности.
С этой целью я бы позвонил LookupAccountName, который принимает строку, представляющую имя пользователя, и возвращает sAMAccountName, то SID и доменное имя домена, в котором был найден пользователь.
Затем пользователь может использовать любой синтаксис, поддерживаемый Windows, для входа в систему, и никакого дополнительного обучения не требуется.
Я бы рекомендовал разрешить пользователю выбирать формат имени, которое он хочет использовать, и определять ввод пользователя на стороне приложения. Например: если пользователь вводит: username@domain.com - считайте его UPN и ищите UPN в AD. Если пользователь вводит: имя пользователя - считайте его samAccountName для предопределенного домена по умолчанию и, конечно, если пользователь вводит домен \ имя пользователя - считайте его samAccountName из указанного домена. Всегда извлекайте SID пользователя и назначайте все разрешения для SID, потому что люди женятся, и имя пользователя может измениться.