Использование кэшированных учетных данных для подключения к SQL 2005 через границу домена

Question

С тех пор, как некоторое время назад на моей машине разработки я перешел на Vista, подключение к SQL-серверам в нашем домене активных каталогов DMZ с помощью клиентских инструментов, таких как SSMS, не работало так, как раньше. В XP, пока я каким-либо образом проходил проверку подлинности на сервере (например, направлял Explorer в \ server.dmzdomain \ c $ и вводил действительные права доступа в приглашение на вход в систему), SSMS использовал эти кэшированные учетные данные для подключения.

Однако после перехода на Vista при попытке подключить SSMS к серверу в домене DMZ я получаю сообщение Ошибка входа пользователя ''. Пользователь не связан с доверенным соединением SQL Server. Если я изменю параметры соединения, чтобы использовать именованные каналы вместо TCP / IP по умолчанию, мои кэшированные учетные данные отправляются, и все работает нормально. Это тот случай, когда брандмауэр Windows выключен или включен, и соединения с серверами в нашем внутреннем домене (в том же домене, в котором находится мой компьютер dev) работают нормально по TCP / IP или по именованным каналам.

Я не против использования именованных каналов для этих соединений в качестве обходного пути, но похоже, что TCP / IP является рекомендуемым способом подключения, и мне не нравится не понимать, почему он не работает так, как я ожидал. Есть идеи?

Answer 1

«Ошибка входа пользователя», пользователь не связан с доверенным соединением с SQL Server.

В этом сценарии клиент может установить tcp-соединение, а также работать под локальной учетной записью администратора или без учетной записи компьютера, независимо от того, зарегистрирован SPN или нет, учетные данные клиента явно не распознаются SQL Server.

Обходной путь здесь:

Создайте ту же учетную запись, что и на клиентском компьютере с тем же паролем на целевом компьютере с SQL Server, и предоставьте соответствующее разрешение учетной записи.

Давайте объясним более подробно:

Когда вы создаете одну и ту же учетную запись NT (назовем ее usr1) на обоих рабочие станции, вы по сути подключаетесь и олицетворяете локальную учетную запись соединительная станция. Т.е. когда вы подключаетесь от станции 1 к станции 2, Вы проходите аутентификацию через аккаунт Station2. Итак, если вы установите стартовая учетная запись для SQL Server (предположим, что он работает на станции 2) usr1 станции2, когда вы подключаетесь к SQL от станции1 с usr1 станции1 логин, SQL будет аутентифицировать вас как usr1 станции2.

Теперь в SQL вы определенно можете получить доступ к ресурсам Station1. Хотя, как большой доступ будет зависеть от разрешения usr1 станции1.

Пока что SQL имеет дело только с пользователем, который является частью роли sysadmin в SQL Server. Чтобы разрешить другим пользователям (не sysamdin) доступ к сетевым ресурсам, вам придется настроить учетную запись прокси. Взгляните на статью для Дополнительная информация. взято из http://blogs.msdn.com/sql_protocols/archive/2006/12/02/understanding-kerberos-and-ntlm-authentication-in-sql-server-connections.aspx

Answer 2

Я бы предположил, что это потому, что Vista запускает большинство приложений изолированно от других.

Я бы порекомендовал либо установить имя пользователя и пароль DMZ в соответствии с именем пользователя и паролем внутреннего домена, либо использовать именованные каналы для подключения.

Answer 3

Вы пытались запустить SSMS в режиме с повышенными правами и установлена ​​ли на клиенте последняя версия SP?