为什么混合云需要统一身份？与Active Directory
容易忽略的细节
先看一个真实场景：一家公司办公楼里跑着Active Directory域控，员工用域账号登录电脑、访问内部文件服务器。业务扩张后，公司把一部分应用迁移到了阿里云或AWS上，云上资源通过IAM（身份与访问管理）控制权限。结果每个运维人员要记两套密码，开发人员想调用云API还得单独申请密钥。更糟的是，员工离职时HR在AD里禁用了账号，但云上IAM里的权限却忘了清理，留下了安全隐患。
这就是混合云身份割裂的典型问题。要想让本地AD和云上IAM“握手”，核心就是解决两点：身份互信和网络可达。身份互信指云上能识别来自AD的用户并信任其身份凭证，同时AD也能理解云上发出的身份令牌。网络可达则是互信的前提——如果本地AD服务器和云IAM服务连不通，一切信任机制都是空谈。
先搞懂几个关键概念
1. Active Directory域控是做什么的？
AD域控就像一个“员工花名册+门禁系统”。它存储了所有用户的账号、密码、所属部门、权限组等信息。你登录公司电脑时输入的密码，就是AD在后台校验。AD还负责管理策略，比如强制每月改密码、限制某些人访问敏感文件夹。对企业来说，AD通常是身份管理的“权威来源”。
2. 云上IAM又是什么？
云服务商的IAM相当于“云资源的门禁”。它定义了谁（用户或角色）能对哪些云资源（比如一台云服务器、一个数据库）做什么操作（读、写、删）。IAM里可以创建独立用户，也可以关联本地用户。很多云厂商都支持外部身份提供者（IdP），允许把云IAM的信任交给AD这样的第三方身份源。
3. 身份互信的本质：SAML与OIDC
让AD和IAM互相信任，最常用的协议是SAML（安全断言标记语言）和OIDC（OpenID Connect）。打个比方：AD就像一个“身份签发处”，可以签发一张“通行证”（SAML断言或OIDC ID Token），上面写着“张三，属于IT部门，有管理员权限”。云IAM拿到这张通行证后，通过验证签发处的签名（需提前配置元数据），就认可张三的身份，并按通行证上的权限分配云资源。
这个过程叫联合身份认证。AD作为身份提供者（IdP），云IAM作为服务提供者（SP）。用户访问云控制台时，会被跳转到AD的登录页，输入密码验证通过后，AD生成通行证并返回给云，云验证后放行——全程密码不上云。
4. 网络可达：信任的物理基础
无论用SAML还是OIDC，用户浏览器和云IAM之间确实能通过公网通信。但AD服务器通常在公司内网，没有公网IP。这时要打通网络才能真正“握手”。常用的方式有：
- VPN连接：在本地和云VPC之间建立IPsec VPN，让云上的请求可以路由到AD服务器。
- 专线直连：通过运营商的光纤或MPLS专线，实现低延迟、高稳定的内网互通。
- 云网络架构：在云上创建VPC，通过路由器与本地网络打通，配置路由表和防火墙规则允许AD相关端口（比如389 LDAP、636 LDAPS、88 Kerberos）通过。
注意：如果只是做Web SSO（单点登录），用户浏览器能直接访问AD的登录页面即可，AD需要能被外网访问（通常通过反向代理或DMZ）。但为了更安全的同步（比如从AD同步用户组到IAM），往往需要直接服务器间的网络可达。
实操路径：从零搭建混合云统一身份
第一步：选定身份代理或联合方案
企业可以自建联合认证基础设施，比如使用Windows Server AD FS（Active Directory 联合身份验证服务）。AD FS安装在一台能同时被内网用户和云SP访问的服务器上，它负责把AD的身份转换成SAML/OIDC令牌。云IAM侧导入AD FS的元数据文件，建立信任关系。
如果不想自建，也可以使用第三方IdP服务（比如Okta、Azure AD），它们可以桥接本地AD和多家云IAM。对于阿里云，可以直接用阿里云RAM角色与AD FS对接；AWS则使用IAM身份中心（原AWS SSO）与AD FS联合。以下以阿里云为例简述流程：
- 在本地部署AD FS，配置Relying Party Trust（依赖方信任）指向阿里云RAM。
- 导出AD FS的联合元数据XML，上传到阿里云RAM的身份提供商（IdP）配置中。
- 在AD FS中创建颁发规则，将AD组的成员映射到阿里云RAM角色。
- 用户访问阿里云时，选择“使用企业IdP登录”，跳转到AD FS登录页，验证通过后直接进入阿里云控制台。
第二步：确保网络可达与安全
网络可达分为两层：
- 面向用户：用户浏览器需要能解析并连接到AD FS的域名（可以是公网域名，通过防火墙映射到内网AD FS）。建议使用HTTPS证书，并开启双因素认证加固。
- 面向服务器：如果要从云IAM同步用户组或属性到本地AD（反向同步），需要云VPC与AD服务器之间网络打通。配置内网DNS解析，让云服务器能通过域名或IP访问AD的端口（389、636、88）。安全组和防火墙只放行必要的IP和端口，避免将AD暴露到公网。
第三步：测试与验证
创建测试用户，在AD FS中分配一个云IAM角色。尝试用该用户登录云控制台，确认能正常跳转、认证并通过角色权限访问资源。检查云IAM中的身份提供商日志，确认断言解析正确。如果失败，常见原因包括：时间不同步（SAML对时间戳敏感）、证书不匹配、属性映射错误。
相关阅读：此处可内链到“Active Directory常见问题”专题。
常见误区与避坑指南与Active Directory
验证与回滚
- 认为VPN就够了：VPN只解决网络层连通性，但身份互信还需要应用层协议（SAML/OIDC）的配合。VPN打通后，一定要确保AD FS能被云SP的终端服务器访问（比如云IAM的断言消费者端点）。
- 忽略端口和协议限制：AD域控用Kerberos和LDAP，这些协议在跨公网时容易被防火墙丢掉。建议LDAP改用LDAPS（636端口），或者通过AD FS代理认证，避免直接暴露AD。
- 用户组同步不完整：很多企业依赖AD组织单位（OU）和组来管理权限，但云IAM只能识别用户属性（如组名）。需在AD FS中正确映射组SID或distinguishedName，确保用户能继承正确的角色。
- 忘记回滚方案：一旦联合认证配置出错，所有用户可能都无法登录云平台。务必保留一个本地IAM管理员账号（非联合用户），用于紧急排障。
想继续深入：此处可内链到“Active Directory优化清单”文章。
关联教程：此处可内链到“Active Directory部署与验证”内容。
补充参考：此处可内链到“Active Directory故障排查实例”。
总结：统一身份是混合云的第一步
先看关键判断
让本地AD域控和云上IAM互信，本质上是建立一种身份层面的“翻译桥”。网络可达是桥墩，SAML/OIDC是桥面，AD FS或类似代理是造桥的工程队。对企业来说，这一步走顺之后，才能实现真正的单点登录、权限统一回收，以及后续的零信任架构落地。不要贪快，先从一个小业务开始测试，逐步扩大范围。混合云的身份整合虽然技术细节多，但原理并不复杂——只要理解“谁来发证、谁来验票、路通不通”，你就能向业务方讲清楚为什么需要这个改造。把这些步骤跑通后，Active Directory基本就能稳定落地。
延伸阅读