LDS配置为遵守密码策略.当用户进行太多错误的密码尝试时,他的帐户被锁定,并且相应地设置了用户的lockoutTime属性.
但是lockoutTime并没有被复制为紧急.实际上,除非目录中的某处发生了其他更改,否则不会复制它.将复制lockoutTime属性.
这是一个(编辑过的Wireshark)跟踪.它显示正常的复制流量
No. Time Protocol Length Info 133 16:23:02 DRSUAPI 562 DsGetNCChanges request 134 16:23:02 DRSUAPI 3042 DsGetNCChanges response 152 16:23:17 DRSUAPI 562 DsGetNCChanges request 157 16:23:17 DRSUAPI 242 DsGetNCChanges response 230 16:24:57 DRSUAPI 562 DsGetNCChanges request 231 16:24:57 DRSUAPI 2930 DsGetNCChanges response 246 16:25:12 DRSUAPI 562 DsGetNCChanges request
在那之后,我锁定用户(使用FOR循环和ldifde).没有任何事情发生,直到我放弃并更改用户的描述属性,然后大约15秒后我看到复制通过.
1984 16:31:05 DRSUAPI 562 DsGetNCChanges request 1985 16:31:05 DRSUAPI 2930 DsGetNCChanges response
锁定时间和描述被复制.作为stated here,如果我设置lockoutTime = 0,则在15秒后进行常规复制!
我已启用replication diagnostics.实例的日志中没有显示任何内容,因为没有复制.当复制确实触发时,我看到一堆事件1239用于最新属性,两个1240事件.一个用于属性lockoutTime,另一个用于描述(我用于触发复制).
我启用了change notification between sites,重新启动了这两项服务,但它没有任何区别.也许是因为这两台服务器在同一个子网上.
Active Directory Technical Specification明确列出了lockoutTime as one of the urgent attributes to replicate.
什么可能阻止紧急复制lockoutTime属性?
这是AD-LDS中的错误(错误检查ID 354126).它影响Windows Server 2008,我不知道Server 2012.
问题是没有向副本发送通知(既不紧急也不正常).当帐户锁定存储在DB中时,LDS不会更新全局通知列表.因此,只有在计划的复制启动后才会进行复制.
repadmin /syncall localhost:389
解决问题的另一种方法是……什么都不做.该错误允许攻击者将猜测密码的机会增加一倍.它很难被利用,因为用户通常不直接调用LDS.即使他们这样做了,这个错误只会使他们的机会增加一倍.
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。