20

I am currently working on integrating LDAP authentication into a system and I would like to restrict access based on LDAP group. The only way to do this is via a search filter and therefore I believe my only option to be the use of the "memberOf" attribute in my search filter. It is my understanding that the "memberOf" attribute is an operational attribute which can be created by the server for me anytime a new "member" attribute is created for any "groupOfNames" entry on the server. My main goal is to be able to add a "member" attribute to an existing "groupOfNames" entry and have a matching "memberOf" attribute be added to the DN I provide.

What I have managed to achieve so far:

I'm still pretty new to LDAP administration but based on what I found in the openldap admin's guide, it looks like Reverse Group Membership Maintence aka "memberof overlay" would achieve exactly the effect I am looking for.

My server is currently running a package installation (slapd on ubuntu) of openldap 2.4.15 which uses "cn=config" style runtime configuration. Most of the examples I have found still reference the older "slapd.conf" method of static configuration and I have tried my best to adapt the configurations to the new directory based model.

I have added the following entries to enable the memberof overlay module:

Enable the module with olcModuleLoad

cn=config/cn\=module\{0\}.ldif

dn: cn=module{0}
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_hdb
olcModuleLoad: {1}memberof.la
structuralObjectClass: olcModuleList
entryUUID: a410ce98-3fdf-102e-82cf-59ccb6b4d60d
creatorsName: cn=config
createTimestamp: 20090927183056Z
entryCSN: 20091009174548.503911Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20091009174548Z

Enabled the overlay for the database and allowed it to use it's default settings (groupOfNames,member,memberOf,etc)

cn=config/olcDatabase={1}hdb/olcOverlay\=\{0\}memberof

dn: olcOverlay={0}memberof
objectClass: olcMemberOf
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: {0}memberof
structuralObjectClass: olcMemberOf
entryUUID: 6d599084-490c-102e-80f6-f1a5d50be388
creatorsName: cn=admin,cn=config
createTimestamp: 20091009104412Z
olcMemberOfRefInt: TRUE
entryCSN: 20091009173500.139380Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20091009173500Z

My current result:

By using the above configuration, I am able to add a NEW "groupOfNames" with any number of "member" entries and have all the involved DNs updated with a "memberOf" attribute. This is part of the behavior I would expect. While I believe the following should have been accomplished with the memberof overlay, I still do not know how to do the following and I would gladly welcome any advice:

  1. Add a "member" attribute to an EXISTING "groupOfNames" and have a corresponding "memberOf" attribute be created automatically.
  2. Remove a "member" attribute and have the corresponding "memberOf" attribute" be removed automatically.

2 Answers 2

11

I've been struggling with the same thing, the openldap documentation is minimalist and hardly helpful at all. When they went over to a config database (not a bad idea in principle) all the options changed so when people are giving example from /etc/ldap/slapd.conf it is useless with a modern slapd config (such as Ubuntu).

I finally got this working. Here's the summary... first LDIF file:

dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulePath: /usr/lib/ldap
olcModuleLoad: memberof

Second LDIF file:

dn: olcOverlay=memberof,olcDatabase={1}hdb,cn=config
objectClass: olcMemberOf
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: memberof
olcMemberOfDangling: ignore
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: groupOfNames
olcMemberOfMemberAD: member
olcMemberOfMemberOfAD: memberOf

Add them into the config database using ldapadd (same as normal config stuff).

It does not automatically update the existing data in the database, so I needed to use slapcat to copy everything out into a temporary file, and visit each group, delete the group and add the same group back in again (forces the memberOf attributes to update correctly). If you are starting with an empty database, then it will correctly update the attributes as objects are added.

Also, note that "olcDatabase={1}hdb" is very typical, but not guaranteed to match your setup. Be sure to check that one.

1
  • 1
    Isn't slapadd (onto the stopped database) the right way to do it? Sep 24, 2013 at 16:23
11
+75

I wrote about this recently on my blog, www.jordaneunson.com I copied and pasted the relevant parts in.

What I had to do was stop the "slapd" service on my LDAP server and edit my slapd.conf file and add the following two lines.

moduleload memberof.la
overlay memberof

I already had a groupOfNames called vpn so I then had to create an LDIF file with the following contents:

dn: cn=vpn,ou=Groups,dc=shop,dc=lan
objectclass: groupofnames
cn: vpn
description: Users allowed to connect on VPN
member: uid=jordan,ou=People,dc=shop,dc=lan

And added this to my ldap database

slapadd -f file.ldif

After this I fired up the ldap server in debug to check for errors

slapd -d 99 -f /etc/ldap/slapd.conf 

and checked to make sure that my group membership of “vpn” was listed in my user entry.

ldapsearch -h ldap -x -b "dc=shop,dc=lan" '(uid=jordan)' memberOf 

and bam! success!

jordan, People, shop.lan
dn: uid=jordan,ou=People,dc=shop,dc=lan
memberOf: cn=vpn,ou=Groups,dc=shop,dc=lan

So I fired the slapd service back up and had much success since then. For a new GUI management tool I'm using phpLDAPAdmin and have no problems with the memberOf attribute being assigned and unassigned to my users.

One last thing to note is that the "memberOf" attribute is not part of the basic LDAP v3 schema and thus doing an ldapsearch will not reveal this attribute unless specifically queried. That is why in my above example it is declared at the end of the ldapsearch parameters.

Hope this helps.

Edit: I just tested your problem with Apache Directory Studio: as long as I enter the attribute member value as a whole as mentioned above it works A-OK. However the memberOf attribute does not show up in the user entry. This is because the memberOf attribute is not part of the LDAPv3 schema. To verify that it is there use the command line tool ldapsearch:

ldapsearch -h ldap -x -b "dc=shop,dc=lan" '(uid=jordan)' memberOf 
7
  • 1
    Loading the module and adding the overlay is exactly what I did unfortunately. As I stated the problem isn't that the "memberOf" attributes aren't added for new groupOfNames entries, it's that they aren't being added when I simply add a "member" attribute to an existing group. I'm currently using Apache Directory Studio to browse and configure my LDAP so it does show the memberOf entries when I browse. It's not a matter of them being hidden.
    – emills
    Oct 13, 2009 at 19:28
  • 1
    How are you creating the member attribute in groupOfNames? Is it using the whole DN? like: "uid=user,ou=People,dc=corp,dc=org" or are you just filling in their username? In order for the reverse mapping to work you need to use the whole DN so that memberOf knows where to place the reverse map. Oct 16, 2009 at 19:51
  • 1
    Edit: I just tested your problem with Apache Directory Studio, as long as I enter the attribute member value as a whole as mentioned above it works A-OK. However the memberOf attribute does not show up in the user entry. This is because the memberOf attribute is not part of the LDAPv3 schema. To verify it's there use the command line tool ldapsearch. <code> ldapsearch -h ldap -x -b "dc=shop,dc=lan" '(uid=jordan)' memberOf </code> Oct 16, 2009 at 21:25
  • 1
    I am using the DN in the member entry. It's not a matter of not seeing it, as I stated already, they only get added (and are therefore visible) with a fresh groupOfNames is added, not when I add a member attribute to an exisiting group.
    – emills
    Oct 21, 2009 at 6:59
  • 1
    <quote> they only get added (and are therefore visible)</quote> I'm sorry but this statement is incorrect. The memberOf attribute is not visible unless you specifically query for it. Could you please post the output of the ldapsearch command listed above? Change the user to one who should have a memberOf attribute but does not. Oct 21, 2009 at 17:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .