HOWTO : OpenLDAP 2.4 sudo Repository on CentOS 6.2

Today we continue with our OpenLDAP series of blog posts. Recall that our goals were :

1. Install OpenLDAP 2.4.
2. Configure Transport Layer Security (TLS).
3. Manage users and groups in OpenLDAP.
4. Configure pam_ldap to authenticate users via OpenLDAP.
5. Use OpenLDAP as sudo's configuration repository.
6. Use OpenLDAP as automount map repository for autofs.
7. Use OpenLDAP as NFS netgroup repository again for autofs.
8. Use OpenLDAP as the Kerberos principal repository.
9. Setup OpenLDAP backup and recovery.
10. Setup OpenLDAP replication.

Since goals 1 to 4 are already achieved in previous blog posts, we are now ready to tackle goal number 5 which is to configure OpenLDAP to be a repository of sudo rules. The official sudo website, the sudoers LDAP manual and the sudo LDAP README file are a good place to start.

Server Configuration

The first thing we need to check the sudo package. We know it is installed because we've been working with it a lot lately. So let's just check which version it is?

rpm -qi sudo | grep -i version
Version     : 1.7.4p5                           Vendor: CentOS

Ok, was it configured --with-ldap? It looks strange to type sudo sudo, but we need to assume UID zero if we want to see the binary's configuration.

sudo sudo -V | egrep -i '^config|ldap'

Configure args: --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --prefix=/usr --sbindir=/usr/sbin --libdir=/usr/lib64 --docdir=/usr/share/doc/sudo-1.7.4p5 --with-logging=syslog --with-logfac=authpriv --with-pam --with-pam-login --with-editor=/bin/vi --with-env-editor --with-ignore-dot --with-tty-tickets --with-ldap --with-ldap-conf-file=/etc/nslcd.conf --with-selinux --with-passprompt=[sudo] password for %p:  --with-linux-audit
ldap.conf path: /etc/nslcd.conf
ldap.secret path: /etc/ldap.secret

From the above output, we can see that this sudo binary has indeed the LDAP configurations and it's using /etc/nslcd.conf as the LDAP configuration path. According to the sudoers LDAP manual, all we need to do now is to add SUDOERS_BASE to /etc/nslcd.conf file. Right?

