Z którego pola należy korzystać podczas uwierzytelniania w usłudze Active Directory?

Obiekty użytkowników Active Directory zawierają szereg pól, które można uznać za identyfikator. Poniżej wymieniono niektóre z nich wraz z etykietą w programie ADUC i nazwą ich atrybutu:

• Pełna nazwa - cn
• ? - Nazwa
• Logowanie użytkownika sAMAccountName - sAMAccountName
• Logowanie do UPN użytkownika: userPrincipalName
• ? - wytworne imię

Staram się, aby nasi programiści znormalizowali używanie tylko jednego z nich podczas pisania niestandardowego kodu, który uwierzytelnia się w stosunku do AD - problem nie polega na tym, który z nich jest „właściwy”, czy też różne są właściwe w różnych okoliczności. Nie jestem nawet pewien, czy należy użyć któregokolwiek z powyższych pól!

Czy ktoś inny wybrał taki, który będzie używany konsekwentnie, i co wpłynęło na ciebie w tej decyzji? Jakaś dokumentacja wyjaśniająca problem?

CN (nazwa zwyczajowa) nie nadaje się do logowania, ponieważ sama CN nie jednoznacznie identyfikuje użytkownika. Mógłbym mieć

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

i mógłbym też mieć

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

CN użytkownika jest również RDN (względna nazwa wyróżniająca). Mają tę samą CN, ale różne nazwy wyróżniające. Możesz zauważyć, że napotkasz problemy, jeśli masz w organizacji dwie osoby o imieniu Ryan Ries, i będziesz musiał utworzyć SamAccountName dla drugiego, coś w stylu rries2.

Nazwa wyróżniająca (nazwa wyróżniająca) nie jest dobra do zalogowania się, ponieważ kto chce zalogować się do systemu o nazwie użytkownika takiej jak CN=ryan,OU=Texas,DC=brazzers,DC=com? Podczas gdy używanie nazwy wyróżniającej jednoznacznie i definitywnie identyfikuje użytkownika, denerwujące jest pisanie. Jest to ten sam rodzaj koncepcji między ścieżkami względnymi i ścieżkami bezwzględnymi w systemie plików. Oznacza to również, że wiesz dokładnie, gdzie w strukturze katalogów znajduje się obiekt, bez konieczności jego wyszukiwania. Które często nie.

Nazywa się to rozpoznawaniem niejednoznacznych nazw (ANR) - przeszukiwanie katalogu użytkownika, gdy nie masz jego nazwy wyróżniającej.

UPN (główna nazwa użytkownika) jest całkiem dobra, ponieważ wyglądają jak adresy e-mail, mogą być takie same jak firmowy adres e-mail użytkownika, są łatwe do zapamiętania i wolą się zalogować, ponieważ nazwa zostanie wyszukana najpierw w domenie lokalnej, a potem w lesie.

Microsoft mówi: Celem UPN jest konsolidacja przestrzeni nazw e-mail i logowania, aby użytkownik musiał zapamiętać tylko jedną nazwę. Nazwa UPN jest preferowaną nazwą logowania dla użytkowników systemu Windows. Użytkownicy powinni używać swoich nazw UPN do logowania się do domeny. Podczas logowania UPN jest sprawdzany najpierw przez przeszukanie domeny lokalnej, a następnie katalogu globalnego. Niepowodzenie znalezienia nazwy UPN w domenie lokalnej lub GC powoduje odrzucenie nazwy UPN. Nazwę UPN można przypisać, ale nie jest ona wymagana , gdy tworzone jest konto użytkownika.

Pamiętaj, że „nie jest wymagany” na końcu przy projektowaniu aplikacji.

SamAccountName jest również dobra, ponieważ SamAccountName musi być unikalny dla wszystkich w domenie (ale nie w lesie). Ponadto SamAccountName są krótkie. Większość osób loguje się za pomocą SamAccountNames, nawet jeśli nie identyfikują Cię jednoznacznie w lesie AD, dlatego musisz określić nazwę domeny, aby pasować do nazwy SamAccountName, aby system wiedział, w której domenie próbujesz się zalogować .

Oto świetna dokumentacja na ten temat do dalszego czytania:

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

Jeśli mówisz sAMAccountNameo nazwie użytkownika jako o czymś, co ktoś mógłby wpisać, aby się zalogować, polecam albo , który byłby unikalny w połączeniu z nazwą domeny, albo taki userPrincipalName, który byłby unikalny w lesie.

O ile nazwa użytkownika jest unikalnym identyfikatorem, system Windows używa identyfikatora SID dla wszystkich pozycji kontroli dostępu i zapewnia pełny zestaw metod tłumaczenia identyfikatorów SID z nazw użytkowników. Identyfikatory SID są zgodne z metaforą użytkownika przez cały okres istnienia konta, ponieważ zmiany nazw i ruchy w domenie nie mają żadnego wpływu, ale usunięcie i ponowne utworzenie skutkuje nowym identyfikatorem SID.

W tym celu, nazwałbym LookupAccountName, który pobiera ciąg reprezentujący nazwę użytkownika i zwraca sAMAccountName, ten SIDi nazwę domeny domeny użytkownik został znaleziony w.

Użytkownik może następnie użyć dowolnej składni obsługiwanej przez system Windows do zalogowania się i nie jest wymagane dodatkowe szkolenie.

Zaleciłbym, aby użytkownik mógł wybrać format nazwy, której chce używać, i określić dane wejściowe użytkownika po stronie aplikacji. na przykład: jeśli użytkownik wpisze: nazwa_użytkownika@domena.com - potraktuj go jako UPN i wyszukaj UPN w AD. Jeśli użytkownik wpisze: nazwa użytkownika - uważaj go za samAccountName dla wstępnie zdefiniowanej domeny domyślnej i oczywiście jeśli użytkownik wpisze domenę \ nazwa użytkownika - uważaj to za samAccountName z określonej domeny. Zawsze pobieraj SID użytkownika i przypisuj wszystkie uprawnienia do SID, ponieważ ludzie biorą ślub i nazwa użytkownika może się zmienić.