Notes on ubuntu-8.10-serverguide-openldap

By karl | Published: April 3, 2009

After deciding to learn to setup OpenLDAP yesterday I realised it was more than a days work, and that the documentation that I thought was going to be the most suited for my platform left a lot of holes for the beginner. I also had a firefox window with all the sites I used as a reference open in tabs, but then decided to print out some colouring pictures for the kids and one site kept crashing firefox (and ruined my day). So no citing references sorry, most of this information was only grepped from google eventually anyway.

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.

This entry was posted in Server, Ubuntu and tagged ldap, openldap, pam, replication, serverguide, ssl, sysadmin, tls, Ubuntu, ubuntu-8.10. Bookmark the permalink. Both comments and trackbacks are currently closed.

17 Comments

David Dana

April 5, 2009 2:42 pm

Outstanding article! Thanks for taking the time to write this out!

This really helped me out and I can’t believe the official docs don’t have this info.
Foerster

April 6, 2009 9:46 am

Hi,

first of all, thx for this article…

I was trying to set up a ldapserver for testing purpose and I followed the same serverguide Tutorial. With your help, I managed to come to the point where I have to restart my server (sudo /etc/init.d/slapd restart).
But then, the deamon could not be started. The debuginfo gives me a

main: TLS init def ctx failed: -207

Any idea? I created the certs, everything and I also ran the commands you suggested in the TLS and SSL section. I’ve tried it now the 5th time from scratch. But I’m always getting the same error.

Is there anybody who can help me? (

Thx in advance and greetings
Foerster

PS: I read something about gnutls and also tried to change the order in my cert files but then I’m getting the -74 failure where I didn’t find any information about…)
- agentk
  
  April 6, 2009 10:17 am
  
  Hmm. Not to sure on what will fix your error as it was not one I encountered myself, but here are a few other things to check.
  
  First does this error stop slapd from starting? Or can you still ldapmodify the TLS settings? If you cannot start slapd and need to change the certs they can been seen in the following file:
  ~$ sudo grep TLS /etc/ldap/slapd.d/cn=config.ldif olcTLSCACertificateFile: /etc/ldap/Example-CA.crt olcTLSCertificateFile: /etc/ldap/wildcard-cert.pem olcTLSCertificateKeyFile: /etc/ldap/wildcard-key.pem
  You can edit that file to correct the certificate locations if needed, but just remember that errors in editing that file will also prevent slapd from starting so make sure you back it up first.
  
  Make sure slapd can open all three files. Eg the following should output the contents of the cert without errors:
  sudo -u openldap cat /etc/ldap/Example-CA.crt
  Check that for each cert.
  
  -207 appears to be an error verifying the validity of a certificate using the CA-cert. Try swaping around the two TLSCertificate’s. Either by editing /etc/ldap/slapd.d/cn=config.ldif or by renaming the certificates.
  
  And lastly here are the steps I used to create a wildcard certificate for example.com. In the -newreq command I used *.example.com as the common name. Make sure it is either the hostname of your machine or *.your.domain. I am only listing the commands, not the output as it is very verbose:
  cd ~ /usr/lib/ssl/misc/CA.pl -newca /usr/lib/ssl/misc/CA.pl -newreq /usr/lib/ssl/misc/CA.pl -signreq openssl rsa wildcard-key.pem mv newcert.pem wildcard-cert.pem cp demoCA/cacert.pem Example-CA.crt sudo mv wildcard-key.pem wildcard-cert.pem Example-CA.crt /etc/ldap/ sudo chown openldap:openldap /etc/ldap/wildcard-key.pem /etc/ldap/wildcard-cert.pem /etc/ldap/Example-CA.crt sudo chmod 400 /etc/ldap/wildcard-key.pem
Foerster

April 7, 2009 2:43 am

Thanks for your help agentk. slapd can open all the files but now I recreated new ones exactly in that way you described.

But now I’m getting a:

main: TLS init def ctx failed: -34

error!

I think I will give it up. I googled a little bit and I found nothing helpfull. I will try it on antoher OS, I guess.

But thank you very much for everything.
greetings
Foerster
- agentk
  
  April 7, 2009 10:04 am
  
  Looking through the GNUtls source -34 is:
  #define GNUTLS_E_BASE64_DECODING_ERROR -34
  Which means GNUtls was unable to decode one of the certificates. So it does have access to the file, but is unable to make sense of it’s contents.
  
  Either caused by GNUtls or the process of creating the certificates.
  
  So, yeah. I think trying a new install might be a good idea at this point.
  
  Btw, I have been testing OpenLDAP in two virtual (kvm) machines and two physical machines and never received an error from GNUtls.
  
  And FYI it still seems related to the original error:
  #define GNUTLS_E_BASE64_UNEXPECTED_HEADER_ERROR -207
  So I’m still not sure if it’s your certificates or GNUtls.
segfault

April 21, 2009 8:46 pm

Hi there,

Have you had anything like the following filling up your syslog’s?

Apr 21 22:38:18 ldap3 slapd[5328]: connection_read(28): no connection!
Apr 21 22:38:58 ldap3 last message repeated 2 times
Apr 21 22:40:08 ldap3 last message repeated 4 times

