SQL Server 2008 Windows身份验证登录错误:该登录来自不受信任的域

这可能发生的另一个原因(刚刚发生在我身上)用户密码是否过期。我没有意识到这一点,直到我尝试远程进入实际的服务器,并被提示更改我的密码。

对我来说,当我编辑一个空白的 drivers/etc/hosts 文件,并为本地网站添加一个条目,但忽略了添加 127.0.0.1 localhost

此问题是由于Active Directory服务器故障造成的,当然,该服务器无法对Windows帐户进行身份验证。谢谢你的帮助。

对于其他遇到此问题的人,我的hosts文件中包含此问题:

127.0.0.1   localhost
127.0.0.1   customname

我需要这样做:

127.0.0.1   localhost
127.0.0.1   localhost   customname

该问题是由于Active Directory服务器故障造成的,当然,该服务器无法验证Windows帐户。

当然不是“因为如果AD不可用,那么Kerberos身份验证将返回到NTLM(域帐户凭据在本地缓存,即使AD/Kerberos不可用,也可以使用它登录)。我想你可能有两个同时发生的条件导致这种失败:

• SQL Server不是本地的(在另一台计算机上)
• 信任配置为“仅限Kerberos”

或其他特定的安全网络/服务器/广告/计算机配置

我的本地计算机上的一个服务器实例出现了这个问题,发现这是因为我指向127.0.0.1时主机文件中没有“localhost”以外的内容。在我的案例中,有两种方法可以解决这个问题:

1. 清除hosts文件中指向127.0.0.1的违规条目
2. 使用“localhost”而不是hosts文件中指向127.0.0.1的其他名称

*只有当我在本地机器上运行SQL Server实例并尝试从同一台机器访问它时,这才对我有效。

确保您没有连接到其他域\用户上的VPN . 或者反过来,确保你 是 连接,如果这是必需的。

尝试使用其他有效登录名 using RUNAS command

runas /user:domain\user “C:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\ssmsee.exe” 

runas /user:domain\user “C:\WINDOWS\system32\mmc.exe /s \”C:\Program Files\Microsoft SQL Server\80\Tools\BINN\SQL Server Enterprise Manager.MSC\”" 

runas /user:domain\user isqlw 

对我来说,这是因为我没有将该帐户添加到要用于SQL数据库本身的角色中。同时由于密码尝试错误,通过复制粘贴问题锁定帐户。

好的,完全在外面,我的回答。我是从虚拟机virtualbox上托管的开发环境中获取此错误的。三台服务器:SharePoint、SQL数据库和域控制器。SharePoint服务器无法连接到配置数据库。我仍然可以使用sa帐户通过ODBC进行SQL身份验证,但不能使用Windows身份验证。但该用户很乐意登录到SQL服务器上的SSM。我也从ODBC得到了更好的错误消息,还通过检查SQL Server上失败的登录消息:

select text from sys.messages where message_id = '18452' and language_id = 1033

因为我向我们的一个企业系统管理员寻求帮助,他在看了我给他发的几张屏幕截图后的5分钟内就诊断出了这个问题,所以我不能相信这一点。 问题是域控制器的时钟设置不正确! 简直不敢相信。服务器设置为仅主机联网,因此没有Internet与时钟同步。这也解释了为什么当我知道系统正在工作时,回滚到以前的快照并不能解决问题。

编辑:在服务器上安装来宾添加项将来宾时钟与主机同步。

JTDS驱动程序上有一个名为useNTLMv2的设置,默认设置为false。在我的数据库软件(DBVisualizer)中将此设置为“真”解决了它。

您可能会看到的另一种情况是,您试图从更改密码时已登录的SSMS会话连接到另一个SQL Server。事件顺序可能类似于:

1. RDP到服务器A(您的SQL服务器),打开SSMS并登录
2. RDP到同一域中的服务器B并更改密码
3. 返回到服务器A上的RDP会话,并通过SSMS尝试将另一个DB添加到现有Alwayson可用性组中。当连接到副本时,您会得到“不受信任的域”-登录错误

要解决此问题,只需注销并重新登录即可。

我一直试图从域帐户登录到SQL Server 2008。SQL Server 2008宿主在不属于域的其他工作组计算机上。听起来很奇怪,在运行SQL Server 2008的工作组服务器上,我必须转到系统属性计算机名(选项卡)更改(按钮)计算机名更改更多…(按钮)并输入“此计算机的主DNS后缀”(为空,因此输入网络所需的后缀)并选中“域成员身份更改时更改主DNS后缀”框。这允许在登录到SQL Server 2008时完成Windows身份验证过程。

我必须使用NetOnly才能在现代窗口上工作:

runas /netonly /user:domain\user "C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\ssms.exe"

另一个原因> 有人更改了默认SQL用户的密码

几分钟前我换了一个新的域控制器…

我在禁用环回检查设置的计算机上修复了此问题:

1. 编辑Windows注册表:开始“运行”regedit
2. 导航到:hklm\system\currentcontrolset\control\lsa
3. 添加一个名为__disableLoopbackcheck__的双字值
4. 将此值设置为1

你可能是 对用户名的误解 您在本地使用。这是我在Windows10家庭中的案例。当我在控制面板中查看用户时,我看到了名称 URPC01 . 但是当我打字的时候 net config workstation ,似乎用户名是 SPC01 . 似乎有人重命名了用户,但内部名称保持不变。

不知道如何修复Windows用户名(以及 C:\Users ,也指原始的内部名称),我在数据库服务器上添加了一个新的用户帐户。

为了启用Windows身份验证,两台计算机必须在同一域中。为了允许管理工作室通过当前凭证并在SQL框中进行身份验证

对于我来说,我必须断开(更改工作组/域)与域的连接,然后重新连接。

还有另一个可能的原因: 在DB服务器上新建的本地帐户设置了“用户下次登录时必须更改密码”标志。

以下是为我修复的: 网络连接的属性 单击“Internet协议版本4(TCT/IPv4)”。 点击“属性”按钮。 点击“高级”按钮。 选择“DNS”选项卡。 删除“此连接的DNS后缀”中的文本。

我也无法远程连接到SQL服务器。在同一域中的SQL Server和远程服务器。几天前我被要求更改密码。 重新启动我试图从中访问SQL Server的SQL Server和远程服务器对我来说都是个小把戏。

在我们的例子中,开发人员使用自己的帐户运行应用程序池,并重置了密码,但忘记在应用程序池中更改密码。杜…

在我的例子中,服务器在域控制器中被禁用。我进入Active Directory中的计算机ou,右键单击服务器,启用它,然后从SQL服务器执行gpupdate/force。花了一点时间,但最终还是成功了。

在我的例子中,在主机文件中,机器名是用旧的IP硬编码的。 我用新的IP替换旧的IP,问题解决了。

主机文件位置

windowsdrive:\windows\system32\drivers\etc\hosts

修改完成 159.XX.XX.XXX机器名

以上都不适合我。我要做的是: 在SQL Server Management Studio的登录屏幕上,选择选项>> 在网络部分,将网络协议更改为命名管道。

此外,我必须做的是使它与 <default> 设置是禁用无线网络(机器也连接到有线局域网)。

我的修复方法是更改web.config文件,使其与我的新SQL连接服务器名相关联(IT安全刚刚在我的开发框中重命名了netdom)。

我在主机文件中输入错误 C:\Windows\System32\drivers\etc

[Microsoft][SQL Server Native Client 11.0][SQL Server]Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.

确保输入如下内容

127.0.0.1   localhost
127.0.0.1   localhost   servername

我正在为指向“127.0.0.1”的SQL Server实例使用别名。 改为“localhost”就可以了。

如果您的SQL Server运行在不属于域的服务器上,并且在连接字符串中使用完全限定的域名(例如xyz.mypc.com),集成安全性=true,则可能需要切换到使用IP地址、machinename(server01)或点(.),以防它是本地宿主的。

这对我很有效,使用fqdn导致了上面的错误。