3. 本地身份与Azure AD集成

在混合云场景中，本地 Active Directory（AD）与 Microsoft Entra ID（原 Azure AD）的集成是业务迁移的第一道门槛。用户既要在本地域登录文件服务器、ERP，又要访问 Microsoft 365、Azure 门户和 SaaS 应用，如果两套身份各自独立，账号、密码、组和权限就会分裂。Azure AD Connect（现称 Microsoft Entra Connect）正是把这两套目录“缝合”起来的同步与认证引擎。本节围绕它的部署、三种认证方式的选择与实现展开。

一、Azure AD Connect 的角色与部署前提

Azure AD Connect 的核心职责有两层：一是目录同步，把本地 AD 的用户、组、联系人及其属性写入 Entra ID；二是认证配置，决定用户登录 Entra ID 时密码在哪里校验。它通过一个名为 AD DS Connector Account 的本地账号读取 AD，通过 Entra ID Connector Account 写入云端，并借助 SQL Server Express LocalDB 保存同步元数据（Metaverse）。

部署前需要确认几个硬性条件：本地 AD 林功能级别至少为 Windows Server 2008，域控可被同步服务器访问；同步服务器建议独立成员服务器，不装域控角色，操作系统为 Windows Server 2016 及以上；需要具备企业管理员或域管理员权限来创建连接器账号；Entra ID 侧需要全局管理员或混合身份管理员完成初始配置。此外，若使用联合身份验证，还需规划 AD FS 与 WAP（Web 应用代理）服务器。

安装时选择“快速设置”还是“自定义”取决于拓扑。单林单域、无特殊过滤需求可用快速设置；多林、多域、需要属性级过滤或自定义同步规则时，必须走自定义路径。安装向导会依次完成：连接 AD 林、连接 Entra ID、配置登录方式、选择同步范围（全部 OU 或指定 OU）、启用同步。建议在正式同步前用 Start-ADSyncSyncCycle -PolicyType Initial 触发一次初始同步，并在 Synchronization Service Manager 中观察“Connectors → AD → Entra ID”的导入、同步、导出三个阶段是否全部成功。

二、密码哈希同步（PHS）：最简单也最常用的方式

密码哈希同步的原理是：本地 AD 在用户改密时，域控把密码的 NTLM 哈希经 Azure AD Connect 同步代理计算为 MD4 哈希，再经过两次加盐哈希（先对 MD4 哈希加固定盐做一次 SHA256，再对结果加随机盐做一次 SHA256），最终得到不可逆的 PBKDF2 派生值写入 Entra ID。Entra ID 只保存这个派生值，无法还原出原始密码，因此 PHS 并不等于“把密码上传到云”。

启用 PHS 后，用户在本地改密，约两分钟内即可用新密码登录 Microsoft 365。若同步服务器离线，改密不会立即生效，但 Entra ID 仍保留上一次的哈希，用户可继续用旧密码登录，直到同步恢复。PHS 还支持“密码写回”（Password Writeback），让用户在 Entra ID 自助改密后回写本地 AD，这需要 Entra ID P1 许可。

PHS 的优点是部署简单、不依赖本地可用性、支持泄露凭据检测；缺点是密码策略以本地 AD 为准，且无法实现本地 AD 被锁定时的即时阻断。对于大多数希望快速上云、又不想改造认证链路的企业，PHS 是首选。

三、直通认证（PTA）：密码校验留在本地

直通认证把密码校验动作保留在本地。用户在 Entra ID 输入密码后，Entra ID 把加密的校验请求发给部署在本地的一台或多台 PTA 代理，代理再向域控发起 Kerberos 或 NTLM 校验，把结果返回云端。密码哈希始终不离开本地，满足“密码不出域”的合规要求。

PTA 代理需要安装在成员服务器上，通过出站 443 端口连接 Entra ID，无需入站端口。多台代理可组成高可用组，Entra ID 会轮询分发请求。若所有代理离线，用户将无法登录云端，因此至少部署两台并监控其健康状态。PTA 支持与 PHS 共存作为备用认证方式：当 PTA 不可用时自动回退到 PHS，这是生产环境常见的容灾组合。

PTA 的典型适用场景是：企业有明确的密码不出本地要求，但又不愿承担 AD FS 的运维复杂度。它比联合身份验证轻量，但比 PHS 多了一层本地依赖。

四、联合身份验证：把认证完全交给 AD FS

联合身份验证（Federation）使用 AD FS 作为身份提供者（IdP）。Entra ID 把登录请求重定向到企业自建的 AD FS 登录页，AD FS 完成认证后签发 SAML 令牌，Entra ID 信任该令牌并放行。此时密码校验、多因素、条件访问策略的触发点都在本地 AD FS。

联合方案需要部署 AD FS 服务器（建议至少两台）、WAP 服务器（对外发布 AD FS）、内部 CA 签发的令牌签名证书，并在 Entra ID 中配置域名联合。它的优势是支持智能卡、证书认证、第三方 MFA 等本地强认证手段，且可精细控制登录页；代价是运维复杂、证书需轮换、AD FS 故障会直接导致云端登录中断。因此联合方案通常用于已有 AD FS 投资、或监管要求认证完全自主可控的大型组织。

五、三种认证方式的对比与选择

下表从密码位置、本地依赖、高可用、典型场景四个维度对比三种方式，便于选型时快速判断。

实际项目中，常见做法是“PHS 为主 + PTA 备用”或“PTA 为主 + PHS 兜底”，既满足合规，又保证云端登录不因本地单点故障而中断。选择时先问三个问题：密码是否允许离开本地？本地认证组件能否接受停机风险？是否已有 AD FS 或强认证需求？答案会直接指向对应方案。

无论选择哪种方式，部署完成后都应做三项验证：用 Get-ADSyncScheduler 确认同步周期正常；在 Entra ID 门户的“登录日志”中查看用户登录是否命中预期认证方式；用测试账号在本地改密后验证云端登录是否在预期时间内生效。只有这三项都通过，身份集成才算真正落地，后续的业务迁移才有可信的身份底座。