Changing LDAP Suffix

Of course when building an LDAP it's best practice to choose wisely and carefully your LDAP structure to minimize any ugly rework later. This is a no brainer. But, I've been working on setting up a demo test system for TFIM. And, as I am not a web developer I'm going to use the demo apps that come with Tivoli Federated Identity Manager 6.1. But this Federation demo assumes that there are specific configurations done in your LDAP first.

Now, I already had a working TAMeB system with TDS and WAS, etc.... So I wanted to use what I had to minimize the work in setting up TFIM. I built another TAMeB environment to act as my partner site as well. Installing TFIM and creating the Federation domain was no problem. Even creating the Federation agreements and exporting both sides was straight forward. But when it came to configuring TAM for TFIM I ran into an unforeseen snag at the point where this program wants to configure for the demo apps:

tam:/opt/IBM/FIM/tools/tamcfg # java -jar ./tfimcfg.jar -action tamconfig -cfgfile /opt/pdweb/etc/webseald-default.conf

...
Press 1 for Next, 2 for Previous, 3 to Repeat, C to Cancel: 1
Perform configuration for demo application (y/n): y
Checking for DN cn=elain,o=identityprovider,dc=com.
FBTTAC062E Error checking for the DN cn=elain,o=identityprovider,dc=com in the user registry:
HPDMG0761W The entry referred to by the Distinguished Name (DN) must be a person entry.

You may need to create this registry entry manually or use the itfim-pre-install-tool.jar to create it for you.
Press 1 to Repeat, 2 for Previous, C to Cancel:

So, I really didn't consider that the demo apps for TFIM would be relying on specific users to exist in TAM/LDAP and even a specific LDAP structure. This is sort of lame. I need these demo apps for my testing, yet I'm forced to have a specific set of users and LDAP design. Annoying.

I set to work making the necessary changes to my LDAP, however one problem was that my suffix was already dc=ca,dc=com and the LDAP will not allow me to create a new object for the demo "o=identityprovider,dc=com". This means I need a new suffix at dc=com which the LDAP will not allow since a suffix already exists containing dc=com. No worries, I figure I'll just do a db2ldif and export my users and groups, etc... (TAM is using these already), then blow out the LDAP, delete the existing suffix and create a new one "dc=com", then just add the "dc=ca" domain under the suffix and finally do a ldif2db.

This all worked right up until I realized that the ACLs do not go back into the LDAP. The db2ldif utility will capture the ACLs and they will be right there in your LDIF file, but for some reason when you use the ldif2db these ACLs do not go back into the LDAP. Additionally I tried a bulkload with the -A and still no ACLs. I know that I must be missing something. Rather than spend a lot of time troubleshooting this I ended up configuring the ACLs for TAM manually on my "dc=com" object so that I could get back to business. If anyone knows what I may have missed, feel free to let me know.

Regards