I get it with the same setup (Ubuntu 8.10) and can’t seem to find out why it’s happening. Replication is working great :S
- agentk
  
  April 21, 2009 9:30 pm
  
  I have seen that actually!
  
  I can generate the error by shutting down either slapd daemon. My suggestion is that one one part of your replication setup has an error. If you have two daemons then there are four parts that could contain the error. cn=config, there and back, and dc=example,dc=com, there and back. My guess would be in one of the dc=example,dc=com and on the server that you are getting the error from.
  
  Also try the exercise of actually testing the replication on each section in each direction.
  
  It took a fair while for me to work out where my replication problems were once I introduced TLS replication.
Paul

May 16, 2009 10:54 am

Thanks for the article. I’m going to try the TLS piece tonight. As for the replication, well, it was miserable on Jaunty. You mentioned that we should make sure that all the changes took. I pasted the configuration text from the server guide into a file to edit in Kate. When I ran ldapmodify, it skipped over sections randomly. Once I figured that out, I used nano, and no more problems adding the configuration changes. I also tested the connections specified in the two files. The commands went something like:

sudo ldapsearch -x -H ldap://12.34.56.78:389 -D cn=admin,cn=config -w secret

and

sudo ldapsearch -x -H ldap://12.34.56.78:389 -D cn=admin,dc=example,dc=com -w secret

It actually took me awhile to get those working. I played with the /etc/ldap/ldap.conf and /etc/default/slapd files.

Now get this. I had just given up on replication. I was gathering some details on my configuration to add to this post. I noticed the olcDbIndex that you were kind enough to post. So I said hey, this guy is smarter than me. Now that I know how to delete, why don’t I just copy what he’s got. And sure enough.

That son of a bitch started working!!!!!!!!!!!!!!!!!!!!!

You are an absolute hero. Until I try TLS at least.

Regards,
paul
Paul

May 22, 2009 12:12 pm

I’m in a world of pain and confusion once more. I tried following the Ubuntu docs for creating a CA and certificates for my server(s). I’m attempting to make it work for another app that has to contact Sugarcrm before attempting OpenLdap replication and TLS. The https and CA part should be EXACTLY the same. In my apache error log [it’s a rails app] I get this error:

at depth 1 – 19: self signed certificate in certificate chain

I found this explanation when I googled the above error message, regarding OpenLdap, no less.

############
>OpenLDAP expects you to use a server certificate that is different from the
>certificate of the issueing CA.

Incorrect.

You simply need to configure the client to accept the
server’s certificate as valid by setting the CA file
to a copy of the server’s certificate.
################

I would be mighty obliged if you could tell me what “setting the CA file
to a copy of the server’s certificate.” means. I already tried the Ubuntu certificate management thingy that you did above. No joy.

And for anyone trying to use a self signed certificate with OpenLdap, the thread that I quoted above can be found here: http://marc.info/?l=openldap-software&m=112585726028819&w=2

It’s a pretty in-depth discussion with some of the core ldap contributors.

