☰

解锁与 AD 断开连接的笔记本上的广告用户

tag-icon • tag-icon passwords user-accounts windows-server-2008-r2
解锁与 AD 断开连接的笔记本上的广告用户

我和同事在出差时遇到了一个用户遇到的具体问题。我尽量将其描述得尽可能通用，以符合超级用户的政策。不幸的是，在谷歌搜索了 1 小时（英语和德语）后，我找不到任何形式的关于我的情况的记录。

场景如下：

  • 某用户（个人）出差（在公司外），由于连续三次输入错误凭证，导致其笔记本上的 AD 用户帐户被锁定。该用户仅在笔记本上使用 AD 帐户。他没有其他本地帐户。
  • 用户（个人）知道正确的当前密码，该密码是在现场时为该笔记本电脑设置的。该密码可成功用于其他服务。
  • 我们的 AD 控制器仅可通过 LAN 本地使用
  • 用户（个人）没有任何 VPN 手段将“家”连接到办公室。
  • 用户现在根本无法登录他的笔记本。

技术信息：

  • AD 是基于 Win 2008 R2 的
  • 笔记本是Win7企业版
  • 用户配置文件存储在本地，但它们仍然是 AD 配置文件，而不是本地用户。

我们考虑过的可能的解决方案都遇到了某种障碍：

  • 给出本地管理员密码：将允许他访问 PC，但不能访问他的邮件等帐户，他也无法通过管理员登录解锁他的个人资料，因为 AD 帐户不能通过 lusrmgr.msc 进行管理。
  • 为他设置 VPN 是不可能的，因为这需要一个他没有的物理令牌
  • 我们可以给出管理员密码并指示他设置远程解决方案，例如 TeamViewer，但是我们在机器上该做什么呢？

未来，我们将改变我们的 PW 政策（已有几十年的历史），采用更为现代化的最佳实践方法（将错误输入的阈值提高到 50 分钟等），以避免这种情况，但上述情况仍然存在，我想以某种方式解决它。

提前感谢您的意见，非常感谢。

答案1

在我的公司，我们遇到了同样的情况，我们所做的就是我们的系统团队从 AD 解锁了帐户 https://blogs.technet.microsoft.com/askds/2013/10/01/locked-or-not-demystifying-the-ui-behavior-for-account-lockouts/

用户使用本地管理员登录并访问 OWA 来查看电子邮件

答案2

我觉得这篇关于死灵法术的文章值得分享我最近的经验和知识。@modmatt 的问答、@Kareem 的评论和回答对我寻找非常相似的问题的解决方案很有帮助。在我在网上搜索答案的所有文章中，这篇文章是最符合我所遇到的问题的文章之一。也许这个分享将来会帮助到其他人。

什么情景导致了该问题的发生？

用户（在本例中实际上是我）已达到 AD 强制的 90 天密码使用期限限制。公司使用本地 AD 服务器，并且也使用某种双向同步到 O365。在正常情况下，更改 corp.local AD 或 O365 上的密码会触发另一个的更新。

因此，用户已更改密码，在本例中是通过公司为用户和角色管理定制的 IDM 工具在 corp.local 域上更改的。这应该触发工作流程以全局更新凭据。

与@modmatt 最初的问题相比，我的情况有两个主要区别：

  1. 该用户是具有 VPN 访问权限的远程用户（仅登录后可用）。
  2. 用户在 AD corp.local 上被锁定，但本地缓存凭据（使用以前的密码）已被解锁，当设备未连接到 VPN 时，用户可以登录/解锁他们的“本地缓存”帐户。

用户不断发生的“账户锁定”循环如下：

  1. 启动装置。
  2. 使用本地/缓存的凭据登录。
  3. 连接到 VPN（Cisco AnyConnect）。
  4. 预期：通过 AD 使用最新密码更新缓存凭据。
  5. 实际：帐户已被锁定。解锁屏幕消息为“引用的帐户目前已被锁定，可能无法登录。”
  6. 此时，再次获得用户访问权限的唯一方法是重新启动并从步骤 1 开始，但循环不断发生。

帮助台一直在与用户进行实时聊天，监控用户的 AD 状态并不断执行帐户解锁。看来，一旦建立 VPN 连接，用户就会被策略锁定，这导致得出结论：帐户中缓存的某些内容导致 AD 无法同步最新凭据之前锁定。

解决方案

帮助台已通知用户确保已使用 office.com 密码重置流程触发帐户解锁流程。用户已遵循此流程，并且拥有一个有效的 O365 帐户和新凭据。已建立的双向同步流程应该会将其与 corp.local AD 同步。

用户之前曾通过自动化流程请求授予“本地管理员”的限时权限，该权限似乎尚未过期，即用户仍然拥有本地管理员权限。

  1. 用户创建了一个“LocalAdmin”帐户，并为该帐户分配了本地管理员权限。（该解决方案实际上不需要分配权限）。这可能是一个标准帐户。
  2. 用户确认账户有效然后重新启动设备。
  3. 帮助台确认 AD 帐户已解锁。
  4. 用户使用新的 LocalAdmin 帐户登录。
  5. 连接到 VPN（Cisco AnyConnect）的用户。
  6. 用户在资源管理器窗口中找到 cmd 提示符，然后按SHIFT+right clicking并“以其他用户身份运行”
  7. corp\<username>+ 来自 office.com 密码重置过程的新密码。
  8. 以域用户身份启动cmd窗口，并触发相关本地缓存刷新。
  9. 帮助台确认 AD 帐户仍处于解锁状态。

然后，用户可以退出本地帐户（副作用：VPN 断开连接）并使用其正常域帐户登录。此后，用户连接到 VPN 并能够运行net user <username> /domain并查看其帐户是否处于活动状态，然后执行gpupdate并继续照常开展业务。

当时不可行的其他解决方案

  • 将设备带到 corp.local 域上的办公地点，让域管理员修复该问题。由于需要大约 1000 公里的通勤，因此这种方法无法立即实施。从 DE 到 DK 的往返。

或者

  • 向用户提供本地用户CorpAdmin凭据以运行上述步骤。当时，提供这些凭据并不是服务台批准的流程。我认为这是一个共享密码。

后见之明：在撰写本文时，我意识到用户（我）可能通过 Citrix VDI 会话（使用其自己的 SSL VPN）更改了他们的 VPN 凭据，而这可能会导致在用户稍后使用最终用户设备上的旧缓存凭据连接到 VPN 时出现竞争条件，从而导致立即出现 AD 锁定和上述循环？

结论：更改密码时始终确保最终用户设备位于 VPN 上，以便 AD 和本地缓存凭据不会不同步并导致上面记录的循环。

可能还值得拥有一个本地标准帐户作为备份，在这种情况下可以充当救援帐户。这似乎不是一个很大的信息安全风险/攻击媒介？

脚注：截至 2022 年 2 月，该特定组织的帮助台建议使用 O365 密码更改流程，而不是CTRL+ ALT+ DEL“更改密码”流程，也不是 corp.local IDM 流程。这是违反直觉的，但我做了记录。这个建议似乎缺少的是确保在执行密码更改时最终用户设备连接到 VPN。这似乎很明显，但事实上，在最终用户设备与 VPN 断开连接的情况下，可以通过 office.com 或 Citrix VDI 执行流程，这可能会（在某些情况下？）导致上述问题。

其他有见地的链接包括这里以及可接受的解决方案这里。

相关内容