sql-server - 哪个用户用于与 SQL Server 的可信连接 - IIS/ASP.NET

Question

首先介绍一下背景。我有一个 ASP.NET 应用程序，位于我们网络上的 DMZ 中。它需要访问位于我们可信网络中的计算机上的 SQL Server 实例。我将调用 Web 服务器 WebServer1 和示例 SQL Server SqlServer1。

目前，我们的网络服务器正在使用包含用户 ID 和密码的连接字符串。这并不理想，我们希望使用 Windows 身份验证来连接到数据库。

为此，我在域中设置了一个用户帐户和密码，我将其命名为 MyDomain\WebApp。我将站点应用程序池的身份设置为这个新帐户，并将站点的匿名身份验证设置为使用应用程序池的身份。

但是，当我尝试更改连接字符串时，将 UserID=fakeuser、Password=fakepass 替换为 Trusted_Connection=Yes，从 Web 应用程序启动数据库调用结果出现错误消息

Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.

编辑:这是 SQL Server 错误日志中的完整错误消息:

SSPI handshake failed with error code 0x8009030c, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure. The logon attempt failed [CLIENT: ]

Error: 18452, Severity: 14, State: 1.

Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. [CLIENT: ]

为了了解发生了什么，我想我应该设置一个简单的页面来告诉我当前用户在工作进程上的身份。这是我遇到非常奇怪的结果的地方。以下是结果以及给出的服务器变量(用上面提到的名字替换真实姓名)

1. WebServer1\WebApp = WindowsIdentity.GetCurrent().Name
2. WebApp = Environment.UserName
3. MyDomain\WebApp = pool.ProcessModel.UserName
4. WebServer1\WebApp = Request.LogonUserIdentity.Name

1 和 4 非常奇怪，并且不作为 Web 服务器上的用户帐户存在。只有#3 返回了在站点的 IIS 应用程序池中看到的正确值。这是使用以下 SO 答案的评论中的方法获得的:https://stackoverflow.com/a/10101417/711674 。

我的假设是，当服务器尝试对 SQL Server 实例进行身份验证时，这不是实际使用的帐户，并且正在使用其他值之一，从而导致出现上述错误消息。

Answer 1

有一篇关于此事的好文章 here 。简而言之:

You need to answer on two main questions:

1. What was the authentication mode for IIS? (Anonymous authentication? Windows authentication? Both?)

2. Was impersonation for the FastCGI module on or off? (i.e. Was the fastcgi.impersonate setting in my php.ini file set to 0 or 1?)

A. IIS Anonymous Authentication enabled and fastcgi.impersonate = 1:

Because I was connecting to IIS anonymously, the built-in anonymous account (which is NT AUTHORITY\IUSERby default in IIS 7.0+) was impersonated. So, my connection attempt failed because this identity does not map to a valid login on my server.

B. IIS Anonymous Authentication enabled and fastcgi.impersonate = 0:

Because impersonation was off, my identity was not used as the identity of the PHP process. Instead, the actual identity of the PHP process was used in the connection attempt. In IIS 7.5, the identity of the PHP process depends on the identity of the application pool it is running in. In this case, PHP was in the default application pool and the identity used in the connection attempt was IIS APPPOOL\DefaultAppPool (so my connection attempt failed).

C. IIS Windows Authentication enabled and fastcgi.impersonate = 1:

With Windows authentication enabled (and Anonymous Authentication disabled), I connected to IIS with the identity that my Web browser was running under (Microsoft\brian.swan, the identity I logged in with). And, with impersonation on, the PHP process ran under the Microsoft\brian.swan identity. So, since that identity mapped to a valid login on my server, my connection attempt succeeded.

D. IIS Windows Authentication enabled and fastcgi.impersonate = 0:

The results here were the same as with Anonymous authentication enabled and fastcgi.impersonate =0 (the connection attempt failed). The only difference occurred when I requested the page from the Web server: a pop-up window asked for my identity when I requested the page.

E. Both Anonymous and Windows Authentication enabled:

Web browsers will try to access a Web server by using anonymous authentication first. So, if both Anonymous and Windows Authentication are both enabled, the results will be the same as those above where Anonymous Authentication is enabled (A and B).