It's been too long - IBM Tivoli Access Manager for e-business ( WebSEAL ) ... and openLDAP - what can possibly go wrong ?

So I haven't installed/used IBM Tivoli Access Manager for e-business ( WebSEAL ) properly since ~2008, although I've worked with a number of clients utilising this secure reverse proxy access management solution.

Last night, I decided to rectify that, and install/configure TAMeB on a VM on my Mac.

Me being me, I decided not to bother with documentation or too many pre-requisites, so I downloaded the software ( plus fixes, taking me to version 6.1.1.8 ), and try and configure it against ... openLDAP. Last time around, I did the right thing and used a "real" user identity management solution, IBM Tivoli Directory Server.

So, after much hacking around, I got to a bit of a blocker.

As part of the installation, one is required to run the following command: -

./install_ammgr -console

to install AND configure TAM.

This, in part, runs the following command: -

/opt/PolicyDirector/sbin/PDMgr_config

This runs for a while and then fails with: -

Unable to verify the management domain location DN in the
LDAP server: (secAuthority=Default).
If the location does not exist on the server, create it,
otherwise specify a different location that does exist.

...

2014-10-15-21:20:23.563+01:00I----- 0x16B480C9 IRAapi ERROR rgy ira ira_domain.c 1424 0xf77e46c0
HPDRG0201E   Error code 0x22 was received from the LDAP server. Error text: "Invalid DN syntax".

Whist this was obviously an LDAP issue, I wasn't too sure precisely what the root cause was.

Thankfully, some digging about in various internal/external fora gave me these two life-saver commands: -

export LDAP_DEBUG=65535 
export LDAP_DEBUG_FILE=/tmp/ldap_debug_file 

Having run these inside the shell from which I then ran PDMgr_config, I got a nice trace log - /tmp/ldap_debug_file - which contained, in part: -

T-143694144:    +---------------------------------------------------------+
T-143694144:    |0000|30840000 01370201 07688400 00012E04|0....7...h......|
T-143694144:    |0010|31736563 41757468 6F726974 793D4465|1secAuthority=De|
T-143694144:    |0020|6661756C 742C6F75 3D757365 72732C64|fault,ou=users,d|
T-143694144:    |0030|633D756B 2C64633D 69626D2C 64633D63|c=uk,dc=ibm,dc=c|
T-143694144:    |0040|6F6D3084 000000F5 30840000 0086040B|om0.....0.......|
T-143694144:    |0050|6F626A65 6374636C 61737331 84000000|objectclass1....|
T-143694144:    |0060|73041073 65634175 74686F72 69747949|s..secAuthorityI|
T-143694144:    |0070|6E666F04 12654170 706C6963 6174696F|nfo..eApplicatio|
T-143694144:    |0080|6E537973 74656D04 07655379 7374656D|nSystem..eSystem|
T-143694144:    |0090|04116369 6D4C6F67 6963616C 456C656D|..cimLogicalElem|
T-143694144:    |00A0|656E7404 1763696D 4D616E61 67656453|ent..cimManagedS|
T-143694144:    |00B0|79737465 6D456C65 6D656E74 04116369|ystemElement..ci|
T-143694144:    |00C0|6D4D616E 61676564 456C656D 656E7404|mManagedElement.|
T-143694144:    |00D0|03746F70 30840000 001D040C 73656341|.top0.......secA|
T-143694144:    |00E0|7574686F 72697479 31840000 00090407|uthority1.......|
T-143694144:    |00F0|44656661 756C7430 84000000 14040776|Default0.......v|
T-143694144:    |0100|65727369 6F6E3184 00000005 0403362E|ersion1.......6.|
T-143694144:    |0110|30308400 00002604 0B696E73 74616C6C|00....&..install|
T-143694144:    |0120|44617465 31840000 00130411 32303134|Date1.......2014|
T-143694144:    |0130|31303135 32303430 32312E30 5A      |1015204021.0Z   |
T-143694144:    +---------------------------------------------------------+

and: -

T-143694144:    +---------------------------------------------------------+
T-143694144:    |OSet| Address = 08656C00  Length = 0016 |     ASCII      |
T-143694144:    +---------------------------------------------------------+
T-143694144:    |0000|02010769 110A0122 0400040A 696E7661|...i..."....inva|
T-143694144:    |0010|6C696420 444E                      |lid DN          |
T-143694144:    +---------------------------------------------------------+

This made me think, and look for references to secAuthority=Default online, from whence I found: -

Number of TAM users in LDAP

Configuration requires secAuthority=Default suffix.

both of which made me realise that TAMeB is looking for a particular suffix/object class, which, of course, doesn't exist, by default, in openLDAP.

Now I'm not sure whether I'll continue to hack around to make TAMeB work with openLDAP, or follow the path of least resistance and install ITDS .........

However, it's good to know about that LDAP debug string, as I'm SURE to need it again in the future ....