Моя компания в настоящее время занимается заменой любых псевдонимов или IP-ссылок на полные доменные имена в нашем коде. Все, что имеет IP или имя компьютера, будет заменено чем-то вроде fileserver.example.com, databaseserver.example.com и т. Д.
Этот процесс работает для подключений к базе данных, ссылок на веб-службы, ссылок API. Проблемы возникают с доступом к общим файлам через UNC-пути. Доступ к файлам через UNC-путь, подобный этому \\fileserver.example.com\path\to\files не работает В НЕКОТОРЫХ СЛУЧАЯХ.
В В НЕКОТОРЫХ СЛУЧАЯХ здесь важная часть.
Путь UNC может быть успешно доступен в следующих случаях
\\COMPUTER_NAME\path\to\files).Путь UNC НЕЛЬЗЯ получить доступ в следующем случае
\\fileserver.example.com\path\to\files).Я получаю следующее сообщение об ошибке.
Logon failure: unknown user name or bad password.
Это сообщение об ошибке заставляет вас думать, что это проблема с доступом, но я не думаю, что это так, потому что пользователь службы, запускающий процесс, может получить доступ к файлу, используя COMPUTER_NAME в пути, который указывает на то же место, что и полное доменное имя.
У кого-нибудь есть опыт работы с этой проблемой?
Предполагается ли вообще использование полных доменных имен для доступа к общим файловым ресурсам через UNC-пути?
Прочитав сообщение Клейтона и просмотрев журналы безопасности в средстве просмотра событий, мы поняли, что это проблема, только когда машина пыталась получить доступ к файлу с UNC-путем. указал на себя.
Это привело меня к проверка обратной связи описано в следующей статье на сайте microsoft.com. https://blogs.technet.microsoft.com/sharepoint_foxhole/2010/06/21/disableloopbackcheck-lets-do-it-the-right-way/
Мы использовали Метод 1. Укажите имена хостов (предпочтительный метод, если требуется проверка подлинности NTLM)
Отключено DisableStrictNameChecking в реестре
Поступил fileserver.example.com в BackConnectionHostNames в реестре
Когда вы используете короткое имя, оно возвращается к использованию аутентификации NTLM. Но с полным доменным именем он должен использовать проверку подлинности Kerberos. Проблема в том, чтобы Kerberos работал, вам нужно DNS-имя и SPN (имя участника-службы), которые вам не хватает. У вас есть 2 варианта:
Вариант 1. Сохраните псевдоним и отключите функцию «Строгая проверка имени» в окнах, создав следующий регистрационный ключ на сервере. Также нужно перезагрузиться.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
DWORD name: DisableStrictNameChecking
DWORD value: 1
Вариант 2: удалите псевдоним и создайте «альтернативное» имя через Windows, которое также создаст имя участника службы Kerberos, чтобы альтернативное имя было действительным для проверки подлинности Kerberos.
NETDOM NEWNAME /ADD
Замените NEWNAME полным доменным именем псевдонима, который вы создали ранее. Это должно выполняться с фактического сервера, который будет обслуживать псевдоним.
Начали исследовать вопрос, так как это показалось интересным. Я начал просматривать, используя FDQN домена в различных средах (я работаю на MSP, поэтому имею доступ к довольно большому количеству доменов).
Коротко говоря, я испытал то, чего никогда раньше не видел / не замечал. При просмотре через проводник Windows с использованием FDQN домена будет отображаться корневая папка файлового ресурса (-ов), но ничего больше. При просмотре с использованием IP-адреса или имени компьютера будут отображаться те же общие ресурсы и папки / файлы внутри общих ресурсов, как и должно.
Еще немного в Google нашел это
Что должно произойти, когда я перейду к своему доменному имени Windows через UNC?.
Он частично отвечает на ваш вопрос и причину, но не полностью соответствует вашей проблеме.
Личный Я думаю, что реализация общих файловых ресурсов через DFS позволит вам использовать пространство имен (концепция, аналогичная FDQN), и когда дело доходит до вывода на пенсию \ реализации новых файловых серверов, это означает, что вам не нужно будет реорганизовать код, чтобы указать на новый сервер. имя файлового сервера.
Это также должно обойти проблему, с которой вы столкнулись.
Надеюсь это поможет.
Обзор DFS https://en.wikipedia.org/wiki/Distributed_File_System_(Microsoft)