Czy jest jakaś różnica między DOMAIN \ nazwa_użytkownika a nazwa_użytkownika@domena.local?

Próbuję rozwiązać problem niejasnego błędu uwierzytelnienia i potrzebuję trochę informacji w tle.

• Czy jest jakaś różnica między sposobem przetwarzania systemu Windows (i programów takich jak Outlook) DOMAIN\usernamea username@domain.local?

• Jakie są odpowiednie warunki dla tych dwóch formatów nazw użytkowników?

• Edycja : W szczególności, czy istnieją jakieś różnice w sposobie uwierzytelniania przez system Windows dwóch formatów nazw użytkowników?

Zakładając, że masz środowisko Active Directory:

Wierzę, że format ukośnika odwrotnego DOMAIN \ USERNAME przeszuka domenę DOMAIN w poszukiwaniu obiektu użytkownika, którego nazwa konta SAM to USERNAME.

Nazwa użytkownika @ domena w formacie UPN przeszuka w lesie obiekt użytkownika, którego nazwa użytkownika to nazwa użytkownika @ domena.

Teraz zwykle konto użytkownika o nazwie SAM konta USERNAME ma UPN USERNAME @ DOMAIN, więc każdy format powinien zlokalizować to samo konto, przynajmniej pod warunkiem, że AD jest w pełni funkcjonalny. Jeśli występują problemy z replikacją lub nie można uzyskać dostępu do katalogu globalnego, format odwrotnego ukośnika może działać w przypadkach, w których nie powiedzie się format UPN. Mogą również występować (nienormalne) warunki, w których obowiązuje sytuacja odwrotna - na przykład, jeśli nie można uzyskać dostępu do kontrolerów domeny dla domeny docelowej, na przykład.

Jednak: możesz również jawnie skonfigurować konto użytkownika, aby miał nazwę UPN, której nazwa użytkownika różni się od nazwy konta SAM i której składnik domeny różni się od nazwy domeny.

Karta Konto w przystawce Użytkownicy i komputery usługi Active Directory pokazuje nazwę UPN pod nagłówkiem „Nazwa logowania użytkownika” i nazwę konta SAM pod nagłówkiem „Nazwa logowania użytkownika (wcześniej niż Windows 2000)”. Więc jeśli masz problemy z konkretnymi użytkownikami, sprawdziłbym, czy nie ma żadnych rozbieżności między tymi dwiema wartościami.

Uwaga: możliwe jest, że zostaną przeprowadzone dodatkowe wyszukiwania, jeśli opisane powyżej wyszukiwanie nie znajdzie konta użytkownika. Na przykład, być może określona nazwa użytkownika jest konwertowana na inny format (w oczywisty sposób), aby sprawdzić, czy daje to dopasowanie. Musi również istnieć pewna procedura znajdowania kont w zaufanych domenach, które nie znajdują się w lesie. Nie wiem gdzie / czy dokładne zachowanie jest udokumentowane.

Aby jeszcze bardziej skomplikować rozwiązywanie problemów, klienci Windows domyślnie buforują informacje o udanych logowaniach interaktywnych, abyś mógł zalogować się do tego samego klienta, nawet jeśli informacje o koncie użytkownika w Active Directory są niedostępne.

Mogę to poprawić, ale nie ma tak naprawdę dużej różnicy.

Domena \ Użytkownik to „stary” format logowania, zwany nazwą logowania niższego poziomu . Znany również pod nazwami SAMAccountName i nazwą logowania starszą niż Windows 2000 .

User@Domain.com to UPN - główna nazwa użytkownika . Jest to „preferowany”, nowszy format logowania. Jest to nazwa logowania w stylu internetowym, która powinna być odwzorowana na nazwę e-mail użytkownika. ( Patrz w MSDN )

Uważam, że powody logowania za pomocą UPN są w większości kosmetyczne - hipotetycznie nadają użytkownikom w Twojej firmie jedną nazwę, za pomocą której można zalogować się na stacjach roboczych, która może również pełnić rolę firmowego adresu e-mail.

