Posted on by admin

Univention memberOf Attribute Saga

When I initially built the main part of my lab, I wanted to have a Domain Controller for centralized authentication. I decided upon using Univention Corporate Server as my domain controller. I never ended up using it for centralized authentication, though it has been very easy to maintain for a local DNS server to avoid DNS loopback problems with my ISP.

After working with separate accounts on all my services long enough, I decided it would be a good time to move at least some of my core services to use centralized authentication. I spin up and experiment with services often enough that I’ll never have 100% of it centralized, but the frequently used ones can at least be easier to login to without memorizing multiple passwords.

The first service I worked on for this was Grafana. I tried getting it to authenticate my admin user previously, however I always had issues getting it to give me admin in Grafana for that privilege was based on the user group. I decided to figure it out this time around.

After running some manual ldapsearch commands on my server, I found the culprit, the memberOf attribute.

Administrator@ucs:~$ ldapsearch -xLLL -D uid=auth-grafana,cn=users,dc=rapternet,dc=us -W ui    d=administrator
Enter LDAP Password:
dn: uid=Administrator,cn=users,dc=rapternet,dc=us
uid: Administrator
krb5PrincipalName: Administrator@RAPTERNET.US
uidNumber: 2002
sambaAcctFlags: [U          ]
krb5MaxLife: 86400
cn: Administrator
krb5MaxRenew: 604800
loginShell: /bin/bash
univentionObjectType: users/user
displayName: Administrator
sambaSID: S-1-5-21-3990746676-2282511386-955537671-500
gecos: Administrator
sn: Administrator
homeDirectory: /home/Administrator
gidNumber: 5000
sambaPrimaryGroupSID: S-1-5-21-3990746676-2282511386-955537671-512
univentionPolicyReference: cn=default-admins,cn=admin-settings,cn=users,cn=pol
 icies,dc=rapternet,dc=us
description: Built-in account for administering the computer/domain
objectClass: krb5KDCEntry
objectClass: univentionPerson
objectClass: person
objectClass: automount
objectClass: top
objectClass: inetOrgPerson
objectClass: sambaSamAccount
objectClass: organizationalPerson
objectClass: univentionPWHistory
objectClass: univentionMail
objectClass: univentionObject
objectClass: shadowAccount
objectClass: krb5Principal
objectClass: univentionPolicyReference
objectClass: posixAccount
univentionUMCProperty: appcenterSeen=false
univentionUMCProperty: udmUserGridView=default
univentionUMCProperty: favorites=updater,appcenter:appcenter,udm:computers/com
 puter,udm:users/user,udm:groups/group,udm:dns/dns
shadowLastChange: 17459
mail: administrator@rapternet.us
mailPrimaryAddress: administrator@rapternet.us

Doing a bit of google search lead me to the reason why, the memberOf attribute requires extra configuration to run on openLDAP, and that was not the default when I initially created my UCS VM.

Univention Corporate Server memberOf Attribute

UCS versions 4.3-0 and up have the memberOf overlay enabled by default. Since mine was built before that, I have to manually enable it. The process is simple enough with the following commands.

ucr set ldap/overlay/memberof=yes
service slapd restart
/usr/share/univention-ldap-overlay-memberof/univention-update-memberof

I found out that my administrator user couldn’t run the UCR command, though it could be run as root (my administrator user didn’t have the right PATH setup to use the UCR terminal command, though maybe thats also a legacy upgrade problem).

Since my first attempt to run the UCR command failed. I decided to make the registry update in the webgui. I found out later that it was available to the root user (shown below) but since I didn’t try that till after making the changes.

UCR Terminal Command Problem

After trying the UCR command and having it fail as my administrator user, I decided to investigate why it didn’t work.

Administrator@ucs:~$ ucr
-bash: ucr: command not found

I also tried running it as root, and that worked. Since I was able to use the ucr command as root, I checked the path UCR was running from.

