The openldap-server guide does try to take you from wo to go fairly well and the following notes are just extra things that would have been handy to know or were needed to continue.

Configuration

The first ldapmodify commands are add extra DbIndex’s. These are handy to know when you receive errors in syslog such as:

• Apr  3 11:01:18 virt01 slapd[11465]: <= bdb_equality_candidates: (objectClass) not indexed

You can view the current DbIndex values:

• ~$ ldapsearch -xLLL -b cn=config -D cn=admin,cn=config -W olcDatabase={1}hdb olcDbIndex
  Enter LDAP Password:
  dn: olcDatabase={1}hdb,cn=config
  olcDbIndex: objectClass eq
  olcDbIndex: cn eq,pres,sub
  olcDbIndex: uid eq,pres,sub
  olcDbIndex: entryUUID eq
  olcDbIndex: memberUid eq
  olcDbIndex: uniqueMember eq

And index’s can be added using the ldapmodify examples. If you need to delete the entire list and start again these ldapmodify commands will help you:

• dn: olcDatabase={1}hdb,cn=config
  delete: olcDbIndex

The sample of output from my ldap setup above will make an okay base to work with.

I followed the schemas section ok with the exception of a correction of the ldapadd command missing a ‘-W’ arg (prompt for password).

• ldapadd -x -D cn=admin,cn=config -W -f /tmp/ldif_output/cn\=config/cn\=schema/cn\=\{8\}misc.ldif

Populating LDAP

You will now notice with the ldapadd command the reference a second admin principal (cn=admin,dc=example,dc=com). This principal is created with the same password as the first admin (cn=admin,cn=config).

LDAP replication

LDAP replication without TLS was setup within minutes following the guide.

Just be very careful to make sure all modifications are complete and correct before adding the ldif files.

The cn=config replication needs to be applied on both servers, but the dc=example,dc=com replication ldif only needs to be applied on one as once cn=config replication is setup it will replicate the dc=example,dc=com settings to the other server.

The second server also does not need to be setup with all the same changes as the first. Just setup the same domain and password when installing slapd then apply the replication ldif. The additional changes made on ldap01 will be replicated to ldap02 automatically. Once both servers have the ldif applied, then restart slapd on each.

It took a fair while to get replication working again using TLS. Most of my problems were certificate related and couple of missed changes in the TLS replication ldif that would not change back.

TLS and SSL

I created my certificates with CA.pl from an existing CA I have setup for other servers. When creating the certificates make sure that the commonName matches the host name of the server as it will be addressed. Ie:

• Server name: ldap01.example.com
• commonName: ldap01.example.com

TLS verification will fail if you do a ldap search against ldap://ldap01/ (as opposed to ldap://ldap01.example.com/).

I have not yet tested wildcard certificates either. Also the ca-certificate can be referred to either by file (olcTLSCACertificateFile) or the dir containing the cert (olcTLSCACertificatePath). But only referring to the cert by file name worked in my testing even though I added to cert to Ubuntu’s ca-certificate management scheme. Ie:

• sudo cp cacert.pem /usr/share/ca-certificates/Example.Com-CA.crt

• echo 'Example.Com-CA.crt' | sudo tee -a /etc/ca-certificates.conf

• sudo update-ca-certificates

I had to set the SLAPD_SERVICES line to: SLAPD_SERVICES=”ldap:/// ldaps:/// ldapi:///” To allow TLS ldap:// connections from other hosts.

The TLS connections are over ldap:// and SSL is over ldaps://. TLS is the newer and preferred standard, but the ldap:// protocol also allows cleartext communication as a fallback.

To test a TLS connection use:

• ldapsearch -xLLL -b cn=config -D cn=admin,cn=config -W -H ldap://ldap01.example.com/ -ZZ

• -H ldap://ldap01.example.com/ – specifies the hostname. Make sure it is the same as commonName in the certificate used.
• -ZZ – Issues a StartTLS command and requires it succed. Using just -Z issues StartTLS but still allows a cleartext connection if the StartTLS directive fails.

To debug a connection append -d5 to the command. It will spew a lot of output, but in there will most likely be the reason for the cause of the error.

The notes at the end of the TLS replication section are also handy for getting a TLS client connection working. I needed the following line in /etc/ldap/ldap.conf on all hosts:

• TLS_CACERT /etc/ssl/certs/Example.Com-CA.crt

Or if you do not wish to check the validity of certificates then you could use:

• TLS_REQCERT allow

TLS Replication

This should only be attempted once both hosts are confirmed working over TLS. Also make sure you test establishing a TLS connection from one host to the other (ie, running the ldapsearch from ldap01 using -ZZ -H ldap://ldap02.example.com/).

After adding the cn=config TLS change to one host (remember it will be replicated to the other host automatically), then restart both slapd backends (sudo /etc/init.d/slapd restart).

If that is working without any errors in syslog then proceed to the dc=example,dc=com tls replication and restart both backends again.

LDAP Authentication

My next headache was with the auth-client-config command. The correct command to use is:

• sudo auth-client-config -t nss -p lac_ldap

Some sites also note another command that is actually unnecessary:

• sudo pam-auth-update ldap

pam-auth-update allows you to pick which auth methods will be used in your system, but ldap is automatically added when you install libnss-ldap.

Other changes I made to /etc/ldap.conf was uncommenting two lines:

• pam_filter objectclass=account

• ssl start_tls

This requires a user have the objectclass=account attribute to be able to login. And the second requires a TLS connection to the ldap server.

To use TLS for pam auth you will need to make sure the cert is specified in /etc/ldap/ldap.conf just as on the server. This can be tested by running the same ldapsearch command on the client as on the server.

After managing to get that working on one client the rest were managed easily using puppet.

User and Group Management

The command to put the ‘secret’ in /etc/ldapscripts/ldapscripts.passwd will not work as expected if you have a dollar symbol in the password. Ie:

• sudo sh -c "echo -n '$ecret' > /etc/ldapscripts/ldapscripts.passwd"

Will result in an empty passwd file. The correct way to echo the password is to escape the $. Ie: ‘\$ecret’. This is not a problem with the server guide, just an oversight that caught me out. It can be seen in the log file as:

• >> 04/01/09 - 17:23 : Command : /usr/sbin/ldapadduser george example
  ldap_bind: Server is unwilling to perform (53)
          additional info: unauthenticated bind (DN with no password) disallowed
  ldap_bind: Server is unwilling to perform (53)
          additional info: unauthenticated bind (DN with no password) disallowed
  Error adding user george to LDAP

The ldapscripts will also often fail if replication is not working either. Check the output of /var/log/ldapscripts.log.

• >> 04/02/09 - 13:49 : Command : /usr/sbin/ldapadduser george example
  Additional information: value does not conform to assertion syntax
  ldap_modify: Server is unwilling to perform (53)
          additional info: shadow context; no update referral
  Error adding user george to LDAP

That is the ldapscripts log output I get when replication was not working.

Finale

After that was all sorted out I was happy as Larry. Next thing to try is SASL authentication i guess. If anybody wants to point me in the right direction to assist with the Jaunty server guide it would be much appreciated. As well as any more notes and corrections to my post.

I’ve been struggling to find a perfect solution for server monitoring for a while now. At the moment it’s a combination of nagios and cacti plus ipmitool. And recently I have also looked at / tried opennms, zenoss, ganglia, argus and munin.

Nagios + cacti has been serving me well, but I would be happier to only have to maintain one system and to have some auto discover of both systems and their services would make life much easier. Most of the apps I looked though have failed my expectations by either being hogs (some even java based), complicated mashups, or too simple for my needs (not able to replace both nagios and cacti). And that left me with zabbix. But even zabbix has left me with a bad taste by requiring the zabbix-agent be installed on client machines. Are my requirements really to much to ask? Surely there is enough to be gleamed from snmp, ipmi and nmap to monitor both server and desktops.

So. How does you see the required agent? A negative? I can easily install it on all my linux server with puppet, but what about windows, the desktop machines and routers etc? And I have yet to see anything come close to the asset management I’d like either.

But on the plus side for zabbix I have found it fairly well thought out, albeit a little confusing at first.

I cant remember the name of that windows thing I tried a little while ago that sent me on this mission to find a decent linux all-in-one system manager, but it was reasonably forgettable because of the auto-discovery problems it kept presenting with the doubling up of systems on each discovery scan, and it’s inability to be uninstalled.

Anyway I’ll be off for a week to shift house but I’ll give zabbix a good go and report back.