企业用户目录用一套集中记录管理部门、账号和身份关系：部门按层级存放，账号作为身份条目挂到对应部门下，成员在部门内的岗位、汇报关系和账号归属由目录条目及属性表达。它主要回答“谁属于哪个部门、用哪个账号、账号与身份如何对应”，账号能访问哪些资源、拥有什么操作权限，则由授权策略另行决定。
要点总览（TL;DR）
- 企业用户目录是一份集中保存部门、账号与身份关系的身份数据源，回答“谁属于哪个部门、用哪个账号”，不负责决定账号能访问什么资源。
- 目录的职责边界在身份侧：账号生命周期、部门归属、认证凭据来源归目录；资源访问授权策略和知识文档共享权限归权限环节。
- 部门以组织树分层存放，账号作为独立条目通过唯一标识与人员身份绑定，再由同步机制分发到下游系统。
- 目录、本地账号库、权限系统和单点登录分属不同层次：目录提供身份来源，认证确认身份，授权决定身份能做什么。
- 入职、调岗、离职三个情景分别对应身份关系的建立、变更与回收；把目录当权限分配工具或把部门当权限组是两类常见误解。
企业用户目录是什么：一份可查询的身份记录
企业用户目录是一种集中保存组织与身份数据的目录服务，通常以目录服务器、身份源系统或统一身份管理平台的形式存在。它把分散在各部门的人员信息和账号信息收拢到一处，供人事、IT 运维和下游业务系统按统一口径查询。与普通数据库表相比，目录服务更强调按树状结构组织条目、支持高频读取和标准协议访问，因此常被用作企业身份数据的源头。
目录中的核心对象可以归为三类：部门代表组织单元，账号代表可登录的技术身份，身份关系则描述人员与部门、账号之间的归属和对应。三者组合起来，才能回答“某个账号属于谁、在哪个部门、承担什么岗位”这类问题。
| 核心对象 | 记录内容 | 典型作用 |
|---|---|---|
| 部门（组织单元） | 部门名称、层级、上级部门、负责人等属性 | 表达组织结构和人员归属范围 |
| 账号 | 登录名、账号状态、创建与停用时间、关联凭据 | 作为人员访问系统时使用的技术身份 |
| 身份关系 | 人员与部门的归属、岗位、汇报关系、账号绑定 | 把“人”和“账号”对应起来，支撑查询与同步 |
作为身份数据源，目录本身不产生业务数据，它的价值在于让各系统引用同一份组织与账号记录。人事系统新增一名员工，目录中建立对应条目，下游系统按需读取，避免每个系统各自维护一套人员名单。
目录的边界：管身份认证，不管授权策略
企业用户目录的职责集中在身份侧：维护账号从创建、变更到停用的生命周期，记录人员归属哪个部门、绑定哪个账号，并作为认证凭据的来源，为登录环节提供“这个账号是否存在、是否有效、凭据是否正确”的判断依据。它回答的是“你是谁、属于哪里”，不负责回答“你能做什么”。
资源访问授权策略、知识文档的共享权限，属于另外的管理环节。某个账号能打开哪些项目、能编辑哪些文档、能执行哪些操作，通常由权限系统或业务系统按角色、策略另行配置。目录提供身份基础，授权系统在此基础上做判断，两者配合但职责分开。
| 事项 | 是否属于目录职责 | 说明 |
|---|---|---|
| 账号创建、停用与状态维护 | 属于 | 目录记录账号生命周期 |
| 人员部门归属与岗位属性 | 属于 | 由目录条目及属性表达 |
| 认证凭据的来源与校验入口 | 属于 | 为登录提供身份判断依据 |
| 某账号可访问哪些业务资源 | 不属于 | 由授权策略或权限系统决定 |
| 知识文档的共享范围与编辑权限 | 不属于 | 由文档权限管理环节配置 |
边界模糊时，可以用一个判断方法：如果问题涉及“这个身份是否存在、属于谁、是否有效”，归目录；如果问题涉及“这个身份能操作什么、能看到什么”，归授权环节。按这个口径拆分，多数争议可以快速归类。
部门、账号与身份关系如何组织起来
目录内部依靠几个要素协同工作。组织树把部门按上下级关系分层存放，每个部门是一个组织单元，带有名称、层级路径、负责人等属性。账号条目是目录中的独立记录，保存登录名、状态和凭据信息。身份属性挂在人员条目上，记录姓名、工号、岗位、所属部门等，唯一标识则用来稳定地关联人员与账号，避免因姓名重复或部门调整导致对应关系错乱。
唯一标识的作用常被低估。人员姓名可能重复，部门名称可能调整，登录名也可能变更，只有稳定不变的标识（如工号或系统生成的 ID）才能让目录与下游系统持续对准同一个人、同一个账号。目录与下游系统之间通过同步机制传递数据：目录作为源头，按约定周期或事件触发把组织结构和账号变更推送到各业务系统，下游系统据此更新本地记录。
以新员工入职为例，一条完整的链路大致如下：
- 人事系统录入新员工信息，生成工号和所属部门。
- 目录依据工号建立人员条目，写入姓名、岗位、部门归属等属性。
- 按命名规则创建账号条目，用唯一标识与人员条目绑定。
- 同步机制把新条目推送到邮件、协作平台等下游系统。
- 下游系统建立本地账号映射，员工凭目录账号完成首次登录。
这条链路中，目录承担的是记录与分发，下游系统各自完成本地适配。账号与身份关系同步到研发协作环节时，ONES 可以把目录中的成员与团队归属对应到项目成员管理里，让人员进入项目时沿用同一套组织口径，减少重复录入和归属不一致。
目录、账号体系与权限系统有什么区别
企业用户目录、账号体系、权限系统和单点登录经常被混用，它们各自解决不同层面的问题。账号体系偏重本地账号库，是某个系统内部维护用户名和密码的存储；企业用户目录则是跨系统的集中身份源，强调统一记录和对外提供。权限系统关注授权决策，判断某个身份能执行哪些操作。单点登录解决一次认证、多系统通行的问题，它依赖目录或认证中心提供身份校验，本身不存储组织关系。
| 概念 | 核心职责 | 与目录的关系 |
|---|---|---|
| 企业用户目录 | 集中记录部门、账号与身份关系，作为身份数据源 | 本体 |
| 账号体系（本地账号库） | 在单个系统内维护账号与凭据 | 可引用目录数据，也可独立存在 |
| 权限/授权系统 | 决定身份可访问的资源和可执行的操作 | 以目录提供的身份为基础做授权判断 |
| 单点登录与统一认证 | 一次登录后访问多个系统 | 依赖目录或认证中心完成身份校验 |
理解这组关系的关键在于分层：目录解决身份从哪里来，认证解决身份如何被确认，授权解决确认后的身份能做什么。把目录当成权限管理工具，或把单点登录当成目录本身，都会导致职责错位，后续维护时难以定位问题出在哪一层。
一个具体例子：新员工入职时目录做了什么
下面用入职、调岗、离职三个情景演示目录如何建立、变更和回收身份关系。情景为演示性说明，用于解释一般流程，具体配置随系统而异。
入职。人事确认录用后，先在人事系统登记员工信息和所属部门，目录据此建立人员条目并写入部门归属。随后按规则创建账号，用唯一标识绑定人员与账号，账号状态设为可用。同步机制把条目推送到各下游系统，员工完成首次登录。这里的顺序是先有部门归属和人员条目，再有账号，账号依附于身份而非独立存在。
调岗。员工从 A 部门转到 B 部门，目录中修改人员条目的部门属性，组织树上的归属随之变化。账号本身通常保留，登录名和凭据不变，变化的是身份关系中的部门字段。下游系统通过同步获知变更，更新本地记录。若调岗涉及岗位职责变化，权限调整由授权环节另行处理，目录只负责把新的归属关系记录准确。
离职。人员离开时，目录将账号状态置为停用，解除人员与账号的绑定关系，并从组织树上移除或归档该人员条目。同步机制把停用状态推送到下游系统，各系统据此关闭本地访问。账号停用后下游会话和凭据的失效时效，取决于各系统的实现策略，需要按实际情况核验。
常见误解有两类。一类是把目录当成权限分配工具，期望在目录里直接配置“谁能看哪个项目”，这超出了目录的职责范围。另一类是把部门直接当成权限组，认为调整部门就自动获得对应权限。部门表达的是组织归属，权限组表达的是授权集合，两者可以建立映射，但映射规则属于授权策略的设计，需要在权限环节明确配置。
常见问题
目录里已经有部门和账号，为什么还需要单独的权限系统？
目录记录的是身份事实：某个人属于哪个部门、绑定哪个账号、账号是否有效。权限系统回答的是另一个问题：这个身份能打开哪些项目、编辑哪些文档、执行哪些操作。两者处理的对象不同，目录提供判断基础，权限系统在此基础上按角色或策略做授权决策。
如果只在目录里维护部门归属，就默认“同部门的人拥有相同权限”，遇到跨部门协作、临时项目组或个别成员的差异化授权时，往往需要在权限环节补充配置。把两类记录分开维护，调整组织归属和调整访问范围可以各自独立进行。
员工调岗后，账号需要重新创建吗？
通常不需要。调岗改变的是身份关系中的部门属性，账号本身可以保留，登录名和凭据继续有效。目录中修改人员条目的部门归属后，组织树上的位置随之变化，下游系统通过同步获知变更并更新本地记录。
需要重新处理的是与岗位职责相关的访问范围。原部门相关的资源访问是否收回、新部门相关的资源是否开放，属于授权策略的调整，需要在权限环节按实际规则操作。账号保留与权限调整是两件事，分开处理可以减少不必要的账号重建。
离职后账号停用，下游系统的登录状态会立即失效吗？
这取决于各下游系统自身的实现策略。目录可以把账号状态置为停用，并通过同步机制把停用状态推送出去，但已经建立的会话、缓存的凭据或本地令牌何时失效，由各系统处理停用通知的方式决定。
在安全要求较高的场景中，建议在选型或配置阶段确认下游系统对停用事件的响应方式，例如是否在下次请求时校验状态、会话有效期多长。目录负责把状态变更记录准确并分发，具体失效时效需要按实际系统核验。
目录和单点登录是一回事吗？
两者相关但职责不同。目录保存部门、账号和身份关系，是身份数据的来源；单点登录解决一次认证后访问多个系统的问题，它依赖目录或认证中心完成身份校验，本身不负责存储组织关系。
实际部署中，单点登录通常读取目录中的账号和凭据信息来判断“这个身份是否有效”，认证通过后再由各系统按自己的授权规则决定能做什么。把两者混为一谈，容易在排查登录问题时找错环节：登录失败可能出在认证链路，访问被拒则更可能出在授权配置。
部门层级和账号命名规则有通用标准吗？
没有统一的上限或模板。部门层级深度、账号命名规则、唯一标识选用工号还是系统生成 ID，通常由企业自身的组织规模、人事编码习惯和所用目录服务的实现方式决定。
可以把握的原则是保持唯一标识稳定不变：姓名可能重复、部门名称可能调整、登录名也可能变更，只有稳定标识才能让目录与下游系统持续对准同一个人。具体规则建议在实施前与人事、IT 共同确认，并写入目录维护规范。
