Recover a missing obfuscated file from TAM

The content is taken from the following blog post, copying it for my future reference.
http://identityandaccessmgmt.blogspot.in/2010/05/how-to-recover-missingdeleted-tam.html

Prior to TAM 5.1 the bind password was defined in the WebSEAL configuration file, in clear text (see bind-pwd). With later TAM versions for security reasons IBM introduced the *.obf file, in which the bind password is obsfucated. Here we describe the process of creating a new obf file in the event that the original file is modified/deleted.
Note that the following solution depends on the existence of a valid obf file and WebSEAL bind account elsewhere within your TAM environment.
The obf file contains the password for the account used by WebSEAL when binding to the user repository (LDAP). The obf file is created during the configuration process and should not be modified or deleted. There is no supported way to recreate the obf file, but you can borrow one from a working WebSEAL instance and synchronise the password (userPassword) using native LDAP commands.
Consider an environment that consists of two WebSEAL instances; good-webseal and bad-webseal. In our example we assume that the obf file has been removed for the bad-webseal instance. When you attempt to restart the WebSEAL it will fail as it will not be able to bind to the LDAP. The solution for this scenario is as follows:
1. Retrieve the userPassword for the good WebSEAL instance - for example:
ldapsearch –h ldap.server –p 389 –D cn=root –w password –b cn=good-webseald/tivoli.com,cn=SecurityDaemons,secAuthority=Default –s base –L objectclass=* userPassworddn: cn=good-webseald/tivoli.com,cn=SecurityDaemons,secAuthority=Default
userPassword: GOOD_PASSWORD_HASH
2. Set the bad WebSEAL bind password to the good WebSEAL password - for example:
ldapmodify –h ldap.server –p 389 –D cn=root –w password
dn: cn=bad-webseald/tivoli.com,cn=SecurityDaemons,secAuthority=Default
changetype: modify
replace: userPassword
userPassword: GOOD_PASSWORD_HASH
3. Create a bad WebSEAL obf file from the good WebSEAL obf file:
cp webseald-good.conf.obf webseald-bad.conf.obf
4. Start the bad WebSEAL
pdweb restart bad
5. The .obf file is now recovered, and the WebSEAL server is now running.

Create a new webseal key database file (webseald.kdb) when corrupted.

How to create a NEW keydatabase for webSEAL instance.

Sometimes by mistake if other instance's certificate is copied over another.
In that case, we can follow the similar steps but the only difference we need to delete all the certs from "/var/pdweb/keytab-<instance>/" location and then perform steps directly on "/var/pdweb/keytab-<instance>/" path (i.e. no need to create a temp directory and replace the certificate).
 It sometimes gets corrupted during the auto refresh of the certificate.

Most common error we see in such cases is as below:

1) 
HPDBA0230E. The certificate label or DN is invalid

OR

2)

HPDCF0061E The function, GSKKM_GetKeyItemByLabel(), returned the error 
code: 0x00000075. 
HPDCF0117E An error occurred in the "IKeyMan" API. Configuration 
failed. 
SSL configuration failed.

Steps to create webSEAL.kdb file when its corupted with above errors:

Before starting with the steps make sure the java path is configured. If not you may export it like below:

export PATH=/opt/ibm/ldap/V6.1/java/bin/:/usr/local/ibm/gsk7/bin/:$PATH

1) Make a temp dir and change to it
mkdir /var/pdweb/keytab-<instance>/temp
cd /var/pdweb/keytab-<instance>/temp

2) Create a mostly empty kdb
gsk7cmd -keydb -create -db replaceicert-webseald.kdb -pw passw0rd -stash -type cms -expire 7200

3)  Add Policy Director CA certificate.

# Note if the /var/PolicyDirector/keytab/pdcacert.b64 doesn't exist you need to get it from the policy server first.

gsk7cmd -cert -add -db replaceicert-webseald.kdb -pw passw0rd -file /var/PolicyDirector/keytab/pdcacert.b64 -label "Policy Director CA"

4) Remove the other CAs
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "Entrust.net Global Secure Server Certification Authority"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "Entrust.net Global Client Certification Authority"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "Entrust.net Client Certification Authority"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "Entrust.net Certification Authority (2048)"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "Entrust.net Secure Server Certification Authority"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "VeriSign Class 3 Secure Server CA"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "VeriSign Class 3 Public Primary Certification Authority"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "VeriSign Class 2 Public Primary Certification Authority"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "VeriSign Class 1 Public Primary Certification Authority"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "VeriSign Class 4 Public Primary Certification Authority - G2"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "VeriSign Class 3 Public Primary Certification Authority - G2"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "VeriSign Class 2 Public Primary Certification Authority - G2"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "VeriSign Class 1 Public Primary Certification Authority - G2"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "VeriSign Class 4 Public Primary Certification Authority - G3"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "VeriSign Class 3 Public Primary Certification Authority - G3"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "VeriSign Class 2 Public Primary Certification Authority - G3"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "VeriSign Class 1 Public Primary Certification Authority - G3"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "Thawte Personal Premium CA"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "Thawte Personal Freemail CA"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "Thawte Personal Basic CA"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "Thawte Premium Server CA"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "Thawte Server CA"

