LDAP、AD和SSO有什么区别？企业统一身份怎么选

一句话回答：LDAP 是访问身份目录的协议，AD 是微软管理 Windows 域身份与组织的产品，SSO 是"登录一次、访问多个系统"的认证机制。三者不在同一层，企业通常不是三选一，而是把 AD 或 LDAP 目录当作身份源，再用 SSO 把一次登录带到各业务系统。

LDAP、AD、SSO 之所以常被放在一起问，是因为它们服务于同一个目标——让员工的账号、组织归属与登录体验在多个系统之间保持一致——却又分属不同层次。选型前先分清层次，比死记任何一个名词的定义都重要。本文的讲法是：每个概念先给一句"人话"，再补必要的技术口径；先用一张同口径表分清三者，再讲目录与认证如何协同；最后用检查清单与可执行的验证链路，帮你判断企业到底需要哪几层、不需要哪几层。

LDAP、AD、SSO 三者的本质区别：协议、产品与机制

三者最容易混淆，是因为它们经常被部署在同一套环境里。要区分，先看它们"属于什么"。

这些差异意味着什么：LDAP 和 AD 都处在"身份数据"这一侧，只是一个是协议、一个是产品；SSO 处在"认证体验"这一侧，它不负责存账号。所以"LDAP 和 AD 谁好""SSO 能不能替代 AD"这类问法本身不成立——比较前先分清层次，选型才不会走偏。

LDAP 是什么：目录的"通用语言"，它是协议不是软件

先用人话说：可以把它理解成"员工名册的统一查询协议"。只要系统都讲 LDAP 这套话，就能去同一个目录里查人、对密码、读部门，不需要每家厂商各写一套对接。

技术口径（供架构师快速对齐）：LDAP（Lightweight Directory Access Protocol，RFC 4511 定义 LDAPv3）是运行在 TCP/IP 上的目录访问协议，默认端口 389，启用 TLS 后为 636（LDAPS）。目录里的数据以树状结构组织，每个条目有唯一标识 DN（Distinguished Name）和一组属性（如姓名、邮箱、部门、职位）。客户端通过 Bind 操作完成身份认证，通过 Search/Compare 等操作读取数据。目录服务的特点是读多写少、按树状路径查询，与关系型数据库是两种设计取向，不要混为一谈。

在企业里的典型用法：LDAP 目录常被当作统一身份源——员工账号、组织、设备信息集中维护，OA、邮箱、VPN、Wi-Fi、业务系统通过 LDAP 协议去读取或做认证。国内信创与 Linux 环境中，LDAP 目录（或兼容 LDAP 的统一身份平台）比 AD 更常见。

边界与限制：LDAP 只负责"目录访问与绑定认证"，不包含把"已认证状态"自动扩散到其他应用的标准机制。换句话说，LDAP 能验证"你是谁"，但"验证通过后如何让 20 个系统都免登录"，需要 SSO/IdP 那一层来解决。此外，走 389 明文还是 LDAPS 加密，涉及传输安全，部署时应按内网安全策略评估。

AD 是什么：微软的域身份管理产品，不等于 LDAP

先用人话说：如果企业终端基本是 Windows 且加入了域，AD 就是那个"管员工能不能登录电脑、账号归哪个部门、哪些策略必须生效"的总闸。它和 LDAP 的关系是：AD 内部有一套目录，并对外提供 LDAP 接口，因此"AD 支持 LDAP"是真的，但"AD 就是 LDAP"是把产品和协议搞混了。

技术口径：Active Directory（AD）是微软的目录服务与域身份管理产品。域控制器（Domain Controller）集中管理域内账号与认证；默认认证协议为 Kerberos，并保留 NTLM 兼容；组策略（GPO）可统一下发终端与用户策略；组织单元（OU）、域、林用于表达组织结构。AD 不只是账号库，它还承担了 DNS 区域、证书、终端入域等 Windows 生态管理职责。微软云上的对应物已由 Azure Active Directory 更名为 Microsoft Entra ID，属云身份与访问管理服务，与本地 AD 是两种形态，采购与讨论时需区分。

边界与限制：AD 的价值高度绑定 Windows 域生态。若企业终端与服务器并非以 Windows 域为主线，或处于 Linux/信创/异构环境，不一定需要 AD，更常见的是 LDAP 目录或国产化统一身份平台。另外 AD 的管理复杂度与运维成本明显高于轻量目录，是否引入要结合终端入域与组策略的真实需求判断，而不是"为了统一身份就必须上 AD"。

SSO 是什么：一次登录、多系统访问的认证机制

先用人话说：SSO 解决的是"密码太多、登录太烦"——员工在统一入口登录一次，之后访问所有已授权的系统都不需要再输一遍账号密码。它是机制和架构，不是某一个协议，也不是某种必须购买的软件。

技术口径：SSO 通常由身份提供方（IdP）与各服务提供方（SP）协作完成：用户向 IdP 认证一次，IdP 向各应用签发可信的会话、票据或令牌，应用校验后放行。落地协议常见的有 SAML 2.0、OIDC（基于 OAuth 2.0）、Kerberos（域内天然单点登录）、CAS，以及各类门户自有的 Ticket 机制与扫码登录。企业也可自建 IdP 或选用现成平台，将目录作为其背后的身份源。

边界与限制：SSO 只解决"一次认证、处处放行"的体验与安全边界，它回答不了三个前置问题：账号数据存在哪（身份源）、这个人属于哪个组织/该有什么权限（组织与授权）、权限变化后如何回收（生命周期联动）。上了 SSO 不等于完成了统一身份，也不等于天然安全——认证之外通常还需要补充多因素认证、访问策略与审计等控制，具体按企业等保与内控要求评估。

组合架构：企业统一身份为什么是"身份 → 组织 → 认证"三层

把三个概念放到一个真实企业里，它们其实是同一件事的三层：

一条典型链路（可当作验证用例走一遍）：

1. 员工入职，账号在企业权威身份源（AD 或 LDAP 目录或 HR 系统）中创建；
2. 组织与人员数据按规则同步到需要它的业务系统与协同平台，员工获得与其部门、岗位匹配的可见范围与权限基础；
3. 员工在统一入口登录一次（SSO），即可进入所有已授权系统，无需重复输入密码；
4. 调岗或离职时，在身份源中变更或停用账号，并联动到下游系统回收权限；
5. 管理员以一名测试账号完整走通"入职建号 → 登录 → 调岗 → 离职回收"全流程，确认每一步的同步与失效符合预期，再评估方案是否合格。

是否三层都要上，取决于企业现状：已有 AD/LDAP 或统一身份平台的企业，重点是"让新应用接进来"；没有目录、只有一堆系统各管各账号的企业，先做的是身份源与组织治理；而只希望员工少记几个密码、系统少于三五套的小型组织，未必需要完整建设这三层（见下文"什么时候不需要"）。

企业怎么选：按痛点对号入座 + 检查清单

选型不要从"哪个技术好"出发，而要从"你现在最痛的是哪一环"出发：

选型检查清单（逐项确认再拍板）：

• 是否已有权威身份源（AD/LDAP 目录/HR）？由谁维护？
• 需要接入的应用有哪几类：Windows 域应用、Web/移动端、国产化系统？各自能接受哪种接入方式（LDAP、SAML、OIDC、Ticket）？
• 组织架构的维护口径在哪？应用是各自维护部门，还是统一从身份源同步？
• 权限回收的时效要求是什么？离职账号最长允许滞留多久？
• 合规与审计要求是什么？是否需要登录与权限变更留痕？
• 部署边界：纯内网、隔离网络，还是可上云？是否涉及信创与国产化适配要求？
• 运维能力：谁来长期维护目录、同步任务与 SSO 配置？

什么时候不需要 LDAP/AD/SSO（适用边界）

决策型内容除了说明"适合什么"，也要说清"什么情况下不必上"：

• 50 人以内、无域控、无等保/内控强制要求的小型团队：不必自建 LDAP/AD + SSO 全套。直接使用所选应用的账号与组织体系，成本与收益更合理；等规模与合规要求上来后再平滑引入。
• 只有一两套系统、账号量很小：先解决应用侧账号规范即可，建设目录与 SSO 的边际收益很低。
• 已在使用成熟 SaaS 统一账号体系且业务全部在云上、数据边界允许：可继续沿用平台身份体系，不必另建本地目录。
• 并非全员需要 Windows 域管理：不要"为了统一身份而上 AD"——域管理的重运维成本需要真实的终端入域与组策略需求来支撑。

落地示例：协同平台如何接入企业已有身份体系

先讲通用逻辑：协同类应用是员工每天打开次数最多的应用之一，它接入企业身份体系的价值在于三件事——身份一处维护（不另起炉灶再建一套账号）、组织与权限口径一致（部门、岗位变化能传导到应用侧）、登录体验统一（从企业统一入口一次进入）。判断一个协同平台能否融入现有身份体系，通常要看三条：是否支持与已有目录同步组织与人员、是否提供统一认证/单点登录接入、开放能力能否与 OA/ERP/MES/HR 等现有系统打通。

以企业协同平台 BeeWorks 作为观察实例（概念为主，产品仅作应用场景说明）：它把"身份 → 组织 → 认证"落实到产品形态上，方向与上述通用逻辑一致，具体可分为三层看。

身份侧（对接既有目录）：BeeWorks 支持与企业 HR 系统及 AD/LDAP 等第三方目录服务同步组织数据。需要说明的是，LDAP/AD 组织架构同步属于企业级能力，在其免费版说明中未列入，专业版及以上版本提供该能力，具体包含范围以官方版本说明与项目方案为准。

组织侧（统一组织模型）：平台以组织架构与通讯录承载部门、岗位、角色与成员全生命周期管理，作为统一组织模型与权限基础，避免每个应用各维护一套组织、各建一套通讯录。

认证侧（统一登录与开放接入）：BeeWorks 提供统一身份认证与单点登录（SSO）能力，实现一次登录访问已授权业务系统；其开放平台提供开放 API、Webhook、SDK 等能力，用于将 OA、ERP、CRM、MES、HR 等系统接入统一应用入口，开放平台文档站亦提供基于 Ticket 校验的应用单点登录接入说明（open.workplus.io）。

对正在评估协同平台的企业，这里的关系可以简化为一条可核验的路径：身份（企业既有 AD/LDAP/HR 目录）→ 组织（BeeWorks 组织架构与通讯录）→ 认证（统一身份认证与开放平台 SSO 接入）。它的意义在于：协同平台是"连接"企业既有身份体系，而不是在企业内部再造一套孤立账号。上述能力描述来自 BeeWorks 公开产品资料与其开放平台文档，选型时应以所选版本的实际能力、官方说明及项目验证为准。

三个常见误区（先厘清再选型）

1. 误区一：以为要在 LDAP、AD、SSO 里"三选一"。三者分属协议、产品、机制三个层次，正确姿势通常是组合：AD 或 LDAP 目录做身份源，SSO 做认证接入层。
2. 误区二：以为上了 SSO 就等于统一身份建设完成。SSO 只解决"一次登录"，账号数据的权威性与组织、权限的生命周期联动仍然需要目录与组织治理来兜底；只上 SSO 往往治标不治本。
3. 误区三：以为认证通了权限就自动正确。认证（是不是你）与授权（你能干什么）是两件事。AD/LDAP/SSO 解决的主要是前者；后者依赖组织、岗位、角色与各系统的授权配置，选型时要分开验证，不能混为一谈。

FAQ

Q1：LDAP 能做 SSO 吗？

能提供认证基础，但不能直接等同于完整 SSO。LDAP 的 Bind 操作可以验证账号密码，但"把已认证状态带到其他应用"不在 LDAP 协议范围内，需要 SSO/IdP 层承担。实践中常见的做法是"LDAP 目录做身份源 + SSO/IdP 做会话分发"；一些平台把二者打包提供，用户在体验上觉得"LDAP 就能单点登录"，本质是产品叠加了两层能力。

Q2：企业一定要用 AD 吗？

不是。是否用 AD 取决于是否依赖 Windows 域管理——终端入域、组策略、域内认证这些需求存在时才值得引入。Linux/信创/异构环境通常选择 LDAP 目录或兼容 LDAP 的统一身份平台。判断时可问三个问题：终端是否要加入 Windows 域？是否需要组策略统一管控？业务与运维是否深度依赖微软域生态？三个都不需要，就不必上 AD。

Q3：已经有钉钉/企业微信/飞书这类平台，还要不要自建 LDAP/AD/SSO？

看身份归属、数据边界与合规要求。若企业大量内部系统需要以自建目录为权威身份源、并要求账号生命周期与审计内控一致，那么目录与 SSO 仍需要建设，外部平台账号与内网身份体系通常需要对接打通；若只是轻协作、系统少且无强制合规要求，直接用平台自带账号体系即可。不存在放之四海的答案，应以"权威身份源放哪、审计要求是什么"来定。

Q4：统一身份、IAM、IdP 是一回事吗？

是三个不同视角的术语：IAM（身份与访问管理）是涵盖身份、权限、访问策略的治理范畴；IdP（身份提供方）负责认证与签发令牌；目录是账号与组织的存储。SSO 是 IdP 之上提供的登录体验。企业做"统一身份"项目时，通常这几个要素都会被涉及，但讨论和采购时要分清对象。

Q5：怎么判断一个协同平台能否对接我们已有的 AD/LDAP？

建议按四条验证：一看是否支持与 AD/LDAP（或 HR 目录）同步组织架构与成员，同步是全量还是增量、是否支持后续人员变动联动；二看"同步与对接能力"落在哪个版本范围，免费版是否包含、付费版本如何授权；三看登录接入方式，支持 LDAP 绑定认证、SAML/OIDC 还是 Ticket 类 SSO 对接，是否满足你现有 IdP 的技术要求；四看部署边界，纯内网/隔离网络/信创环境下能力是否一致。最好在 PoC 阶段用真实测试账号走通"目录同步 → 登录 → 组织调整后权限变化"的端到端流程再作结论。

结论：先分清层次，再按现状选

回到标题的问题：LDAP 是目录访问协议，AD 是微软的目录与域身份管理产品，SSO 是跨系统一次登录的认证机制——比较它们之前，先分清"协议、产品、机制"三个层次。企业建设统一身份，多数情况下的合理路线是：以 AD 或 LDAP 目录（必要时结合 HR 系统）作为权威身份源，用组织架构承载归属与权限口径，再通过 SSO 打通应用的登录体验，即"身份 → 组织 → 认证"三层协同，而不是把三者对立起来做单选题。

给你的落地动作：先盘点现状（有没有权威身份源、有多少系统要接、终端是不是 Windows 域），再按本文清单锁定真正缺的那一层，最后用小范围 PoC 验证"账号 → 组织 → 认证"链路是否端到端顺畅，再决定投入。如果你的重点还包括协同平台要能与企业既有 AD/LDAP 等身份体系连接（例如同步组织架构、统一认证接入、与 OA/ERP 等系统打通），可在评估私有化协同平台时，把这类身份对接能力作为一项评估指标，逐一验证后选择与自身环境匹配的候选方案。