Есть ли разница между 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 не удастся. Могут также существовать (ненормальные) условия, при которых применяется обратное, например, если для целевого домена невозможно достичь контроллеров домена, например.

Однако: вы также можете явно настроить учетную запись пользователя, чтобы иметь имя участника-пользователя, компонент имени пользователя которого отличается от имени учетной записи SAM, а компонент домена отличается от имени домена.

На вкладке «Учетная запись» в «Active Directory - пользователи и компьютеры» отображается имя участника-пользователя под заголовком «Имя входа пользователя» и имя учетной записи SAM под заголовком «Имя входа пользователя (до Windows 2000)». Поэтому, если у вас возникли проблемы с конкретными пользователями, я бы проверил, нет ли расхождений между этими двумя значениями.

Примечание: возможно, что дополнительные поиски будут выполнены, если поиск, который я описал выше, не найдет учетную запись пользователя. Например, возможно, указанное имя пользователя преобразуется в другой формат (очевидным образом), чтобы проверить, соответствует ли это. Также должна быть какая-то процедура поиска учетных записей в доверенных доменах, которые не находятся в лесу. Я не знаю, где / задокументировано ли точное поведение.

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

Я могу исправить это, но в этом нет особой разницы.

Домен \ Пользователь - это «старый» формат входа, называемый именем входа нижнего уровня . Также известен под именами SAMAccountName и именем входа до Windows 2000 .

User@Domain.com - это имя участника-пользователя . Это «предпочтительный», более новый формат входа в систему. Это имя для входа в Интернет-стиле, которое должно соответствовать имени электронной почты пользователя. ( Ссылка на MSDN )

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

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

edit # 2: Мне нравится ответ Гарри Джонстона ниже о двух немного отличающихся форматах поиска. Это имеет смысл, и самое главное это может объяснить вашу проблему. :)

Формат с косой чертой ( DOMAIN\username) фактически NetBIOSэквивалентен DNS-имени домена ( domain.mycompany.local). Имя ограничивается 15 символов и не может содержать точки, подчеркивание и т.д.
NetBIOS

Эта страница объясняет более подробно:
* Джефф Шерц, 2012-08-20, Понимание форматов имен Active Directory (Архивировано здесь .)

Как упомянуто @ harry-johnston выше, это действительно просто старый формат, совместимый с NT4 и Windows 2000, но он, похоже, застрял как любимый формат (его меньше печатать!). В конце концов, поддержка устаревшего формата может пойти из Windows.

Вероятно, это хорошая идея, чтобы пользователи привыкли использовать формат UPN, поскольку это также позволяет избежать проблем, при которых у них возникают проблемы при входе в систему с использованием своего имени пользователя, и не осознает, что окно входа Windows по умолчанию настроено на локальное. Домен ПК (например, pc01\fred) или когда они подключаются к различным хостам удаленных рабочих столов и должны помнить, чтобы включить домен, а также их имя пользователя, поскольку клиент удаленного рабочего стола может кэшировать другое ранее использованное имя домена. Придерживаясь формата UPN каждый раз, вы в конечном итоге получаете меньше звонков в службу поддержки.

Существует определенная разница между этими двумя, только 99% пользователей не будут иметь проблем с этим. Я постараюсь объяснить разницу и когда такая проблема может возникнуть.

Если вы используете домен \ имя пользователя при попытке доступа к файлообменнику, DNS сначала разрешит домен, а затем проверит имя пользователя. Если вы используете имя пользователя @ домен, то он будет непосредственно проверять, находится ли пользователь в ACL (список контроля доступа) и имеет ли он доступ. Так что это имеет значение, вы можете подумать ... ну, представьте себе это:

1 контроллер домена с именем DC01 и все клиенты получают днс и находятся в этом домене. Вы хотите выполнить миграцию, и кто-то добавил другой сервер с тем же именем. Последний сервер также станет DC, поэтому локальный SAM больше не будет использоваться, а также имеет общий файловый ресурс.

Когда пользователи подключатся к серверу, им будет предложено ввести учетные данные. Если вы используете домен \ имя пользователя, он сначала проверит текущий домен вместо использования нового домена, и мы использовали учетные записи из нового домена в общей папке. Поэтому, как только он нашел текущий dc и проверил имя пользователя, он не может быть найден. (даже если имя пользователя и пароль найдены и совпадают, они не будут работать, так как не будут использовать имя пользователя для проверки, разрешено ли оно в ACL, но будут использовать SID. sid будет создан на время создания пользователя в AD, и у вас есть изменение 1 в триллионе, что это то же самое, здорово да :-P).