用户'DOMAIN \ MACHINENAME $'登录失败

Question

我知道这几乎与以下内容重复：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 Box
SQL Box
SQL测试盒

我的申请

我有一个ASP.NET Web应用程序，它引用了一个使用LINQ-to-SQL的类库。连接字符串在类库中正确设置。根据{{​​3}}我还将此连接字符串添加到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" />

此连接通过将其添加到Server Explorer确认为有效。这是我的.dbml文件正在使用的连接字符串。

问题：

我收到以下错误：

System.Data.SqlClient.SqlException: Login failed for user 'DOMAIN\MACHINENAME$'.

现在引用此Login failed for user 'username' - System.Data.SqlClient.SqlException with LINQ in external project / class library它表示实际上是本地网络服务并且使用任何其他非域名都不起作用。

但我感到困惑，因为我已经检查了SQL Box和SQL Test Box SQL Management Studio，并且在安全性下都有NT AUTHORITY/NETWORK SERVICE - ＆gt;登录，在数据库级别，未列在安全性 - ＆gt;用户，但在数据库级别安全 - ＆gt;用户我将用户显示在连接字符串中。

在Web服务器上的NTFS级别，权限使NETWORK SERVICE具有完全控制权。

我感到困惑的原因是因为我的Web服务器上有许多其他Web应用程序，它们在SQL Box和SQL Test Box上引用数据库，它们都可以工作。但除了我使用类库之外，我找不到它们和我当前的应用程序之间的区别。那会有关系吗？检查NTFS权限，服务器和数据库级别的安全登录设置，连接字符串和连接方法（SQL Server凭据）以及IIS应用程序池和其他文件夹选项都是相同的。

为什么这些应用程序在没有将machinename $添加到我的任何一个SQL框的权限的情况下都可以工作？但这就是一个链接告诉我要解决这个问题的方法。

Answer 1

NETWORK SERVICE和LocalSystem将始终作为本地的相应帐户（内置\网络服务和内置\系统）进行身份验证，但两者都将远程验证为计算机帐户。

如果您发现Login failed for user 'DOMAIN\MACHINENAME$'之类的故障，则意味着作为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 $的例外，则表示您在连接字符串中使用Integrated Security。如果这是意料之外的，则意味着你搞砸了你使用的连接字符串。

Answer 2

使用IIS配置应用程序时会发生此错误，并且IIS转到SQL Server并尝试使用没有适当权限的凭据登录。设置复制或镜像时也会发生此错误。  我将讨论一个始终有效且非常简单的解决方案。 转到SQL Server＆gt;＆gt;安全＆gt;＆gt;登录并右键单击NT AUTHORITY \ NETWORK SERVICE并选择Properties

在新打开的“登录属性”屏幕中，转到“用户映射”选项卡。然后，在“用户映射”选项卡上，选择所需的数据库 - 尤其是显示此错误消息的数据库。在下部屏幕上，检查角色db_owner。单击“确定”。

Answer 3

就我而言，我的IIS应用程序池有Identity="ApplicationPoolIdentity"。

我将IIS APPPOOL\ApplicationName用户添加到SQL Server后就可以了。

Answer 4

对我有用的技巧是从我的连接字符串中删除Integrated Security并在你的libruary的User ID=userName; Password=password中添加常规App.config你的连接字符串可能没有使用集成安全性但是Web.config中创建的那个是！

Answer 5

一位同事有同样的错误，这是由于IIS中的一点配置错误 为Web应用程序分配了错误的应用程序池。

事实上，我们使用具有特定身份的自定义应用程序池来满足我们的需求。

在他的本地IIS管理器中 - ＆gt;网站 - ＆gt;默认网站 - ＆gt;我们的网络应用名称 - ＆gt;基本设置... 应用程序池是“DefaultAppPool”而不是我们的自定义应用程序池。

设置正确的应用程序池解决了这个问题。

Answer 6

我将<identity impersonate="true" />添加到了我的web.config，它运行正常。