Thanks for any help!
Paul
- agentk
  
  May 22, 2009 2:28 pm
  
  I suspect that they are refering to setting the TLS_CACERT entry in /etc/ldap/ldap.conf to point to the certificate that was used to sign itself.
  
  But following the Ubuntu Server Guide for setting up a CA you should end up with certificates signed by your CA certificate. Not self signed.
  
  It also depends on weather the error in Apache is coming from the SugarCRM or OpenLDAP directives too.
  
  You could also try turning of TLS certificate checking in /etc/ldap/ldap.conf by adding ‘TLS_REQCERT allow’. That is as long as Apache respects that file, otherwise there may be other options in apache you can try.
  
  Sorry I can’t be of more help.
  - Paul
    
    May 23, 2009 1:46 am
    
    Believe me, all help is appreciated. I followed the Ubuntu guide for creating the CA. Then I deleted and followed another guide, with the exact same results. The only real change is a slight difference in file names. I will say, this tutorial below is quite authoritative.
    
    http://www.tc.umn.edu/~brams006/selfsign.html
    
    I created the server.key and .csr and .crt for the same server that was running the CA. I signed that certificate with my CA. Next, I logged onto my machine running Sugarcrm and generated the server.key and .csr there. Next, I sftp’ed the .csr to the first machine running the CA. I created that .crt and sftp’ed back. I copied the CA root certificate ca.crt to /etc/ssl/certs on both machines. I installed each .crt to their respective /etc/ssl/certs, and then I copied both to each trying to get it to work.
    
    > But following the Ubuntu Server Guide for setting up a CA you should end up with
    > certificates signed by your CA certificate. Not self signed.
    
    There was actually a discussion about this in the thread that I linked to in my prior post. It says that ultimately there has to be a root certificate self-signed in the chain somewhere, even from Thawte or verisign. I think it’s a real live instance of Russell’s Paradox. You know the one, about the barber that only shaves barbers that don’t shave themselves. Does he shave himself?
    
    Enough with the math. May be my problem is that I have a certificate generated and signed on the same machine as the CA ???????? I made sure to give different common names to the CA and the certificate by appending ‘CA’ to the end of the CA, as per the tutorial that I linked to above.
    
    Here’s the relevant portion of my vhost file on the server running the CA [and rails app]:
    
    ServerAdmin [email protected]
    ServerName 192.168.0.3
    SSLEngine On
    SSLCertificateFile /etc/apache2/ssl/server.crt
    SSLCertificateKeyFile /etc/apache2/ssl/server.key
    SSLCACertificateFile /etc/ssl/certs/ca.crt
    
    Here’s the relevant portion of the vhost on the server running Sugar:
    
    SSLEngine On
    SSLCertificateFile /etc/apache2/ssl/hoth.crt ## hoth is the name of the server
    SSLCertificateKeyFile /etc/apache2/ssl/server.key
    SSLCACertificateFile /etc/ssl/certs/ca.crt
    
    Here’s the error message again:
    at depth 1 – 19: self signed certificate in certificate chain
    
    My thinking was that it would be easier to get ssl working with these two apps and then try openldap and TLS. It hasn’t worked out so far : (
    
    Cheers! P
    - agentk
      
      May 23, 2009 10:25 pm
      
      Haha. I realise how long my friday was when I made that quote now. Lets just ignore it to prevent confusion.
      
      Just so we can establish a base for what is causing the error:
      Where is the error message appearing? Apache logs? Sugar? OpenLdap? Does apache work ok with all of the TLS and certificates diasbled?
      Does the rails app authenticate too? Are there any errors posted there too?
      
      As for the certificates, it should not matter which machine has done the signing, just what cert was signed with what cert. I only have one CA on one machine that I generate all off my host certificates with.
Paul

June 7, 2009 8:18 am

Hey I’m back at it. Sorry for not checking back. I ended up buying certs from Godaddy. I definitely would not do the self-signed thing again. As a noobie to ssl and openldap, it created confusion that was hard for me to solve. This tutorial has already helped me again today. I’ll post the things that a ran into soon and hopefully news of my success.

Thanks again.

P.S. You are definitely still a hero!
Paul

June 7, 2009 11:06 am

Mixed-success. I have much to document. But first the bad news. I have my new commercial certs for my domain http://www.example.info, and OpenLdap wants it to match my server name, hoth. Too bad I didn’t know about wildcards or alternate certificate names. Now the good news. I generated two certificates on a third machine and got them installed with TLS working on both Ldap servers. I think it balked before because I was trying to connect to the other two ldap servers with the same machine that has the CA. To make it uglier, I was connecting through dyndns. And I was trying to do too much other junk on top of that.

OK. Live and learn. Now that TLS works, I floundered updating the replication piece. I tried updating the config database, but apparently, I was slightly off. Looking at the update file that I created from the tutorial, it looks like I should be able to re-run it. I thought it would just replace the olcSyncRepl line, but no dice. It gives a message that it is updating, and then hangs. If I control -c and get back to the command prompt, it hangs if I try to do an ldapsearch. If I control -c and then /etc/init.d/slapd restart, I can ldapsearch again and see that it didn’t update the config. Being a clever fellow, I went to the other server figuring that if I got it right, it would replicate. I didn’t get it right. Same behavior when I try to re-run the file.

Do you by chance know how to delete the syncrepl bit so that I can keep trying to get it right? Here’s what the file looks like:

dn: olcDatabase={0}config,cn=config
replace: olcSyncrepl
olcSyncrepl: {0}rid=001 provider=ldap:///www.example.info binddn=”cn=admin,cn
=config” bindmethod=simple credentials=password searchbase=”cn=config” type=refreshAndPersist retry=”5 5 300 5″ timeout=1 starttls=yes
olcSyncrepl: {1}rid=002 provider=ldap:///casserver.example.info binddn=”cn=admin,cn
=config” bindmethod=simple credentials=password searchbase=”cn=config” type=refreshAndPersist retry=”5 5 300 5″ timeout=1 starttls=yes

BTW, in case you notice, I have an example.info domain where my servers are running, but my ldap is setup as cn=example,cn=com because I have that domain also.

Thanks for all your help. I hope this can help others. Openldap is hard.
Paul
Paul

June 7, 2009 12:30 pm

Ok, sorry to be like a stalker.

So I figured out that I have to escape the url with % signs. I had it working without them when I tested TLS before.

ex.: sudo ldapsearch -x -H ldap:///%e%x%a%m%p%l%e%.%c%o%m -D cn=admin,dc=example,dc=com -W -ZZ

Weird. I’d try it in the config file if I could figure out how without blowing up the server.

–peace out.
iksan

May 28, 2011 5:37 pm

Dear All

i have a problem when i add user in ldap, the coment is
“sudo ldapuseradd george example”

error Massage display

“Error adding user goerge to LDAP ”
What is the problem.. ?
help me please
- iksan
  
  May 28, 2011 5:39 pm
  
  the comand is
  “sudo ldapadduser george example”
  
  not “ldapuseradd george example”
  
  help me
  
  Thanks for your ettention