ASP.NET Core Kestrel应用gMSA账户Negotiate认证跨机401问题

核心场景 #

ASP.NET Core Web API以gMSA作为Windows服务运行在Kestrel上，启用Negotiate认证（无回退策略）。本地服务器发起请求时响应正常，但域内其他机器使用同一用户请求返回401未授权，已关闭所有机器防火墙且SPN配置符合微软官方文档要求。

可能的原因及解决方向 #

1. gMSA缺少Kerberos委派权限 #

跨机器的Kerberos认证要求服务账户（此处为gMSA）具备委派权限，允许其代表客户端用户完成身份验证流程。本地请求可能依赖Windows环回豁免机制或NTLM绕过了委派检查，但跨机器请求必须满足Kerberos委派要求：

• 打开AD用户和计算机控制台，找到目标gMSA账户，进入属性→委派选项卡
• 选择信任此用户委派到指定服务，添加对应的SPN（HTTP/server.domain.net）
• 测试环境可临时启用**信任此用户委派到任何服务（仅用于测试）**验证是否解决问题（生产环境禁止使用该选项）

2. Kestrel HTTPS证书配置不匹配 #

Kerberos认证对HTTPS证书的身份标识有严格要求，证书不匹配会导致票据验证失败：

• 确保证书的主体名称(CN)或SAN扩展字段包含请求URI中的server.domain.net
• 将证书导入客户端机器的「受信任根证书颁发机构」，确保客户端信任该证书
• 检查Kestrel的HTTPS配置，确认已正确绑定目标证书，避免因自签证书未被信任导致的认证失败

3. 客户端Kerberos票据异常 #

域内客户端机器可能未获取到有效的Kerberos票据，导致认证失败：

• 在客户端执行klist purge命令清除现有票据，重新登录后再次发起请求
• 在服务器执行setspn -L DOMAIN\gMSA账户名$（注意gMSA账户名后需加$），确认SPN列表包含HTTP/server.domain.net和HTTP/server

4. Negotiate认证未明确指定SPN #

Kestrel可能未正确关联gMSA的SPN，导致无法识别客户端发送的Kerberos票据：

• 修改认证配置，显式指定服务SPN：

builder.Services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
    .AddNegotiate(options =>
    {
        options.KerberosServicePrincipalName = "HTTP/server.domain.net";
    });

gMSA的凭证由AD自动管理，无需手动指定密码，此配置可确保Kestrel使用正确的SPN处理认证请求

5. 客户端DNS解析异常 #

客户端机器无法正确解析server.domain.net到服务器实际IP，会导致Kerberos票据请求失败：

• 在客户端执行nslookup server.domain.net，确认解析结果与服务器实际IP一致
• 若使用DNS别名访问服务，需确保别名对应的SPN也已注册到gMSA账户

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