Weblog entry #32 for lee

Using an LDAP server as an Evolution addressbook
Posted by lee on Tue 19 Jun 2007 at 10:45

This post details the steps needed to set up an LDAP server for use as an Evolution network addressbook. Note, I'm not an LDAP expert by any stretch so suggestions/fixes are welcome.

The first thing to do, before installing the server is to use the TCP wrapper support to restrict LDAP access to just the ranges you need, for example 19.0.2.0/24: /etc/hosts.deny

ldap: ALL
/etc/hosts.allow
ldap: 192.0.2.

Alternatively you can make arrangements at your relevant firewalls to allow traffic via port 389 tcp/udp.

Then install the LDAP packages:

# apt-get install slapd ldap-utils

Aside from the admin password, I accepted all of the default configuration choices. My "base" is "dc=example,dc=com" Once slapd is installed add a user account, e.g. for John Smith, first by creating the file john.ldif :

# Organisational Unit, only needed once
dn: ou=People,dc=example,dc=com
objectclass: organizationalUnit
ou: People

dn: cn=John Smith,ou=People,dc=example,dc=com
cn: John Smith
sn: Smith
givenname: John
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
ou: People
mail: smith@example.com
userpassword: topsecret

This is then added into slapd using the admin password

$ ldapadd -x -D "cn=admin,dc=example,dc=com" -W -f john.ldif

Now I add TLS support. There's no out-of-the-box TLS set-up in the Debian package I installed_ (as you might get with MTA/MRA packages). For our purposes we don't need a properly signed certificate, a self-signed "snakeoil" cert will be OK. I already had a self-signed certificate set up for something else, so I just copied it to ldap.pem.

