OpenLDAP gidNumber与组成员关系不一致的AD/OpenLDAP互操作问题咨询

你遇到的这个问题本质是AD和OpenLDAP在用户-组关联机制上的核心设计差异导致的，我来帮你拆解清楚：

核心差异：OpenLDAP的gidNumber≠AD的primaryGroupID #

• 在AD中，primaryGroupID是隐式的组成员关系标识：用户即使不在组的member列表里，只要primaryGroupID匹配组的objectSid后缀，就会被视为该组的成员，同时memberOf属性会自动包含这个组。这是AD特有的设计。
• 但在OpenLDAP里，gidNumber只是用户对象的一个属性，仅用于指定用户在类Unix系统中的默认组ID，它不会自动建立和对应组的成员关系。OpenLDAP的组成员关系完全由组对象的member属性决定——也就是说，只有当用户DN出现在组的member列表里，才会被视为该组的成员。

为什么会出现你看到的配置？ #

你提到的情况（user1的gidNumber对应group1，但group1的member只有user2）是完全合法的OpenLDAP配置，可能的原因包括：

• 管理员手动修改了组的member属性，但忘记同步更新用户的gidNumber；
• 该配置是为了让user1在Linux系统中默认使用group1的权限，但不需要在LDAP层面拥有group1的组权限；
• 同步工具只同步了用户的gidNumber字段，没有同步组的member属性。

你的互操作工具逻辑存在问题 #

现在的问题出在新的互操作工具上：它错误地把OpenLDAP的gidNumber直接等同于AD的primaryGroupID来处理，这违背了两者的设计逻辑。

• 在你的场景中，user1本来不是group1的成员（OpenLDAP的member列表里没有他），但工具通过gidNumber把他映射成group1的主组，覆盖了AD里原本的primaryGroupID（Domain Users），这就导致权限判断出错——你本来想拒绝group1成员的访问，结果user1被错误归类，失去了访问权限。

解决建议 #

1. 紧急恢复：先把AD中user1的primaryGroupID改回Domain Users，恢复他的正常访问权限；
2. 修正工具逻辑：
   • 方案一：让工具同步OpenLDAP的member属性到AD的组成员关系，同时仅当用户在OpenLDAP中确实是某个组的成员（出现在member列表）时，才将该组映射为AD的主组；
   • 方案二：让工具忽略OpenLDAP的gidNumber，保留AD原生的primaryGroupID逻辑，仅同步明确的member成员关系；
3. 规范OpenLDAP配置：如果需要保持gidNumber和组成员关系一致，建议在OpenLDAP中维护两者的同步——当修改用户的gidNumber时，自动把用户添加到对应组的member列表，反之亦然。

备注：内容来源于stack exchange，提问作者marismmm