LDAP 集成后出现“账号不同步”，先要分清是用户完全无法登录，还是能登录但姓名、部门、状态没有更新。两类现象对应认证链路和目录同步链路，排查起点不同。下面按目录侧、映射与匹配、同步任务、平台生效的顺序给出原因假设、验证证据和定位步骤，并说明修复后的验证与复发预防。
要点总览（TL;DR）
- 先区分两类现象：用户完全无法登录属于认证链路问题，能登录但姓名、部门、状态未更新属于目录同步链路问题，两者排查起点不同。
- 常见原因可归为五类：目录侧连通与查询范围、字段映射、账号匹配冲突、同步任务状态、平台侧缓存与登录方式。
- 定位顺序从目录侧开始：先用绑定账号验证能查到目标用户，再依次核对同步范围、字段映射、匹配规则、任务执行结果与平台账号状态。
- 修改配置或重跑全量同步前先备份配置、明确影响范围并设定停止条件，每步只验证对应现象。
- 修复后按个别用户、部门、全量三层验证，并把同步任务执行结果与错误日志纳入例行巡检。
先分清症状：登录失败与信息不同步是两条排查线
“账号不同步”是一个笼统描述，直接去查同步任务容易走错方向。第一步是把现象拆成可分别验证的两类：一类是用户输入正确凭据仍无法登录，属于认证链路问题；另一类是用户能正常登录，但姓名、部门、组织架构归属或账号状态与目录中的记录不一致，属于目录同步链路问题。两类问题的排查起点不同，前者优先看认证方式与绑定配置，后者优先看同步任务与字段写入。
拆分现象时同步记录三个维度，作为后续对照基线。影响范围决定排查粒度：个别用户异常，通常指向该用户的目录属性、匹配规则或过滤条件；某个部门整体异常，通常指向组织单元范围、Base DN 或部门级过滤；全量用户异常，通常指向网络连通、绑定账号权限、任务未启用或调度失效。发生时间点决定怀疑方向：集成上线后立即出现，多与初始配置有关；运行一段时间后出现，多与目录侧变更、账号状态调整、任务中断或缓存有关。
建议在动手修改前先形成一份症状清单，至少包含：受影响账号示例、所属部门、首次发现时间、现象类型（登录失败或信息未更新）、最近一次目录侧变更（如调岗、改名、离职）。这份清单既是排查起点，也是修复后的验证对照。清单中的每一条都应来自实际观察，例如登录报错截图、账号详情页属性值、同步任务执行记录，避免用“应该是配置问题”这类判断替代证据。
原因假设与排除证据：从目录到平台的五类常见原因
账号不同步的原因可以归为五类：目录侧、映射侧、匹配侧、同步任务侧、平台侧。下表把每类原因写成待验证的假设，并给出对应的验证证据。使用这张表时，先记录观察到的事实，再判断假设成立与否；验证通过的假设才能作为结论，未验证的假设继续保留待查。
| 原因类别 | 常见假设 | 验证证据 |
|---|---|---|
| 目录侧 | 网络不通、端口被拦截、绑定账号密码错误或权限不足、Base DN 或查询过滤器写错，导致查不到目标用户 | 用目录管理工具以同一绑定账号执行相同查询，确认能否返回目标用户及其属性；核对端口、Base DN、过滤器与实际目录结构是否一致 |
| 映射侧 | 属性字段对应关系缺失或写错、必填字段在目录中为空、编码或日期格式不一致，导致写入失败或写入空值 | 对照映射配置逐项检查源属性与目标字段；在目录中查看目标用户的对应属性是否有值、格式是否符合预期 |
| 匹配侧 | 唯一标识（账号名、邮箱等）存在大小写、空格、全半角差异，或与平台已有账号重名，导致账号被跳过或错误合并 | 比对目录账号与平台账号的唯一标识原值；查看同步记录中是否有跳过、冲突或合并提示 |
| 同步任务侧 | 任务未启用、调度周期未生效、增量模式漏掉变更、上次执行报错中断 | 查看任务状态、最近执行时间与执行结果；对照目录侧变更时间与任务执行时间是否衔接 |
| 平台侧 | 缓存未刷新、登录走了本地账号而非目录认证、账号状态被停用 | 查看平台账号详情中的来源与状态；确认登录方式配置；在排除缓存影响后重新验证 |
五类原因之间存在先后依赖：目录侧查不到用户时，映射和匹配都无从谈起；映射正确但匹配冲突时，账号仍可能被跳过。因此验证顺序应与依赖关系一致，而不是按现象猜测逐项试改。另一个常见误区是把“用户说没同步”直接等同于同步任务故障，实际上登录失败可能来自认证配置，信息未更新可能来自字段映射，二者都不必然意味着任务本身出错。
在 ONES 场景中，LDAP 协议服务和 Microsoft AD 服务可用于自动同步组织架构并验证登录，企业微信、钉钉也可作为账号与组织架构来源，非标准目录可通过标准接口更新组织架构。这些能力说明同步与认证是两条并行的链路，排查时也应分别核对：认证侧关注登录方式与目录验证是否生效，同步侧关注组织架构与账号属性是否写入。具体配置项与日志位置以产品文档或实施支持为准。
按顺序定位：从目录连通到平台生效的排查步骤
定位顺序遵循“先上游、后下游，先只读、后修改”的原则。每一步都给出检查动作、判断依据和停止点：判断依据成立才进入下一步，不成立则在该步继续排查，避免在原因未确认时修改多处配置。
第一步，验证目录侧可查询。使用目录管理工具，以同步任务配置的绑定账号和相同参数（服务器地址、端口、Base DN、过滤器）查询一个受影响用户。判断依据是能返回该用户且关键属性有值。若查询失败，检查网络连通、端口可达、绑定账号凭据与查询权限、Base DN 是否覆盖目标用户所在组织单元。此步的停止点是：查询成功返回目标用户后再进入下一步；查询失败时不要修改同步任务配置。
第二步，核对同步范围与过滤条件。查看同步任务配置的查询范围与过滤规则，确认受影响用户落在范围内。判断依据是用户所在组织单元被 Base DN 覆盖，且未被部门、状态、账号类型等过滤条件排除。常见情况是新建部门不在原 Base DN 下，或过滤条件排除了某类账号。此步只做核对与记录，确认范围问题后再调整配置。
第三步，检查字段映射与必填项。对照映射配置，确认姓名、账号、邮箱、部门等关键字段的源属性与目标字段一一对应，必填字段在目录中有值且格式可被接受。判断依据是映射无缺项、抽样用户的属性值能正确对应。编码、日期格式、多值属性的处理方式也在此步核对。
第四步，检查账号匹配与冲突处理。比对目录账号与平台已有账号的唯一标识，确认是否存在大小写、空格、全半角差异或重名。判断依据是唯一标识一致且无冲突记录；若存在冲突，查看同步记录中被跳过或合并的账号，确认处理策略是否符合预期。此步应记录冲突账号清单，作为后续处理的输入。
第五步，查看任务执行结果与平台侧状态。确认同步任务已启用、调度周期生效、最近一次执行成功，并核对平台侧账号的来源、状态与关键属性是否已更新。判断依据是任务执行记录无报错，且平台账号属性与目录一致。若任务成功但平台未更新，检查缓存刷新与登录方式配置；若账号状态为停用，确认是否由目录状态同步而来。
涉及修改配置或重跑全量同步时，先备份当前同步配置与映射规则，明确影响范围（涉及哪些用户和部门），并设定停止条件，例如重跑后冲突账号数量超过预期、或出现大面积账号状态变化时立即暂停。全量同步可能覆盖平台侧已有属性，重跑前应确认平台侧手工维护的字段是否会被覆盖。每一步修改后只验证该步对应的现象，避免同时改动多处导致无法判断哪项修改生效。
在 ONES 中执行上述步骤时，同步任务与账号状态的管理动作可以在同一处衔接：先确认目录侧可查询，再核对同步配置与执行结果，最后在账号详情中核对来源与属性。ONES 支持通过标准接口更新组织架构，适用于非标准目录场景；若企业同时启用 SSO，还需确认登录方式配置与目录验证之间的关系，避免用户走错认证入口。
恢复验证与复发预防
修复后先做单点验证：用受影响用户实际登录，核对姓名、部门、组织架构归属、账号状态等关键属性是否与目录一致。单点验证通过后扩大范围：抽取同一部门的其他用户，确认部门级配置修改生效；再抽查其他部门或全量账号，确认修改未引入新的异常。验证时应使用修复前记录的症状清单逐条对照，而不是只看“能登录了”这一项。
验证通过的标志包括：受影响用户可正常登录；关键属性与目录记录一致；同步任务最近一次执行成功且无新增错误；冲突或跳过账号已按预期处理。若验证中发现新的异常账号，回到定位步骤对应环节继续排查，不重复已确认正常的步骤。
复发预防围绕例行检查展开。把同步任务的执行结果与错误日志纳入日常巡检，关注执行失败、连续跳过、冲突数量异常增长等信号。目录侧的账号变更（离职、调岗、改名、部门调整）应与同步周期衔接检查，确认变更后一个同步周期内平台侧状态已更新。配置变更保留记录，包括修改人、修改内容、修改时间和验证结果，并为关键配置保留可回滚的备份。对于依赖目录状态的账号停用逻辑，定期抽查停用账号与目录状态是否一致，避免离职账号长期保留访问能力。
当组织架构调整频繁时，可缩短巡检间隔或在变更后主动触发一次同步并核对结果；当目录侧由多个系统共同维护时，明确账号属性的权威来源，减少同一字段被不同系统覆盖的情况。这些做法不改变同步机制本身，但能让异常更早暴露，缩短从发现到恢复的时间。
常见问题
目录侧用绑定账号能查到用户，但平台里仍然没有这个账号，下一步该查什么？
目录查询成功说明网络、端口、绑定账号权限和查询范围基本正常，问题更可能出在下游。按顺序核对三处：一是同步任务的过滤条件，确认该用户所在组织单元或账号类型没有被排除；二是字段映射，确认账号、姓名等必填字段在目录中有值且格式可被接受；三是匹配规则，确认唯一标识与平台已有账号不存在大小写、空格或重名冲突。若这三处都正常，再查看同步任务最近一次执行记录，确认任务在目录查询之后确实执行过。
集成上线时同步正常，运行一段时间后部分账号不再更新，通常从哪里入手？
运行一段时间后出现的异常，优先怀疑目录侧发生了变化。常见情况包括：用户调岗后所在组织单元不在原 Base DN 覆盖范围内；账号被改名或更换邮箱，导致唯一标识与平台记录不再一致；目录中账号被停用，同步后平台侧状态随之变化。建议先取一个受影响账号，在目录中核对其当前组织单元、唯一标识和状态，再对照同步任务的查询范围与匹配规则，确认变更后是否仍落在同步范围内。同时查看任务执行记录，确认异常出现的时间点与目录变更时间是否吻合。
重跑全量同步前需要做哪些准备，什么情况下应该暂停？
重跑前先备份当前同步配置与字段映射规则，明确本次重跑涉及的部门和用户范围，并记录平台侧由人工维护、可能被覆盖的字段。设定停止条件，例如重跑后冲突账号数量明显超过预期、出现大面积账号状态变化、或关键属性被写成空值，遇到这些情况立即暂停并回退配置。重跑后先抽查少量账号确认结果符合预期，再扩大验证范围，避免一次性影响全部用户。
用户能登录但部门显示不对，属于同步问题还是登录问题？
能登录说明认证链路已经打通，部门显示不对属于目录同步链路的问题，排查重点在组织架构与属性写入。先确认目录中该用户的部门属性当前值，再核对同步任务的查询范围是否覆盖其所在组织单元、部门字段的映射关系是否正确、以及最近一次同步是否成功执行。如果目录中部门已变更但平台未更新，检查变更时间与同步周期的衔接；如果目录中部门本身未变，则问题可能出在映射配置或平台侧缓存，排除缓存影响后重新核对。
如何降低账号不同步问题再次发生的概率？
把同步任务的执行结果与错误日志纳入日常巡检，重点关注执行失败、连续跳过和冲突数量异常增长。目录侧的离职、调岗、改名等变更，在变更后一个同步周期内核对平台侧状态是否已更新。配置变更保留修改人、内容、时间和验证结果，关键配置保留可回滚备份。组织架构调整频繁时，可缩短巡检间隔或在变更后主动触发一次同步并核对结果；目录由多个系统共同维护时，明确各账号属性的权威来源，减少同一字段被不同系统覆盖。
