客户端解锁缓慢故障解决方法

故障现象：
客户端管理员为保证客户端资源访问安全，设置了组策略中的“交互式登录：需要域控制器身份验证以进行解锁”。客户离开座位时习惯锁屏，正常情况下输入密码可以迅速恢复桌面，但个别需要等待30-60秒不等时间才能通过验证，影响了办公效率。

环境描述：
客户端大部分为XP系统，少量WIN7；AD父子域结构，子域负责客户端登陆验证，域控2003和2008系统混合，分属不同站点，客户端默认使用2003域控验证。

解决方法：在客户端上创建并设置以下注册表键值：
Path:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\ Kerberos\Parameters
Name: MaxPacketSize
Type: REG_DWORD
Value: 1

原因分析：
2003以后，AD使用Kerberos协议进行身份验证，分为TCP和UDP两种。在RFC 1510的规范下，XP客户端默认首先通过UDP发送数据包到域控KDC的88端口。而现在RFC4120逐渐取代1510，指定KDC必须接受TCP请求，默认下，vista和2008以后直接使用TCP
默认下，2003使用UDP数据包最大size为1465字节，而对于XP是2000字节，TCP用于超过此最大值的情况，可以通过修改注册表更改UDP包最大值。XP客户端向2003域控提交验证数据包时，首先使用UDP，数据包大小根据用户账户而大小不一，其中影响较大的是SID历史记录和组成员身份（故障的用户账户大部分是经常用于组测试的，即反复从不同的组中添加删除，判断这是造成上述的SID历史记录庞大的原因）。当超过最大值，系统将数据包分段打包发送，由于UDP天生不可靠性，到底目的地无序而且没有完整性检验的反馈，最后结果就是丢包。这一切客户端无从得知，只能干等，隔一定时间后重新发送UDP以及后续改用TCP才成功验证。
注册表中的MaxPacketSize=1可以强制客户端使用TCP发送kerberos数据包，由于面向连接所以不会丢包（注意，vista和2008以后默认MaxPacketSize=0，但事实上已经强制使用TCP了），这样就解释了为什么XP/WIN7/SERVER2003/2008不同组合会有不同的登陆结果