SQL Server 2008 - 登录失败。 该登录来自不受信任的域，无法与 Windows 身份验证一起使用
我刚刚安装了 SQL Server 2008 Developer 版本，并尝试使用 SQLCMD.exe 进行连接，但出现以下错误：
H:\>sqlcmd.exe -S ".\SQL2008"
Msg 18452, Level 14, State 1, Server DEVBOX\SQL2008, Line 1
Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.
SQL Server 实例配置为使用 SQL Server 和 Windows 身份验证模式。 如果我指定 -U sa 那么我可以成功登录，但我想使用 Windows 身份验证。 使用 SSMS 与 Windows 身份验证进行连接似乎工作正常。
I've just installed SQL Server 2008 Developer edition and I'm trying to connect using SQLCMD.exe, but I get the following error:
H:\>sqlcmd.exe -S ".\SQL2008"
Msg 18452, Level 14, State 1, Server DEVBOX\SQL2008, Line 1
Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.
The SQL Server instance is configured to use SQL Server and Windows Authentication mode. If I specify -U sa then I can log in successfully, but I'd like to use windows authentication. Connecting using SSMS with windows authentication seems to work fine.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我遇到了这个问题，这是因为运行应用程序的计算机不被信任，无法通过活动目录在域上进行委派。 例如，如果它是在应用程序池标识 DOMAIN_application.environment 下运行的 .net 应用程序，除非计算机受信任，否则该标识无法调用 SQL。
I had this issue and it was because the machine running the application isnt trusted for delegation on the domain by active directory. If it is a .net app running under an application pool identity DOMAIN_application.environment for example.. the identity can't make calls out to SQL unless the machine is trusted.
您没有向 sqlcmd.exe 传递任何凭据，
因此它尝试使用 Windows 登录凭据对您进行身份验证，但您的 SQL Server 设置不能接受这些凭据...
当您安装它时，您可能已经提供服务器管理员密码（对于
sa帐户）尝试...
作为参考，
有更多详细信息此处< /a>...
You're not passing any credentials to sqlcmd.exe
So it's trying to authenticate you using the Windows Login credentials, but you mustn't have your SQL Server setup to accept those credentials...
When you were installing it, you would have had to supply a Server Admin password (for the
saaccount)Try...
for reference,
theres more details here...
就我而言，此错误是由重命名我的客户端计算机引起的。 我使用了一个长度超过 13 个字符的新名称（尽管有警告），这导致 NETBIOS 名称被截断并且与完整的计算机名称不同。 当我将客户端重新命名为更短的名称后，错误就消失了。
In my case, this error was caused by renaming my client machine. I used a new name longer than 13 characters (despite the warning), which resulted in the NETBIOS name being truncated and being different from the full machine name. Once I re-renamed the client to a shorter name, the error went away.
刚刚尝试过：
H:>"C:\Program Files\Microsoft SQL Server\90\Tools\Binn\sqlcmd.exe" -S ".\SQL2008"
1>
它有效..（我的路径中有 Microsoft SQL Server\100\Tools\Binn 目录）。
仍然不确定为什么 SQL Server 2008 版本的 SQLCMD 不起作用。
Just tried this:
H:>"C:\Program Files\Microsoft SQL Server\90\Tools\Binn\sqlcmd.exe" -S ".\SQL2008"
1>
and it works.. (I have the Microsoft SQL Server\100\Tools\Binn directory in my path).
Still not sure why the SQL Server 2008 version of SQLCMD doesn't work though..
您的错误实际上是在说“您正在尝试使用 Windows 身份验证，但您的登录不是来自受信任的域”。 这很奇怪，因为您正在连接到本地计算机。
也许您使用本地帐户而不是域帐户登录 Windows？ 确保您登录的域帐户也是 SQL2008 实例上的 SQL Server 主体。
Your error is quite literally saying "you're trying to use Windows Authentication, but your login isn't from a trusted domain". Which is odd, because you're connecting to the local machine.
Perhaps you're logged into Windows using a local account rather than a domain account? Ensure that you're logging in with a domain account that is also a SQL Server principal on your SQL2008 instance.
您是否指定用于登录的用户名和密码？ 你的完整命令行到底是什么？
如果您在自己的机器上运行，则可以指定用户名/密码，或使用
-E参数使用 Windows 凭据登录（如果 SQL Server 安装允许这些凭据） 。马克
Do you specify a user name and password to log on? What exactly is your complete command line?
If you're running on your own box, you can either specify a username/password, or use the
-Eparameter to log on with your Windows credentials (if those are permitted in your SQL server installation).Marc
我也遇到了这个错误，尽管我的问题是我不断通过虚拟机在两个公司网络之间切换，并使用不同的访问凭据。 我必须运行命令提示符：
此后我的网络问题得到解决，我可以再次连接到 SQL。
I was getting this error too, although my issue was that I kept switching between two corporate networks via my Virtual Machine, with different access credentials. I had to run the command prompt:
After this my network issues were resolved and I could connect once again to SQL.
刚刚找到这个帖子并在这里发布了一个替代答案（复制如下）：
https://stackoverflow.com/a/37853766/1948625
具体来说，在这个问题上，如果点“
.命令行的”与-S值中使用的“127.0.0.1意思相同，那么可能与命令行的连接字符串有同样的问题其他问题。 请改用主机名，或检查主机文件。老问题，和我的症状略有不同，但同样的错误。 我的连接字符串是正确的（集成安全性，并且我不提供用户和密码），
数据源设置为127.0.0.1。 多年来一直运作良好。但最近我在静态主机文件中添加了一行用于测试目的 (
C:\Windows\System32\drivers\etc\hosts)删除这一行，错误就消失了。
我从这篇文章中得到了线索（https://support.microsoft.com/en- gb/kb/896861）其中讨论了主机名和环回。
其他可能的修复（如果您需要在主机文件中保留该行）是在数据中使用主机名（如 MYSERVER01 ）而不是 127.0.0.1 。连接字符串的源。
Just found this thread and posted an alternative answer (copied below) here:
https://stackoverflow.com/a/37853766/1948625
Specifically on this question, if the dot "
." used in the-Svalue of the command line means the same as127.0.0.1, then it could be the same issue as the connection string of the other question. Use the hostname instead, or check your hosts file.Old question, and my symptoms are slightly different, but same error. My connection string was correct (Integrated security, and I don't provide user and pwd) with
data sourceset to127.0.0.1. It worked fine for years.But recently I added a line in the static host file for testing purposes (
C:\Windows\System32\drivers\etc\hosts)Removing this line and the error is gone.
I got a clue from this article (https://support.microsoft.com/en-gb/kb/896861) which talks about hostnames and loopback.
Other possible fix (if you need to keep that line in the hosts file) is to use the hostname (like
MYSERVER01) instead of127.0.0.1in thedata sourceof the connection string.