用户'DOMAIN \ MACHINENAME $'登录失败
我知道这几乎是重复的:在ASP.NET和SQL Server 2008中登录失败的用户'NT AUTHORITY IUSR'“登录失败用户'用户名'登录失败 - System.Data.SqlClient.SqlException与外部LINQ项目/类库,但与我的服务器上的其他应用程序相比,有些事情并没有加起来,我不知道为什么。
正在使用的框:
网络框
SQL框
SQL测试框
我的应用程序:
我有一个ASP.NET应用程序,它引用了一个使用LINQ到SQL的类库。 连接字符串在类库中正确设置。 根据登录用户'用户名'失败 - System.Data.SqlClient.SqlException与外部项目/类库中的LINQ我也将此连接字符串添加到Web应用程序。
连接字符串使用SQL凭据(在Web应用程序和类库中):
<add name="Namespace.My.MySettings.ConnectionStringProduction"
connectionString="Data Source=(SQL Test Box);Initial Catalog=(db name);Persist Security Info=True;User ID=ID;Password=Password"
providerName="System.Data.SqlClient" />
通过将此连接添加到服务器资源管理器,确认该连接正在工 这是我的.dbml文件正在使用的连接字符串。
问题:
我收到以下错误:
System.Data.SqlClient.SqlException: Login failed for user 'DOMAINMACHINENAME$'.
现在在ASP.NET和SQL Server 2008中引用这个错误“用户'NT AUTHORITY IUSR'的登录失败”,它说这确实是本地网络服务,使用任何其他非域名都不起作用。
但是我很困惑,因为我已经检查了SQL Box和SQL Test Box SQL Management Studio,并且都在安全性 - >用户的安全性 - >登录数据库级别下列出了NT AUTHORITY/NETWORK SERVICE
,但是在数据库级别安全性 - >用户我让用户显示在连接字符串中。
在Web服务器上的NTFS级别,权限有NETWORK SERVICE完全控制。
我感到困惑的原因是因为我的Web服务器上有许多其他Web应用程序,它们都在SQL Box和SQL Test Box上引用数据库,它们都可以工作。 但我找不到他们和我当前的应用程序之间的区别,除了我正在使用类库。 这是否重要? 检查NTFS权限,在服务器和数据库级别设置安全登录,连接字符串和连接方法(SQL Server凭据)以及IIS应用程序池和其他文件夹选项都是相同的。
为什么这些应用程序无需将机器名$添加到我的任何SQL盒的权限就可以工作? 但这就是这条链接告诉我要解决这个问题的方法。
NETWORK SERVICE和LocalSystem将始终作为相关帐户在本地进行身份验证(内置网络服务和内置系统),但都将通过远程身份验证为机器帐户。
如果您看到Login failed for user 'DOMAINMACHINENAME$'
等Login failed for user 'DOMAINMACHINENAME$'
则意味着以NETWORK SERVICE或LocalSystem身份运行的进程已访问远程资源,已将自己认证为机器帐户并被拒绝授权。
典型的例子是在应用程序池中运行的ASP应用程序设置为使用NETWORK SERVICE凭证并连接到远程SQL Server:应用程序池将作为运行应用程序池的计算机进行身份验证,并且是需要授予访问权限的计算机帐户。
当访问被拒绝给机器账户时,则必须授予访问权限给机器账户。 如果服务器拒绝登录'DOMAIN MACHINE $',那么您必须授予'DOMAIN MACHINE $'登录权限而不是NETWORK SERVICE。 授予对NETWORK SERVICE的访问权限将允许作为NETWORK SERVICE运行的本地进程连接,而不是远程连接,因为远程服务器会根据您猜到的DOMAIN MACHINE $进行身份验证。
如果您希望asp应用程序作为SQL登录连接到远程SQL Server,并且您获得有关DOMAIN MACHINE $的异常,则意味着您在连接字符串中使用了集成安全性。 如果这是意外的,这意味着你搞砸了你使用的连接字符串。
当您使用IIS配置应用程序时,会发生此错误,并且IIS转到SQL Server并尝试使用没有适当权限的凭据进行登录。 复制或镜像设置时也会发生此错误。 我将会讨论一个始终有效并且非常简单的解决方案。 转到SQL Server >>安全>>登录并右键单击NT AUTHORITY NETWORK SERVICE并选择属性
在登录属性新打开的屏幕中,转至“用户映射”选项卡。 然后,在“用户映射”选项卡上,选择所需的数据库 - 尤其是显示此错误消息的数据库。 在屏幕下方,检查角色db_owner。 点击确定。
一位同事有同样的错误,这是由于IIS中的一个小配置错误。
为Web应用程序分配了错误的应用程序池。
实际上,我们使用具有特定标识的自定义应用程序池来满足我们的需求。
在他的本地IIS管理器 - >站点 - >默认网站 - >我们的Web应用程序名称 - >基本设置...应用程序池是“DefaultAppPool”,而不是我们的自定义应用程序池。
设置正确的应用程序池解决了问题。
链接地址: http://www.djcxy.com/p/74071.html