Answer 7

基本上要解决这个问题，我们需要进行一些设置，比如

• 在ApplicationPoolIdentity下运行的Web应用程序
• 使用连接字符串中的Windows身份验证通过ADO.Net连接到数据库的Web应用程序

与Windows身份验证一起使用的连接字符串包括Trusted_Connection=Yes属性或Integrated Security=SSPI文件中的等效属性Web.config

我的数据库连接处于Windows身份验证模式。所以我通过简单地将 Application Pools 身份从 ApplicationPoolIdentity 更改为我的域登录凭据 DomainName \ MyloginId

来解决这个问题

步骤：

1. 点击应用程序池

2. 选择应用程序的名称

3. 转到高级设置

4. 展开流程模型，然后点击身份。点击三 点在右端。
5. 点击设置... 按钮，然后单击“提供” 您的域名登录凭据

对我来说它已经解决了。

注意：在生产环境或IT环境中，您可能在同一个域下拥有应用池标识的服务帐户。如果是这样，请使用服务帐户而不是登录。

Answer 8

对我来说，当我用一个允许访问数据库的网络帐户替换默认的内置帐户'ApplicationPoolIdentity'时问题得到了解决。

可以在Internet Information Server（IIS 7+）中进行设置＆gt;应用程序池＆gt; Advanded Settings＆gt;过程模型＆gt;身份

Answer 9

我们在处理Analysis Services数据库时收到了类似的错误消息。事实证明，用于运行Analysis Services实例的用户名尚未添加到SQL Server的安全登录中。

在SQL Server 2012中，SQL Server和Analysis服务配置为默认情况下以不同用户身份运行。如果您已使用默认值，请始终确保AS用户可以访问您的数据源！

Answer 10

我也遇到了SQL Server身份验证用户的错误

我尝试了一些修复，但它们没有用。

我的解决方案是在Management Studio：Properties / Security下配置其“服务器身份验证模式”以允许SQL Server身份验证。

Answer 11

在这里添加新答案，因为以前的答案并不能解释我遇到的问题。问题在于，SQL中所需的用户名是应用程序池的名称，而不是其身份。

我在IIS中将AppPools设置为ApplicationPoolIdentity身份。

我具有访问权限的SQL安全用户名称为IIS APPPOOL\DefaultAppPool，它在ASP.NET Full Framework .net应用程序中正常运行。

启动ASP.NET Core应用程序时，它使用应用程序名称创建了一个新的AppPool，但没有CLR版本，并且仍使用相同的ApplicationPoolIdentity身份。

但是在查看通过System.Security.Principal.WindowsIdentity.GetCurrent().Name使用的用户名后，我意识到它没有使用DefaultAppPool，而是新的应用程序池名称。因此，我必须在“ SQL安全性”选项卡中添加一个名为IIS APPPOOL\ApplicationName的新用户，而不是默认用户。

Answer 12

对于我来说，问题是＆＃39; DOMAIN \ MACHINENAME $＆＃39;通过将DefaultApplicationPool标识设置为NetworkService来修复。

Answer 13

每个人似乎忽略的唯一一点是，您可能需要集成安全性= true。您可以在池帐户下运行该站点。这一切都很好，并且仍然可以使用原始用户凭证而不是池来命中SQL服务器。它被称为约束委派。如果您启用它并设置SPN窗口将转换池的凭据与用户的请求转到最终服务（SQL只是一个这样的服务）。您必须在Web服务器上注册为SQL请求提供服务的ONE AND ONLY SQL服务器。设置这一切对我来说太多了，试图在这里准确描述。我花了很长时间自己解决这个问题。

Answer 14

检查您是否

User Instance=true

连接字符串中的

。尝试删除它，这将解决您的问题。

Answer 15

我花了几个小时试图修复这个问题，我终于得到了它 - SQL Server浏览器是＆＃34;停止＆＃34;。解决方法是将其更改为＆＃34;自动＆＃34;模式：

  

