Thursday, December 31, 2009

Subject Alternative Name with GSKit

Subject Alternative Name's (SANs) allow you to obtain a single SSL certificate to protect multiple hosts. So lets say you have two LDAP servers (server1 and server2) and you want to enable SSL, but you want to have clients reference only one DNS name (ldapserver) to connect to any of the LDAP servers. Likely you will have a load balancer of some kind in front of the LDAP. One way to do the Certificate Signing Request (CSR) is to specify "ldapserver" in the host name field and then specify "server1" as the SAN. The problem is IKeyMan doesn't have a way of including a SAN in the CSR.

This is not a problem for a couple of reasons. For one, you can use the command line tools with GSKit to create a CSR containing a SAN. While the GUI lacks this capability it seems the command line supports it:

gsk7cmd -cert -create -db /keys/tds.kdb -pw password -label junk -dn "cn=tds1,o=bigco,c=us" -san_dnsname tdswin1,tdssrv1 -expire 3653

The other option is to create the CSR using IKeyMan without the SAN. When you post the CSR certificate into the web form at Verisign or whatever other CA you choose, you should be able to use the CA form to specify the SAN. This way the signed version of the certificate you receive back from the CA will contain the SAN. IkeyMan supports receiving the signed certificate back into the key database with the SAN included so this will work fine. In fact this is the easiest way to do this. For your LDAP servers it is best to create the Key database using IKeyMan and issue the CSR from there. That way you can do the Receive Certificate operation later when you receive the signed certificate back from the CA.

Cheers!

Tuesday, December 22, 2009

TDS Web Admin Tool - Superuser

Be careful changing the credentials for this. When you login to the TDS Web Admin Tool and attempt to change either the user name or password for the superuser (default superadmin) I have seen cases where something got screwed up and the end result was to uninstall and re-install the TDS Web Admin Tool completely.

It seems that the tool is a little quirky if you try to change the user name and password at the same time. My best recommendation is to change the username, log out of the tool, then log back into the tool with your new user name and the original password. Then change the password for the user. Log out of the tool, then back in with the new user name and new password.

Monday, December 14, 2009

How much do you rely on the TDS Web Admin Tool?

I usually setup TDS as an enterprise LDAP, but usually as part of a larger security initiative such as Identity and Access Management. Since LDAP is the underlying user registry for ITIM and ITAM we typically do not use the TDS Web Admin tool for much more than some initial setup and configuration of the LDAP. Beyond that ITIM and ITAM have their own management tools.

But, if your goals for LDAP were simpler and you are not implementing an Identity Management solution, well you are limited to a few different tools to manage your LDAP directory:

Command Line tools such as ldapsearch, ldapadd, idsldapsearch, idsldapadd, etc....
TDS Web Admin Tool (GUI)
3rd Party tools such as Softerra's LDAP Administrator

Those who are new to LDAP in general and do not prefer to use command line tools, naturally gravitate to the TDS Web Admin Tool. In general its a pretty good tool and in TDS 6.2 it is much better than 6.0 for tasks such as setting up replication, but its still a bit buggy.

For example I ran into a problem recently where we had a boolean attribute configured as a mandatory attribute for our objectclass. Using TDS Web Admin Tool to create a new user entry results in an objectclass violation. Meanwhile using idsldapadd works just fine. It turned out to be a legitimate bug with a fix on the way, but there are other quirky issues with this tool.

Another problem I noticed in one case I have 5000 entries populated in the LDAP. If I navigate through the directory tree I can see the entries listed, but if I click on an entry it should open up the edit screen for that entry. Instead it does nothing at all. Yet, if I use the directory search tools in TDS Web Admin GUI I can find a specific entry and then click on the entry which correctly opens the edit screen for that same entry. Weird.

Another issue which I would consider a bug and I don't know if IBM will ever address this:

If I customize the LDAP Schema by using custom schema files I.e. V3.myschema.oc and V3.myschema.at, the Web Admin Tool does not acknowledge this and continues to drop stuff in V3.modifiedschema instead. TDS supports creating custom schema files by allowing you to reference the custom files in ibmslapd.conf. This is one way of keeping your custom schema organized neatly. In fact if you keep all of your custom attributes and classes in order by OID (assuming you are using a legitimately registered OID) then it makes it easy to know what OID to use next for any new attributes or classes. Also, if you have replicas, schema updates to the replicas is a simple matter of copying your updates schema files over to the replicas and restarting them.

Anyhow, most folks managing LDAP servers seem to prefer using 3rd Party tools if they need a good GUI style interface, but it would be nice if the Web Admin Tool was a little less buggy.