前言

在企业信息化建设中，一个常见诉求是：员工继续使用本地 AD 域账号，同时能够无缝访问 Office 365、Teams 等云端应用，并在统一策略下完成认证与权限控制。

这个问题的本质并不是“本地目录还是云目录二选一”，而是如何在安全、体验、合规之间取得平衡。混合身份认证正是为此而生：既保留本地目录的管理基础，又借助云端身份服务提升统一登录能力与安全治理能力。

本文会围绕实际落地最常遇到的核心问题展开：

  • AD 与 Entra ID 的职责边界与协作关系
  • PHS、PTA、ADFS 三种方案的取舍逻辑
  • 面向教育/组织接入场景的扩展实践（如 OneRoster、外部目录接入）
什么是混合身份认证？

Hybrid Identity 是指通过本地目录（如Microsoft Active Directory、OpenLDAP 等）与云目录（如 Microsoft Entra ID、Google Cloud Identity 等）的集成，为用户提供统一的身份验证和授权机制。这种解决方案允许用户使用单一身份访问本地和云中的资源，无论资源的位置如何。具体场景如下：

  • 允许你或你的组织内的用户，使用 Azure AD 登录你开发的应用。
  • 允许其他组织的用户，使用 Azure AD 登录你开发的应用。
为什么会有混合身份认证，是否可以不使用本地目录，而完全依赖云目录？

取决于企业的具体需求，包括现有架构、协议支持、网络条件、合规性要求等。对于大多数企业，采用混合架构（本地目录+云目录）可能是更现实的选择。

我们能做的？
  • 了解术语概念
    • 业务相关
    • 沟通需要
    • 理解深层次架构
  • 提供产品方向
  • 解决技术问题

一、基础概念

  1. 身份 (Identity)： 用户/设备/服务的唯一代表（用户名、邮箱等）。
  2. 认证 (Authentication, AuthN)： 证明“你是谁”（密码、指纹、短信验证码、MFA）。
  3. 授权 (Authorization, AuthZ)： 决定“你能做什么”（RBAC角色权限、ABAC属性权限）。
  4. 身份生命周期： 创建账号 -> 启用 -> 更新（改密码） -> 禁用 -> 删除。

IAM、IDP、IDM三者共同构成了现代企业身份管理与安全体系

  1. IAM (身份与访问管理):
    • 目标： 确保正确的人/物在正确的时间访问正确的资源。
    • 核心： 管身份（谁）、管认证（验身份）、管授权（给权限）。
    • 举例：RBAC、MFA
  2. IDP (身份提供者):
    • 作用： 存身份信息 + 做认证。
    • 举例： Entra ID、公司AD、Google、微信登录。
  3. IDM (身份管理):
    • 作用： 管身份的一生（创建、更新、禁用、删除）。
    • 工具： Azure AD Connect、SailPoint（自动化账号）。
三者关系
  • IAM 是宏观体系，依赖 IDM 提供数据、IDP 提供认证，但自身核心是权限管理。
  • IDM 和 IDP 可独立使用，但在企业级场景中通常被纳入 IAM 架构。
  • 选择解决方案时需明确需求：
    • 只需统一账户管理？→ IDM
    • 只需单点登录？→ IDP
    • 需要全流程管控？→ IAM 平台（含 IDM + IDP 功能）

二、本地目录与云目录

  1. AD (Active Directory):
    • 本质： 本地目录服务（装Windows Server上）。
    • 功能： 管公司电脑登录、管文件服务器权限、用Kerberos认证。
  2. AAD / Microsoft Entra ID (原Azure AD):
    • 本质： 云身份服务（SaaS）。
    • 功能： 管Office 365等云应用登录、做SSO、安全策略（如强制MFA）、支持B2B/B2C。
    • 入口： https://entra.microsoft.com

AD 与 Entra ID (原AAD) 核心关系

特性 Active Directory (AD) Microsoft Entra ID (原AAD)
类型 本地目录服务 (装Win Server上) 云身份服务 (IDaaS)
核心作用 管本地内网登录、权限、组策略 管云应用访问、SSO、安全策略、B2B/C
主要协议 LDAP, Kerberos SAML, OIDC, OAuth 2.0
登录对象 公司电脑、本地应用 Office 365, SaaS应用, 手机App
关系 互补协作 (通过Azure AD Connect连接) 不是替代
现代/云核心 ❌ ✅
关键协作点 混合身份认证 (PHS/PTA) 同步用户 成为统一的访问控制点与策略执行层

一句话总结： AD管好本地基础，Entra ID作为通向云端和现代化应用的身份桥梁与安全控制中心。两者通过Azure AD Connect紧密协作。

三、关键技术与协议

  1. LDAP： 查改目录信息（AD用它）。
  2. Kerberos： AD域内安全登录协议（不用传密码）。
  3. SSO协议 (让登录一次通行多个应用):
    • SAML 2.0： 企业网页应用常用（如用AD登录Salesforce）。
    • OIDC (OpenID Connect)： 现代APP/网页常用（如用微信登录）。
    • OAuth 2.0： 授权协议（授权App访问你的资源），常配合OIDC。
  4. SCIM： 自动同步用户账号信息（如人事系统 -> AD/Entra ID）。

四、微软混合身份认证 (本地AD + 云Entra ID)

image-20250728150908254

微软工具：Azure AD Connect

  • 功能： 同步本地AD用户到Entra ID。
  • 核心方法：
    1. 密码哈希同步 PHS (Password Hash Synchronization) ：
      • 同步密码哈希到云（单向），登录在云验证。最简单常用。
      • 优点： 快（云验证）、云灾备可用。
    2. 直通认证 PTA (Pass-through Authentication) ：
      • 登录时云把密码传给本地代理，由本地AD验证。
      • 优点： 强制本地密码策略。
    3. 联合认证 ADFS (Active Directory Federation Services) ：
      • 登录重定向到本地认证服务器 (如ADFS)。
      • 缺点： 复杂，依赖本地服务器。尽量少用。

企业微信截图_5f8d3cc5-8ec0-40ad-b023-4286b9f4bdda

方法 密码在哪验证? 优点 缺点 微软推荐 适用场景
PHS (哈希) 云 简单、快、云灾备登录 本地策略更新有延迟 首选 可以接受密码哈希存储在云端
PTA (直通) 本地 (经代理) 强制即时本地密码策略 需代理+本地在线，稍慢 ✅ 需要保持密码验证在本地，对实时身份验证有要求
联合 (ADFS) 本地 (ADFS) 协议兼容性强 复杂、慢、依赖本地服务器在线 ❌ (特殊情况) 1）需要与不支持现代认证协议的遗留应用集成，比如只支持SAML 2.0 的应用。2）合规性要求，需要保持身份验证完全在本地。

五、其他玩法

1、Google Cloud Directory Sync (GCDS)

类似微软的 Connect，Google 提供了 GCDS 工具，用于将本地 Active Directory 用户同步到 Google Workspace。部署在内网环境即可，只需要确保服务器能够访问 Active Directory 和 Google Workspace API。但是也有跟我们同样的问题，无法同步密码。

优势
  • 单向同步：确保本地 Active Directory 的数据不会被修改，仅更新 Google Workspace 的数据。
  • 安全可靠：GCDS 运行在本地服务器，所有数据同步过程都在本地完成，不会将敏感的 Active Directory 数据暴露到外部。
那么 Google 怎么处理密码问题

用户首次登录 Google Workspace 时，强制用户重置密码。

2、OneRoster（主要针对教育场景，脱离混合身份认证范畴）

OneRoster 是由 1EdTech 联盟制定的一种行业标准，用于在教育机构的系统之间安全、可靠地交换教师学生信息、课程数据和成绩数据。它旨在解决教育机构在数据同步和管理上的需求，尤其是在 学生信息系统 (SIS) 和 学习管理系统 (LMS) 之间的数据交换问题。

（OneRoster 已经成为教育技术领域的重要标准，ClassLink、Microsoft 和 Google Workspace 教育版等厂商均使用了 1EdTech 的 OneRoster 标准）

具体流程（以微软的实现举例）

sequenceDiagram participant SDS as School Data Sync (SDS) participant SIS as SIS (支持 OneRoster API) participant Entra as Microsoft Entra ID participant Teams as Microsoft Teams Note over SDS: 同步周期开始 (每12小时) SDS->>SIS: 1. 获取 OAuth 2.0 访问令牌
(client_id + client_secret) SIS-->>SDS: 返回访问令牌 (access_token) loop 增量数据请求 SDS->>SIS: 2. 调用 OneRoster API
GET /users?filter=dateLastModified>{lastSyncTime} SIS-->>SDS: 返回增量用户数据 SDS->>SIS: 3. 调用 OneRoster API
GET /classes?filter=dateLastModified>{lastSyncTime} SIS-->>SDS: 返回增量班级数据 SDS->>SIS: 4. 调用 OneRoster API
GET /enrollments?filter=dateLastModified>{lastSyncTime} SIS-->>SDS: 返回增量注册关系数据 end SDS->>SDS: 5. 数据验证与转换
• 检查必填字段
• 映射用户角色
• 关联班级-用户关系 SDS->>Entra: 6. 同步用户账户
• 创建/更新教师账号
• 创建/更新学生账号 Entra-->>SDS: 返回同步结果 SDS->>Entra: 7. 创建 Microsoft 365 组
• 每个班级对应一个组
• 教师设为所有者
• 学生设为成员 Entra-->>SDS: 返回组创建结果 SDS->>Teams: 8. 为每个班级创建 Team
• 关联 Microsoft 365 组
• 添加班级频道
• 配置作业/文件结构 Teams-->>SDS: 返回 Team 创建状态 SDS->>SDS: 9. 记录同步元数据
• 更新 lastSyncTime
• 生成同步报告 Note over SDS: 同步完成，等待下次周期

六、应用思考

思考：如何让其他域的组织登录到我们的系统？比如，某个学校教师或学生使用类似 xxx@edu.com 的域账号登录我们系统。（以下应用场景主要是解决我们实际的业务场景，不一定与混合身份认证有关）

1、使用 LDAP 协议连接外部 AD，导入到我们系统

1）这是当前已支持的产品方案，使用 AMS 连接学校的 AD，通过指定 BaseDN 和 Filter 过滤条件等，过滤出符合条件的所有成员信息。

2）通过设置的映射关系找到成员邮箱，生成随机密码导入到 Account。

3）教师收到邮件，邮件里有随机密码，教师通过自己的域账号 + 随机密码登录。

弊端

1）学校需要将 AD 开放外网，并配上证书等。Active Directory 和其他 LDAP 服务器存储了大量敏感信息，例如用户身份、密码哈希和组织结构，会增加数据暴露的风险。

2）出于安全原因，AD 不允许通过 LDAP 拿到用户密码，教师目前是通过随机密码登录，后续自己修改。

3）需要我们自己通过定时器去做账号的自动同步。

image-20250728164343037

2、使用 Connect 连接 AD 与 AAD

1）学校组织部署 Connect 进行 AAD 与 AD 之间的连接，包括 PHS 和 PTA 等方式。

2）AMS 接入 AAD OpenAPI，或者使用 LDAP 连接 AD DS，导入到 Account 上，不需要密码，在用户三方登录后初始化密码。

3）AMS 仍然可以对账号进行控制，比如能否登录大板，是否有某个应用的 License。

4）教师接入 AAD 三方登录，教师登录时重定向到 AAD 登录界面，直接输入 AD 的账号密码即可，认证成功后跳转到我们系统。

优势：域账号信息完全保持一致，可以使用域账号密码登录。

劣势：需要组织管理员部署 Connect。

注：如果组织属于政府单位，要求强合规，LDAP 的任何数据都不能外泄，那么可以使用 AD FS 方式进行混合认证。

image-20250728164400479

3、AD设备导入

从 AD 快速批量导入设备到 AMS，在 AMS 控制设备的账号模式、访客模式等。

image-20250728192731589

4、提供同步工具

参考 Google 的做法，开发一个 Windows 或者 Linux 的工具，给学校部署，相比后台连接 LDAP 更有优势。（但不太建议，这是大厂的做法，建立在 Google 公信力的基础上）

5、使用 OneRoster

大致流程如下

1、AMS 负责连接支持 OneRoster 的 SMS 系统，请求 SMS 的 OneRoster API 拿到教师数据，同步添加到 AMS 用户列表，并在 Account 上批量注册用户。

2、其他的班级课堂等数据，也可同步到 Class Pro。

sequenceDiagram participant SDS as AMS participant SIS as SMS (支持 OneRoster API) participant Entra as Account participant Teams as Class Pro Note over SDS: 同步周期开始 (每12小时) SDS->>SIS: 1. 获取 OAuth 2.0 访问令牌
(client_id + client_secret) SIS-->>SDS: 返回访问令牌 (access_token) loop 增量数据请求 SDS->>SIS: 2. 调用 OneRoster API
GET /users?filter=dateLastModified>{lastSyncTime} SIS-->>SDS: 返回增量用户数据 SDS->>SIS: 3. 调用 OneRoster API
GET /classes?filter=dateLastModified>{lastSyncTime} SIS-->>SDS: 返回增量班级数据 SDS->>SIS: 4. 调用 OneRoster API
GET /enrollments?filter=dateLastModified>{lastSyncTime} SIS-->>SDS: 返回增量注册关系数据 end SDS->>SDS: 5. 数据验证与转换
• 检查必填字段
• 映射用户角色
• 关联班级-用户关系 SDS->>Entra: 6. 同步用户账户
• 创建/更新教师账号
• 创建/更新学生账号 Entra-->>SDS: 返回同步结果 SDS->>Teams: 7. 创建组
• 每个班级对应一个组
• 教师设为所有者
• 学生设为成员 Teams-->>SDS: 返回组创建结果 SDS->>Teams: 8. 添加班级频道
• 配置作业/文件结构 Teams-->>SDS: 返回创建状态 SDS->>SDS: 9. 记录同步元数据
• 更新 lastSyncTime
• 生成同步报告 Note over SDS: 同步完成，等待下次周期

参考

https://mslearningcampus.com/User/Login?ReturnUrl=%2F（AAD 登录）

https://old-docs.authing.cn/connections/azure-ad.html

https://learn.microsoft.com/en-us/entra/architecture/auth-ldap

https://www.1edtech.org/

https://support.google.com/a/answer/106368?hl=zh-Hant