如果已禁用，请转到“控制面板” - >“管理”   工具 - ＆gt;服务，并查找SQL Server代理。右键单击，然后   选择＆＃34;属性。＆＃34;来自＆＃34;启动类型＆＃34;下拉，改变   ＆＃34;禁用＆＃34;到＆＃34;自动＆＃34;。

quote from here

Answer 16

当客户端重命名SQL Server时，我遇到了这个问题。将SQL Reporting Service配置为连接到旧服务器名称，他们还为该旧服务器名称创建了一个别名，该别名重定向到新服务器名称的IP。

所有旧的IIS应用程序都在运行，并通过别名重定向到新的服务器名称。凭直觉，我检查了他们是否正在运行SSRS。尝试连接到SSRS网站会产生错误：

”该服务不可用。请与系统管理员联系以解决问题。系统管理员：报表服务器无法连接到其数据库。请确保数据库正在运行并且可访问。您还可以检查报告服务器跟踪日志以获取详细信息。“

它正在服务器上运行，但由于它使用旧服务器名的别名而无法连接。重新配置SSRS以使用新的服务器名称，而不是旧的/别名对其进行修复。

Answer 17

1. 将应用程序池标识更改为本地系统
2. 在SQL Mgmt上>安全>登录
   1. 双击NT AUTHORITY \ SYSTEM
   2. 用户映射>检查您的数据库并在下面为其赋予角色。
   3. 还请记住使用正确的密码创建用户数据库或安全性登录名。

Answer 18

尝试使用以下方法测试解决方案时出现此错误

string cn = "Data Source=[servername];Integrated Security=true;Initial Catalog=[dbname];";

我解决的方法是：我必须打开Visual Studio并在另一个帐户下运行它，因为我用来打开的帐户不是我的管理员帐户。

因此，如果您的问题类似于我的问题：将VS固定到任务栏，然后使用Shift和右键单击打开菜单，以便您可以以其他用户身份打开VS。

Answer 19

这里有一些很好的答案，但是由于我刚刚花时间在解决这个问题上，希望这可以对某人有所帮助。

就我而言，一切都正常，然后由于问题中提到的错误而无故停止。

IIS作为网络服务运行，并且先前已在SQL Server上设置了网络服务（请参阅本帖子的其他答案）。服务器角色和用户映射看起来正确。

问题是；完全没有明显的原因；网络服务已在数据库中切换为“拒绝”登录权限。

要解决：

1. 打开SSMS>安全>登录。
2. 右键单击“ NT AUTHORITY \ NETWORK SERVICE”，然后单击“属性”。
3. 转到“状态”标签，并将Permission to Connect To Database Engine设置为“授予”。

Answer 20

我之前遇到同样的问题，从connectionstring中移除Persist Security Info=True对我有效。

Answer 21

事实证明，我的问题出在Visual Studio的“发布”设置中。我的appsettings.json连接字符串是正确的，但是发布设置中的数据库连接字符串已集成安全性= true。

Answer 22

我让 \MACHINE$ 帐户成为 SQL 服务器上 sysadmin 角色的一部分，但它没有帮助。服务器位于同一台计算机和 IIS 上。应用程序池标识设置为网络服务。

帮助我的是将应用程序池从集成模式更改为经典模式。

Answer 23

您可以使用网络服务或经过身份验证的用户。
然后给 Server Roles => public 和 sysadmin
然后给用户映射 => 选择你的数据库和
检查 public 和 db_owner。

Answer 24

我使用带有单独服务 ID (AD) 的 .NET Core 3.1 连接到数据库，它在 Visual Studio 2019 中运行，但不在测试或生产服务器中运行。

进行了以下对我有用的更改，还可以找到连接详细信息

"Server=ServerName;Database=dBName;Integrated Security=True;Trusted_Connection=True;User Id=DOMAIN\\ServiceId;Password=**********;MultipleActiveResultSets=True"

然后.. 使用在服务 ID 上运行的身份更改应用程序池。

enter image description here