是否可以在 OpenLDAP 中的两个不同 OU（组织单位）下分配一个用户（条目）？
我正在规划一个全新的 OpenLDAP 服务器的结构，以将其与 Moodle 集成。
我考虑了以下结构：
- O=CompanyName
- OU=项目名称
- uid=UserID001
- uid=UserID002
- uid=UserID003
- OU=项目名称
- uid=UserID002
- OU=项目名称
查看同一用户“uid=UserID002”可以分配在一个或多个项目中。这将使软件和 LDAP 之间的同步变得更加容易。
使用 OpenLDAP 可以做到这一点吗？我听说 IBM LDAP 允许这样做，是真的吗？是否存在任何类型的条目“符号链接”？
I'm planning the structure of a brand new OpenLDAP server to integrate it with Moodle.
I thought about the following structure:
- O=CompanyName
- OU=ProjectName
- uid=UserID001
- uid=UserID002
- uid=UserID003
- OU=ProjectName
- uid=UserID002
- OU=ProjectName
See that the same user 'uid=UserID002' can be allocated in one or more Projects. This would make synchronization between softwares and LDAP easier.
Is it possible to do that using OpenLDAP? I heard that IBM LDAP allow it, is it true? Is there any kind of 'symbolic link' to an entry?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可以使用 LDAP 别名轻松地做到这一点，但在这些情况下的一般想法是对项目节点使用诸如
organizationalRole之类的模式。organizationalRole具有多值roleOccupant属性， 是占据该角色的条目的 DN...而不是在每个项目。因此，您只需在每个项目或所有项目中搜索(roleOccupant={0})，其中{0}是您要检查的 DN。You can do that using LDAP aliases easily enough, but the general idea in these cases is to use a schema such as
organizationalRolefor the project nodes.organizationalRolehas multi-valuedroleOccupantattribute, which are DNs of entries that occupy the role ... rather than creating an entire forest of subcontexts under each project. So you just search each project, or all of them, for(roleOccupant={0})where{0}is supplied as the DN you're checking on.一些目录服务器支持属性唯一性的概念，甚至有一个用于 uid 唯一性的插件。您应该联系您的目录服务器管理员以确定您的本地目录服务是否支持属性唯一性概念，如果支持，则是否为
uid属性配置了属性唯一性。就命名属性唯一性的一般概念而言，您的想法没有什么不应该得到支持 LDAP 标准组的专业质量目录服务器的支持。
uid只是一个属性，在您的示例中，除了它成为相对可分辨名称组件之外，它没有什么特别的。标识目录服务器中的条目的对象是可分辨名称，uid是与任何其他属性一样的属性。根据 RFC4512，LDAP 确实支持别名的概念，但是您的情况不应使用功能。
Some directory servers support the notion of attribute uniqueness, going so far as to have a plugin for uid uniqueness. You should contact your directory server administrator to determine whether your local directory services support the notion of attribute uniqueness, and if it does, is the attribute uniqueness configured for the
uidattribute.As far as the general concept of naming attribute uniqueness is concerned, there is nothing about your idea that should not be supported by a professional-quality directory server that supports the group of LDAP standards.
uidis just an attribute, and in your example there is nothing special about it except that it becomes a relative distinguished name component. The object that identifies an entry in the directory server is the distinguished name, theuidis an attribute like any other.According to RFC4512, LDAP does support the notion of aliases, but that functionality should not be used in your case.
您最好使用
memberOf覆盖层。您可以使用
groupOfNames对象类（已存在）通过member属性指定属于项目条目的成员。您可以根据需要添加任意数量的member属性，其中每个成员属性都是一个（完整）DN。就我个人而言，我会创建自己的 objectClass（例如称为项目）来扩展 groupOfNames 类，以便我可以向其中添加额外的项目相关属性。但这取决于您想要变得多么复杂。
然后，您将重新定义您的结构，如下所示...
这将使您的结构更加清晰，并且项目项（例如 cn=ProjectName）与您的用户条目分开。项目项将是您的 groupOfNames 类，其中包含 OU=People 类中人员的成员属性（例如
member: uid=UserID001,OU=People,O=CompanyName）。当安装到您的 olap 中时，memberOf 覆盖层将执行以下操作：将一个名为
member of的附加属性添加到您的 ldap 搜索结果中（它是动态生成的）。这是一种非常常见的覆盖方式，甚至 AD 服务器也使用这种方式，因此这种方法很常用，您可能会发现 Moodle 会理解它们。
测试设置时需要注意的一点...
ldapsearch查询默认情况下不会显示memberof属性，因此您需要专门询问它。例如;ldapsearch -Y EXTERNAL -H ldapi:/// "(objectClass=groupOfNames)" uid, memberof当我第一次开始使用它们时，这个问题困扰了我。我认为有一个“全部”选项将强制搜索显示隐藏的属性，但目前无法想到它是什么。查看 ldapsearch 的手册页。
无论如何，希望有帮助..:)
You're best to use the
memberOfoverlay.You use the
groupOfNamesobject class (that's already there) to specify members that will belong to project entry using thememberattribute. You can add as manymemberattributes as you want, where each member attribute is a (full) DN.Personally I would create my own objectClass (e.g. called project) that extended the groupOfNames class so I could add extra project related attributes to it. But depends how complex you want to get.
You would then redefine your structure like the following...
This would make your structure a lot cleaner and with the Project items (eg. cn=ProjectName) being kept separate from your user entries. The project items would be your groupOfNames classes that contain member attributes to the people in the OU=People class (e.g.
member: uid=UserID001,OU=People,O=CompanyName).What the memberOf overlay will do, when installed into your olap, will add an additional attribute called
member ofto your ldap search results (it's dynamically generated).This is quite a common overlay that's used, and is even used by AD servers, so this method is commonly used and you might find that Moodle will understand them.
A little thing to watch out for when testing your setup....
ldapsearchqueries won't show thememberofattribute by default, so you will need to specifically ask for it. e.g.;ldapsearch -Y EXTERNAL -H ldapi:/// "(objectClass=groupOfNames)" uid, memberofThat one stumped me when I first started using them. I think there is an 'all' option that will force the search to show the hidden attributes, but can't think what it is at the moment. Check out ldapsearch's man pages.
Anyway, hope that helps.. :)