必须先精准识别NTLM使用场景再分阶段禁用：查安全日志ID 4624（Logon Type 3+NTLM）、域控注册表NTLM强度设置、硬编码点；GPO按“审计→限制入向→全域禁止”三步走；Kerberos需确保时间同步、DNS正反解、SPN正确注册并验证票据与抓包。

怎么快速摸清哪些服务还在用NTLM

盲目禁用等于自断手脚。必须先知道谁在用、为什么用、能不能改——否则iis突然401、sql server连不上、老旧.net后台直接白屏，都是分分钟的事。

关键不是“有没有NTLM”，而是“谁在什么场景下非用不可”：

• 查安全日志：ID 4624事件中，Logon Type为3且Authentication Package是NTLM的，基本就是网络认证行为；重点关注时间集中、来源IP固定、目标服务名明确的条目
• 看域控注册表：HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0下的NtlmMinClientSec和NtlmMinServerSec值，能反映当前最低允许的NTLM强度（比如是否还容忍LM或NTLMv1）
• 盯住硬编码点：老系统里写死auth=NTLM的Web.config、PowerShell脚本里调用Invoke-WebRequest -Credential却没加-UseDefaultCredentials、第三方设备管理界面直连http://ip/admin而非FQDN——这些才是迁移卡点

GPO里怎么设NTLM策略才不翻车

策略不是一锤子买卖。微软自己都分三阶段推进，你直接开Deny all，90%概率第二天早上收告警邮件。

正确做法是“先看见、再限制、最后堵死”：

• 第一周：把Network security: Restrict NTLM: NTLM authentication in this domain设为Audit all，同时开启Event Viewer → Security里的详细审核策略（Object Access → Audit Sensitive Privilege Use），让日志说话
• 第二步：确认无误后，先动接收端——把Network security: Restrict NTLM: Incoming NTLM traffic设为Deny all，这能拦住外部发起的NTLM连接，但不影响本机出向Kerberos
• 最后一步：等所有服务票据正常、klist tickets能看到HTTP/SQL服务票据了，再把域级NTLM策略切到Deny all

注意：Domain controller: Allow server operators to schedule tasks这类权限策略别被误关，它和NTLM无关，但GPO批量启用时容易顺手勾上。

Kerberos跑不通？80%问题不在协议本身

Kerberos不是装完AD就自动好使的。它极度依赖三件事：时间、DNS、SPN。缺一个，kinit或klist看起来正常，但实际访问服务就0x80090322（KDC_ERR_S_PRINCIPAL_UNKNOWN）或0x80090315（SEC_E_INVALID_TOKEN）。

• 时间偏差＞5分钟？w32tm /resync /force强制同步，客户端和服务端都要指向同一PDC仿真器，跨国VPS尤其要注意时区和NTP源延迟
• DNS正反解失败？nslookup web01.contoso.com要返回IP，nslookup 192.168.1.100（服务端IP）必须能反解出web01.contoso.com，否则KDC拒绝签发服务票据
• SPN漏注册？setspn -S HTTP/web01.contoso.com CONTOSO\websvc——-S参数会先查重再注册，避免重复SPN引发票据拒绝；别用HTTP/web01这种短名，Kerberos只认FQDN

怎么验证真的迁成功了，而不是“看起来可以”

别信IE能打开网页就叫Kerberos成功。真实业务流量可能走的是另一套通道，比如PowerShell远程、SQL Server Management Studio直连、甚至Windows服务后台调用。

• 客户端执行klist tickets，重点看是否有krbtgt/CONTOSO.COM（TGT）和HTTP/web01.contoso.com（服务票据）；没有后者，说明应用根本没尝试Kerberos
• 抓包验证：Wireshark过滤kerberos && ip.addr == 域控IP，确认有AS-REQ/AS-REP（取TGT）和TGS-REQ/TGS-REP（取服务票据）交互；如果只有TCP三次握手+HTTP 401+Negotiate头来回，但没Kerberos ASN.1数据，那就是降级到了NTLM
• 服务端查日志：IIS里开Failed Request Tracing，SQL Server启SQL Server Profiler跟踪Security Audit → Audit Login事件，看Authentication Method字段是不是Kerberos

最容易被忽略的是：某些.NET应用用了HttpClientHandler.Credentials = CredentialCache.DefaultNetworkCredentials，看似走系统凭据，但若没配IE信任站点或没开Negotiate，它仍会悄悄fallback到NTLM——得靠抓包或服务端日志才能揪出来。