I would make sure under authentication you select Kerberos, kill users after they have been idle, make sure you have a valid cert, disable guest access.
For SSL go here:
http://www.afp548.com/article.php?story=20071203011158936
Below is what that link states
The Change
The difference between 10.4 and 10.5 lies entirely in /etc/openldap/ldap.conf. Where before it used to say
TLS_REQCERT = never
now it says
TLS_REQCERT = demand
This change means that the underlying ldap client will only use SSL certificates that it thinks are valid dropping the connection attempt if it thinks the cert is bad. So, what constiutes a valid cert?
Out of the box... nothing. The LDAP client trusts no one. Even if you actually paid for your SSL certificate and you have no issues when you use it to secure a website, the LDAP client will still refuse it. Annoyingly the GUI, in this case Directory Utility, will happily show you a green dot next to your server, it's just that it won't actually be used. If you require binding and SSL, that should fail as well.
While this is annoying if you didn't expect it, I find it hard to argue that it was a bad move. Without validating a site against its own certificate left the client systems open to something as simple as a DNS poisoning attack. So I do feel that this is a good thing, but it cetainly does take a bit more work to get things functioning.
Test via the CLI
The easiest way to test what exactly is going on is to use the ldapsearch command to verify if you're able to connect or not. This assumes that you've first set up OD and enabled SSL for LDAP, either using the default certificate on the server or one you've configured yourself.
ldapsearch -v -x -H ldaps://biggie.afp548.com -b "dc=biggie,dc=afp548,dc=com"
Substituting in your correct server FQDN and search domain. This should fail on a stock 10.5 install with this error.
ldap_bind: Can't contact LDAP server (-1)
additional info: error:14090086:SSL routines:SSL3
GET_SERVERCERTIFICATE:certificate verify failed
Fairly self-explanatory, at least to what the error is. So now how to fix it.
Get the Cert
You're going to need to feed the cert to the LDAP client so that it knows to trust it. While it's possible to do this via exporting the cert from the server itself it's typically easier to use the "openssl s_client" to snarf the cert.
openssl s_client -connect biggie.afp548.com:636
Which should come back with a deluge of information for you. Within that is going to be a dozen or more lines that are blocked off by:
-----BEGIN CERTIFICATE-----
and
-----END CERTIFICATE-----
Take that text, including the begin certificate and end certificate lines and paste them into a text file. A CLI text editor would be best for this to ensure that you don't accidentally save it as a .rtf or something funky like that.
For purposes of demonstration we'll assume that you've saved the cert to /tmp/ssl.cert.
Note: you should get an error number 18 or 19 when using the s_client. This refers to either a self-signed certificate, 18, or a self-signed certificate in the chain, 19. Keep this in mind as the next step should clear this out.
BTW, control-c to get out of the s_client connection.
Test the Cert
Now that you have the cert sequestered into a text file you can test again with s_client manually specifying the certificate.
openssl s_client -connect biggie.afp548.com:636 -CAfile /tmp/ssl.cert
Which should display similar output to before, however, with a significant change to the last line:
Verify return code: 0 (ok)
Instead of either the 18 or 19 that you were getting before. This means that you've successfully managed to get openssl to be happy with the certificate that you're using on the remote server. So now to make LDAP as happy...
Edit ldap.conf
You are going to need to add a new line to /etc/openldap/ldap.conf that points to the certificate you've just pulled down. I tend to keep things tidy here and create a /etc/openldap/certs folder and then just copy the text file that we got before into there. Here we'll assume you renamed the file the name of the server and put it into this location.
After moving the cert you can add one line into /etc/openldap/ldap.conf
TLS_CACERT /etc/openldap/certs/biggie.afp548.com
Now retest with the ldapsearch command and see if it works.
ldapsearch -v -x -H ldaps://biggie.afp548.com -b "dc=biggie,dc=afp548,dc=com"
Should actually return an LDIF of your whole LDAP setup, so this may take a while. Trim down the search if you want.
Ensuring OD Works
At this point you should be able to join and use an SSL-secured OD setup via Directory Utility. So please do that at this time. You may need to kick Directory Services if you had already attempted to setup the LDAP server.
sudo killall DirectoryService
Securing a Collection of Certs
The method above will only allow that one specific server, with that one specific cert to be trusted. If you have multiple LDAP servers you're working with you're going to need to specify those individually, or put them all in the same directory and point ldap.conf towards them. Here's how to do the later.
Grab all of the certs as before using openssl s_client.
Now you're going to have to use another OpenSSL utility to get the certs into a hashed format.For each cert you will run the it through c_hash which will give you a name that you'll need to rename the cert file to.
/System/Library/OpenSSL/misc/c_hash /etc/openldap/certs/biggie.afp548.com
03be8eb2.0 => /etc/openldap/certs/biggie.afp548.com
In this example you'd rename your existing cert file to 03be8eb2.0
Then you can add
TLS_CACERTDIR /etc/openldap/certs/
to your /etc/openldap/ldap.conf file.
Probably best to remove any earlier TLS_CACERT directives you have in ldap.conf at this time as well.
On the Other Hand
You could revert the ldap.conf file back to the 10.4 behavior and be done with all this...
Keychains
Note that while it would certainly make most of the pain go away, OpenSSL and therefor the LDAP libraries have no concept of what a keychain is. So, no, importing the certs into your keychain won't do anything for the LDAP issue.
Other Notes
You will never be able to use the default certificate that comes with OS X Server without changing TLS_REQCERT back to never. The default certificate isn't configured with a hostname so it will never pass an integrity check.
As mentioned by Mr. McCune in the comments, you may also want to investigate pointing ldap.conf to the default trusted root store that is included with curl on OS X.
TLS_CACERT /usr/share/curl/curl-ca-bundle.crt
Which should allow you to use a purchased certificate without having to do additionaly mods to ldap.conf.
