ASP.Net Web 应用程序尝试使用模拟和委派连接到 SQL Server

发布于 2024-08-18 11:22:57 字数 662 浏览 1 评论 0 原文

我正在尝试在 Intranet ASP.Net Web 应用程序中使用模拟和委派,以便将经过身份验证的用户凭据传递到 SQL Server。

Web服务器和SQL服务器是两台独立的机器,但在同一个域中,因此需要委派。

我已完成以下操作:

  • 在我的网络应用程序中设置 网络配置。
  • 在 Active Directory 中启用从 Web 服务器到 SQL Server 上的 MSSQLSvc 服务的约束委派。
  • 通过 IIS 在网站中仅启用 Windows 身份验证。

显然这一切都应该有效,但事实并非如此(SQL Server 拒绝匿名用户的访问 - “用户'NT AUTHORITY\ANONYMOUS LOGON'登录失败”)。

在 IIS7 中,应用程序池设置为使用集成管道模式并使用 NetworkService Identity 运行。该网站仅启用了 Windows 身份验证,扩展保护处于关闭状态,启用了内核模式身份验证,并且 NTLM 是提供程序。

我读过的所有网页似乎都表明我的设置应该有效。我缺少什么?

I'm trying to use Impersonation and Delegation in an intranet ASP.Net web-app in order to pass authenticated users' credentials onto a SQL Server.

The web server and SQL server are two separate machines, but in the same domain, so Delegation is required.

I've done the following:

  • set <authentication mode="Windows"/> and <identity impersonate="true"/> in my web-app's web.config.
  • enabled Constrained Delegation from the web server to the MSSQLSvc service on the SQL Server, in Active Directory.
  • enabled only Windows Authentication in the website, through IIS.

Apparently this should all work, but it doesn't (the SQL Server is denying access to the anonymous user - "Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'").

In IIS7, the Application Pool is set to use Integrated Pipleline Mode and is running with the NetworkService Identity. The website only has Windows Authentication enabled, Extended Protection is Off, Kernel-mode authentication is enabled, and NTLM is the provider.

All the web pages I've read seem to indicate that my setup should work. What am I missing?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

淡紫姑娘! 2024-08-25 11:22:57

我找到了答案:

IIS7 中的 Windows 身份验证提供程序必须设置为“Negotiate:Kerberos”,而不是 NTLM。这意味着必须禁用内核模式身份验证设置。这似乎没问题。我认为我的说法是正确的,即使用自定义身份(即一个特定身份)时需要内核模式身份验证。委派可以使用任意数量的身份。所以一切都很好。

我也写了一篇关于此的博客文章 ,其中有更详细的内容。

I've discovered the answer:

The Windows Authentication provider in IIS7 must be set to Negotiate:Kerberos, not NTLM. This means that the Kernel-mode authentication setting must be disabled. This seems to be fine. I think I'm right in saying that Kernel-mode authentication is required when using a custom identity, i.e. one specific identity. Delegation can use an arbitrary number of identities. So all is well.

I've written a blog post about this too, which goes into a bit more detail.

何止钟意 2024-08-25 11:22:57

不 - 说您需要 Kerberos(SPN)来信任服务器进行委派是不准确的,而且这是唯一的方法。是的,这是一种方法(并且您确实需要所有这些方法才能通过 Kerberos 实现),但它不是唯一的方法,甚至不是技术上最安全的方法或最简单的方法。您是否真的需要进行额外的配置并为每个 Web 用户在 SQL 中创建数据库的登录名?如果这些帐户中的任何一个被盗怎么办?更多的账户,更多的漏洞。

不,而是创建一个域服务帐户,并让它访问 SQL。如果您的安全人员锁定了某些内容,请授予该用户以下权限:作为服务登录、作为批处理作业登录和允许本地登录。或者,如果这只是为了开发和测试理论,或者您不关心或找不到设置,或者稍后仍然遇到错误,这可能不会得到大量关注,但给它本地管理员(有时您必须做你必须做的事情 - 一些安全专家将事情锁定得比我想写的更严格 - 以后总是可以排除安全故障以将其重新锁定)。然后将该帐户设置为应用程序池上的自定义帐户,并在 SQL 中为该帐户提供登录名。就在那个数据库上给它 dbo。

在IIS中的网站上,将身份验证类型设置为Windows。我在其他博客中看到他们说“基本”,因此 Kerberos 可以工作,但 NTLM 使用 Windows 身份验证。在 IIS 7 中,您可能还想启用 ASP .NET 模拟。就我个人而言,我只在 IIS 6 上尝试过此操作,但原理是相同的。

在 web.config 中,将其添加到 下,它是 的“对等”:

<connectionStrings>
  <add 
     name="NorthwindConnectionString" 
     connectionString="Data Source=serverName;Initial 
     Catalog=Northwind;Integrated Security=SSPI;User 
     ID=userName;Password=password"
     providerName="System.Data.SqlClient"
  />
</connectionStrings>

并且在

<authentication mode="Windows"/> 
<identity impersonate="true"
      userName="domain\user" 
      password="password" />

然后将字符串读入您的应用程序,如下所示:

using System.Configuration;

string connString = String.Empty;
if (ConfigurationManager.ConnectionStrings.ConnectionStrings.Count > 0)
{
    connString = ConfigurationManager.ConnectionStrings["NorthwindConnectionString"].ConnectionString; 
    if (connString != null) // do DB connection stuff here
        Console.WriteLine("Northwind connection string = \"{0}\"",
        connString.ConnectionString);
    else
        Console.WriteLine("No Northwind connection string");
}

请参阅 http://msdn.microsoft.com/en-us/library/ms178411.aspx

如果在模拟标记和 SQL 连接的 web.config 中填写该帐户后,它无法与服务帐户连接,则可以使用 WindowsImpersonationContext (http://msdn.microsoft.com/en-us/library/system.security.principal.windowsimpersonationcontext.aspx< /a>)。具体来说,您在获取令牌后需要 wic.Impersonate() 和 wic.Undo() 。您可以从 web.config 中以 AppKeys 的形式读取服务帐户域、名称和密码。

简而言之,有一些方法可以解决这些问题。您甚至可以在 web.config 中加密密码 - 都在 ConnectionString 中,如果您想将其存储在 AppKey 中而不是直接存储在“模拟”标记中,如果您不希望其中有纯文本密码(其中我建议反对),因此如果您需要使用模拟方法(就像我所做的那样),您可以使用它来创建登录令牌。

No - it is not accurate to say you need Kerberos, an SPN, to trust the server for delegation, and that this is the ONLY way to do it. Yes, this is one way to do it (and you do need all of it to make it happen via Kerberos), but it is not the ONLY way, or even technically the most secure way or easiest way. Do you really want to have to do extra configurations and create a login for every web user to your DB in SQL? What if any one of those accounts is compromised? More accounts, more vulnerabilities.

No, create a Domain service account, instead, and let that access SQL. If your security guys lock down things, give that user these rights: Logon as a service, Logon as a batch job, and Allow logon locally. Or, if this is just to develop and test the theory or you don't care or can't find the settings or are still getting errors later on, and this might not get a large following, but give it local Admin (sometimes you gotta do what you gotta do - some security pros lock down things tighter than I would care to write about - can always troubleshoot security later to lock it back down). Then set that account as the custom account on the app pool and give that account a login in SQL. Give it dbo on just THAT ONE database.

On the website in IIS, set the authentication type as Windows. I've seen them say "Basic" in other blogs so Kerberos will work, but NTLM uses Windows authentication. In IIS 7, you may also want to enable ASP .NET impersonation. Personally, I've only tried this on IIS 6, but the principal is the same.

In the web.config, add this under <configuration>, which is a "peer" to <system.web>:

<connectionStrings>
  <add 
     name="NorthwindConnectionString" 
     connectionString="Data Source=serverName;Initial 
     Catalog=Northwind;Integrated Security=SSPI;User 
     ID=userName;Password=password"
     providerName="System.Data.SqlClient"
  />
</connectionStrings>

And in <system.web>:

<authentication mode="Windows"/> 
<identity impersonate="true"
      userName="domain\user" 
      password="password" />

Then read the string into your app like this:

using System.Configuration;

string connString = String.Empty;
if (ConfigurationManager.ConnectionStrings.ConnectionStrings.Count > 0)
{
    connString = ConfigurationManager.ConnectionStrings["NorthwindConnectionString"].ConnectionString; 
    if (connString != null) // do DB connection stuff here
        Console.WriteLine("Northwind connection string = \"{0}\"",
        connString.ConnectionString);
    else
        Console.WriteLine("No Northwind connection string");
}

See http://msdn.microsoft.com/en-us/library/ms178411.aspx.

If it will not connect with the service account after filling in that account in the web.config for the impersonate tag and the SQL connection, you can then use impersonation methods using WindowsImpersonationContext (http://msdn.microsoft.com/en-us/library/system.security.principal.windowsimpersonationcontext.aspx). Specifically, you want wic.Impersonate() and wic.Undo() after getting their token. You can read in the service account domain, name, and password from the web.config, in the form of AppKeys.

In short, there are ways around the issues. You can even encrypt the password in the web.config - both in the ConnectionString, and if you want to store it in an AppKey instead of directly in the "impersonate" tag, if you don't want plain text passwords in there (which I'd recommend against), and so you can have it for the creation of a Logon token, if you need to use the Impersonation methods (as I did).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文