Я пытаюсь устранить скрытую ошибку аутентификации, и мне нужна дополнительная информация.
Есть ли разница между тем, как 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 - имя участника-пользователя. Это «предпочтительный», более новый формат входа в систему. Это имя входа в Интернет-стиле, которое должно соответствовать имени пользователя электронной почты. (Ref. в MSDN)
Причины для входа в систему с UPN, я думаю, в основном косметические - они гипотетически дают вашим пользователям в вашей компании единое имя для входа на свои рабочие станции, которое также может выступать в качестве их корпоративного адреса электронной почты.
редактировать: Более подробная информация - еще одно преимущество имен участников-пользователей состоит в том, что вы можете настроить более одного действительного имени-участника для входа в систему. Опять же, в основном косметический. Но важно то, что не все приложения совместимы с UPN, и это может быть то, что вы испытываете.
редактировать # 2: Мне нравится ответ Гарри Джонстона ниже о двух немного разных форматах поиска. Это имеет смысл и, что наиболее важно, может объяснить вашу проблему. :)
Формат с косой чертой (DOMAIN\username) на самом деле NetBIOS эквивалент DNS-имени домена (domain.mycompany.local).
В NetBIOS имя ограничено 15 символами и не может содержать точки, подчеркивания и т. д.
Эта страница объясняет более подробно:
* Джефф Шертц, 20 августа 2012 г. Общие сведения о форматах именования Active Directory (Архивировано Вот.)
Как упоминалось выше @ harry-johnston, на самом деле это просто старый NT4 и Windows 2000-совместимый формат, но, похоже, он остался любимым форматом (его меньше печатать!). В конце концов, поддержка устаревшего формата может исчезнуть из Windows.
Вероятно, это хорошая идея, чтобы пользователи привыкли использовать формат UPN, поскольку он также позволяет избежать проблем, когда у них возникают проблемы с входом на ПК со своим именем пользователя и они не понимают, что поле входа в Windows по умолчанию установлено на локальное Домен ПК (например, pc01\fred) или когда они подключаются к разным хостам удаленного рабочего стола и должны не забывать указывать домен, а также свое имя пользователя, потому что клиент удаленного рабочего стола может кэшировать другое ранее использованное доменное имя. Придерживаясь формата UPN каждый раз, в конце концов, меньше обращений в службу поддержки.
Несомненно, разница между этими двумя вещами есть, только 99% пользователей не будут иметь с ней проблем. Я постараюсь объяснить разницу и когда может возникнуть такая проблема.
Если вы используете домен \ имя пользователя при попытке доступа к общей папке, DNS сначала разрешит домен, а затем проверит имя пользователя. Если вы используете имя пользователя @ домен, он будет напрямую проверять, находится ли пользователь в ACL (списке управления доступом) и имеет ли доступ. Итак, какое это имеет значение, вы можете подумать ... ну, представьте себе это:
1 контроллер домена с именем DC01 и все клиенты получают днс и находятся в этом домене. Вы хотите выполнить миграцию, и кто-то добавил еще один сервер с тем же именем. Последний сервер также станет контроллером домена, поэтому локальный SAM больше не будет использоваться, а также будет иметь общий файловый ресурс.
Когда пользователи будут подключаться к серверу, им будет предложено ввести учетные данные. Если вы используете домен \ имя пользователя, он сначала проверит текущий домен вместо использования нового домена, и мы использовали учетные записи из нового домена в общей папке. Итак, как только он нашел текущий DC и проверил имя пользователя, он не может быть найден. (даже если имя пользователя и пароль найдены и точно такие же, это не сработает, поскольку оно не будет использовать имя пользователя для проверки, разрешено ли оно в ACL, но будет использовать SID. Sid будет создан в время создания пользователя в AD, и у вас есть изменение на 1 на триллион, что это то же самое, отлично да :-P).