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!

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.

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.

LDAP: error code 52 - Unavailable

OK, There may be numerous reasons for this error, but of course TDS just doesn't come right out and explain it for you. This was a weird one in my case because I was simply trying to delete a password policy which I had no problems creating just moments ago. I was trying a quick and dirty test which turned into several hours of troubleshooting in the midst of my other duties.

Well I tried to delete this password policy using the TDS Web Admin Tool and this is what resulted:

GLPWSA124E Failed to delete the password policy object.

Then I attempted to use my trusty LDAP Browser/Editor and different error, but same result:

10:19:52 PM: Failed to delete entry cn=pwPolicy1, CN=IBMPOLICIES
Root error: [LDAP: error code 52 - Unavailable]

So, just for kicks I enabled trace logging:

ldtrc on

I restarted the server and attempted to delete my password policy again. Here's what showed up in the log:

137:23:14:33 T115510160 Delete operation for DN CN=PWPOLICY1,CN=IBMPOLICIES requested by CN=ROOT.
137:23:14:33 T115510160 select_backend: g_backends=0x9928310, dn=CN=PWPOLICY1,CN=IBMPOLICIES
137:23:14:33 T115510160 select_backend: selected CN=IBMPOLICIES
137:23:14:33 T115510160 subtreeDn=CN=IBMPOLICIES
137:23:14:33 T115510160 The update is not from a supplier.
137:23:14:33 T115510160 send_ldap_result2: err=10 matched=[] text=[]
137:23:14:33 T115510160 WriteToSocket: Sending msg to client

So, I'm thinking "who cares if the update is from a supplier or not?" This got me thinking about a replication issue. Now when I built my replicas for this test lab, I did not configure replication for CN=IBMPOLICIES. At the time I had no desire to replicate these.

In looking at this further I see that the replication topology is all hosed for CN=IBMPOLICIES.

Peer 1:









Peer 2:









So, then how to clean this mess up? I found a handy tech note on the IBM Support Web Site. I know this was referenced by the good folks at L2 Support who put on an STE a while back. It just took me a while to relate the fact that I couldn't delete this simple password policy to a replication issue. Anyhow, the tech note:

http://www-01.ibm.com/support/docview.wss?rs=767&context=SSVJJU&q1=cn%3dibmpolicies&uid=swg21226577&loc=en_US&cs=utf-8&lang=en

LDAP - What's in a string?

Sometimes when I'm doing projects I run across some things that make me wonder.. Huh?

When you are building LDAP objectclasses and attributes for your Identity Management project, should you be using Directory String or IA5 String for your typical attributes? Actually there are several string types supported by LDAP:

IA5String, DirectoryString, PrintableString, OctetString, PostalAddress, CountryString and NumericString.

Most often in the projects I have worked on we would use DirectoryString for most custom attributes. Looking at the RFC's you can pick up bits and pieces about the differences beteen IA5String and Directory String. My friend Thom Anderson does a great comparison of these two string types. Read on:

"The IA5 is more constrained than Directory String. You can think of it is ASCII on steroids . . . ASCII is a 7-bit protocol and for years, persons have been finding themselves with an eight-bit byte wondering what to do with the extra bit. Normally, they use the ‘zero’ value of the extra bit for ASCII characters and then use the ‘one’ value for things such as special characters (early IBM PC) or European characters (IA5). Although the ‘IA’ in IA5 means ‘international alphabet. It does not include all languages as that would require more than 8 bits. That is where Directory String comes in. Directory String is basically UTF-8, a version of Unicode that has only 8 bits for Western languages, but requires more bits (in 8-bit increments) as one moves East."

"Only in IA5 can you be assured that the number of characters and number of bytes is the same. Of course, that would limit one to Western characters, but that is not such a bad thing. In many cases, it will not make any difference. In the U.S. ASCII is sufficient and it is a subset of both IA5 and UTF-8."