5) Create a self signed cert with the correct subject
gsk7cmd -cert -create -db replaceicert-webseald.kdb -pw passw0rd -dn "CN=<instance>-webseald-<hostname>,OU=Default,O=Access Manager,C=US" -label "PD Server"

6) Copy the new keystore and sth file over the existing for the non-working instance.

Leave the temp dir
cd ..
cp /var/pdweb/keytab-<instance>/temp/replaceicert-webseald.kdb /var/pdweb/keytab-<instance>/<instance>-webseald.kdb
cp /var/pdweb/keytab-<instance>/temp/replaceicert-webseald.sth /var/pdweb/keytab-<instance>/<instance>-webseald.sth

7) Correct the permissions
chmod 600 /var/pdweb/keytab-<instance>/<instance>-webseald.kdb
chmod 600 /var/pdweb/keytab-<instance>/<instance>-webseald.sth
chown ivmgr:ivmgr /var/pdweb/keytab-<instance>/<instance>-webseald.kdb
chown ivmgr:ivmgr /var/pdweb/keytab-<instance>/<instance>-webseald.sth

8) Change the password and request a new cert from the Policy Server
svrsslcfg -chgpwd -f /opt/pdweb/etc/webseald-<instance>.conf
svrsslcfg -chgcert -f /opt/pdweb/etc/webseald-<instance>.conf

9) Verify the key is correct
/opt/PolicyDirector/sbin/dispkdb -f /var/pdweb/keytab-<instance>/<instance>-webseald.kdb

10) Start the WebSEAL server.
pdweb start <instance>

11) If everything works remove the temp dir and the temp key
rm -r /var/pdweb/keytab-<instance>/temp

Integrate IBM Tivoli Access Manager for e-business with Lotus iNotes with LTPA Single Sign On(SSO)

This post describes the procedure for integrating IBM Tivoli Access Manager for e-business (Tivoli Access Manager) with Lotus iNotes to achieve Single Sign-On (SSO) and Single Sign-Off capability using LTPA SSO method.

The diagram above shows an integration architecture that supports the following
processes:
1. A browser request for Lotus iNotes is submitted through WebSEAL.
2. WebSEAL intercepts the request, authenticates and authorizes the user as
required.
3. WebSEAL forwards the request to the Domino Server along with a cookie
containing the encrypted LTPA token which holds the unique Distinguished
Name (DN) of the user authenticated by WebSEAL.
4. Domino decrypts the LTPA token and authenticates the DN against those in its
NAB and if a match is found access is granted.
5. The requested iNotes content for the authenticated user is sent back to
WebSEAL.
6. WebSEAL performs filtering as appropriate for the junction method then the
content is returned to the browser.

This integration scenarios is for the following product versions:
Lotus Domino Server 7.0.1, 8.0, 8.5 or 8.5.2
IBM Tivoli Access Manager Base 6.0, 6.1 or 6.1.1
IBM Tivoli Access Manager WebSEAL 6.0, 6.1 or 6.1.1
Note: Lotus iNotes might have additional constraints in the form of supported
browsers. Domino documentation for the supported version numbers should
be consulted prior to proceeding with this integration.

Before we start:: 2 point to keep in mind!


1) Configuring Tivoli Access Manager and the iNotes user
registry

-both Lotus Domino and Tivoli Access Manager use separate
user registries

-For each user in the Domino Address Book that requires iNotes, create a
corresponding user in Tivoli Access Manager

2)Generating the LTPA key file
-The LTPA key file is needed when creating the WebSEAL junction to the
Domino server, and also when creating the SSO document on the Domino server.

Option Description
-A Enable LTPA cookies
-F path_to_LTPA_keyfile Full path name location of the LTPA key file
-Z keyfile_password Password required to open the key file

Configuration Steps:

1)Tivoli Access Manager WebSEAL configuration.

option-1: copy the existing environment junction xml files to the new environment.
may need to generate a new LTPA keyfile here with help of WAs. not sure if the existing
LTPA keyfile(have to check on this),if we use the existing keyfile- make sure we know the
password to open the file.

option-2: create a new junction:-

2) Lotus Domino configuration

step-1: need the LTPA key file that was previously generated and used
when creating the WebSEAL junction. Copy this file from the WebSEAL
machine to an appropriate directory on the Domino server.

step-2: Configuring the SSO document for the Domino server
-Creating Web SSO Configuration.

step-3: Configuring the Domino server for single sign-on
To ensure that the Domino Server is properly configured for Single Sign-On.

step-4: Adding the LDAP DN to the Person documents

This step adds the LDAP DN to the User Name field of the user document. For
each user requiring SSO through WebSEAL to their iNotes database, we need to do this
configuration.

step-5: Configuring the Domino server for single sign off
To ensure that the Domino Server is properly configured for Single Sign Off.

For more details like post installation verification, uninstallation and Troubleshooting,
Please refer the attached pdf from IBM. Integration guide from IBM