Howdy,
Here's something people don't gripe enough about ;) Actually the problem is only common if you work in a shop that runs the iPlanet Administration Server (Formerly, Netscape LDAP) and you have it set up to run securely using TLS or SSL, and you have it set up so that you need to enter a password to start it up. That's a lot of "and"s. Okay, only 2. I'm exaggerating ;)
Having a secure LDAP setup (which runs as the "slapd" process) is good enough without the extra authentication needed to start it up. It's good to know that this is only optional. Depending on your requirements, you may or may not want to make it necessary for someone to know a password in order to start the service, assuming they already have the proper credentials and system privilege. You'll still enjoy the benefits of secure network authentication (for users accessing the database) and encryption of the trasmitted data (for the LDAP requests and responses).
If it makes you feel more secure (or your site security requires it), setting up the TLS/SSL keys for LDAP easily allows you enter that additional password. In fact, it automatically prompts you and makes you go out of your way to type enter twice in order to have a "blank" password (which, in this case, is equivalent to no password at all).
The most common issue this causes (We're not going to go into key setup or port access issues here today) is a failure to boot non-interactively. For instance, if you have LDAP set to start up in an init script called S99ldapstart, with a line like this:
/opt/ldap/slapd-server1-636/start-slapd
and you issue:
/etc/rc2.d/S99ldapstart
while you're logged in, you'll be prompted to enter the security password to start the server. Once you enter the password, the server starts up as normal. This is all well and good if you're on the machine and running the script through an interactive shell, however it won't work at all when the "rc" program tries to run this script at boot time. That sort of situation is analagous to you entering the start command (as above) and then just sitting there and never entering the password you're being prompted for. The secure LDAP server will never start.
Fortunately, even though the answer doesn't seem to be widely available (although it is packed away in online manuals, etc), it is relatively easy to implement and works like a charm. The only downside is that you put yourself at odds with the extra security you've added to the process (by insisting on the startup password) by having to store the password in a plain-text file that (if compromised) will give anyone who can access it the password you don't want them to have!
Deriving our settings from the above information (LDAP Base directory is: /opt/ldap and Server base directory is: /opt/ldap/slapd-server1-636) and accepting, for the purposes of this demonstration, that our secure startup password is "Bingo" (All passwords are case sensitive. Capitalization counts :) we can do the following at the command line, and set ourselves up for hands-free secure LDAP startups forever (or until we change the password):
host # echo "Internal (Software) Token:Bingo" >/opt/ldap/alias/slapd-server1-636-pin.txt
host # chmod 400 /opt/ldap/alias/slapd-server1-636-pin.txt
And that's it :) The most important thing to remember, since you can do this for any SSL/TLS enabled LDAP server instance, is the format of both the "name" and the "contents" of the file that will hold that password.
1. The name of the file must be of the form:
$LDAP_ROOT/alias/$LDAP_SERVER-pin.txt
Where (for this example) LDAP_ROOT=/opt/ldap and the LDAP_SERVER=slapd-server1-636. If it's not named like that, iPlanet Directory Server will not recognize it.
2. The contents of the file must be compact. No spaces are allowed anywhere they're not explictily shown here, in this example, including at the end of the line. Any deviation from this rule-of-thumb may make it so that your secure LDAP server doesn't recognize the password and reverts back to the prompt, leaving you with a server hung at startup. The password must be of the form "Token:PASSWORD" with no spaces.
Once you've done this once or twice, it's a walk in the park. Every time you need to boot your server, you can be sure that your secure LDAP servers will start up properly. Since this setup is so exacting in its requirements, it's also pretty simple to troubleshoot if breaks :)
Cheers,
, Mike
linux unix internet technology