Weblog entry #32 for lee
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
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 ]
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 ]
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 ]
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 ]
Any idea where the problem might be?
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]