由 dawei 在最近发生Outlook事件之后,我想知道如何最有效地解决以下问题：
假设一个相当典型的中小型AD基础设施：几个DC,一些内部服务器和Windows客户端,几个使用AD和LDAP进行用户身份验证的服务,来自DMZ(SMTP中继,VPN,Citrix等)和几个内部服务全部依赖于AD进行身份验证(Exchange,SQL服务器,文件和打印服务器,终端服务服务器).您可以完全访问所有系统,但它们有点太多(计算客户端)以单独检查.
现在假设,由于某些未知原因,一个(或多个)用户帐户由于密码锁定策略每隔几分钟就会被锁定.
>找到对此负责的服务/机器的最佳方法是什么？
>假设基础架构是纯粹的,标准Windows没有额外的管理工具,并且默认情况下几乎没有变化,那么找到导致这种锁定的过程是否可以加速或改进？
>可以采取哪些措施来提高系统对这种帐户锁定DOS的弹性？禁用帐户锁定是一个明显的答案,但随后您遇到了用户可以轻松利用密码的问题,即使执行复杂性也是如此.
添加我在答案中没有看到的东西.
What would be the best way to find the service/machine responsible for this ?
您不能只查看PDCe上的安全日志,因为虽然PDCe确实拥有有关整个域的帐户锁定的最新信息,但它没有关于从哪个客户端(IP或hostname)失败的登录尝试来自,假设失败的登录尝试发生在除PDCe之外的另一个DC上. PDCe会说“帐户xyz被锁定”,但如果失败的登录发生在域中的另一个DC上,它将不会从哪里说.只有实际验证登录的DC才会记录登录失败,包括客户端的地址. (也没有将RODC纳入此讨论.)
当您有多个域控制器时,有两种很好的方法可以找出失败的登录尝试的来源. Event forwarding,微软的Account Lockout Tools.
我更喜欢将事件转发到中心位置.将所有域控制器的登录尝试失败转发到中央日志记录服务器.然后,您只有一个地方可以在整个域中查找失败的登录信息.事实上,我个人并不喜欢微软的账户锁定工具,所以现在有一个好方法.
事件转发.你会爱上它的.
Assuming the infrastructure is pure,standard Windows with no additional management tool and few changes from default is there any way the process of finding the cause of such lockout could be accelerated or improved?
往上看.然后,您可以拥有监控系统,例如SCOM或Nagios或您使用的任何东西,梳理单个事件日志并用手机或其他任何东西炸毁您的手机.它并没有比这更快.
What could be done to improve the resilient of the system against such an account lockout DOS?
>用户教育.告诉他们停止设置Windows服务以在其域用户帐户下运行,在完成后注销RDP会话,教他们如何清除Outlook的缓存密码的Windows凭据库等.>使用托管服务帐户,以便用户不再需要管理这些用户帐户的密码.用户搞砸了一切.如果您给用户一个选择,他或她将总是做出错误的选择.所以不要给他们一个选择.>通过GPO强制执行远程会话超时.如果用户在RDP会话中闲置6小时,请将其启动.