root@ucs:/home/Administrator# which ucr
/usr/sbin/ucr

And yes, my administrator user was missing UCR from the path.

Administrator@ucs:~$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games

While my root user had the UCR path included in its PATH variable

root@ucs:/home/Administrator# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

This is something to update later, and is just a side tangent for the current adventure.

UCR Update

The UCR WebUI can be found under System → Univention Configuration Registry. This worked well and was simple enough to do, I still had to run the update on the command line to build the intial memberOf attribute dataset.

Administrator@ucs:~$ /usr/share/univention-ldap-overlay-memberof/univention-update-memberofmodify cn=Domain Admins,cn=groups,dc=rapternet,dc=us
modify cn=Domain Users,cn=groups,dc=rapternet,dc=us
modify cn=Domain Guests,cn=groups,dc=rapternet,dc=us
modify cn=Windows Hosts,cn=groups,dc=rapternet,dc=us
modify cn=DC Backup Hosts,cn=groups,dc=rapternet,dc=us
modify cn=DC Slave Hosts,cn=groups,dc=rapternet,dc=us
modify cn=Computers,cn=groups,dc=rapternet,dc=us
modify cn=Backup Join,cn=groups,dc=rapternet,dc=us
modify cn=Slave Join,cn=groups,dc=rapternet,dc=us
modify cn=Authenticated Users,cn=Builtin,dc=rapternet,dc=us
modify cn=Enterprise Domain Controllers,cn=groups,dc=rapternet,dc=us
modify cn=Domain Controllers,cn=groups,dc=rapternet,dc=us
modify cn=Schema Admins,cn=groups,dc=rapternet,dc=us
modify cn=Enterprise Admins,cn=groups,dc=rapternet,dc=us
modify cn=Group Policy Creator Owners,cn=groups,dc=rapternet,dc=us
modify cn=Denied RODC Password Replication Group,cn=groups,dc=rapternet,dc=us
modify cn=Administrators,cn=Builtin,dc=rapternet,dc=us
modify cn=Users,cn=Builtin,dc=rapternet,dc=us
modify cn=Guests,cn=Builtin,dc=rapternet,dc=us
modify cn=piwigo_users,cn=groups,dc=rapternet,dc=us
modify cn=piwigo_admins,cn=groups,dc=rapternet,dc=us
modify cn=piwigo_webmasters,cn=groups,dc=rapternet,dc=us

I then rebooted the system than restarting the slapd service (I had other updates that required the restart).

Checking for the memberOf Attribute

Using another ldapsearch after the reboot, I wanted to check to make sure everything was enabled properly.

