研发平台的账号状态和部门归属一旦与AD目录脱节，离职账号仍可登录、调岗人员仍挂在旧部门的情况就会反复出现。处理这类问题的关键，是把AD作为账号状态和组织属性的事实来源，按“目录变更→同步映射→平台内处置→核验留痕”的固定链路运行，并对账号停用与部门变更分别设定判定条件和生效规则。本文给出可直接执行的流程、角色分工、映射表结构和检查清单，覆盖身份与账号层面，不展开访问授权策略和知识文档权限的具体设计。
要点总览（TL;DR）
- 把AD目录作为账号状态和组织属性的唯一事实来源，平台侧只做映射与处置，避免双写导致状态漂移。
- 账号停用先分三类：离职走永久停用与工作移交，转岗保留账号并回收原岗位权限，临时冻结阻断登录并设定复核日期。
- 部门变更先确定映射口径（AD组织单位还是部门属性字段），再规定生效时点（即时、定时或人工确认），历史工作项保留变更时点的归属。
- 流程设四个角色：目录管理员、平台管理员、业务部门负责人、员工本人；交付物包括映射表、停用工单、变更记录和核验报告。
- 上线前完成全量比对与模板准备，运行中每周抽样核验、每月巡检异常账号，映射规则调整保留版本记录。
账号停用与部门变更的处理框架
整套流程成立的前提只有一个：AD目录是账号状态和组织属性的权威来源，研发平台侧只做映射与处置，不允许在平台内单独新建或修改人员状态后不回写目录。一旦出现双写，账号状态就会漂移，后续的停用和变更判断都失去依据。
在这个前提下，两类事件走不同的处置主线：
| 事件类型 | 触发来源 | 处理主线 | 主要产出 |
|---|---|---|---|
| 账号停用 | AD中账号被禁用、移出人员组或标记离职 | 确认停用情形→平台账号禁用→会话与凭据失效→在途工作移交→核验留痕 | 停用工单、移交记录、核验结果 |
| 部门变更 | AD组织单位调整或部门属性字段变更 | 识别变更字段→按映射表换算平台组织→确定生效时点→调整归属→保留历史→记录变更 | 变更记录、映射更新记录 |
同步链路由四段组成：目录侧变更（由HR或目录管理员发起）、同步机制（AD对接自动同步或接口推送）、平台侧处置（禁用账号、调整组织归属）、核验留痕（抽样比对与记录归档）。四段中任何一段缺失，流程都会在某个环节断掉，例如只做了同步但没做核验，就无法发现映射错误导致的归属偏差。
需要明确边界：本文处理的是“这个人还在不在、属于哪个部门”的身份问题。账号停用后该人员原有的项目访问权限如何回收、知识文档的可见范围如何调整，属于访问授权策略和知识文档权限管理的范畴，应在身份状态确认之后由对应机制承接，不在本流程内展开。
账号停用的判定条件与处置步骤
账号停用最容易出问题的地方，是把所有“人走了”的情况当成同一种处理。实际至少有三类情形，触发条件和处置力度不同，需要先分类再执行。
三类停用情形的触发条件
| 情形 | 典型触发条件 | 处置力度 | 数据归属处理 |
|---|---|---|---|
| 离职 | HR系统离职流程完成，AD账号被禁用或移出人员组 | 永久停用，账号禁用，凭据作废 | 在途工作项和待办移交给指定接收人 |
| 转岗 | AD部门属性变更，原岗位职责终止 | 保留账号，回收原岗位相关权限 | 原部门工作项按交接约定移交或保留只读 |
| 临时冻结 | 长期休假、外派、合规调查等临时状态 | 阻断登录，账号保留，设定复核日期 | 工作项暂不移交，指定代理人 |
三类情形的共同点是“不能再以原身份正常使用平台”，区别在于账号是否保留、数据是否移交、是否需要到期复核。临时冻结必须带复核日期，否则容易变成事实上的永久停用却无人清理。
停用操作步骤
每一步都要有明确的输入、动作、输出和完成标志，避免执行到一半无法判断是否做完。
- 确认停用输入。输入：HR离职或调岗通知、AD账号当前状态、生效时间、数据归属接收人。动作：核对目录状态与通知一致，确认接收人已指定。输出：停用申请单。完成标志：申请单上生效时间、情形类型、接收人三项齐全。
- 平台侧禁用账号。输入：停用申请单。动作：在平台内将账号状态置为禁用，或在AD禁用后由同步机制带入禁用状态。输出：账号状态变更记录。完成标志：平台内该账号无法登录，状态与目录一致。
- 会话与凭据失效。输入：已禁用的账号。动作：使现有登录会话失效，撤销或冻结该账号持有的访问凭据。输出：会话失效记录。完成标志：用原凭据尝试登录被拒绝。
- 在途工作移交。输入：该账号名下未完成的待办、在途工作项、待审批事项。动作：按申请单指定的接收人批量移交，或转为待分配状态。输出：移交清单。完成标志：原账号名下无未处理待办，接收人确认接收。
- 核验与留痕。输入：停用申请单、移交清单。动作：比对目录状态与平台状态，记录处理时间和操作人。输出：核验记录。完成标志：核验记录归档，状态一致。
停用与删除的先后关系
停用和删除要分开处理。账号禁用后应保留一段时间，用于处理历史数据归属、审计追溯和误操作恢复，保留期长度由企业合规要求决定。确认无在途依赖、无审计追溯需求后，再执行删除或匿名化。直接删除会让历史工作项的创建人信息丢失，也会让审计记录出现断点。
在ONES中，AD对接可自动同步组织架构并验证登录，账号禁用后的工单流转、移交记录和核验结果可以用工作项与记录类功能承载，把停用申请、移交清单和核验结论放在同一条流程里留痕，便于后续审计时按人检索。
部门变更的映射规则与生效处理
部门变更的核心问题是“以哪个字段为准”。AD中与部门相关的信息通常有两个来源：组织单位（OU）的层级位置，以及账号上的部门属性字段（如department）。两者可能不一致，必须先确定唯一口径。
映射口径的选择
| 映射依据 | 适用情况 | 注意事项 |
|---|---|---|
| AD组织单位（OU） | 目录结构本身按部门组织，OU层级稳定 | OU调整会影响整棵子树，需评估批量影响 |
| 部门属性字段 | 目录结构按其他维度组织，部门信息维护在属性中 | 依赖属性维护质量，需规定字段填写规范 |
| 两者结合 | OU表示大组织，属性表示细分部门 | 需明确冲突时以哪个为准，并写入映射表 |
映射表至少包含：AD字段或OU路径、平台组织单元、映射方向、维护责任人、最近更新时间。映射表本身要有版本记录，任何调整都留痕，否则变更后无法回溯是按哪版规则换算的。
生效时点的取舍
即时同步适合组织调整频繁、对归属准确性要求高的场景，变更在目录侧完成后短时间内反映到平台。定时同步（如每日一次）实现简单、对目录压力小，但存在最长一个同步周期的延迟，跨部门协作在延迟窗口内可能仍按旧部门归属。人工确认适合涉及审批权限交接的敏感变更，由平台管理员核对后再生效。三种方式可以组合：常规部门调整走定时同步，涉及负责人变更或跨事业部调整走人工确认。
历史归属的保留
部门变更后，历史工作项、文档和审批记录不应随人员归属一起改写。通常的处理是：历史记录保留变更时点的部门归属，新增工作按新部门归属。这样既保证当前组织视图准确，也保证历史统计和审计可追溯。如果平台支持按时间点查询组织归属，应在变更记录中写明生效时间，便于回溯。
权限与审批衔接的边界
跨部门变更往往伴随审批权限变化，例如原部门审批人不再有权审批该人员的新申请。身份流程负责把人员归属调整到位，并输出变更记录；审批权限的重新授予属于授权策略范畴，由对应机制依据变更记录执行。两者的衔接点是变更记录：身份流程产出“谁在什么时间从哪个部门到了哪个部门”，授权侧据此判断需要回收和新增哪些权限。
角色分工与交付物
流程能否稳定运行，取决于每个环节是否有人负责、有产出可查。以下职责划分可按企业实际调整，但每个动作都应有明确责任人。
| 角色 | 在停用事件中的职责 | 在部门变更中的职责 |
|---|---|---|
| 目录管理员 | 在AD中执行账号禁用，确认禁用原因和生效时间 | 维护OU结构或部门属性字段，保证填写规范 |
| 平台管理员 | 确认平台侧禁用生效，执行会话失效和工作移交，完成核验 | 按映射表核对组织归属调整结果，处理映射异常 |
| 业务部门负责人 | 指定数据归属接收人，确认移交完成 | 确认人员调入调出，提出审批权限调整需求 |
| 员工本人 | 离职或转岗前完成手头工作交接说明 | 配合确认新归属部门和工作交接内容 |
审批节点建议设在两处：停用申请由业务部门负责人确认接收人后提交，平台管理员执行；部门变更中涉及负责人变动的，由上级负责人确认后生效。普通成员调岗可按定时同步自动处理，不逐条审批，避免流程负担过重。
交付物清单包括：部门字段映射表（含版本记录）、停用工单（含情形类型、生效时间、接收人）、变更记录（含变更前后归属、生效时间）、核验报告（含抽样结果和异常处理）。异常升级路径为：平台管理员发现同步结果与目录不一致时，先记录异常并暂停相关账号的自动处置，升级至目录管理员核查目录侧数据，涉及映射规则问题的升级至映射表维护责任人修订规则。
示例：一次离职停用与一次跨部门调岗
以下为演示情景，用于说明流程如何走通，不代表特定企业的实际配置。
离职停用示例
某研发人员提交离职，HR流程完成后，目录管理员在AD中禁用其账号并移出人员组。平台侧同步机制将该账号置为禁用。平台管理员收到停用申请单，核对情形类型为“离职”、生效时间为离职当日、接收人为其直属主管。随后执行会话失效，将该账号名下3个未完成待办和1个在途评审移交给主管，主管确认接收。核验时比对目录与平台状态一致，核验记录归档。账号保留至保留期结束，期间无审计追溯需求，再执行删除。
该示例中出现的异常：同步后平台账号已禁用，但该账号仍有一个进行中的审批任务未出现在待办列表中，原因是该任务以角色身份挂载而非个人身份。处理方式是平台管理员在移交时按角色检索补充处理，并在核验清单中增加“按角色挂载的任务”检查项。
跨部门调岗示例
某员工从A部门调至B部门，目录管理员修改其部门属性字段，OU位置暂未调整。平台按定时同步在当日夜间将该员工归属调整为B部门。变更记录写明变更前后部门、生效时间。该员工此前在A部门创建的12个工作项和若干文档保留原部门归属，新增工作按B部门归属。业务部门负责人确认调岗后，提出审批权限调整需求，由授权侧依据变更记录处理。
该示例中出现的异常：OU位置与部门属性字段不一致，导致按OU映射的报表中该员工仍显示在A部门。处理方式是明确映射口径以部门属性字段为准，并在映射表中记录该例外，同时推动目录管理员同步调整OU位置。
两个示例的共同规律是：目录侧变更先行，平台侧处置跟随，核验环节必须比对目录与平台两侧状态，异常大多来自映射口径不一致或非个人身份挂载的任务，需要在检查清单中预先覆盖。
完成检查与持续维护
流程上线前和运行中都需要可逐项核对的检查项，以下清单可直接使用。
上线前检查项
- AD侧账号状态字段和部门字段已确认，映射口径写入映射表并有责任人。
- 三类停用情形（离职、转岗、临时冻结）的触发条件和审批人已定义。
- 同步机制已配置并完成一次全量比对，差异项已处理。
- 停用工单模板包含情形类型、生效时间、接收人、核验结论字段。
- 变更记录模板包含变更前后归属、生效时间、映射规则版本。
- 异常升级路径已通知到各角色，责任人明确。
定期维护清单
- 同步结果抽样核验：建议每周抽取一定数量的停用账号和部门变更记录，比对目录与平台状态，记录差异率。
- 异常账号巡检：每月检查长期未登录、状态与目录不一致、归属部门为空或指向已撤销部门的账号，按情形清理或修正。
- 映射表版本维护：映射规则每次调整都记录版本、调整原因和责任人，旧版本保留可查。
- 临时冻结复核：按设定的复核日期逐条确认，到期未续期的转为停用或恢复。
当核验发现差异率上升、或同一类异常反复出现时，说明映射规则或同步配置存在系统性问题，应暂停相关自动处置，由映射表维护责任人修订规则并重新全量比对，确认后再恢复自动流程。流程的持续有效依赖两个习惯：每次变更都留痕，每次核验都记录结论。
常见问题
临时冻结的账号到期后没人复核，怎么避免变成事实上的永久停用？
临时冻结必须在停用申请单上写明复核日期和责任人，并把复核日期作为工单的必填字段。运行中按复核日期逐条确认：到期后确认恢复的解除阻断，确认不再需要的转为正式停用并走工作移交。建议每月巡检时专门列出已过复核日期仍未处理的账号，按逾期天数升级至平台管理员和业务部门负责人，避免冻结状态长期悬空。
AD中组织单位和部门属性字段不一致时，以哪个为准？
先确定唯一口径并写入映射表，冲突时按映射表规定执行。常见做法是以部门属性字段为准，因为人员调岗时通常先改属性字段，OU位置调整可能滞后；同时把OU与属性不一致的账号列为异常，推动目录管理员同步调整OU位置。如果企业目录结构本身按部门组织且OU层级稳定，也可以OU为准，但要评估OU调整对整棵子树的影响。关键是口径唯一、例外有记录。
账号停用后，按角色挂载的审批任务为什么容易漏掉？
停用流程通常按个人账号检索待办和在途工作项，而部分审批任务以角色身份挂载，不显示在个人待办列表中，账号禁用后这些任务仍停留在原角色上。处理方式是在移交环节增加按角色检索的步骤，把该人员担任的角色所挂载的任务一并处理，并在核验清单中加入“按角色挂载的任务”检查项。角色本身是否需要重新指定承接人，也应在停用时一并确认。
停用和删除之间要间隔多久？
保留期长度由企业合规要求和审计追溯需求决定，没有统一标准。判断依据是：历史工作项的创建人信息是否还需要保留、审计记录是否可能被调取、是否存在误操作需要恢复的可能。确认无在途依赖、无审计追溯需求后再执行删除或匿名化。直接删除会让历史工作项的创建人信息丢失，审计记录出现断点，因此停用与删除应作为两个独立步骤分别审批。
ONES在AD域集成中能承载哪些环节？
ONES支持对接LDAP协议服务和Microsoft AD服务，实现组织架构自动同步与登录验证；对于非标准目录服务，可通过标准接口更新组织架构。在停用与变更流程中，停用申请单、工作移交清单、变更记录和核验结论可以用工作项与记录类功能承载，放在同一条流程里留痕，便于审计时按人检索。同步触发方式、字段映射范围和版本支持差异，需以实际配置和版本说明为准。
