A reasonable looking intro to LDAP is available here: http://staff.pisoftware.com/bmarshal/publications/intro_ldap/index.htm
Another one which covers LDAP system authentication is here: http://staff.pisoftware.com/bmarshal/publications/system_auth/sage-au/system_auth.html
A reasonable selection of LDAP related notes: http://www.kingsmountain.com/ldapRoadmap.shtml
The OpenLDAP2 packages under Debian Woody (3.0), are compiled --with-cyrus-sasl, which will cause issues if you want to do full ldap auth due to a bug in sasl, and also --with-sql, which means they link against libiodbc2, which in turn requires xlib, glib and gtkxmhtml to be installed! So you end up having to have xlib (the basic X libraries) installed when you want to install slapd (the ldap daemon).
The good news is this is fixed in testing. They seperate out the components that require xlib and so on. Until then, if you want to get rid of xlib, you'll need to recompile the debs for slapd --without-sql, or recompile libiodbc2 without the components that need xlib ec
Also see our LDAPAuthentication wiki page, and also http://ldots.org/ldap/, written by Michael !JasonSmith? at CanterburyUniversity.
Some other interesting URL's - Debian's Wiki LDAP entry, some backports of various LDAP utilities for Debian Woody are at http://cmeerw.org/debian/ and some more notes at http://cmeerw.org/notes/ldap.html
Under debian, you'll need to recompile slapd. change the line in debian/rules from --without-tls to --with-tls
You'll want to create certificates. See SSLNotes.
Note: When creating certificates, set the hostname (cn) as being the name that you'll be connecting to the server on! It'll fail otherwise. Eg, if you'll be using ldap+tls to ldap.wlug.org.nz, make sure to set that as the Common Name! And only ever connect to that name.
Update your slapd.conf appropriately
TLSCACertificateFile /etc/ssl/cacert.pem TLSCertificateFile /etc/ldap/certs/slapd-cert.pem TLSCertificateKeyFile /etc/ldap/certs/slapd-key.pem TLSRandFile /etc/ldap/certs/randfile TLSCipherSuite HIGH:MEDIUM:+SSLv2
in /etc/init.d/slapd, change the line that says
start-stop-daemon --start --quiet --pidfile "$pf" --exec /usr/sbin/slapd
to read
start-stop-daemon --start --quiet --pidfile "$pf" --exec /usr/sbin/slapd -- -h "ldaps:/// ldap:///"
This starts slapd listening on ldaps and ldap. You can also use ldapi to use ldap over a unix domain socket.
RedHat 7.x supports TLS out of the box. All you have to do is recreate your slapd certificate & uncomment the TLS config lines in /etc/openldap/slapd.conf.
cd /usr/share/ssl/certs make slapd.pem ... answer some questions
Note: When answering the 2nd to last question about the "Common Name" it is important you specify the server name you're going to be using when connecting from clients. Eg, ldap.somehost.com. It is important that you set up clients to connect via this name. If they use another name that resolves to the same IP it's not going to work. This caught me out in the beginning. I would get connection errors in clients like GQ (a GTK LDAP query tool http://biot.com/gq/).
chmod u=rw,g=r,o= slapd.pem chown root.ldap slapd.pem
Note: It is important to have the permissions and ownership set right on your slapd.pem cert. If you don't slapd will fail to start and exit without displaying an error.
See LDAPAuthentication for a detailed example of this.
After I configured LDAP client auth I also enabled nscd(8) to load at boot (in runlevels 2, 3, 4, & 5). nscd is the daemon which handles passwd and group lookups for running programs and caches the results for the next query. This is important if your using network name services such as LDAP or NIS. Without it your LDAP server gets hammered and clients are slower to respond. Using it also seemed to solve some seg faults I was having with tools like RPM. Weird but true.
There are a few things to get tripped up on with LDAP.
Here are a list of attibutes used by the various "Outlook/OE" clients for their addressbooks. Note, there is no simple way to "add" contacts to an LDAP tree from these programs - none that I am aware of anyway... Outlook 2K (Workgroup mode)/ Outlook XP:
commonName
department
display-name
givenName
mail
organizationalUnitName
organizationName
physicalDeliveryOfficeName
postalAddress
2roleOccupant
surname
telephoneNumber
title
Outlook Express:
comment
commonName
conferenceInformation
department
display-name
facsimileTelephoneNumber
givenName
homePhone
homePostalAddress
info
initials
IPPhone
labeledURI
mail
Manager
mobile
organizationalUnitName
organizationName
otherFacsimileTelephoneNumber
otherMailbox
otherPager
pager
physicalDeliveryOfficeName
postalAddress
postalCode
Reports
street
streetAddress
surname
telephoneNumber
title
userCertificate;binary
userSMIMECertificate;binary
Note 1: outlook uses the 'mail' attribute for the email address, some
LDAP server (Netscape) declare this as 'rfc822mailbox'.
Linking mail->rfc822mailbox makes it work.
Note 2: Outlook 2K/XP does not query LDAP for a users' PKI certificate, Outlook express does.
Here are some useful apps to use with your LDAP system:
Contact management only tools:
ldapadd was spitting this error at me every time I tried to add anything, a google search provided nothing, but several people complaining about approximately the same problem (and not getting any replies). Commenting out all the replica information in my slapd.conf fixed it, confused, adding it back breaks it again. I have no idea why replication should {a,e}ffect structural classes of objects in the tree, but there ya go, it does. This is slapd-2.1.17-1, if you have a newer version this bug may be fixed.
I have a Debian Testing now (21 January 2005) and slapd 2.1.30-3. I just replicated my LDAP database and was getting this no structuralObjectClass when I was trying to add some entry in the slave LDAP database. I don't know if I can acctually add stuff to the slave LDAP server, couse it doesn't replicate it to the master (maybee I'm missing some configs here). My point is that I manage to add an user entry in the replicated LDAP server by adding the line "structuralObjectClass: account" to the ldif entry... To see the structural data of an entry of your you should execute: "ldapsearch -b "uid=caozinho,ou=People,dc=tux.dc=com" -s base +". Hope this helps you!
You're trying to use SASL and SASL isn't configured properly. try ldapsearch -x, if this works, then you have SASL issues. The usual solution is to always use "-x" :)
OpenLDAP has a special root account that has root access to the LDAP tree, bypassing any ACLs that you have in place. This account is controlled through the rootdn and rootpw attributes in slapd.conf.
rootpw must be initialised from the output of the slappasswd command this isn't immediately obvious from any of the documentation and trying to bind as the rootdn will fail silently if you initialise it as a plaintext value.
http://www.newwave.net/masneyb/dhcp-3.0.1rc12-ldap-patch
6 pages link to LDAPNotes: