Windows 身份验证可信连接不起作用
MSSQL Server 位于“abc”域中并具有混合模式身份验证。 我正在使用 MSSQL Jdbc 驱动程序 2.0 从不在域或域“xyz”中但在同一网络中的计算机进行连接。 我已以 xyz 域中的管理员或帐户身份登录。
使用以下 url 进行“sa”或 SQL 模式身份验证的连接可以正常工作。
jdbc:sqlserver://%DB_IP%:%DB_PORT%;SelectMethod=cursor;DatabaseName=dbname
它不起作用 对于使用凭据 "MSSQLDomain\username" ie "abc\用户名”，使用以下网址
jdbc:sqlserver://%DB_IP%:%DB_PORT%;SelectMethod=cursor;integratedSecurity=true;DatabaseName=dbname;
给出以下错误。 用户“”登录失败。 该用户未与可信的关联 SQL 服务器连接。
我尝试将属性 Trusted_Connection=Yes 添加到 url，但仍然给出相同的错误。 我不想映射 SQL Server 的驱动器。 我可以通过提供“MSSQLDomain\用户名”和密码来访问 SQL Server 计算机的任何共享文件夹。
如果两台计算机位于同一域中，则两种身份验证模式都可以正常工作。 如果我使用不在同一网络（即同一子网）域或“xyz”域中的计算机上的 jtDS 驱动程序，则它可以正常工作。
MSSQL Server is in the "abc" domain and have mixed mode authentication.
I am connecting from the machine which is not in domain or in a domain "xyz" but with in the same network using MSSQL Jdbc driver 2.0. I have logged in as admin or account in xyz domain.
It works fine using following url for connection for "sa" or SQL Mode Authentication.
jdbc:sqlserver://%DB_IP%:%DB_PORT%;SelectMethod=cursor;DatabaseName=dbname
It doesn't work For window authentication using credential "MSSQLDomain\username" i.e "abc\username", using following url
jdbc:sqlserver://%DB_IP%:%DB_PORT%;SelectMethod=cursor;integratedSecurity=true;DatabaseName=dbname;
Gives following error.
Login failed for user ''. The user is not associated with a trusted
SQL Server connection.
I have tried adding property Trusted_Connection=Yes to url, but still gives same error.
I don't want to map the drive of the SQL Server. I am able to access the any shared folder of the SQL Server Machine by providing "MSSQLDomain\username" and password.
It works fine for both authentication mode, if both machine is in same domain.
If I am using jtDS Driver from the machine which is not in domain or in "xyz" domain within same network i.e same subnet, it works fine.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我曾经参与过建立跨域的 SQL 服务器连接，这是非常痛苦的。 为了使用来自另一个域的凭据，您分配权限的域必须信任该帐户所在的域。 IT 专业人员通常非常不愿意以这种方式信任另一个域，并且有充分的理由，因此如果尚未建立这种信任关系，则可能不太可能说服管理员这样做。
建立信任关系后，您可能需要在 Active Directory 中为 SQL Server 注册 SPN，并分配委派权限。 这种类型的环境非常难以设置、故障排除和维护。
我希望您可以通过其他方式来做到这一点，因为听起来您正面临一个非常困难的情况。
希望能帮助到你
日韩
I have been involved with making a SQL server connection cross to domains like that, and it is exceptionally painful. In order to use credentials from another domain, the domain where you are assigning the permissions has to trust the domain, where the account is coming from. IT Pro's are generally VERY reluctant to trust another domain in this manner, and for good reason, so if this trust relationship has not been established it might not be very likely to convince the admins to do this.
Once you have the trust relationship established, you will probably need to register the SPN's for your SQL server in Active Directory, and assign delegation permissions. This type of environment is very difficult to setup, troubleshoot and maintain.
I hope that there is some other way that you can do this, because it sounds like you are headed for a very difficult scenario.
Hope it helps
Rihan
这是 Windows 身份验证经过深思熟虑且正确的行为。
这是因为您连接的域与 SQL Server 实例所在的域不是同一个 Windows 域。
我相信可以这么说，有一些桥接域的方法，但是它们需要自定义且棘手的实现。 您还必须配置域之间的信任关系。
以下主题包含您可能会发现有用的讨论。
http://sql-server-performance.com/Community/论坛/p/24601/137574.aspx
This is the deliberate and correct behaviour of Windows Authentication.
It is because the Domain from which you are connecting from, is not the same Windows Domain as the one where your SQL Server instance resides.
I believe there are methods for bridging the Domains so to speak, however they require custom and tricky implementation. You also will have to configure a trust relationship between the domains.
The following thread contains discussions which you will likely find useful.
http://sql-server-performance.com/Community/forums/p/24601/137574.aspx
更改登录凭据可能会有所帮助，
使用 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 登录来自不受信任的域。 要解决此问题，请验证您是否登录到正确的域。
Changing the login credentials might help,
use SQL authentication instead of nt authentication
https://support.microsoft.com/en-us/kb/555332
Symptoms
After you install Microsoft SQL Server 2014, SQL Server 2012, SQL Server 2008, SQL Server 2005, or SQL Server 2000 and you try to connect to the server that is running SQL Server, you receive one of the following error messages:
Login failed for user '%.*ls'. The login is a SQL Server login and cannot be used with Windows Authentication.%.*ls
Login failed for user ''. The user is not associated with a trusted SQL Server connection. (Microsoft SQL Server, Error: 18452)
Login failed for user ''. (Microsoft SQL Server, Error: 18456)
Resolution
This problem occurs if the user tries to log in with credentials that cannot be validated. This problem can occur in the following scenarios:
Scenario 1:
The login may be a SQL Server login but the server only accepts Windows Authentication
To resolve this issue, configure SQL Server in Mixed Authentication Mode.
Scenario 2:
You are trying to connect by using SQL Server Authentication but the login used does not exist on SQL Server
To resolve this issue, verify that the SQL Server login exists. For more information, see Create a login in SQL Server Books Online.
Scenario 3:
The login may use Windows Authentication but the login is an unrecognized Windows principal
An unrecognized Windows principal means that Windows can't verify the login. This might be because the Windows login is from an untrusted domain. To resolve this issue, verify that you are logged in to the correct domain.