Проверка подлинности Windows, не работает доверенное соединение - PullRequest
2 голосов
/ 19 мая 2009

Сервер MSSQL находится в домене abc и имеет аутентификацию в смешанном режиме. Я подключаюсь с компьютера, который не находится в домене или домене "xyz", но в той же сети, используя драйвер MSSQL Jdbc 2.0. Я вошел в систему как администратор или учетная запись в домене xyz.

Работает нормально, используя следующий URL для подключения к "sa" или аутентификации в режиме SQL.

JDBC: SQLServer: //% DB_IP%:% DB_PORT%; SelectMethod = курсор, DatabaseName = имя_бд

Не работает для проверки подлинности окна с использованием учетных данных "MSSQLDomain\username" т.е. "abc\username", с использованием следующего URL

JDBC: SQLServer: //% DB_IP%:% DB_PORT%; SelectMethod = курсор, integratedSecurity = истина; DatabaseName = имя_бд;

Дает следующую ошибку. Не удалось войти в систему для пользователя ''. Пользователь не связан с доверенным Соединение с SQL Server.

Я попытался добавить свойство Trusted_Connection = Yes к URL, но все равно выдает ту же ошибку. Я не хочу отображать диск SQL Server. Я могу получить доступ к любой общей папке на компьютере с SQL Server, указав «MSSQLDomain \ username» и пароль.

Работает нормально для обоих режимов аутентификации, если оба аппарата находятся в одном домене. Если я использую драйвер jtDS с компьютера, который не находится в домене или в домене "xyz" в той же сети, т.е. в той же подсети, он работает нормально.

Ответы [ 3 ]

2 голосов
/ 19 октября 2015

Изменение учетных данных может помочь, использовать аутентификацию SQL вместо аутентификации nt

https://support.microsoft.com/en-us/kb/555332

Симптомы

После установки Microsoft SQL Server 2014, SQL Server 2012, SQL Server 2008, SQL Server 2005 или SQL Server 2000 и попытки подключения к серверу, на котором выполняется SQL Server, вы получаете одно из следующих сообщений об ошибке:

Ошибка входа пользователя "%. * Ls". Имя входа является именем входа SQL Server и не может использоваться с проверкой подлинности Windows.%. * Ls

Ошибка входа пользователя ''. Пользователь не связан с доверенным соединением SQL Server. (Microsoft SQL Server, ошибка: 18452)

Ошибка входа пользователя ''. (Microsoft SQL Server, ошибка: 18456)

Разрешение

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

Сценарий 1:

Имя входа может быть именем входа SQL Server, но сервер принимает только проверку подлинности Windows

Чтобы решить эту проблему, настройте SQL Server в режиме смешанной аутентификации.

Сценарий 2:

Вы пытаетесь подключиться с использованием аутентификации SQL Server, но используемый логин не существует на SQL Server

Чтобы решить эту проблему, убедитесь, что имя входа SQL Server существует. Дополнительные сведения см. В разделе «Создание имени входа в электронной документации по SQL Server».

Сценарий 3:

При входе в систему может использоваться проверка подлинности Windows, но это неопознанный участник Windows

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

2 голосов
/ 19 мая 2009

Это намеренное и правильное поведение проверки подлинности Windows.

Это потому, что домен, из которого вы подключаетесь, не тот домен Windows, в котором расположен ваш экземпляр SQL Server.

Я полагаю, что существуют методы, позволяющие соединить Домены, так что они требуют нестандартной и сложной реализации. Вам также необходимо настроить доверительные отношения между доменами.

Следующая ветка содержит обсуждения, которые вы, вероятно, найдете полезными.

http://sql -server-performance.com / Сообщество / форумы / р / 24601 / 137574.aspx

0 голосов
/ 19 мая 2009

Я участвовал в создании соединения SQL-сервера с такими доменами, и это чрезвычайно болезненно. Чтобы использовать учетные данные из другого домена, домен, которому вы назначаете разрешения, должен доверять домену, откуда поступает учетная запись. ИТ-специалисты, как правило, ОЧЕНЬ неохотно доверяют другому домену таким образом и по уважительной причине, поэтому, если эти доверительные отношения не установлены, вряд ли убедит администраторов сделать это.

После установления доверительных отношений вам, вероятно, потребуется зарегистрировать имена участников-служб для вашего SQL-сервера в Active Directory и назначить разрешения на делегирование. Этот тип среды очень сложен в настройке, устранении неполадок и обслуживании.

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

Надеюсь, это поможет Рихан

...