Будь-яка різниця між DOMAIN \ username та username@domain.local?

Я намагаюся усунути неясну помилку аутентифікації, і мені потрібна довідкова інформація.

• Чи є різниця між тим, як обробляють Windows (і такі програми, як Outlook), DOMAIN\usernameі username@domain.local?

• Які належні умови для цих двох форматів імені користувача?

• Редагувати : Зокрема, чи є якісь відмінності в тому, як Windows засвідчує два формати імені користувача?

Припустимо, що у вас є середовище Active Directory:

Я вірю, що формат зворотної косої риски DOMAIN \ USERNAME здійснить пошук у домені DOMAIN для об’єкта користувача, у якого назва облікового запису SAM - USERNAME.

У форматі UPN ім'я користувача @ домен буде шукати ліс об'єкта користувача, ім'я якого принципу користувача - ім'я користувача @ домен.

Тепер, як правило, в обліковому записі користувача з іменем SAM-акаунта USERNAME є UPN USERNAME @ DOMAIN, тому будь-який формат повинен знаходити один і той же обліковий запис, принаймні за умови, що AD є повністю функціональним. Якщо є проблеми з реплікацією або ви не можете досягти глобального каталогу, формат зворотної косої риси може працювати в тих випадках, коли формат UPN вийде з ладу. Також можуть бути (ненормальні) умови, за яких застосовується зворотний бік - можливо, якщо для цільового домену, наприклад, не вдасться досягти контролерів домену.

Однак ви також можете явно налаштувати обліковий запис користувача таким чином, щоб мати UPN, компонент імені користувача якого відрізняється від імені акаунта SAM і чий доменний компонент відрізняється від імені домену.

На вкладці "Обліковий запис" в "Користувачі та комп'ютери" Active Directory відображається UPN під заголовком "Ім'я користувача для входу", а "Ім'я облікового запису SAM" - під заголовком "Ім'я користувача для входу (до Windows 2000)". Тож якщо у вас виникають проблеми з певними користувачами, я би переконався, що між цими двома значеннями немає розбіжностей.

Примітка. Можливо, що додаткові пошуки виконуються, якщо пошук, який я описав вище, не знайде обліковий запис користувача. Наприклад, можливо, вказане ім'я користувача перетворено в інший формат (очевидним чином), щоб побачити, чи це відповідає збігу. Повинно бути певна процедура пошуку облікових записів у довірених доменах, яких немає в лісі. Я не знаю, де / чи зафіксовано точну поведінку.

Тільки для подальшого ускладнення усунення несправностей клієнти Windows за замовчуванням кешуватимуть інформацію про успішні інтерактивні входи, щоб ви могли увійти до того самого клієнта, навіть якщо інформація про ваш обліковий запис користувача в Active Directory недоступна.

Я можу виправитись з цього приводу, але різниці немає дуже.

Домен \ Користувач - це "старий" формат входу, який називається іменем входу на нижньому рівні . Відомі також імена SAMAccountName та ім'я для входу до Windows 2000 .

User@Domain.com - це UPN - головне ім'я користувача . Це "кращий", новіший формат входу. Це ім'я для входу в інтернет-стилі, яке повинно зіставляти ім’я електронної пошти користувача. ( Посилання на MSDN )

Причини для входу в систему за допомогою UPN, я думаю, є здебільшого косметичними - вони гіпотетично дають вашим користувачам у вашій компанії єдине ім’я, за допомогою якого можна увійти на свої робочі станції, що також може виступати як їх корпоративна електронна адреса.

редагувати: Більш детальна розробка - ще одна перевага UPN - те, що ви можете налаштувати більше ніж один дійсний UPN для своїх користувачів. Знову ж таки, багато в чому косметично. Але важливо те, що не всі програми сумісні з UPN, і це може бути те, що ви відчуваєте.

редагувати № 2: Мені подобається відповідь Гаррі Джонстона нижче про два трохи різних формати пошуку. Це має сенс, а головне, що насправді може пояснити вашу проблему. :)

Формат нарізаної коси ( DOMAIN\username) фактично є NetBIOSеквівалентом імені DNS домену ( domain.mycompany.local). Ім'я обмежується 15 символів і не може містити точки, підкреслення і т.д.
NetBIOS

Ця сторінка пояснює більш докладно:
* Jeff Schertz, 2012-08-20, Розуміння форматів іменування Active Directory (Архів тут .)

Як згадував @ harry-johnston вище, його справді лише старий сумісний формат NT4 та Windows 2000, але, схоже, він тримався як улюблений формат (його менше набирати!). Зрештою, підтримка застарілого формату може надійти від Windows.

Це, мабуть, гарна ідея, щоб користувачі звикли користуватися форматом UPN, оскільки це також уникає проблем, коли у них виникають проблеми з входом на ПК із їхнім іменем користувача, і не розуміє, що поле для входу в Windows за замовчуванням відповідає місцевим стандартам Домен ПК (наприклад, pc01\fred) або коли вони підключаються до різних хостів віддаленого робочого столу, і потрібно пам’ятати про включення домену, а також їх ім’я користувача, оскільки клієнт віддаленого робочого столу може кешувати ще одне раніше використовуване доменне ім’я. Дотримуючись формату UPN кожен раз, лише зрештою виклики меншої підтримки.

Існує різниця між цими двома, лише 99% користувачів з цим не матимуть проблем. Я спробую пояснити різницю, і коли може виникнути така проблема.

Якщо ви використовуєте домен \ ім'я користувача при спробі отримати доступ до файлового файлу, DNS спочатку вирішить домен, а потім перевірить ім'я користувача. Якщо ви використовуєте ім'я користувача @ домен, він безпосередньо перевірить, чи є користувач у списку ACL (список контролю доступу) та чи має він доступ. Тож, що важливо, ти можеш подумати ... ну, малюй це:

1 контролер домену з ім'ям DC01 і всі клієнти отримують dns і знаходяться в цьому домені. Ви хочете переміститись, і хтось додав інший сервер з таким самим іменем. Останній сервер також стане постійним струмом, тому локальний SAM більше не буде використовуватися, а також має спільний доступ до файлів.

Коли користувачі підключаться до сервера, їм буде запропоновано отримати облікові дані. Якщо ви використовуєте домен \ ім'я користувача, він спочатку перевірить поточний домен замість нового домену, і ми використали облікові записи з нового домену на спільній доступності файлів. Отже, як тільки він знайде поточний dc і перевірить ім'я користувача, його не можна знайти. (навіть якщо ім'я користувача та пароль знайдені і точно такі ж, він не працюватиме, оскільки він не буде використовувати ім'я користувача, щоб перевірити, чи він дозволений в ACL, але він буде використовувати SID. Sid буде створений у час створення користувача в AD, і ви змінили 1 на трильйон, що це те саме, чудово так :-P).