edycja: Bardziej szczegółowe opracowanie - kolejną zaletą UPN jest to, że możesz skonfigurować więcej niż jedną prawidłową UPN dla swoich użytkowników do logowania. Ponownie, głównie kosmetyczne. Ale ważne jest to, że nie wszystkie aplikacje są kompatybilne z UPN i może to być to, czego doświadczasz.

edycja # 2: Podoba mi się odpowiedź Harry'ego Johnstona na temat dwóch nieco odmiennych formatów wyszukiwania. Ma to sens, a co najważniejsze, może faktycznie wyjaśnić twój problem. :)

Format ukośny ( DOMAIN\username) jest w rzeczywistości NetBIOSodpowiednikiem nazwy DNS domeny ( domain.mycompany.local). Nazwa jest ograniczona do 15 znaków i nie może zawierać kropki, podkreślenia itp
NetBIOS

Ta strona wyjaśnia bardziej szczegółowo:
* Jeff Schertz, 2012-08-20, Zrozumienie formatów nazewnictwa Active Directory (zarchiwizowane tutaj )

Jak wspomniano powyżej przez @ harry-johnston, to tak naprawdę tylko stary format zgodny z NT4 i Windows 2000, ale wydaje się, że utknął jako ulubiony format (mniej pisać!). W końcu obsługa starszego formatu może pochodzić z systemu Windows.

Prawdopodobnie dobrym pomysłem jest przyzwyczajenie użytkowników do korzystania z formatu UPN, ponieważ pozwala to również uniknąć problemów z logowaniem się do komputera za pomocą nazwy użytkownika i nie zdaje sobie sprawy, że okno logowania systemu Windows ma domyślną wartość lokalną Domena PC (np. pc01\fred) Lub gdy łączą się z różnymi hostami pulpitu zdalnego i muszą pamiętać o dołączeniu domeny oraz nazwy użytkownika, ponieważ klient pulpitu zdalnego może buforować inną poprzednio używaną nazwę domeny. Trzymanie się formatu UPN za każdym razem po prostu zmniejsza liczbę zgłoszeń do pomocy technicznej.

Istnieje wyraźna różnica między tymi dwoma, tylko 99% użytkowników nie będzie miało z tym problemu. Spróbuję wyjaśnić różnicę i kiedy może wystąpić taki problem.

Jeśli użyjesz domeny \ nazwa użytkownika podczas próby uzyskania dostępu do udziału plików, DNS najpierw rozpozna domenę, a następnie sprawdzi nazwę użytkownika. Jeśli użyjesz nazwy użytkownika @ domena, sprawdzi ona bezpośrednio, czy użytkownik znajduje się na liście ACL (lista kontroli dostępu) i ma dostęp. Cóż więc może mieć znaczenie ... wyobraź sobie:

1 kontroler domeny o nazwie DC01 i wszyscy klienci otrzymują dns ​​i są w tej domenie. Chcesz przeprowadzić migrację, a ktoś dodał inny serwer o tej samej nazwie. Ten ostatni serwer również stanie się kontrolerem domeny, więc lokalny SAM nie będzie już używany i będzie miał udział plików.

Gdy użytkownicy połączą się z serwerem, zostaną poproszeni o podanie poświadczeń. Jeśli użyjesz domeny \ nazwa użytkownika, najpierw sprawdzi bieżącą domenę zamiast nowej domeny i użyliśmy kont z nowej domeny w udziale plików. Po znalezieniu bieżącego dc i sprawdzeniu nazwy użytkownika nie można go znaleźć. (nawet jeśli nazwa użytkownika i hasło zostaną znalezione i są dokładnie takie same, nie będzie działać, ponieważ nie użyje nazwy użytkownika do sprawdzenia, czy jest dozwolona na liście ACL, ale użyje identyfikatora SID. Identyfikator SID zostanie utworzony w pliku czas tworzenia użytkownika w AD i masz zmianę 1 na bilion, że to jest to samo, świetnie huh :-P).