Windows Authentication经透明代理后失效的原因及解决办法

问题原因 #

直接访问https://myapp.domain.com时，客户端的Kerberos认证会向域控制器请求HTTP/myapp.domain.com这个服务主体名称（SPN）对应的服务票据，IIS服务器的运行账户因为已注册该SPN，能正常解密票据完成认证。

但通过https://proxy.domain.com转发时，客户端会基于请求的Host头（透明代理通常保留原Host头为proxy.domain.com），向域控制器请求HTTP/proxy.domain.com的服务票据。如果IIS服务器的运行账户未注册这个SPN，就无法解密该票据，导致认证失败。

另外需要注意：NTLM认证无法跨代理传递委托，而Windows认证默认优先使用Kerberos，这也是代理场景下认证失效的核心诱因。

是否需要注册HTTP/proxy.domain.com的SPN？ #

是，必须在IIS服务器的运行账户（应用池账户或机器账户）上注册HTTP/proxy.domain.com这个SPN，这样域控制器才会把该SPN对应的服务票据颁发给客户端，IIS服务器才能正常解密并完成认证。

具体解决步骤 #

1. 确认IIS应用池运行账户

   • 如果应用池使用Network Service或Local System，对应的域账户为机器账户，格式是域\机器名$（比如CONTOSO\MYAPP-SRV$）
   • 如果使用自定义域账户，直接记录该账户名（比如CONTOSO\IISAppPoolAcct）

2. 注册SPN
   使用域管理员权限打开命令提示符，执行对应命令：

   • 机器账户场景：

     setspn -S HTTP/proxy.domain.com CONTOSO\MYAPP-SRV$
     

   • 自定义域账户场景：

     setspn -S HTTP/proxy.domain.com CONTOSO\IISAppPoolAcct
     

   （-S参数会自动检查SPN是否已存在，避免重复注册导致Kerberos故障）

3. 验证SPN注册结果
   执行以下命令查看目标账户已注册的SPN，确认HTTP/proxy.domain.com已存在：

   setspn -L CONTOSO\目标账户名
   

4. IIS与代理配置检查

   • 确保IIS的Windows认证已启用Kerberos（默认已启用，可在IIS管理器→站点→认证→Windows认证→高级设置中确认）
   • 确认透明代理未修改请求的Authorization头，且正确转发所有Kerberos相关的请求头（如Authorization、WWW-Authenticate）

5. 客户端侧验证
   确保客户端机器已加入域，UseDefaultCredentials = true配置正确，且proxy.domain.com的DNS解析正常。

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