【问题标题】:Windows Authentication Impersonation - Second request gets wrong user identityWindows 身份验证模拟 - 第二个请求获取错误的用户身份
【发布时间】:2017-03-20 08:10:08
【问题描述】:

我有以下架构:

Client1(Browser-App) -> Server1 (WebAPI/IIS) -> Server2 (WebAPI/IIS)

我将 ASP.NET 用于我的服务器端应用程序/api,用户应通过“Windows 集成身份验证”进行身份验证。

如您所见,从 server1 到 server2 有第二个跃点。如果两个 WebAPI 不在同一台服务器上,NTML 不支持第二个跃点。 所以我配置了一个 AD 域来支持“kerberos”。

它现在与第二个跃点一起工作。 我的 test-WebAPIs 像这样输出用户的身份:

server1: test.domain/user1
server2: test.domain/user1

但是如果我更改Client1上的登录用户并执行与“otherUser2”相同的请求,则只有第一跳获得正确的身份:

server1: test.domain/otherUser2
server2: test.domain/user1

在第二个跃点上显示第一个请求的旧用户。 我测试了多个场景:如果以下请求来自另一个 Windows 用户的客户端,则行为相同...

看起来第一个请求的 Windows 身份缓存在 server2 上...这对我来说是个大问题,我认为这应该是不可能的...如果在错误的用户上下文!

这是一个已知问题吗?我做错什么了吗? 有没有解决方案或更好的配置?

在第一个 ASP.NET WebAPI 上,我使用这样的模拟:

WindowsIdentity identity = (WindowsIdentity)HttpContext.Current.User.Identity;

            using (var wic = identity.Impersonate())
            {
                try
                {
                    WebClient c = new WebClient
                    {
                        UseDefaultCredentials = true
                    };
  • 我使用 .NET 的 WebClient 类。
  • 两台 IIS 服务器都配置了“协商”和“NTML”的“Windows 身份验证”。
  • Server1 是域控制器、DNS 和 DHCP 服务器 (+IIS)
  • Server2 只是安装了 IIS 的普通服务器。
  • 所有计算机都在同一个域中。

我无法向我解释这种行为......这对我来说毫无意义。为什么第一个传入请求的身份应该缓存在“server2”上? 如果我重新启动 IIS 并使用另一个 Windows 身份重新执行请求,这是“第一个工作请求”,其他人在“server2”上获得他的身份。

【问题讨论】:

  • 信息:服务器是“windows server 2012 R2”,IIS 的版本是 8
  • IIS AppPool 是否在 user1 下运行?
  • 它在具有委派权限和分配 SPN 的用户“模拟”下运行

标签: c# asp.net windows-authentication kerberos kerberos-delegation


【解决方案1】:

我找到了解决方案/问题。

这实际上是一个缓存问题...第一个用户的身份被缓存了。 您可以使用此“IIS 设置”更改此行为:

  • authPersistNonNTLM
  • authPersistSingleRequest

或者您在 API1 的 HTTP-Client 可以禁用 TCP-Connection 缓存:

  • 连接:关闭

而不是

  • 连接:保持活动状态

但我的场景中的实际问题是提琴手(一个 HTTP 代理工具)。 我在 API1 的 web.config 中将提琴手配置为代理。这使连接保持打开状态,并重用了第一个身份...

我希望我可以帮助其他人回答这个问题。

【讨论】:

    猜你喜欢
    • 2020-06-07
    • 2014-02-05
    • 1970-01-01
    • 2021-07-05
    • 1970-01-01
    • 2014-02-10
    • 1970-01-01
    • 2017-06-01
    • 2023-02-26
    相关资源
    最近更新 更多