This page gives some hints how to setup your LDAP nameservice on a particular linux distro.
LDAP nss configuration using start_tls (ssl via port 389) for encryption:
host %%LDAPSERVER1%% %%LDAPSERVER2%% base ou=foo,o=ispman ssl start_tls tls_checkpeer yes tls_cacertfile /etc/ssl/your_ca.pem pam_lookup_policy yes nss_base_passwd ou=people,ou=foo,o=ispman?one?host=%%HOST%%
On Debian Etch's libnss-ldap I had trouble with the 'host' entry, so I used uri ldap://
base o=ispman uri ldap://your.ldap.server.ip ldap_version 3 rootbinddn uid=proxyuser,ou=admins,o=ispman ssl start_tls tls_checkpeer no
If you set "ssl start_tls", the client asks the ldap server for a encrypted connection. With start_tls this happens on the same port as an unencryted connection, usually port 389. It's more or less the successor of ldaps:// which uses SSL on a different port. Now keep in mind, that the ldap server delivers it's cert to the client, when a connection is established. The client uses the cert to encrypt the connection from that point on. The problem is, that you never now, if the cert is real, as some man-in-the-middle might act like a server, i.e. some attacker took over the servers IP and acts like 'your' ldap server. So we need something to check the cert that the server delivered. To achieve that goal, we sign the servers cert by a "trusted 3rd party", i.e. a trustcenter. We copy the trustcenter's public key to /etc/ssl/your_ca.pem on the client. With "tls_checkpeer on" every time a cert is delivered to the client, it will check the signature of the cert with the trustcenter's public key. (Explaining who a trustcenter and PKI works is beyond of scope here)
So, if you you have a crossovercable between between you machines, you wont probably need tls_checkpeer, but it can't harm. It raises security.