客户端解锁缓慢故障解决方法-阿里云开发者社区

开发者社区> 安全> 正文
登录阅读全文

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

简介:

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

环境描述:
客户端大部分为XP系统,少量WIN7AD父子域结构,子域负责客户端登陆验证,域控20032008系统混合,分属不同站点,客户端默认使用2003域控验证。

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

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


本文转自天鬼皇 51CTO博客,原文链接:http://blog.51cto.com/ghostlan/1300000,如需转载请自行联系原作者


版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
+ 订阅

云安全开发者的大本营

其他文章