Wrong :(

The sudo version shipped with CentOS 6.2 (and RedHat 6.2 for that matter) has a bug with sudo. You can find both the CentOS bug and the RedHat bug pages. You can try to configure sudo parameters into /etc/nslcd.conf if you want. But that will only result in an error like this one :

Starting nslcd: nslcd: /etc/nslcd.conf:20: unknown keyword: 'sudoers_base'

So what should we do? Give up? No! We only have to download the latest sudo rpm from the official sudo download site. Simply get the latest binary package for CentOS 6 which is currently sudo-1.8.4-5.el6. So let's download it. NOTE : please don't just copy/paste this wget command, but make sure to grab the latest version of sudo from the official web site. Also, please note that we're using the 64 bit version. Maybe your machine requires the 32 bit version. In that case, the package would be called sudo-1.8.4-5.el6.i386.rpm

wget http://www.sudo.ws/sudo/dist/packages/Centos/6/sudo-1.8.4-5.el6.x86_64.rpm

Make sur to upgrade sudo on all the systems you need to have sudo LDAP enabled...

sudo rpm -U ./sudo-1.8.4-5.el6.x86_64.rpm

Check the new sudo package.

rpm -qi sudo | grep -i version
Version     : 1.8.4                             Vendor: Todd C. Miller

Check to see if it has a different LDAP configuration from the one which comes with CentOS 6?

sudo sudo -V | grep ldap

Configure options: --prefix=/usr --with-logging=syslog --with-logfac=authpriv --with-pam --enable-zlib=system --with-editor=/bin/vi --with-env-editor --with-ignore-dot --with-tty-tickets --with-ldap --with-passprompt=[sudo] password for %p:  --with-selinux --with-linux-audit --with-pam-login

ldap.conf path: /etc/ldap.conf

ldap.secret path: /etc/ldap.secret

And indeed it does. We can see that the ldap.conf file is not /etc/nslcd.conf anymore, but /etc/ldap.conf.

Now that we have a new version of sudo, we must check the LDAP schema that comes with it. 

rpm -ql sudo | grep schema

/usr/share/doc/sudo-1.8.4p4-5.el6/schema.ActiveDirectory

/usr/share/doc/sudo-1.8.4p4-5.el6/schema.OpenLDAP

/usr/share/doc/sudo-1.8.4p4-5.el6/schema.iPlanet

Ok, we need to check the /usr/share/doc/sudo-1.8.4p4-5.el6/schema.OpenLDAP file to find out what are the sudo schema objects?

grep NAME `rpm -ql sudo | grep -i openldap`

    NAME 'sudoUser'

    NAME 'sudoHost'

    NAME 'sudoCommand'

    NAME 'sudoRunAs'

    NAME 'sudoOption'

    NAME 'sudoRunAsUser'

    NAME 'sudoRunAsGroup'

    NAME 'sudoNotBefore'

    NAME 'sudoNotAfter'

    NAME 'sudoOrder'

objectclass ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' SUP top STRUCTURAL

Let's compare this list to our current sudo schema and see if we have access to all those objects? First we need to know in which schemas the sudo objects are defined.

sudo ldapsearch -LLLY EXTERNAL -H ldapi:/// -b cn=schema,cn=config dn

dn: cn=schema,cn=config

dn: cn={0}core,cn=schema,cn=config

dn: cn={1}cosine,cn=schema,cn=config

dn: cn={2}inetorgperson,cn=schema,cn=config

dn: cn={3}collective,cn=schema,cn=config

dn: cn={4}corba,cn=schema,cn=config

dn: cn={5}duaconf,cn=schema,cn=config

dn: cn={6}openldap,cn=schema,cn=config

dn: cn={7}dyngroup,cn=schema,cn=config

dn: cn={8}java,cn=schema,cn=config

dn: cn={9}misc,cn=schema,cn=config

dn: cn={10}nis,cn=schema,cn=config

dn: cn={11}ppolicy,cn=schema,cn=config

dn: cn={12}kerberos,cn=schema,cn=config

dn: cn={13}schema,cn=schema,cn=config

Hummm, that's strange, we don't have a sudo schema. But we did install one in a previous post when we first installed our OpenLDAP server. But wait, what's this strange cn={13}schema,cn=schema,cn=config schema? Let's see if it contains our sudo objects?

sudo ldapsearch -LLLY EXTERNAL -H ldapi:/// -b cn={13}schema,cn=schema,cn=config | grep -i sudo

Sure enough, it contains our sudo objects. But is it complete? We're not sure because this sudo schema came with sudo version 1.7.x while we have sudo version 1.8.x installed now. Let's check which objects are currently in our OpenLDAP schema.

sudo ldapsearch -LLLY EXTERNAL -H ldapi:/// -b cn={13}schema,cn=schema,cn=config | grep NAME | awk '{print $4,$5 }' | sort

NAME 'sudoCommand'

NAME 'sudoHost'

NAME 'sudoOption'

NAME 'sudoRole'

NAME 'sudoRunAs'

NAME 'sudoRunAsGroup'

NAME 'sudoRunAsUser'

NAME 'sudoUser'

When we compare this list of objects to the objects found in the schema.OpenLDAP file from sudo 8.x, we are missing a few objects (i.e. sudoNotAfter, sudoNotBefore and sudoOrder). Plus our sudo schema is not named correctly. So let's change all this. To do so, let's first remove the current sudo schema. According to this mailing-list archive thread, we cannot remove schemas from our OpenLDAP server via ldapdelete(1). So in order to remove the old cn={13}schema,cn=schema,cn=config schema from our OpenLDAP server, we must delete it from the /etc/openldap/slapd.d directory. If anyone knows a better way to remove schemas, please let me know!

sudo /etc/init.d/slapd stop
sudo rm /etc/openldap/slapd.d/cn\=config/cn\=schema/cn\=\{13\}schema.ldif

sudo /etc/init.d/slapd start

Confirm that the old {13}schema is now gone from the configuration.

sudo ldapsearch -LLLY EXTERNAL -H ldapi:/// -b cn=schema,cn=config dn

As expected, the above command returned nothing. We can now generate a new sudo schema in LDIF format. To do so, create a temporary configuration file like this :

rpm -ql sudo | grep -i schema.openldap | sed 's/^/include /g' > ~/ldap/sudo.conf

Next, use slapcat(8C) to generate the new sudo schema in LDIF format.

slapcat -f sudo.conf -F ~/ldap -n 0

This will create the ~/ldap/cn\=config.ldif file and the ~/ldap/cn\=config directory in which our new sudo schema file was generated. It was unfortunately created with the wrong name again. If someone knows how to assign a name to a new LDIF schema, please let me know! So let's change it's name.

cp ~/ldap/cn\=config/cn\=schema/cn\=\{0\}schema.ldif ~/ldap/sudo.ldif

But changing the file name is not enough, we also need to change the dn: and cn: attribute values in the file. A quick sed(1) command does just that.

sed -i.bak -e "s/^dn: cn={0}schema/dn: cn=sudo,cn=schema,cn=config/g" -e "s/^cn: {0}schema/cn: sudo/g" ~/ldap/sudo.ldif

We should now be ready to install our new sudo schema. The OpenLDAP FAQ-O-Matic explains how to do so. But it never worked for me. YMMV of course, but let's use this recipe from the mailing-list archive. It says that we must first remove these objects from the file :

structuralObjectClass:
entryUUID:
creatorsName:
createTimestamp:
entryCSN:
modifiersName:
modifyTimestamp:

Again, a quick sed(1) will take care of that.

sed -i.bak -re "/^(structuralObjectClass|entry[C|U]|creat[e|o]|modif[i|y])/d" ~/ldap/sudo.ldif

If we don't remove those objects, we will see these errors in the sldapd log file :

slapd[10783]: conn=1010 op=2 RESULT tag=105 err=53 text=no global superior knowledge

slapd[10783]: conn=1012 op=2 RESULT tag=105 err=19 text=structuralObjectClass: no user modification allowed

The end LDIF file now should look like this. We can now add it to the directory.

sudo ldapmodify -a -H ldapi:/// -f ~/ldap/sudo.ldif

If you're looking into the server log file, you should see this :

slapd[10783]: conn=1013 op=2 ADD dn="cn=sudo,cn=schema,cn=config"

Confirm that we now have the new schema in place?

sudo ldapsearch -LLLY EXTERNAL -H ldapi:/// -b cn=schema,cn=config dn | grep sudo

Excellent! :)

Let's clean-up a bit, since we don't need the ~/ldap/cn\=config.ldif, ~/ldap/sudo.ldif and ~/ldap/sudo.conf files nor the ~/ldap/cn\=config directory anymore, so we can remove them.

rm -rf ~/ldap/cn\=config* ~/ldap/sudo.*

Convert sudoers to LDAP

Before we convert the sudoers file, let's take a look at an example file.

sudo cat /etc/sudoers

To convert this sudoers file, we need to create yet another LDIF file.

sudo SUDOERS_BASE=ou=sudo,ou=services,dc=company,dc=com perl
/usr/share/doc/sudo*/sudoers2ldif /etc/sudoers > ~/ldap/sudoers.ldif

That generates the LDIF file with our current sudoers configuration translated into LDIF. This all good, but we don't have the LDAP container for sudo yet. Actually, we don't even have our services OU yet. So we need to add a few lines at the start of the file to create the services OU.

vi ~/ldap/sudoers.ldif # This is NOT the final sudoers.ldif file. See below for a complete one.

The rest of the file contains your sudoers configuration. Before we can add this new LDIF file, we must clean it up a bit. The problem are the spaces around the equal signs. If you leave it like this « env_keep = COLORS » instead of like that « env_keep=COLORS » then we will get LDAP errors. This quick sed(1) command will clean things up.

sed -i.bak -e "s/ = /=/g" -re 's/= {0,2}"/=/g' -e 's/"$//g' -e "s/p \+/p+/g" ~/ldap/sudoers.ldif

Almost there, we only need one more sed(1) run to add structure to the LDIF file.

sed -i.bak -e "/^dn: ou=sudo,/a objectClass: organizationalUnit" -e "/^dn: ou=sudo,/a description: sudo" ~/ldap/sudoers.ldif

The end result looks like that :

cat ~/ldap/sudoers.ldif

Now we can add it to our LDAP server.

sudo ldapmodify -aH ldapi:/// -f ~/ldap/sudoers.ldif

We should see this in the server logs :

slapd[10783]: conn=1028 op=2 ADD dn="ou=sudo,ou=services,dc=company,dc=com"

slapd[10783]: conn=1028 op=2 RESULT tag=105 err=0 text=

slapd[10783]: conn=1028 op=3 ADD dn="cn=defaults,ou=sudo,ou=services,dc=company,dc=com"

slapd[10783]: conn=1028 op=3 RESULT tag=105 err=0 text=

slapd[10783]: conn=1028 op=4 ADD dn="cn=root,ou=sudo,ou=services,dc=company,dc=com"

alice slapd[10783]: conn=1028 op=4 RESULT tag=105 err=0 text=

slapd[10783]: conn=1028 op=5 ADD dn="cn=panic,ou=sudo,ou=services,dc=company,dc=com"

slapd[10783]: conn=1028 op=5 RESULT tag=105 err=0 text=

slapd[10783]: conn=1028 op=6 ADD dn="cn=%sysadmin,ou=sudo,ou=services,dc=company,dc=com"

Confirm that we now have a sudoers file in our LDAP server?

sudo ldapsearch -LLLY EXTERNAL -H ldapi:/// -b ou=sudo,ou=services,dc=company,dc=com

Excellent!

But can anybody see our sudoers configuration? That wouldn't be good. Let's find out...

ldapsearch -xZLLLWD cn=drobilla,ou=users,dc=company,dc=com -b ou=sudo,ou=services,dc=company,dc=com -H ldap://alice.company.com

Insufficient access (50)

Good! Exactly how it should be. But can the cn=nssproxy user read the data?

ldapsearch -xZLLLWD cn=nssproxy,ou=users,dc=company,dc=com -b ou=sudo,ou=services,dc=company,dc=com

Normally, we should see all of our sudoers configuration.

Client Configuration

Since we have a working sudo schema along with an LDAP version of our sudoers file, we can now configure client machines to fetch their sudoers data from the OpenLDAP server.

Make sure you install the latest sudo version on the client from the sudo website! See above on how to do this.

Then configure the sudo only /etc/ldap.conf file.

sudo vi /etc/ldap.conf

Fix permissions on the file (it has a password in it...)

sudo chmod 600 /etc/ldap.conf

sudo chown root:root /etc/ldap.conf

Don't forget to place your corporation's CA certificate on the client (if you use one or if you self signed it).

sudo cp ~/companyCA.crt /etc/pki/tls/certs/

Then change the sudoers line (or add it) to /etc/nsswitch.conf. Notice how files is listed before ldap? That's in case we have a general LDAP failure or a network failure. If that happens, then we'll be able to read the local sudoers file.

sudo vi /etc/nsswitch.conf

sudoers: files ldap

And now test our new LDAP-enabled sudo binary. We should see our LDAP sudoers configuration printed on screen.

sudo -l

If we take a look at the /var/log/slapd.log file on the OpenLDAP server, we will see some error messages like these :

slapd[10783]: <= bdb_equality_candidates: (sudoUser) not indexed

To fix this, go back to the OpenLDAP machine and create another LDIF file.

vi ~/ldap/sudoers.indexes.ldif

Add those new indexes to the database.

sudo ldapmodify -H ldapi:/// -f sudoers.indexes.ldif

While keeping an eye on the slapd.log file, run another sudo command from the client we just configured. 

sudo ls

The bdb_equality_candidates errors should now have disapeared.

We thus have achieved our fifth goal!

1. Install OpenLDAP 2.4.
2. Configure Transport Layer Security (TLS).
3. Manage users and groups in OpenLDAP.
4. Configure pam_ldap to authenticate users via OpenLDAP.
5. Use OpenLDAP as sudo's configuration repository.
6. Use OpenLDAP as automount map repository for autofs.
7. Use OpenLDAP as NFS netgroup repository again for autofs.
8. Use OpenLDAP as the Kerberos principal repository.
9. Setup OpenLDAP backup and recovery.
10. Setup OpenLDAP replication.

Next time we will configure an NFS server and use OpenLDAP to store our autofs configuration.

HTH,

DA+