[Network Administration]: OpenLDAP on Linux

OK, after the failed attempt to bring everything together with the LDAP server on the Synology NAS, I’m just going to bring up an openldap implementation on my linux box. It’s going to give me more flexibility in the long run anyway. To start, I’m just going to do simple authentication. Easy enough.

I’m using this doc from the Ubuntu documentation: https://help.ubuntu.com/10.04/serverguide/openldap-server.html. There is also a great Admin Guide on the openldap site.
One change is that I did encrypt the root DN user password to the database, which it doesn’t seem like they are doing in the documentation. If you run slappasswd and give it the new password, it will output to stdout the hashed password in the appropriate hash. This can then be used in place of the cleartext password in the LDIF file.

[Update 12/27/2012]:I’m changing some of this from the setup. I’m going to be using the rfc2307bis schema instead of the nis (rfc2307) schema. The rfc2307bis schema is newer, but has languished in draft form (from what I can tell.) The rfc2307bis schema has built in autofs support which I can use also out of the box for OS X and with some tweaks for linux. There are some changes to support the rfc2307bis schema. One of these is the support for posixGroups in the new schema. The objectClass is auxilliary instead of structural as in the nis schema. I’m going attach the posixGroup object onto the groupofuniquenames object for reasons later on. Anyway, I need to create the ldif file for rfc2307bis from the schema file. I got a copy of the schema from here. The later versions of openldap(post 2.3, from what I can tell) already have uidNumber and gidNumber hardcoded, so these need to be removed from the rfc2307bis schema before converting to ldif otherwise slaptest will complain about “Duplicate attributeType: “””, etc. To create the ldif file, I used slaptest. You can also read the openldap.ldif file for what you would need to edit to create an LDIF file from a schema file.
I created a schema.conf config file with the following:

include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/rfc2307bis.schema

Then I ran slaptest like:

slaptest -f schema.conf -F /tmp/ldap

The new ldif files are in the ‘-F’ argument to the command — /tmp/ldap. Lastly, I had to do some cleanup of the LDIF file.
I fixed the header in /tmp/ldap/cn\=config/cn\=schema/cn={2}rfc2307bis.ldif file so that it looks like:

dn: cn=rfc2307bis,cn=schema,cn=config
objectClass: olcShemaConfig
cn: rfc2307bis

I remvoed the {X} indecies for the attributeTypes and olcObjectClasses, and I also removed the footer at the bottom:

structuralObjectClass: olcSchemaConfig
entryUUID: cb3ed780-e1ee-1031-8765-bda612e13bb6
creatorsName: cn=config
createTimestamp: 20121224082226Z
entryCSN: 20121224082226.180848Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20121224082226Z

This allowed me to load the rfc2307bis schema into the server using the ldapadd command from the doc. Now I needed to change what I have to the groups. Mine look like this:

dn: cn=users,ou=groups,dc=ldap,dc=server,dc=tld
objectClass: groupOfUniqueNames
objectClass: namedObject
objectClass: posixGroup
cn: users
gidNumber: 10000
uniqueMember: uid=testid,ou=people,dc=ldap,dc=server,dc=tld
memberUid: testid

With this, I now have the full DN as the uniqueMember. The one issue with groupofuniquenames (or groupofnames) is that the group cannot be empty. I followed the rest of the instructions from the doc above. I needed to add namedObject as an objectClass as posixGroup is no longer a structural object. Originally, I was going to use groupOfUniqueNames, but because of OS X I reverted back to using memberUid and I didn’t want to have multiples of the group members as DN entries and user ids.
You can check that it work with the su command to the testuser. If you need to debug, you can look in /var/log/syslog with the slapd label. Logging of the server can be obtained by setting the attribute olcLogLevel.
This is what I added to the ldif that imported to turn on logging (all logging given the -1 for the value — it is quite verbose)

# Load global attributes
dn: cn=config
objectClass: olcGlobal
cn: config
olcLogLevel: -1

After getting both the server and client up and running, I tweaked some of the parameters of the config file, both for /etc/ldap/ldap.conf and for the pam modules /etc/ldap.conf. I can get the proper information from the accounts if I run getent passwd.

Now that I’ve gotten the LDAP server running, I can also use the ldap-utils and the ldapscripts for the administration.

[Update: 1/26/2012]: Error with Ubuntu 10.04 passwd and LDAP
For failing passwd commands for ldap users:

$ passwd
Enter login(LDAP) password:
passwd: Authentication information cannot be recovered
passwd: password unchanged

Remove the use_authtok from the following line:

password [success=1 user_unknown=ignore default=die] pam_ldap.so use_authtok try_first_pass

[Update: 12/14/2012]: LDAP for WordPress
Got LDAP logins for WordPress working. Since I’ve got a multisite setup, I’ve installed ‘WPMU Ldap authentication’. I tried some of the other plugins also. Mainly I wanted one that would work network wide. One change that I did make in it is to change the default role from subscriber to author as I would like people who sign in to be able to contribute rather than just view the blog. The diff is:

diff -r srv/www/wordpress/wp-content/plugins/wpmuldap/lib/wpmu_ldap.functions.php /srv/www/wordpress/wp-content/plugins/wpmuldap/lib/wpmu_ldap.functions.php
< if (!isset($new_role)) $new_role = ‘subscriber’;

> if (!isset($new_role)) $new_role = ‘author’;
< function wpmuLdapAddUserToBlog($user_id,$blog_id,$new_role = ‘subscriber’) {

> function wpmuLdapAddUserToBlog($user_id,$blog_id,$new_role = ‘author’) {
< add_user_to_blog( $dashboard, $userid, get_site_option( ‘default_user_role’, ‘subscriber’ ) );

> add_user_to_blog( $dashboard, $userid, get_site_option( ‘default_user_role’, ‘author’ ) );
< add_user_to_blog( ‘1’, $userid, get_site_option( ‘default_user_role’, ‘subscriber’ ) );

> add_user_to_blog( ‘1’, $userid, get_site_option( ‘default_user_role’, ‘author’ ) );

Another slight issue is that the group setting does not appear to work with the posixGroup object class that I’ve got set up. The plugin is looking for the list of users for a group to be listed in DN form. However, the posixGroup class lists the users by their user id for the system. Also, I don’t think that it reads the Nickname attribute at least from what I can tell from the LDAP server logs.
[Update 12/27/2012]:With the new rfc2307bis schema and the groupofuniquenames, I was able to get the group permissions working. Since the groups now have the user DN as the uniquemember attribute the ldap group lookup will compare the user DN against the DN in the allowed groups.
[Update 1/21/2013]:Since my standard posixGroup entries are using memberUid, I just added another group with groupOfUniqueNames that I read for my wordpress groups.