我知道这几乎是:The error "Login failed for user 'NT AUTHORITY\IUSR'" in ASP.NET and SQL Server 2008和Login failed for user 'username' - System.Data.SqlClient.SqlException with LINQ in external project / class library的复制品,但有些东西与我服务器上的其他应用程序相比并不合理,我不确定为什么。
正在使用的盒子:
Web框
SQL框
SQL测试框
我的应用程序:
我有一个SQL应用程序,它引用了一个使用ASP.NET -to-SQL类库。在类库中正确设置了连接字符串。根据Login failed for user 'username' - System.Data.SqlClient.SqlException with LINQ in external project / class library,我还将此连接字符串添加到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文件使用的连接字符串。
The problem:
我得到以下错误:
System.Data.SqlClient.SqlException: Login failed for user 'DOMAIN\MACHINENAME$'.
现在引用这个The error "Login failed for user 'NT AUTHORITY\IUSR'" in ASP.NET and SQL Server 2008,它说这是真正的本地网络服务,使用任何其他非域名都不起作用。
但是我很困惑,因为我已经检查了SQL Box和SQL Test Box SQL Management Studio,并且在数据库级别的Security -> Logins下都有NT AUTHORITY/NETWORK SERVICE
,它没有在Security -> Users下列出,但是在数据库级别Security -> Users中,我将该用户显示在连接字符串中。
在web服务器上的NTFS级别,具有网络服务的权限具有完全控制权。
我感到困惑的原因是因为我的web服务器上有许多其他Web应用程序,这些应用程序引用SQL Box和SQL Test Box上的数据库,它们都可以正常工作。但除了使用类库之外,我找不到它们与我当前的应用程序之间的区别。这有关系吗?检查NTFS权限、在服务器和数据库级别设置安全登录、连接字符串和连接方法(SQL server凭据)以及IIS应用程序池和其他文件夹选项都是相同的。
为什么这些应用程序在不将machinename$添加到我的任何一个SQL框的权限的情况下都可以工作?但这就是唯一的链接告诉我要做的事情来解决这个问题。
发布于 2010-05-11 05:29:05
NETWORK SERVICE和LocalSystem将始终以本地相应帐户的身份进行身份验证(内置\网络服务和内置\系统),但两者都将远程身份验证为机器帐户。
如果您看到像Login failed for user 'DOMAIN\MACHINENAME$'
这样的失败,这意味着作为网络服务或作为LocalSystem运行的进程已经访问了远程资源,已经将自己验证为机器帐户,并且被拒绝授权。
典型的示例是在设置为使用网络服务凭据并连接到远程SQL Server的应用程序池中运行的ASP应用程序:应用程序池将作为运行应用程序池的计算机进行身份验证,并且此计算机帐户需要被授予访问权限。
当拒绝访问计算机帐户时,则必须授予该计算机帐户访问权限。如果服务器拒绝登录'DOMAIN\MACHINE$',那么您必须将登录权限授予'DOMAIN\MACHINE$‘,而不是网络服务。授予对网络服务的访问权限将允许作为网络服务运行的本地进程进行连接,而不是远程进程,因为远程进程将验证为DOMAIN\MACHINE$。
如果您希望asp应用程序以SQL登录身份连接到远程SQL Server,而您得到了关于DOMAIN\MACHINE$的异常,这意味着您在连接字符串中使用了集成安全性。如果这是意想不到的,那就意味着你搞砸了你使用的连接字符串。
发布于 2011-10-29 19:13:42
如果您使用IIS配置了应用程序,并且IIS转到SQL Server并尝试使用没有适当权限的凭据登录,则会发生此错误。设置复制或镜像时也可能发生此错误。我将介绍一个始终有效且非常简单的解决方案。转到SQL Server安全>>登录,右键单击NT AUTHORITY\NETWORK SERVICE并选择属性
在新打开的登录属性屏幕中,转到“用户映射”选项卡。然后,在“User Mapping”选项卡上,选择所需的数据库-尤其是显示此错误消息的数据库。在下方的屏幕上,选中角色db_owner。单击OK。
发布于 2017-02-11 12:57:56
基本上,为了解决这个问题,我们需要像这样进行一些设置
在ApplicationPoolIdentity
中使用Windows身份验证通过ADO.Net连接到数据库
用于Windows身份验证的连接字符串包括Web.config
文件中的Trusted_Connection=Yes
属性或等效属性Integrated Security=SSPI
我的数据库连接处于Windows身份验证模式。因此,我只需将ApplicationPoolIdentity的应用程序池身份更改为我的域登录凭据DomainName\MyloginId,即可解决此问题
步骤:
高级应用程序单击您的高级应用程序的名称Pools
对我来说,它已经解决了。
注意:在生产或IT环境中,您可能会在同一域下使用服务帐户来标识应用程序池身份。如果是这样,请使用服务帐户而不是您的登录帐户。
https://stackoverflow.com/questions/2806438
复制相似问题