Tuesday, June 30, 2009

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

Wednesday, June 3, 2009

Which product version do you have?

The Tivoli security products contain several components and middleware making it sometimes difficult to know exactly what versions and fix packs you are at for all of the pieces. Also, you may only need this information once in a while maybe for troubleshooting a problem or planning some upgrade or change to the environment. So you ask, "what was that command again to determine the version of TIM, TAM, WAS, TDI, etc...? And as usual for every piece of the puzzle the commands or procedure for determining the versions and fix packs are different. Then, finding this information on the IBM Support site or the Information Center for some pieces is difficult. You would think that for each product the first chapter of the Problem Determination Guide would start with "How to determine your product version and fix pack level". NOT!

I'm simply listing here the results of my hour and 1/2 of internet searches here to hopefully save time when I need this info again. There are by the way some very good IBM Wiki sites for this info. I've listed some below. It's crazy though that these Wiki's did not show up in my searches of the IBM Support site.

Check Version Info for TDS 5.2

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

Example:

rpm –qa | grep ldap
rpm –qa | grep db2
rpm –qa | grep gsk
ls –l /usr/ldap/bin
ibmslapd -V

If the Web Administration Tool is installed and configured please collect the output of:
ls -l /usr/ldap/idstools/IDSWebApp.war

Check for version info for TDS 6.0

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

Example:

rpm -qa | grep -i ldap
rpm -qa | grep -i db2
rpm -qa | grep -i gsk
ibmslapd -V
idsilist -a

If the Web Administration Tool is installed and configured collect the output from:
./opt/ibm/ldap/V6.0/idstools/deploy_IDSWebApp.sh -v

Check for version info for TDS 6.1

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

Example:

/opt/ibm/ldap/V6.1/bin/idsversion
rpm -qa | grep -i gsk
idsilist -a

If you are using DB2 v9.1 or higher issue the following command:
/usr/local/bin/db2ls

Otherwise issue:
rpm -qa | grep -i db2

If the Web Administration Tool is installed and configured, please collect the following:
/opt/IBM/ldap/V6.1/idstools/deploy_IDSWebApp -v

Check version of the TDS Web Admin Tool (Any version)

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

Check for Version of WebSphere

http://www-01.ibm.com/support/docview.wss?rs=638&context=SSPREK&q1=version&uid=swg21306756&loc=en_US&cs=utf-8&lang=en

Example:

versionInfo.sh in the app_server_root\bin directory.

Check for version info for TAMeB

http://www.ibm.com/software/info/testinfo.jsp?uid=IC000043

Example:

pdversion

Check for version info for TIM

http://www.ibm.com/developerworks/wikis/display/tivoliim/Determining+Product+Fixpack+Levels

From the TIM Admin Console, open the "About" page

Example:

Server name: secperf12
Version: 5.0.0.3
Build number: 200809241018
Maintenance level: IF0014
Build date: September 24 2008
Build time: 10:18:08 GMT-05:00

Check for version info for GSKit

http://www.ibm.com/developerworks/wikis/display/tivoliim/Determining+IBM+GSKit+Fixpack+Level

Check for version info for TDI 6.0


http://www.ibm.com/developerworks/wikis/display/tivoliim/Determining+IBM+Tivoli+Directory+Integrator+Fixpack+Level

Check for version info for TDI 6.1

http://www-01.ibm.com/support/docview.wss?uid=swg21302983

Example:

Unix/Linux -
1) cd /usr/ibm/common/acsi/bin
2) //source the setenv.sh
. /var/ibm/common/acsi/setenv.sh
3) //run the listIU.sh
./listIU.sh | grep -i tdiserversiu


Check for version info for TIM Agents


http://www-01.ibm.com/support/docview.wss?rs=644&context=SSTFWV&dc=DA420&dc=DA480&dc=DA490&dc=DA430&dc=DA410&dc=DB600&dc=DA400&dc=D600&dc=D700&d

c=DB520&dc=DB510&dc=DA500&dc=DA470&dc=DA4A20&dc=DA460&dc=DA440&dc=DB550&dc=DB560&dc=DB700&dc=DB530&dc=DA4A10&dc=DA4A30&dc=DB540&q1=version&uid=s

wg21140454&loc=en_US&cs=utf-8&lang=en


Example:

Run agentCfg -> Configuration Settings

Tuesday, June 2, 2009

INFO: ssl.disable.url.hostname.verification.CWPKI0027I

From what I can tell there can be a number of reasons you might get this error during TAM Configuration or unconfiguration. In my case I made a small mistake while in a hurry and also because in my test lab, I don't take as much care as I would typically take as with a production system. I did not unconfigure Web Portal Manager before removing WAS. This should not be a big deal, but apparently it is.

I'm preparing my TAM Test Lab to also support TFIM. In doing this I upgraded my TAMeB components to 6.1 FP002. But, also I chose to replace the WAS 6.1 server with a WAS 6.1 ND because I plan to do some other clustering stuff as well.

The TAMeB upgrade and patches worked fine. Afterwords, TAM, pdadmin, WPM was all fine. But after manually removing WAS 6.1 and installing WAS 6.1 ND, WPM was hosed. To install WPM, I simply installed it using the GUI installer as I have done before only this time WPM did not show up in the ISC as it should even though the installation said it was successful. So, I then realized that when I had removed WAS and installed WAS ND, I had never unconfigured WPM.

Attempting to unconfigure Web Portal Manager using pdconfig or amwpmconfig resulted in this:

Tivoli Access Manager administrator ID: [sec_master]:
Tivoli Access Manager administrator password:******** *java.lang.IllegalStateException: HPDAZ0602E Corrupted file: Insufficient information to contact a Policy Server.


Then I realized the JRTE needed to be reconfigured for the new WAS 6.1 ND so I ran through the JRTE configuration again for my latest Java 5 location and for the WAS 6.1 ND JRE. Then the next problem was this:

Enter the IBM WebSphere Application Server or Deployment Manager
installation full path [/opt/IBM/WebSphere/AppServer]:
Policy server host name [tam]:
Tivoli Access Manager policy server port number [7135]:
Enter the Access Manager policy server domain [Default]:
Tivoli Access Manager administrator ID: [sec_master]:
Tivoli Access Manager administrator password:******** *Enter the hostname of the IBM WebSphere Application Server
or Deployment Manager[tam]:
Enter the SOAP Admin port number of the WebSphere
Application Server or Deployment Manager [8880]:
Is WebSphere security enabled (y/n) [n]?
Unconfiguration of:
Access Manager Web Portal Manager
is in progress. This might take several minutes.

Jun 1, 2009 10:58:47 PM com.ibm.ws.ssl.config.SSLConfigManager
INFO: ssl.disable.url.hostname.verification.CWPKI0027I
java.lang.NullPointerException
at com.tivoli.pd.jwpmcfg.WPMConfigure.unconfig(WPMConfigure.java:572)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at com.tivoli.pd.jwpmcfg.WPMConfigWrapper.unconfig(WPMConfigWrapper.java:325)
at com.tivoli.pd.jwpmcfg.AMwpmcfg.interactUnCfg(AMwpmcfg.java:447)
at com.tivoli.pd.jwpmcfg.AMwpmcfg.main(AMwpmcfg.java:271)


So after scratching my head enough times and poking around I discovered that all I needed to do was delete /opt/PolicyDirector/etc/amwpmcfg.properties. This allowed me to reconfigure the Web Portal Manager using pdconfig and now Web Portal Manager shows up properly in the Integrated Solutions Console as it should. So I only lost 4 hours messing around with this silly issue. Just goes to show how a simple mistake can cost you 1/2 day of work.

Cheers!