MemberOf only on DC Master?

UCS - Univention Corporate Server
, ,
#1

Hello,

I’ve installed the memberOf overlay module today (first on slaves, last on master). The I’ve run the script on the DC Master. But it seems to be working only on the DC Master:

univention-ldapsearch uid=username memberOf

On the DC Slaves and the DC Backup the result is empty (not the output of course).

Is this the expected behavior?

EDIT: I’ve checked for replication errors already.

#2

Hey,

please check the UCR variable ldap/overlay/memberof on the affected servers. If is set to false, set it to true and run /usr/share/univention-ldap-overlay-memberof/univention-update-memberof afterwards.

Kind regards,
mosu

#3

It’s everywhere set to true.

#4

Hey,

please run the script regardless of the value of said variable. Then run the search again.

Please note that the attribute is only output if it’s actually requested:

[0 root@uma ~] univention-ldapsearch uid=mosu | grep -i memberof
[1 root@uma ~] univention-ldapsearch uid=mosu memberof | grep -i memberof
# requesting: memberof
memberOf: cn=vj,cn=groups,dc=ucstest,dc=bunkus,dc=org

Kind regards,
mosu

#5

I’ve run rerun the script

/usr/share/univention-ldap-overlay-memberof/univention-update-memberof

I’ve also tried this:

ucr set ldap/overlay/memberof='true'
systemctl restart slapd.service

But the output is still the same:

# univention-ldapsearch uid=username memberof | grep -i memberof
# requesting: memberof
#6

Hey,

I’ve just verified that the following steps work on my installation where the overlay was disabled:

  1. Set the corresponding UCR variable: ucr set ldap/overlay/memberof=true
  2. Make sure it is actually enabled in the slapd.conf file. The following should return a line containing overlay memberof: grep 'overlay.*memberof' /etc/ldap/slapd.conf
  3. Restart the LDAP server: systemctl restart slapd.service
  4. Search for a user requesting the memberOf attribute: univention-ldapsearch uid=mbunkus memberof

Kind regards,
mosu

#7

Strange, but it doesn’t help.

#8

Have you made sure your slapd.conf contains the following section:

moduleload                       memberof.so
overlay                          memberof
memberof-group-oc        posixGroup
memberof-member-ad       uniqueMember
memberof-memberof-ad     memberOf
memberof-dangling        ignore
memberof-dn                      cn=admin,dc=ucstest,dc=bunkus,dc=org
memberof-refint          false

(with your DN for memberof-dn, of course)

#9

Yes:

#       /etc/univention/templates/files/etc/ldap/slapd.conf.d/41univention-ldap-overlay-memberof
moduleload                       memberof.so
overlay                          memberof
memberof-group-oc        posixGroup
memberof-member-ad       uniqueMember
memberof-memberof-ad     memberOf
memberof-dangling        ignore
memberof-dn                      cn=admin,dc=top2,dc=top1
memberof-refint          false
#10

Hey,

looks good. Welp, I’m out of of ideas for the time being :frowning_face:

m.

#11

Hey,

addendum. I wrote above that I got it working. However, that was on a DC Master.

I’ve now run into the same problem you’ve described on a DC Slave (on 4.3-0, but that shouldn’t matter in this case). After installing & enabling the overlay, after running the update script, an LDAP search didn’t show the memberof attributes.

What helped was simply re-joining the DC Slave into the domain. Directly after univention-join had completed, an LDAP search did output the memberOf attribute. So just re-join both your DC Backup and DC Slave and see if that helps. The process isn’t dangerous as no data will be lost.

Kind regards,
mosu

1 Like
#12

Ok thank you for the hint.

I’ve also added a user to a group and the memberOf attribute is there for all members of this group.

#13

Hey,

hmm… maybe you could try running that script /usr/share/univention-ldap-overlay-memberof/univention-update-memberof once more on the DC Master (instead of on the DC Backup/DC Slave) before trying the re-join and see if that makes a difference. What that script seems to be supposed to be doing is to trigger an update to the membership of all groups so that the LDAP server updates its memberOf overlay automatically. It’s possible that such a change doesn’t actually work on DC Slave/DC Backups as the Master’s OpenLDAP is the only writable one in a domain (the OpenLDAP structure is a classical single master/multiple slaves structure with the Master’s OpenLDAP being the master — unlike the Samba LDAPs where all AD DC LDAPs are writable and where bi-directional synchronization takes place).

#14

Rerunning doesn’t help. But before I’ll try a rejoin, I’l do a migration to the MDB backend. Maybe this will help.

#15

The migration doesn’t help.

Mastodon