案例分享：跨两个 AD 域的员工离职如何处理？

一、离职处理看起来很简单，实则不简单

在纸面上，员工离职处理就是一动作：把账号禁掉。

实际不是。它是一连串紧紧咬合的步骤——重置密码、清空 AD 组成员身份、把账号从云端安全组里摘出来、移除邮箱、回收 Microsoft 365 许可、撤销角色分配、如果邮箱还要作为共享资源保留就得先做转换、迁移对象位置、最后按计划删除，而且这个“最后”既不能太早也不能太晚。

每一步都必须在每一次执行中，按正确的顺序，稳定地发生。

如果是一个人一个人地手动做，一周处理一个，这套流程还能管得住。但当它变成每个月都要在一个拥有多个法人实体、多个域的组织里跑一遍，情况就完全不一样了。

到那个阶段，“手动”已经不再是一种流程，而是一个风险敞口。总有一个地方、某一个环节会被漏掉。而在为时已晚之前，你很难看出漏的是什么。

本篇文章和大家分享一个真实的企业故事，以及我们为它搭建的三段式自动化解决方案。

二、两个域，一套人马

▌多域环境：同一集团下存在两个或多个相互独立、但人员会流动的 Active Directory（AD，活动目录）域，账号身份分散在不同域中。

这家企业叫 Meredian Group，是一个成熟的企业集团，旗下有一家做礼宾服务的子公司。这家子公司原本是母公司的内部服务部门，后来才分拆成独立品牌的业务。如今，母公司运行自己的 AD 域，我们称之为域 1；礼宾业务运行另一个独立域，称之为域 2。

因为域 2 的业务本来就是从域 1 的集团里长出来的，两个域关系紧密。

这种紧密体现在人员的流动方式上。有些员工在母公司和礼宾业务都工作过，或者从一边调到另一边，而原来的账号从来没有被关闭过。所以同一个人，在技术上、也在合规上，可能同时在两个域各拥有一个账号——一个对应他在母公司的岗位，一个对应他在礼宾业务的岗位。

这就是这里离职处理最危险的地方。

假设 Meredian 公司的离职流程默认是手动的，做法是“找到用户账号，然后删掉”。当一个人只有一个账号时，这没问题；在这里不行。

流程只看得见它当前运行的那个域，它没有办法知道这个人在另一个域里是否还持有另一个身份。结果就是，域 1 或域 2 上总有一个账号被删掉，而离职本身并不完整。

三、问题到底出在哪里

当一家企业因为手工离职流程背上运维负担时，第一反应通常是：把标准动作序列自动化掉——重置密码、清组、移除邮箱、撤销许可证、删除，然后让它无人值守地跑。

这是一个合理的起点，也恰恰是这个思路崩掉的地方。

无论手动还是自动，只要这么跑得足够久，同样的失败场景会循环出现，典型的有六种：

失败场景实际后果
漏掉诉讼保留账号照样被删除，这是一个很难挽回的合规错误
漏掉重复身份删错账号，或把正确身份仅存的副本一起删掉
未确认账号真的被禁用“已完成离职”的状态被标记，但账号还是活的
角色分配没被摘掉管理员级权限活得比它所属的身份还久
许可证静默撤销失败它授予的访问权限就一直存在
异常没有进入工单系统出过什么事没有任何记录

这些问题反复出现，原因只有一个：流程只是在按顺序执行步骤，它没有判断力。无论这个过程是人做的，还是一套没有针对具体环境适配的自动化。

它不知道要为一个诉讼保留、或一个被标记的属性停下来。它不知道要在删除之前，去检查这个账号在另一个域上是不是有个“孪生兄弟”。

把同样的步骤跑得更快、规模更大，并不会让离职更安全，只会比手工操作更快地重复同样的疏漏。

所有这些潜在失败场景，缺的都不是步骤，而是决策：在哪些点上流程要停下来、检查一个条件、然后决定是继续、转人工，还是中止。

四、在动作之前，先放“决策块”

给 Meredian 公司的解决方案，不是为了自动化而自动化，而是把判断力嵌进离职工作流里，让流程在关键节点检查条件，再决定继续、转人工还是停止。决策块是实现这件事的常见方式，也是我们在这里采用的做法。

根据环境不同，离职可以被多个属性和条件所闸控。我们看其中两个例子。

第一个是扩展属性。它是 Active Directory 架构里自带的十五个通用自定义字段（extensionAttribute1 到 extensionAttribute15），出厂全为空，由管理员自行决定存什么。在 Meredian 这样的环境里，管理员可以用它作为标记，表示账号的 HR / 开通同步流程已经完成。

第二个是诉讼保留，Exchange / Microsoft 365 的标准功能，用于保全邮箱内容、阻止其被永久删除——通常是因为该账号涉及正在进行或预期中的法律诉讼、调查，或监管要求。保留生效期间，无论账号其他状态如何，邮箱都必须保持完整。Meredian 和多数企业一样，一旦出现法律事项就会启用保留。

这两个检查之所以重要，是由 Meredian公司的结构决定的：账号分散在两个域，流程只能对“HR 同步状态已确认”的账号采取安全动作；作为集团企业，它又承担着法律保全义务，任何删除都绝不能覆盖这一义务。

所以，在离职流程做出任何不可逆的动作之前，必须先明确两件事：

  1. 自定义扩展属性是否有值？如果为空，说明账号的开通 / HR 同步状态不可信。自动化就此停止，不发起任何 AD 操作，同时向工单系统派单转人工处理。
  2. 邮箱是否启用了诉讼保留？如果是，结果相同：硬停止，转人工处理。

只有这两项检查都通过，真正的离职动作才开始。这正是 ManageEngine ADManager Plus 的用武之地。

我们的角色，是用 ADManager Plus 的编排模板为 Meredian公司实现这套工作流。编排模板位于产品的“自动化 > 配置 > 编排模板”中，允许你把离职动作串成链条，中间插入逻辑类的决策块（如“基于条件的决策”“基于前一区块结果的决策”）、时间延迟与 Webhook。

链式动作负责执行清理步骤，决策块执行上面这两项关键检查，Webhook 把结果回写到已配置的工单系统。

我们把工作拆成三段自动化，每段都是一个独立的编排模板：

自动化 1：域 1 原生离职

执行标准清理链：重置密码、更新带时间戳的 Description 字段、撤销组 / 许可证 / 角色、移除邮箱。然后检查用户的国家 / 地区属性——比如，这是不是欧盟 / 英国账号？

  • 非欧盟 / 英国：禁用账号 → 移动到指定组织单位（OU）→ 如果移动成功，延迟 90 天后删除。
  • 欧盟 / 英国：同样路径，但多一步——90 天等待期结束后，再复核账号是否真的处于禁用状态，确认后才删除。这个二次检查存在的原因，是欧盟 / 英国有更严格的合规要求。

自动化 2：域 2 原生离职

同样的两项检查、同样的核心清理链，另外加上邮箱转换和扩展属性更新。区别在于，最后一步不是地区判断，而是对域 1 的重复身份检查：

  • 未发现重复：正常收尾，回写工单系统，延迟 90 天后执行删除。
  • 发现重复：自动化拒绝删除。它把重复账号的邮箱地址回写到工单系统，并另开一张工单，而不是去猜哪一个身份可以安全移除。

自动化 3：清理处理器

这一段存在的意义，纯粹是为了接住自动化 2 标记出来的情况。它执行同样的两项检查和同样的清理链，但完全跳过重复身份检查——因为账号能走到这一步，这个检查已经在上游发生过了。成功则回写工单系统并在 90 天后删除；失败则转由人工处理。

五、闭环：每一种结果都生成一张工单

这套设计不能是一个含糊的黑盒。每一个最终结果都会回写到已配置的工单系统，形成一张人可以接手处理的工单，而不是仅仅记在系统内部日志里。

  • 决策块检查失败 → 在任何 AD 动作执行之前，回写成转人工工单。
  • 离职顺利执行完成 → 回写成确认记录。
  • 在另一个域发现重复身份 → 回写并附上重复账号的邮箱地址，另开工单；正是这张工单把账号带进清理处理器自动化，而不是悬在半空。

跨双域离职自动化流程
上图是这套方案的完整流向：受理 → 合规与属性校验 → 数据保留 → 标准离职 → 保留等待期 → 重复身份检查 → 删除 → 完成，以及四条分支（转人工、诉讼保留延期、发现重复身份、硬停止）。

自动化能够到达的每一个结果——干净成功、硬停止、还是转交——都有对应的回写，因此没有任何一件事是静默完成的。

这才真正堵上了“异常无声消失”这个缺口：在这里，失败不只是让自动化停下来，它还会产生一条有人接手的记录。

六、这套设计对国内企业意味着什么

Meredian 公司遇到的问题非常有代表性。只要你的组织跑着多个域——不管是并购来的、分拆出来的、子公司自建的，还是历史遗留系统一直没整合干净的——你就有同样的重复身份暴露面，而这套设计正是为捕捉它而生的。

只要你的组织承担法律或监管义务，你就有同样的理由，在任何删除发生之前先检查诉讼保留（或国内对应的司法 / 监管保全要求）。

“应对审计记录进行保护，定期备份，避免受到未预期的删除、修改或覆盖等。”——GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》8.1.4.3（安全审计）相关要求。账号从创建、变更到注销的全过程留痕，是审计合规的基础证据链。

《中华人民共和国数据安全法》要求企业建立健全数据安全管理制度，并对重要数据的处理活动开展风险评估与记录；员工的账号注销、数据删除属于需留痕、可追溯的关键动作之一。

对国内企业来说，这套思路的价值在于把“离职”从一个人事动作，升级成一条可审计、可回溯、可问责的治理链路：谁批的、什么时候执行的、检查过哪些条件、为什么停下来了，全都有据可查。

七、结论

Meredian公司的起点是运维负担和合规风险：既要逐个用户手工处理，又要承担“账号在诉讼保留期间被删掉”“重复身份被误判为干净退出”的风险。解法是重新思考“自动化”到底应该意味着什么。

离职流程光做到“不需要人一步步点”是不够的。它必须知道什么时候不该继续，也必须每一次停下时都留下记录。

这就是脚本和系统的区别：一个负责执行，另一个负责判断。

这个转变在上线之后是看得见的：

  • 诉讼保留在任何决定性动作触发之前就被检查了；
  • 重复身份在删除之前被识别，而不是之后；
  • 禁用状态是被验证过的，而不是被假定的；
  • 每一个异常都留下了轨迹，而不是悄悄消失。

离职处理从一个“假设不会出错”的手工序列，变成了一套“假设总会有东西被漏掉、并为此设计好拦截”的受治理自动化。

需要说明一点边界：架构设计先行，ADManager Plus 是实现这套架构所用的平台。换一套工具同样能实现这套判断逻辑，关键在于你有没有在正确的位置放上决策点。

八、总结

  1. 多域不是例外，是常态。并购、分拆、子公司、遗留系统，任何一种都可能让同一个人持有多个身份。离职流程必须以“这个人在别处是否还有账号”为前提来设计。
  2. 删除是不可逆的，检查必须前置。诉讼保留、扩展属性、重复身份，这些检查一旦放到删除之后，就等于没有。
  3. 自动化的价值在决策，不在速度。把同样的步骤跑得更快，只是更快地重复同样的错误。
  4. 每一次停止都要有人接手。工单回写不是形式主义，它是把“静默失败”变成“可见事件”的唯一手段。

常见问题（FAQs）

  1. ADManager Plus 的编排模板是什么？

    编排模板是 ADManager Plus 中用于串联管理任务的工作流载体，位于“自动化 > 配置 > 编排模板”，可以把多个动作按顺序串成链条，并在中间插入条件判断（逻辑类的决策块，如“基于条件的决策”“基于前一区块结果的决策”）、时间延迟和外部系统调用（Webhook），从而实现带判断能力的自动化，而非单纯的批量执行。可用的编排模块还包括自定义脚本、通知、数据库操作，以及 AD 操作、Exchange 操作和云操作（如启用 / 禁用诉讼保留、撤销 Microsoft 365 许可证、转换共享邮箱等）。

  2. 这套方案只适用于两个域的场景吗？

    不是。原案例是“域 1 + 域 2”的典型结构，但同样的决策块逻辑可以扩展到更多域，也可以用于单域但存在历史遗留账号、外包账号、测试账号混杂的环境。核心是“删除前先查有没有孪生身份”这一判断点。

  3. 诉讼保留和国内的合规要求如何对应？

    诉讼保留是 Exchange / Microsoft 365 的原生能力。在国内语境下，与它性质相近的是司法保全、监管调查中的数据留存要求，以及等保 2.0 对审计记录留存期限的规定。落地时应结合企业所处行业的监管要求确定保留策略。

  4. 为什么要设置 90 天延迟删除，而不是立即删除？

    延迟窗口是给“误判”留的纠错余地。账号先被禁用、移入指定 OU，保留期满再执行删除；欧盟 / 英国账号还会额外复核禁用状态。这相当于给不可逆动作加了一个缓冲期。具体时长应结合企业制度与适用要求确定。

  5. 部署这套自动化需要改动现有 AD 架构吗？

    不需要改动 AD 架构本身。方案基于 AD 原生的扩展属性、组、OU 等对象，通过 ADManager Plus 的编排能力在外层组织流程。具体实施前建议先在测试域验证决策块的条件判断是否符合企业实际。

相关文章推荐