更换IIS应用池身份后SSO失效，咨询两种身份对SSO的差异

这问题我之前帮客户排查过类似的，核心差异其实就藏在身份验证协议支持和AD委派配置里，咱们一步步拆解清楚：

1. Kerberos SPN的自动注册差异 #

• 默认应用池身份（比如ApplicationPoolIdentity或Network Service）：
  这些内置账户属于本地机器身份，IIS会自动帮它们在AD里注册对应的SPN（服务主体名称）——这可是Kerberos SSO的关键前提。客户端访问时，浏览器能自动通过Kerberos协商传递当前用户的凭据，自然就实现了SSO。
• 自定义AD域账户：
  域账户不会自动注册SPN！如果没给这个AD账户绑定网站对应的SPN（比如HTTP/your-web-server.domain.com和HTTP/your-web-server），Kerberos协商直接失败，浏览器就会 fallback 到NTLM。而NTLM在很多内网环境下不会自动传递凭据，登录框就弹出来了。

2. 委派权限的本质区别 #

• 默认身份：
  Network Service本身是机器账户的一部分，默认就有一定的委派权限（比如允许代表客户端访问本地资源），IIS也会自动处理部分委派配置，不用你手动在AD里折腾。
• 自定义AD账户：
  你需要这个账户代表客户端去访问带ACL授权的AD属性，那必须在AD里给它配置约束委派——得明确允许它针对AD的LDAP服务（比如ldap/domain-controller.domain.com）做委派。没这个权限的话，Kerberos根本完成不了委托流程，自然要让你手动输凭据。

3. 本地安全上下文的差异 #

• 默认身份：
  ApplicationPoolIdentity默认属于IIS_IUSRS组，IIS会自动为它创建合适的本地安全上下文，处理Windows认证时能无缝对接Kerberos/NTLM的管道。
• 自定义AD账户：
  虽然你把它加进了IIS_IUSRS，但它是域身份，本地权限得额外配置。比如得确保这个账户有服务器本地登录的权限（默认域用户可能没有），而且IIS的Windows认证模块得能正确识别这个域账户的身份，才能顺利传递客户端的凭据。

• 先查SPN：在域控制器上跑命令 setspn -L your-ad-account，看看有没有对应网站的HTTP开头的SPN。没有的话用 setspn -A HTTP/your-web-server your-ad-account 和 setspn -A HTTP/your-web-server.domain.com your-ad-account 补上。
• 再查AD委派：打开AD用户和计算机，找到你的AD账户，右键→属性→委派选项卡，选“信任此用户委派指定的服务”，然后添加域控制器的ldap服务。
• 验证本地权限：通过服务器的本地安全策略→本地策略→用户权限分配→允许本地登录，把你的AD账户加进去。
• 检查IIS设置：在网站的Windows认证模块里，确保启用Kerberos，同时禁用“启用内核模式认证”（自定义AD账户用内核模式容易出身份上下文冲突）。

内容的提问来源于stack exchange，提问作者Fred.G