一、统一身份最大的敌人是已有目录几乎每家企业都有一套跑了多年的身份目录Windows 域用 Active DirectoryLinux/应用侧用 OpenLDAP或者两者并存。账号、组、邮件、部门全在这上面几十个系统靠它认证。现在要上统一身份认证把 SSO、MFA、生命周期收口到一处最直接的问题不是新平台怎么建而是怎么在不推翻 AD/LDAP 的前提下接管它。推倒重来是最差的选项所有系统改认证、所有账号重新建、所有脚本重接停工数月、出错一堆。正确做法是渐进接管——新统一身份平台和现有目录共存先同步、再切流、可回溯让业务无感地完成身份主权的转移。二、AD/LDAP 在企业里的真实角色先厘清现有目录到底管了什么才知道接管时哪些能碰、哪些不能动账号与密码AD 存着域账号和口令哈希系统是靠它验口令。这是最敏感、最不能乱动的部分。组织与组部门 OU、安全组、通讯组决定权限和邮件分发。属性姓名、邮箱、电话、工号被 HR 系统和各种应用读取。认证协议AD 走 Kerberos LDAP(S) 简单绑定LDAP 走 bind DN 口令。很多系统认 AD是通过 LDAP bind拿账号口令去 AD 验或 Kerberos拿 TGT 换服务票据。统一身份要接管本质是让这些系统以后认新的统一身份而非直接认 AD——但过渡期还得让 AD 继续工作。三、目录同步不推翻先对齐第一步不是切认证而是目录同步——把 AD/LDAP 的账号、组织、属性按映射规则同步到新统一身份平台建立一一对应的身份映射表。同步方向通常单向AD → 统一身份或双向变更互相回写谨慎。单向更安全AD 仍是权威源统一身份是它的镜像避免双向回写把 AD 搞乱。同步内容账号sAMAccountName / uid 映射到统一身份主ID。组织OU/组映射到统一身份的部门与角色。属性姓名、邮箱、工号字段名不同要建映射如mail→email。状态启用/禁用同步离职账号在 AD 禁用时统一身份也禁用。同步解决了两边都有人但认不出是同一个的问题。建立了映射后续切流时系统才知道新平台里的用户 X 旧 AD 里的用户 X。以安当ASP为例它的定位是统一身份认证平台具备与现有 AD/LDAP 目录对接、按字段映射同步账号与组织的能力作为接管的第一步把既有身份镜像过来而不是要求企业先清空 AD 重建。注意它的对接走标准目录协议LDAP/S、SAML2、OIDC 等并不提供 CAS 协议——若某业务系统依赖 CAS 单点登录不能把它当作 CAS Server 来对接应走其支持的协议或代填兜底。四、渐进切流一个系统一个系统地挪目录同步好后逐个系统把认证从直接认 AD切到认统一身份。切流策略有多种按系统风险选策略一统一身份做代理后端仍认 AD。新平台前置用户到统一身份登录拿凭证统一身份再用 AD 账号去后端系统完成 bind协议转换。好处是系统零改坏处是 AD 口令仍在使用、没真正收口。适合过渡期快速见效。策略二系统改认统一身份协议。应用本身支持 SAML2/OIDC直接配成信任统一身份登录跳转到新平台。这是目标形态真正收口。改造成本看应用是否原生支持。策略三代填兜底。老系统啥协议都不支持只能由统一身份在后端用存好的凭据代填登录。这是兜底凭据不落地、审计统一但终究不如协议对接干净。切流顺序先低风险的内部系统如 Wiki、项目管理再中风险业务系统最后高敏感系统如财务、生产。每切一个观察一阵确认登录、权限、审计都正常再动下一个。五、混合态新旧并存的必然阶段接管不可能一夜完成必然有段混合态一部分系统认统一身份一部分还认 AD用户有时走新平台、有时走旧域。这个阶段要管好三件事统一登录入口给用户一个统一门户能跳到已接管的系统未接管的系统仍走旧方式但入口集中用户不混乱。凭据一致性过渡期用户在 AD 和统一身份各有口令要避免两套口令不同步导致困惑。可让统一身份在代理模式下复用 AD 口令或强制统一改密到新平台。状态同步AD 禁用账号统一身份侧要及时禁用已接管系统随之锁掉反之统一身份禁用代理模式下的 AD 也要联动。状态同步断链会导致AD 走了人还能登新系统。混合态是验收期重点验证任一账号在全域的启用/禁用是否一致不一致就是漏同步的 Bug。六、回溯机制切错了能回去渐进迁移必须能回溯——某个系统切到统一身份后发现问题权限错乱、协议不兼容要能快速退回认 AD的原状不影响业务。回溯靠两点一是系统侧保留原 AD 认证配置不删只禁用出问题切回即可二是映射表完整知道退回后账号怎么对应。切流时先并行、后关闭原通道确认稳定再删旧配置绝不切完就毁掉回退路。七、账号映射的坑同名不同人目录同步最阴的坑是账号冲突。AD 里zhangsan和 LDAP 里zhangsan可能不是同一个人不同系统历史各自建号。直接按用户名映射会张冠李戴。正确做法用唯一业务键映射以 HR 工号或邮箱为权威键工号相同才是同一人用户名相同不算。同步前先跑一遍冲突检测把用户名同但工号异的列出人工确认。映射表建错后面切流全员串号是重大事故。另一个坑属性字段名不一致导致同步丢字段如mail和email没映射邮箱全空。同步前做字段映射清单逐一核对。八、落地改造路径盘目录列 AD/LDAP 的域、OU、组、属性、当前接了哪些系统、用什么协议认证。建映射以工号/邮箱为权威键建账号—组织—属性映射清单跑冲突检测。目录同步单向把 AD/LDAP 同步到统一身份建立身份映射表状态同步。选切流策略按系统风险定代理/协议/代填低敏先切。逐系统切流一个系统灰度、观察、稳定再下一个保留回退配置。管混合态统一入口、凭据一致、状态同步验全域启用禁用一致。收口已接管系统稳定后逐步关闭原 AD 直认证通道统一身份成权威源。验审计抽查各系统登录、权限、禁用联动确认接管无遗漏。九、常见坑推倒重来清空 AD 重建停工数月。应渐进接管、保留回退。按用户名映射同名不同人串号。用工号/邮箱权威键 冲突检测。双向回写乱目录同步互相写把 AD 搞脏。过渡期单向AD 权威。切完毁回退旧配置删了出问题回不去。先并行、后关闭。状态不同步AD 禁用统一身份没禁用离职还能登。状态联动必做。误用 CAS 对接把不支持 CAS 的统一身份当 CAS Server 接 OA协议不匹配失败。走其支持的协议或代填。十、小结统一身份接管现有 AD/LDAP核心不是技术炫酷而是不推翻、先同步、渐进切、可回溯。目录同步建立映射切流按风险逐个挪混合态管好一致性与回退最后收口成权威源。慢一点但业务不停、不出串号事故才是企业级的稳妥。附实战配置样例与行业案例这一节给出字段映射、冲突检测、切流策略与检查清单。字段映射清单示意mapping: AD.sAMAccountName - asp.uid AD.mail - asp.email AD.displayName - asp.name AD.department - asp.org HR.emp_id - asp.emp_id # 权威键冲突检测同步前跑username 同但 emp_id 异 → 列出人工确认防串号事故。单向同步配置AD 权威定时拉增量同步到统一身份状态enabled/disabled同步离职 AD 禁用→统一身份禁用。过渡期不双向回写乱目录。切流策略选择低敏系统走代理统一身份前置复用 AD 口令中高风险改认 SAML2/OIDC老系统代填兜底。能走协议不代填。混合态状态联动与凭据一致性全域启用/禁用一致性抽查AD 禁用→统一身份禁用→已接管系统锁掉反向联动。过渡期统一门户集中入口代理模式复用 AD 口令或强制改密到新平台避免两套口令混乱。回溯配置旧 AD 认证配置并行保留切流稳定再关出问题一键退回。行业案例千人中型企业接管某千人员工企业 AD 跑十年数十系统认 AD。统一身份先同步映射低敏 Wiki 先切半年逐步接管业务系统离职漏登从漏收卡变一处失效零中断。审计举证与检查清单举证留同步映射、各系统切流状态、登录与禁用联动记录。检查清单权威键映射冲突检测单向同步起步按风险切流保留回退状态联动协议选对勿把平台当 CAS Server依赖 CAS 的系统走支持协议或代填。落地演进与协同边界统一身份接管现有目录服务最忌讳一刀切。稳妥的路径分四个阶段。第一阶段是只读同步把现有目录里的账号、组、属性拉到统一身份侧建立镜像不改动任何认证流向仅用于校验数据一致性。第二阶段是认证代理新登录请求先过统一身份统一身份再向后端目录做凭证校验用户无感但认证权已收口。第三阶段是切割把应用的认证指向逐步切到统一身份原生协议原目录退居数据源。第四阶段才考虑下线或冻结原目录的认证能力。四步走让任何一步出问题都能回退不会全员登不进去。属性映射是同步阶段最容易踩坑的地方。两套系统的字段命名、编码、组织单位结构往往不一致直接全量照搬会出现重名、乱码、层级错乱。应先做属性对照表明确哪些字段一一对应、哪些需要转换、哪些在原目录里本就缺失需补全。映射规则要写成可复核的文档并在试同步后用抽样核对验证而不是凭感觉信任自动匹配。与应用系统的接入要区分协议能力。现代应用若支持标准协议应优先走协议对接由应用原生信任统一身份颁发的断言体验与安全性都最好老旧应用不支持标准协议时才考虑通过反向代理或凭据代填的方式兜底。两类并存是常态关键是无论哪种最终都要把登录事件归并到统一身份的审计视图避免出现应用自己管一套会话、统一身份看不见的盲区。多租户场景要提前规划隔离边界。当一套统一身份服务多个组织或部门账号命名空间、管理权限、认证策略都可能要彼此隔离。架构上应明确租户标识如何贯穿账号生命周期、策略如何按租户下发、以及跨租户的管理操作如何留痕。等系统跑起来再补隔离成本远高于一开始就设计清楚。回滚预案必须可演练。任何迁移都可能遇到某个关键应用不兼容新认证这时要能迅速把它切回原目录保证业务不受影响。回滚不是失败而是工程纪律的一部分预案里要写清触发条件、操作步骤、以及回滚后的状态校验并且至少演练一次。常见误区是把统一身份当成再建一套账号结果与原目录长期双轨、数据越漂越乱。正确定位是以原目录为权威源、统一身份为认证与策略中枢权威源唯一才能避免双轨分裂。度量指标建议跟踪一是目录同步的一致性偏差率反映映射质量二是应用接入覆盖率已切到统一身份的应用占比三是切割期因认证不兼容触发的回滚次数反映兼容风险。三者帮助判断迁移是否真正稳住了。常见排查与运维巡检统一身份接管目录服务的故障多数出在同步与兼容两处。同步偏差表现为统一身份侧的账号、组、属性与原目录对不上常见原因是映射规则写得不严谨或源数据本身有重名乱码。排查时应回到属性对照表逐项抽样核对而不是信任自动匹配并定期跑一致性校验把偏差率压到可接受水平。属性错乱的后果是切到统一身份后应用拿到的组织单位、邮箱等字段不对导致授权判断出错。这类问题在切割阶段最易爆发排查要点是确认映射在试同步阶段已验证且切割前有充分的灰度比对而非直接全量切换。应用不兼容是回滚的高发诱因。某个关键应用不支持统一身份颁发的断言切过去后全员登不进只能紧急回滚。排查应在切割前就做兼容性清单对不支持标准协议的系统预先安排反向代理或凭据代填兜底并把不兼容即暂不切作为纪律避免拿核心业务赌兼容性。回滚失败的表现为想切回原目录却切不回去原因多是原目录的认证能力在过渡期已被提前冻结。排查预案时必须明确第四阶段的触发条件与操作步骤且冻结动作要晚于所有应用稳定切割并保留回滚后的状态校验确保退得回去。多租户越权是隔离设计缺位的信号。表现为某租户的账号能看到或影响到另一租户的资源。排查时应确认租户标识贯穿账号生命周期与策略下发跨租户管理操作全程留痕并在上线前做越权渗透测试而非上线后才发现隔离形同虚设。巡检口径建议每周核对目录同步一致性偏差率每月审查应用接入覆盖率与未兼容系统的兜底状态每季度演练一次回滚流程每半年做多租户越权渗透测试确认隔离边界真的成立。行业落地片段与经验沉淀高校的场景是多个院系各自一套目录统一身份先把各院系目录只读同步建镜像再逐步把应用认证切到统一身份原目录退居数据源。经验是四阶段推进、每步可回滚避免全校登不进去。集团企业的多子公司场景考验多租户隔离。经验是租户标识贯穿账号生命周期与策略下发跨租户管理操作全程留痕上线前做越权渗透测试隔离边界才靠得住。医疗机构的合规压力大目录迁移的每一步都要留审计证据。经验是把同步偏差、属性映射、应用兼容性清单、回滚演练都写成可复核文档测评时直接举证而非临时补材料。落地优先级建议统一身份接管目录服务的优先级第一是只读同步与属性映射核对确保数据一致第二是认证代理收口再逐步切割应用第三是保留可演练的回滚预案最后才是原目录冻结与多租户隔离加固。整个过程以权威源唯一、每步可退、审计可举证为纪律避免建成第二套孤岛账号体系。能力成熟度自测统一身份接管目录服务的成熟度自测第一原目录是否仍是唯一权威源、统一身份只做认证与策略中枢建成第二套孤岛账号就是失败。第二同步是否持续、偏差率是否可控并有核对偏差无人管则数据越漂越乱。第三应用接入是否覆盖且不支持标准协议的有兜底覆盖不全则仍有系统看不见。第四回滚预案是否可演练、原目录冻结是否晚于稳定切割退不回去则迁移即成事故。第五多租户隔离是否经越权渗透验证未验证则隔离形同虚设。五问全过迁移才算真正稳住了而非只是把登录入口挪了个地方。延伸阅读与持续优化目录接管完成之后统一身份的重心应从迁得动转向用得好。一方面持续扩大应用接入覆盖把更多系统纳入标准协议对接减少反向代理与代填类兜底另一方面深化多因子与风险画像能力让认证强度随风险动态变化。治理上保持权威源唯一、审计视图统一并随组织调整持续验证多租户隔离。当统一身份成为所有系统的事实入口后续的单点登录、零信任、凭据治理等能力才有共同的基石可依托。方案参考准备用统一身份平台接管现有 AD/LDAP 的团队建议按以下路径落地不推倒重来保留 AD/LDAP 作为过渡期权威源新平台渐进接管绝不清空重建。权威键映射账号映射以工号/邮箱为唯一业务键先跑冲突检测避免用户名同不同人串号字段名逐一建映射清单。单向同步起步过渡期 AD → 统一身份单向同步建立身份映射表与状态同步不双向回写乱目录。按风险切流低敏内部系统先切代理/协议/代填三策略按需高风险财务生产最后切每系统灰度观察。保留回退配置切流后旧 AD 认证配置先并行不删出问题一键退回稳定再关闭原通道。管混合态一致统一登录入口、凭据一致、全域启用/禁用状态联动抽查任一口径禁用是否全域生效。协议选对对接走 LDAP/S、SAML2、OIDC 等标准协议依赖 CAS 的系统勿把平台当 CAS Server改走支持协议或代填兜底。审计留证留存同步映射、各系统切流状态、登录与禁用联动记录作为接管完成与合规举证。选型时确认统一身份平台是否具备标准目录对接与字段映射同步能力、能否在过渡期与 AD/LDAP 安全共存——不具备这些接管就会退化成伤筋动骨的重建工程。