关于Service Fabric反向代理的Windows身份验证配置问询

我明白你的需求——已经在Service Fabric上跑起来的Asp.Net Core 2.0应用，直接用服务器IP+端口访问时Windows身份验证正常，但想切换到通过Service Fabric反向代理来访问，同时还不想丢了Negotiate带来的自动登录体验。下面是具体的实现步骤和关键注意事项：

1. 配置Service Fabric反向代理传递身份凭据 #

Service Fabric反向代理默认不会转发Windows身份验证的相关信息，所以第一步必须修改集群配置，开启凭据传递能力：

• 打开集群的ApplicationManifest.xml，找到对应反向代理服务的<ServiceManifestImport>节点，添加如下配置覆盖：

<ConfigOverrides>
  <ConfigOverride Name="Config">
    <Settings>
      <Section Name="ReverseProxy">
        <Parameter Name="EnableWindowsAuthPassThrough" Value="true" />
        <Parameter Name="AuthForwardMode" Value="PassThrough" />
      </Section>
    </Settings>
  </ConfigOverride>
</ConfigOverrides>

• 这里EnableWindowsAuthPassThrough设为true是核心，它允许反向代理把客户端的Windows身份验证令牌传递给后端的Asp.Net Core服务；AuthForwardMode设为PassThrough则表示直接转发身份验证请求，不做额外处理。

2. 确认Asp.Net Core应用的身份验证配置无误 #

虽然你已经开启了NTLM和Negotiate，但还是要再核对下应用端的配置，确保和反向代理的配置兼容：

• 在Startup.cs的ConfigureServices方法中，确保正确注册Windows身份验证服务：

// 如果是托管在IIS环境下
services.AddAuthentication(IISDefaults.AuthenticationScheme);

// 如果是自托管模式（Service Fabric通常用这个）
services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
        .AddNegotiate()
        .AddNtlm();

• 紧接着在Configure方法里，要把身份验证中间件放到授权中间件之前：

app.UseAuthentication();
app.UseAuthorization();

• 另外，检查部署配置（比如launchSettings.json或者Service Fabric的服务配置），确保windowsAuthentication设为true，anonymousAuthentication设为false，避免匿名访问干扰：

"iisSettings": {
  "windowsAuthentication": true,
  "anonymousAuthentication": false
}

3. Kerberos测试的额外注意点 #

如果你正在测试Kerberos协议，通过反向代理访问时还有几个关键细节要处理：

• 给Service Fabric反向代理的服务账户注册正确的SPN（服务主体名称）。比如你的反向代理域名是sf-proxy.yourdomain.com，需要在域控制器上执行：

setspn -A HTTP/sf-proxy.yourdomain.com YOURDOMAIN\ProxyServiceAccount

• 同时，你的Asp.Net Core应用的服务账户也需要注册对应的SPN，并且要配置约束委派，允许反向代理将客户端的身份委派给后端服务，否则Kerberos的身份传递会失败。
• 客户端机器必须加入域，并且信任反向代理和后端服务的SPN，否则自动登录会失效， fallback到NTLM或者手动输入凭据。

4. 验证Negotiate自动登录是否正常 #

要确认Negotiate带来的自动登录体验没有丢失，可以做以下检查：

• 用域内的客户端机器访问反向代理的URL，浏览器应该自动使用当前登录的域账户完成身份验证，不需要弹出登录框。
• 用Fiddler抓包查看请求头，确认存在Authorization: Negotiate [令牌内容]的字段，这说明Negotiate协议在正常工作。
• 如果出现登录框，大概率是Kerberos配置有问题，此时系统会自动 fallback到NTLM，你可以检查客户端和服务器的域信任关系，或者SPN配置是否正确。

5. Basic身份验证的兼容处理 #

如果你同时在测试Basic身份验证，需要注意：

• Basic身份验证的凭据是Base64编码的明文，必须配合HTTPS使用，否则会有凭据泄露的风险。
• 在Asp.Net Core中添加Basic身份验证支持时，要注意设置优先级，确保Negotiate/NTLM优先触发，Basic只作为 fallback选项，这样不会影响自动登录体验。

内容的提问来源于stack exchange，提问作者Adam Schiavone