我是最终用户，而不是 IT 专业人员。不幸的是，我的公司资源无法解决这个问题。我正在寻找一些建议给他们。
在过去的四个月里，我在公司网络上平均每天被锁定 2-3 次帐户。我已经度过了没有问题的日子，并且在一天内被锁定了 7 次。在过去的 8 年里，我曾两次被拒之门外。
每次锁定都需要致电我们的公司服务台以解锁我的帐户。发生锁定是因为我们的安全系统“认为”我正在尝试使用无效凭据（错误密码）重复进行身份验证。
迄今为止，极其繁琐的调试过程的全部细节都在我的博客文章中：http: //tech.kateva.org/2009/05/debugging-network-account-lockouts.html。
大约一周前，我破解了 Outlook 2007，我的锁定消失了。代价是我必须在 Outlook 客户端连接到 Exchange 服务器的每一“天”第一次手动验证（域/用户名和密码）。烦人，但我可以忍受。
自从我开始这个过程以来，我的笔记本电脑已经焕然一新。我有一个带有原始公司标准磁盘映像的新硬件，并且我回到了 Outlook 2003。我也回到了被锁定状态！
所以我不认为问题出在我的笔记本电脑上。
在进一步调查中，我发现如果我发送 Outlook 2003 总是请求我没有被锁定的凭据。
所以我需要了解身份验证过程的不同之处
一个。Outlook 连接到 Exchange 并使用与我的用户帐户（NTLM 网络域/un 和 pw）关联的凭据自动进行身份验证（标准行为）。
湾。Outlook 连接到 Exchange，我必须手动输入我的网络 un 和 pw。
不知何故，“b”工作正常。但是，我认为，使用进程“a”Exchange Server（我们的 Outlook？）正在向 Active Directory 发送错误的凭据，导致我被锁定。
我怀疑我的 Active Directory 帐户和/或 Exchange Server 邮箱配置错误。
我需要向我们的帮助台和安全台提供他们可以在 Active Directory 或 Exchange Server 上调查的内容的良好列表。如果我不能这样做，我将需要获得一个新的公司 ID 并放弃我现有的用户 ID。
我想如果我能指出他们正确的方向，并给他们非常精确的指导，他们就能解决这个问题。
任何建议都会有所帮助。我可能只需要研究 NTLM (AD) 身份验证如何处理 Exchange Server 请求。
在我过去工作的一个大型组织中，我们遇到了帐户锁定问题。
我所做的（作为 IT 组织的成员）是构建一个位于 PDC（现在的 PDC 仿真器）上的脚本。每当帐户被锁定时，此域控制器都会在安全日志中注册事件 ID # 644（Windows Server 2008 上为 4740）。该事件还包括上次尝试使用不正确密码登录的客户端计算机的名称。所以我的脚本每 5 分钟轮询一次安全日志，并将这些数据发布到帮助台可以访问的网页上。
一旦我们有了这个，改变帮助台的工作流程以在遇到帐户锁定问题时检查该页面，然后帮助用户发现导致锁定的机器上的内容是一件小事。正如您在博客文章中指出的那样，罪魁祸首通常是第二台计算机，用户在从主计算机更改密码时忘记了他们已登录。通常，第二台机器将运行 Outlook，或者通过用户的（现在已过期）凭据映射驱动器。
并且当帮助台在他们的日子里休息时，他们可以主动检查这个网页，并为那些还不知道自己已经成为帐户锁定受害者的人解决问题。
如果对这个脚本感兴趣，我可以把它挖出来，掸掉，然后贴在这里。
我假设您用于 Exchange 的用户名、密码和域与您登录计算机时使用的凭据相同。
如果重新安装企业 SOE 后问题再次出现，并且仅发生在您身上……您是否有漫游配置文件，或者您的设置是否以任何其他方式推送到网络位置？如果是这样，那将解释为什么问题会在工作站刷新后出现。您的博客文章说您将数据“恢复”到您的新国有企业。你确定你没有恢复有问题的应用程序吗？
卸载您可能已添加到 Outlook 2003 的任何插件，以及您在收到新 SOE 后对其进行的任何其他非标准自定义（例如，不是您的 IT 部门为您安装的）自定义。
大多数情况下，我看到这是因为有人将他们的旧凭据留在了计划任务或锁定的远程桌面会话中。您可以尝试使用 Wireshark 和 Sysinternals 工具的组合来识别导致锁定的计算机上的违规进程（假设它来自您的计算机）。
更新
Microsoft 的此链接可能会帮助您和/或您的 IT 团队解决此问题。
[解决帐户锁定问题]( http://technet.microsoft.com/en-us/library/cc773155(WS.10).aspx "Microsoft Technet")
再次从 IT 的角度来看，另一个答案是重新考虑帐户锁定策略。
锁定策略设置在 10 分钟内 10 次错误登录尝试会导致完全锁定，直到管理员重置帐户，这种情况并不少见。不仅如此，如此低的限制使您容易受到简单的拒绝服务 (DoS) 攻击：BadGuy(TM) 只需使用 10 个错误密码，现在他已锁定帐户。想象一下这发生在 500 个帐户上！我已经看到了：这不好玩。更糟糕的是，想象一下它对您的所有管理员帐户都进行了！
我的论点是，只要安全风险的增加很小，这个限制就可以大大放宽。
暴力破解密码，即使密码非常简单，也需要数千或数百万次尝试才能获得成功的机会。那么为什么不考虑一个允许在 5 分钟内尝试 50 次登录，然后在 5 分钟后自动重置的密码策略呢？以这个速度（每 5 分钟尝试 50 次），大多数暴力破解脚本会简单地放弃，但大多数粗略的 DoS 尝试不会达到限制。那些确实知道帐户在 5 分钟后解锁并允许再尝试 50 次的暴力脚本将被限制为每天 7200 次尝试。当然，您可以随意调整限制。
我要回答我自己的问题。即使在重新启用 Outlook 直通身份验证之后，我也没有被锁定一个多星期，所以即使没有明确的治疗方法，我也可以报告我把东西放在哪里了。
提醒一下，上次我被锁在门外时，我刚刚收到了一台全新的笔记本电脑，上面有全新的企业形象。
我做的最后两件事是：
我非常感谢 Neobyte 提供给 Microsoft 修改后的故障排除页面的链接：
http://technet.microsoft.com/en-us/library/cc773155%28WS.10).aspx
我留下了一些心理创伤。鉴于与 Microsoft 的身份验证服务及其大量遗留黑客相关的令人震惊的各种问题，以及与分布式身份验证和身份验证锁定等事后安全功能的交集，我现在对使用任何新的或新颖的公司网络都非常保守或“云”计划。它们需要建立在比 Microsoft 提供的更强大的基础架构上，并且需要 IT 资金和 IT 重组才能实施。
困扰我的一件事是 DC 上的时间同步问题的可能性，并且可能是您的工作站阻碍了 Kerberos。糟糕的时间会导致登录失败，这会导致锁定。命令“w32tm”可以帮助您诊断您的工作站是否正在偏离 DC 或 Exchange 服务器（或彼此）的时间。你不需要任何特殊的权限来检查我相信的那个命令。
我猜手动 Outlook 登录正在启动一个全新的登录会话，而不是尝试重用您在登录桌面会话时获得的令牌。无论出于何种原因，这并没有像桌面登录那样变得陈旧。
我接下来要查找的是可疑的事件日志条目，但我认为这已经完成了。不幸的是，我无法描述“可疑”会是什么样子。我会比较一个正常的直通登录到 Exchange 和你失败的登录，如果不明显的话，我会开始用谷歌搜索差异。:}
不久前，我们遇到了一个用户帐户反复锁定的问题。原来他曾尝试通过 IMAP 客户端（在这种情况下为 iPhone）设置他的电子邮件帐户，并且由于我们的密码政策要求每 30 天更改一次密码，当他更改密码但没有在 iPhone 上更新密码时，他的帐户保留由于使用了错误的密码而被锁定。
至少值得检查。