Administrator@ucs:~$ ldapsearch -xLLL -D uid=auth-grafana,cn=users,dc=rapternet,dc=us -W uid=administrator \* +
Enter LDAP Password:
dn: uid=Administrator,cn=users,dc=rapternet,dc=us
uid: Administrator
krb5PrincipalName: Administrator@RAPTERNET.US
uidNumber: 2002
sambaAcctFlags: [U]
krb5MaxLife: 86400
cn: Administrator
krb5MaxRenew: 604800
loginShell: /bin/bash
univentionObjectType: users/user
displayName: Administrator
sambaSID: S-1-5-21-3990746676-2282511386-955537671-500
gecos: Administrator
sn: Administrator
homeDirectory: /home/Administrator
structuralObjectClass: inetOrgPerson
entryUUID: 53ddf1e8-121f-1036-9fa4-2b28a36a0e86
creatorsName: cn=admin,dc=rapternet,dc=us
createTimestamp: 20160918191037Z
gidNumber: 5000
sambaPrimaryGroupSID: S-1-5-21-3990746676-2282511386-955537671-512
univentionPolicyReference: cn=default-admins,cn=admin-settings,cn=users,cn=policies,dc=rapternet,dc=us
description: Built-in account for administering the computer/domain
objectClass: krb5KDCEntry
objectClass: univentionPerson
objectClass: person
objectClass: automount
objectClass: top
objectClass: inetOrgPerson
objectClass: sambaSamAccount
objectClass: organizationalPerson
objectClass: univentionPWHistory
objectClass: univentionMail
objectClass: univentionObject
objectClass: shadowAccount
objectClass: krb5Principal
objectClass: univentionPolicyReference
objectClass: posixAccount
univentionUMCProperty: appcenterSeen=false
univentionUMCProperty: udmUserGridView=default
univentionUMCProperty: favorites=updater,appcenter:appcenter,udm:computers/computer,udm:users/user,udm:groups/group,udm:dns/dns
shadowLastChange: 17459
mail: administrator@rapternet.us
mailPrimaryAddress: administrator@rapternet.us
entryCSN: 20200830190753.356900Z#000000#000#000000
modifyTimestamp: 20200830190753Z
memberOf: cn=Domain Admins,cn=groups,dc=rapternet,dc=us
memberOf: cn=Domain Users,cn=groups,dc=rapternet,dc=us
memberOf: cn=DC Backup Hosts,cn=groups,dc=rapternet,dc=us
memberOf: cn=Schema Admins,cn=groups,dc=rapternet,dc=us
memberOf: cn=Enterprise Admins,cn=groups,dc=rapternet,dc=us
memberOf: cn=Group Policy Creator Owners,cn=groups,dc=rapternet,dc=us
memberOf: cn=Administrators,cn=Builtin,dc=rapternet,dc=us
memberOf: cn=piwigo_users,cn=groups,dc=rapternet,dc=us
memberOf: cn=piwigo_admins,cn=groups,dc=rapternet,dc=us
memberOf: cn=piwigo_webmasters,cn=groups,dc=rapternet,dc=us
modifiersName: cn=admin,dc=rapternet,dc=us
entryDN: uid=Administrator,cn=users,dc=rapternet,dc=us
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE

I finally see the memberOf attribute showing in my LDAP searches, and now at least know that I can get the groups and use them in Grafana, Portainer, etc. I can now start reconfiguring some of my services to authenticate against it using the administrators group thats default in UCS as my baseline admin group.

Administrator@ucs:~$ ldapsearch -xLLL -D uid=auth-grafana,cn=users,dc=rapternet,dc=us -W uid=administrator memberOf
Enter LDAP Password:
dn: uid=Administrator,cn=users,dc=rapternet,dc=us
memberOf: cn=Domain Admins,cn=groups,dc=rapternet,dc=us
memberOf: cn=Domain Users,cn=groups,dc=rapternet,dc=us
memberOf: cn=DC Backup Hosts,cn=groups,dc=rapternet,dc=us
memberOf: cn=Schema Admins,cn=groups,dc=rapternet,dc=us
memberOf: cn=Enterprise Admins,cn=groups,dc=rapternet,dc=us
memberOf: cn=Group Policy Creator Owners,cn=groups,dc=rapternet,dc=us
memberOf: cn=Administrators,cn=Builtin,dc=rapternet,dc=us
memberOf: cn=piwigo_users,cn=groups,dc=rapternet,dc=us
memberOf: cn=piwigo_admins,cn=groups,dc=rapternet,dc=us
memberOf: cn=piwigo_webmasters,cn=groups,dc=rapternet,dc=us

Conclusion to the memberOf Saga

This was an interesting adventure into some of the inner workings of my domain controller. Since LDAP isn’t something I commonly work on, this provided a good amount of insight into debugging the system and some of the other portions of UCS that are there to configure the system.

Not long after getting the attribute setup in LDAP, I was able to authenticate my administrator user against grafana and get administrative rights in it without any changes to my LDAP configuration on the service. My Grafana group configuration was correct all along, with the only problem being a misconfiguration on my UCS LDAP server.

Resources

Proudly powered by WordPress