Himmelblau项目：从本地AD迁移至Entra ID时保留UID/GID的技术方案

Himmelblau项目：从本地AD迁移至Entra ID时保留UID/GID的技术方案

himmelblau Azure Entra ID Authentication for Linux 项目地址: https://gitcode.com/gh_mirrors/hi/himmelblau

背景介绍

在企业身份管理系统迁移过程中，从本地Active Directory(AD)过渡到Azure Entra ID(原Azure AD)时，如何保留现有的用户ID(UID)和组ID(GID)是一个常见的技术挑战。Himmelblau作为身份管理解决方案，提供了多种技术路径来实现这一目标。

核心挑战分析

传统SSSD配置通常依赖本地AD的LDAP接口来获取用户和组的POSIX属性。当企业决定完全迁移到Entra ID并停用本地AD时，这些UID/GID映射关系将面临丢失的风险。这会导致文件系统权限、服务账户配置等一系列依赖这些ID的系统出现问题。

解决方案一：自定义Entra ID应用扩展属性

实现原理

通过在Entra ID租户中创建自定义应用程序，可以添加POSIX属性作为目录扩展属性。这些属性包括：

• uidNumber(用户ID)
• gidNumber(组ID)
• unixHomeDirectory(用户主目录)
• loginShell(登录shell)
• gecos(用户描述信息)

实施步骤

1. 创建自定义应用：使用Microsoft Graph API创建专门用于存储POSIX属性的应用
2. 添加扩展属性：为应用添加上述POSIX属性字段
3. 创建服务主体：为应用创建服务主体使其成为企业应用
4. 数据迁移：将现有AD中的POSIX属性迁移至这些扩展属性中

技术要点

• 属性数据类型选择：UID/GID应使用Integer类型(32位值)
• 属性命名规则：实际存储时会自动添加"extension_[AppID无横线部分]_"前缀
• API版本差异：获取扩展属性需要使用Beta版Graph API

解决方案二：混合模式过渡方案

实现原理

在过渡期间，可以同时配置：

• SSSD：仅用于NSS(名称服务切换)，负责提供UID/GID映射
• Himmelblau：负责PAM(可插拔认证模块)认证

适用场景

• 需要逐步迁移的复杂环境
• 暂时无法完全停用本地AD的情况
• 作为完全迁移前的临时方案

方案对比与选型建议

| 方案 | 优点 | 缺点 | 适用场景 | |------|------|------|----------| | 自定义应用扩展 | 完全云原生，无需本地AD | 需要开发工作，属性管理复杂 | 长期云化目标，技术能力强的团队 | | 混合过渡方案 | 改动小，风险低 | 依赖本地AD，非最终方案 | 过渡期使用，简单快速实施 |

实施注意事项

1. 测试验证：任何方案都应先在测试环境验证
2. 数据备份：迁移前确保所有POSIX属性有备份
3. 变更窗口：规划适当的维护窗口进行切换
4. 监控机制：实施后建立监控机制确保无异常

总结

Himmelblau项目提供了从本地AD迁移至Entra ID时保留UID/GID的完整技术路径。企业可根据自身技术能力和迁移策略，选择创建Entra ID自定义应用扩展或采用混合过渡方案。无论选择哪种方案，都应遵循分阶段实施、充分测试的原则，确保身份管理系统的平稳过渡。

himmelblau Azure Entra ID Authentication for Linux 项目地址: https://gitcode.com/gh_mirrors/hi/himmelblau