You need to protect the private key, and add openldap to the ssl-cert group (if you're not using the debian setup, other key access methods may vary).

# chown root:openldap /etc/ssl/private/ldap.pem
# chmod 640 /etc/ssl/private/ldap.pem
# adduser openldap ssl-cert

Then you need to add the following to "globals" section of /etc/ldap/slapd.conf

TLSCACertificateFile    "/etc/ssl/certs/ssl-cert-snakeoil.pem"
TLSCertificateFile      "/etc/ssl/certs/ldap.pem"
TLSCertificateKeyFile   "/etc/ssl/private/ldap.pem"

You can have multiple separate databases served by the LDAP server, and you could make it part of the primary database. But to simply things, I've set up the addressbook database as a separate database.

Firstly set up a directory. You can use a subdirectory of /var/lib/ldap/ but I prefer to use /srv.

# mkdir -p /srv/ldap/addressbook
# chown openldap:openldap /srv/ldap/addressbook
# chmod 700 /srv/ldap/addressbook

Now I add the configuration section for the addressbook database to the bottom of /etc/ldap/slapd.conf

database        bdb
suffix          "o=Addressbook"
rootdn          "cn=admin,dc=example,dc=com"
directory       "/srv/ldap/addressbook/"
schemacheck     on
lastmod         on
#
dbconfig set_cachesize 0 2097152 0
dbconfig set_lk_max_objects 1500
dbconfig set_lk_max_locks 1500
dbconfig set_lk_max_lockers 1500
#
access  to dn="" by * read
access  to dn="cn=Subschema" by * read
access  to *
        by dn="cn=admin,dc=example,dc=com" write
        by dn="cn=John Smith,ou=People,dc=example,dc=com" write
        by anonymous auth
        by * none
index           cn,mail,sn,givenname    eq,subinitial

We've given the "John Smith" account write access to this LDAP database, but other accounts, including anonymous in a LAN-only set-up, could just be given read access.

Restart slapd to enable the new database.

# /etc/init.d/slapd restart

Then, before you can add new entries, create addressbook.ldif

dn: o=Addressbook
objectclass: organization
o: Addressbook
description: Online Addressbook
$ ldapadd -x -D "cn=admin,dc=example,dc=com" -W -f addressbook.ldif

Assuming everything went OK during this setup, you should now have an operational LDAP addressbook.

To try it out, open Evolution's Contact tab and select "New Address Book".

Set the type as "LDAP" and put your server name under server information. If you're using it across the Internet and have TLS set up, ensure TLS encryption is selected (it should be by default). Click on the "Details" tab and click "Find possible search bases". This should return the base DN of both databases - if it doesn't there's a problem somewhere (sorry!). Select "o=Addressbook". Set the search scope to "Sub".

Go back to the "General" tab and set the login method to "Using distinguished name" and set the Login to

cn=John Smith,ou=People,dc=example,dc=com

Then click OK. You'll then be prompted for a password (the one set in john.ldif, not the LDAP admin password).

There'll be no entries in the Addressbook yet, so create a new contact and set the "Where" to be your LDAP addressbook. Or, to pull down a few entries search for fields containing "@".

You'll notice that some of the properties are "greyed out", uneditable. This is because they're not covered by the standard schemas.

If you have a copy of evolutionperson.schema somewhere (e.g. in /usr/share/evolution-data-server-1.12/ ) copy it into /etc/ldap/schema/ and add the following to the Global section of /etc/ldap/slapd.conf and restart.

include         /etc/ldap/schema/evolutionperson.schema

This will allow the use of Evolution-specific fields to be stored in your LDAP database [UPDATED: actually it doesn't seem to work, more research needed], but these won't be available from other apps using LDAP (Mozilla Thunderbird, for example, also requires a specific schema. Ugh.)

Another schema is needed for the iCal related fields (TODO) and the Instant Messenger fields (?!).

 

Comments on this Entry

Posted by JulienV (86.218.xx.xx) on Mon 25 Jun 2007 at 18:10
[ Send Message | View Weblogs ]

Hi,

I have finally found the time to read our article! This is very interesting, as I have a similar setup running at home.

I plan to write a small article for my website, as my setup differs from you mainly as each user has its own address book (where they have read/write access), and they also have the possibility to use a global address book, where only identified users have write access:

access to dn.subtree="ou=global,ou=directories,dc=example,dc=com"
        by dn="cn=admin,dc=example,dc=com" write
        by users read
        by anonymous auth
        by * none

access to dn.regex="ou=([^,]+),ou=directories,dc=example,dc=com"
        by dn.regex="uid=$1,ou=users,dc=kirya,dc=net" write
        by dn="cn=admin,dc=example,dc=com" write
        by anonymous auth
        by * none

I have also setup my horde setup to use this LDAP directory. Turba2 needs rfc2739.schema, as well as the Net_LDAP PEAR package.

I am also trying to find a schema to use with IM fields in Evolution, and especially VoIP entries in Ekiga, but no success for now.

Cheers,
Julien

[ Parent | Reply to this comment ]

Posted by damko (62.123.xx.xx) on Thu 23 Aug 2007 at 22:18
[ Send Message ]
I'm currently working on this topic me too. I wrote some lines on my blog

http://dventurin.blogspot.com/2007/08/roadmap-gestire-contatti-cl ienti_21.html

it's in italian but ... better than nothing. I made many tries but finally I was capable to load the remote address book in ekiga. it's a pity that ekiga doesn't consider to list also common telephone numbers but only voip numbers.

I really would love to be involved in any project related to this topic and ldap. Pls feel free to contact me.

cheers
Dam

[ Parent | Reply to this comment ]

Posted by lee (146.101.xx.xx) on Wed 3 Oct 2007 at 16:50
[ Send Message | View Weblogs ]
One thing I didn't add: in order to use self-signed SSL certificates with LDAP TLS
you need to modify either ~/.ldaprc or /etc/ldap/ldap.conf . You either need to explicity add the snakeoil CA certificate somewhere, or easier, just disable strict certificate checking by adding "TLS_REQCERT allow".

[ Parent | Reply to this comment ]

Posted by Magnate (212.85.xx.xx) on Tue 22 Jan 2008 at 12:47
[ Send Message ]
I too have set up slapd to provide my contacts for Evolution. My issue is that I want the same contact data to be available to multiple clients: Evolution, Thunderbird/SeaMonkey and, yes, Outlook. The problem is that each client uses a custom schema which doesn't work for any others. I can see three choices:

1. Try to use one client's schema for all clients. Outlook is likely to be the most difficult to change, so if slapd, Evolution and Mozilla can be all configured to use the Outlook/ActiveDirectory schema, that might work.

2. Combine all client schemata and create a superset schema for the slapd server. All clients could then see the fields defined in their schema, but the problem is how to map the same data onto different fields and propagate changes between client schema (e.g. MozillaHomeStreet is the same as PersonalStreetAddress, so when one is updated by a client, the other one needs to be updated at the same time).

3. Reduce all clients to using the basic RFC fields defined in the core, cosine and inetorgperson schemata shipped with slapd. This may be the easiest solution, but the challenge is how to configure the clients to prevent me from unwittingly using other fields.

Any comments welcome.

CC

[ Parent | Reply to this comment ]

Posted by twisti (84.113.xx.xx) on Wed 12 Mar 2008 at 22:17
[ Send Message ]
I tried to set up the ldap server with current Debian Lenny packages and I'm actually able to add contacts to the database. But they only show up in Evolution right after I added them. After a restart of Evolution there are no contacts shown anymore. But when I try to add the same entry again, Evolution tells me that the contact already exists.

Any idea where the problem might be?

[ Parent | Reply to this comment ]

Posted by twisti (84.113.xx.xx) on Sun 16 Mar 2008 at 12:52
[ Send Message ]
OK, found the problem:

http://bugzilla.gnome.org/show_bug.cgi?id=324203

This is a feature.

[ Parent | Reply to this comment ]

Posted by Anonymous (69.112.xx.xx) on Fri 19 Sep 2008 at 15:57
This is notably a bit old and has perhaps been addressed elsewhere however I found a problem with this documentation using current versions of slapd as of the time of this writing.

The instructional line calling for "schemacheck on" results in the following error.

/etc/ldap/slapd.conf: line 147: unknown directive <schemacheck> inside backend database definition.

[ Parent | Reply to this comment ]

Posted by Anonymous (91.65.xx.xx) on Mon 19 Jan 2009 at 15:32
Sorry for bringing this up again. I wonder how you managed to get the LDAPS connection working with Evolution. I encounter the same bug as described in the evolution bug database - the TLS negotiation keeps failing:

http://bugzilla.gnome.org/show_bug.cgi?id=356541

Importing the self-signed CA into evolution does not help and neither does adding it to /etc/openldap/ldap.conf nor /etc/ssl/certs (and adding the appropriate link). Whereas importing it into thunderbird or accepting the certificate warning in thunderbird does work. Any ideas?

[ Parent | Reply to this comment ]

Posted by lee (146.101.xx.xx) on Mon 19 Jan 2009 at 18:02
[ Send Message | View Weblogs ]
Can't help you there I'm afraid. My setup is as described. Evolution 2.24.1 with the following in ~/.ldaprc
  TLS_REQCERT  allow

[ Parent | Reply to this comment ]

Posted by greggyb (137.110.xx.xx) on Tue 6 Oct 2009 at 20:01
[ Send Message ]
I struggled with this for a while because it was hard to figure out why gnutls was rejecting the certificate. For me, the issue was that I had signed my certificate using the md5 message digest, and gnutls doesn't think that's secure enough. I switched my openssl.cnf to set default_md = sha1 in both the [ CA_default ] and [ req ] sections, generated a new root certificate and a new certificate for my ldap server, and then gnutls was happy. When your ldap server is up, with tls enabled on port 636, running a command like this on a client:

gnutls-cli -p 636 --x509cafile /path/to/your/ca-cert.pem example.com

should not produce any complaints (obviously replacing /path/to/your/ca-cert.pem and example.com with your own certificate path and server address). Near the bottom of the output you should see:

- Peer's certificate is trusted

Even after all that, though, it seemed like Evolution wasn't going to work. It looks like the tls parts aren't properly called in the gui for setting up the address book (the "Address Book Properties" window), so even if you enter everything correctly on the "General" tab---your server name, your port (636), ssl encryption, using DN for login, and entering the same DN that works with ldapsearch (see below)---when you click "Find Possible Search Bases" on the "Details" you'll get an error: "Failed to authenticate with LDAP server." The backend *does* initialize the tls parts correctly, though, so if you enter the right search base, you should be able to use the address book.

You can make sure that your database is configured correctly using ldapsearch. The following command should work with only a couple minor complaints:

ldapsearch -Z -x -H ldaps://example.com:636/ \
-D "cn=John Smith,ou=People,dc=example,dc=com" \
-W -b "o=Addressbook"

(again replacing example.com and "cn=John Smith,..." with the appropriate versions for your configuration). The first complaint will be

ldap_start_tls: Operations error (1)

because ldapsearch with both -Z and a ldaps uri will try to start tls twice (which results in the "Operations error" but otherwise works fine). Near the bottom of the output you might see:

# search result
search: 3
result: 0 Success

and you might wonder if "0 Success" is really success. It is. Failure, e.g. entering the wrong search base for -b, looks like this:

# search result
search: 3
result: 32 No such object

Entering the wrong DN for -D looks like this:

ldap_bind: Invalid credentials (49)

Sorry for the long comment, but getting this working took me a while, and this web site has the most useful information on the rest of the process, so I thought it would help to fill in some more details.

[ Parent | Reply to this comment ]