My<cod/>.net
Использование кэшированных учетных данных для подключения к SQL 2005 через границу домена
С момента переезда в Vista некоторое время назад на моей машине разработки подключение к серверам SQL в нашем домене DMZ active directory из клиентских инструментов, таких как SSMS, не работает так, как раньше. В XP, пока я аутентифицировался каким-то образом на сервере (например, направляя Explorer в \server.dmzdomain\c$ и вводя допустимые cred в приглашение входа), SSMS будет использовать эти кэшированные учетные данные для подключения.
Однако с момента перехода на Vista, при попытке подключения SSMS к серверу в домене DMZ я получаю сообщение Login failed for user ". Пользователь не связан с доверенным соединением сервера SQL. Если я изменю параметры подключения, чтобы использовать именованные каналы вместо стандартного TCP/IP,, мои кэшированные учетные данные будут отправлены, и все будет работать нормально. В этом случае Брандмауэр Windows выключен или включен, а соединения с серверами в нашем внутреннем домене (тот же домен, в котором находится мой dev PC) отлично работают над TCP/IP или именованными каналами.
Я не возражаю слишком много использовать именованные каналы для этих соединений в качестве обходного пути, но похоже, что TCP/IP-рекомендуемый метод подключения, и мне не нравится не понимать, почему он не работает, как я ожидал. Есть идеи?
"Ошибка входа для пользователя '', Пользователь не связан с доверенным соединением сервера SQL".
В этом случае клиент может сделать tcp connetion, плюс, запущенный под локальным администратором или учетной записью машины без администратора, независимо от того, зарегистрирован SPN или нет, учетные данные клиента явно не распознаются сервером SQL.
Обходной путь здесь заключается в следующем:
Создайте ту же учетную запись, что и на клиентском компьютере, с тем же паролем на целевом сервере SQL, и предоставьте ей соответствующее разрешение.
Давайте объясним подробнее:
Когда вы создаете одну и ту же учетную запись NT (назовем ее usr1) на обоих рабочие станции, вы по существу подключаетесь и олицетворяете локальную учетную запись соединительная станция. I.e при подключении от станции 1 к станции 2, вы проходите проверку подлинности через учетную запись station2. Итак, если вы установите учетная запись запуска для сервера SQL (предположим, что он работает на station2) должна быть USR1 станции 2, Когда вы соединяетесь с SQL от станции 1 с usr1 станции 1 логин, SQL будет аутентифицировать вас как usr1 станции 2.
Теперь, в пределах SQL, вы определенно можете получить доступ к ресурсам station1. Хотя, как это сделать большая часть доступа будет зависеть от разрешения USR1 станции 1.
До сих пор SQL имеет дело только с пользователем, который является частью роли sysadmin внутри SQL сервер. Чтобы разрешить другим пользователям (не sysamdin) доступ к сетевым ресурсам, вам придется установить учетную запись прокси-сервера. Взгляните на статью для дополнительная информация. взято из http://blogs.msdn.com/sql_protocols/archive/2006/12/02/understanding-kerberos-and-ntlm-authentication-in-sql-server-connections.aspx
Я бы предположил, что это связано с тем, что Vista запускает большинство приложений в изоляции от любого другого.
Я бы рекомендовал вам либо установить имя пользователя и пароль DMZ в соответствии с именем пользователя и паролем внутреннего домена, либо использовать именованные каналы для подключения.