As part of account management processing ITIM will temporarily lock access to the related service. The status of the service is recorded in the resource_provider table in the ITIM database.

Under normal processing the service is unlocked when account management processing completes. If a process is terminated or aborted however it may not complete cleanly. This may leave the service in a locked state - thereby rendering it unusable for any further processing. Under this condition subsequent adapter requests remain in the Pending Request queue and 'Resource Failed' is recorded in the process state.

To address this condition it is necessary to manually unlock the service. The following procedure describes how this can be achieved:

1. Within the ITIM application abort the Pending Request in state 'Resource Failed' and any other Pending Requests that target the locked service.

2. Connect to ITIMDB as the ITIMUSER

              db2 "connect to <ITIMDB> user <ITIMUSER> using <ITIMUSERPWD>"

Note: resource_status can have a value of null (-), 0 (unlocked) or 1 (locked)

3. Update the resource_status column for the record that represents the locked service

db2 "update resource_providers set resource_status=0 where resource_dn=<output from step 2>

i.e.

db2 "update resource_providers set resource_status=0 where resource_dn='erglobalid=0123456789123456789,ou=services,
erglobalid=000000000000000000000,ou=TENANT,dc=com'"

Following completion of these steps, retry the account update via ITIM - this operation should now complete successfully.

This remedial action is appropriate for both ITIMv4.6 and ITIMv5.0

This is just a very brief reference for utilising the GSKit command line utility (gskNikm) for creating / extracting keys.This may be useful for example if you want to create keys in batch or in a script. Sample values are given for each command input.

To create a key database:

gsk7cmd -keydb -create -db <key-name.kdb> -pw <password> -type cms -expire 365 -stash

To generate a certificate signer request (to send to CA for signing):

gsk7cmd -certreq -create -db <key-name.kdb> -pw <password> -type cms -label <key-label> -dn cn=<key-name.company.com,O=company,C=GB> -size 1024 -file <cert_request_key-name.arm>

To add a CA to a key file (if company has an internal CA, for example):

gsk7cmd -cert -add -db <key-name.kdb> -pw <password> -type cms -label <"Company CA"> -file <company-ca.arm> -format ascii

Receiving your certificate (in response to the CSR - once your personal certificate has been signed):

gsk7cmd -cert -receive -file <key-name.cer> -db key-name.kdb -pw <password> -type cms -format ascii -default_cert yes

NB: it may be necessary to import intermediate signer certs, in chain order, before you can import the personal certificate.

Convert kdb to jks (ie for use in configuration of WebSphere Application Server):

gsk7cmd -keydb -convert -db <key-name.kdb> -pw <password> -old_format cms -new_format jks

It's not uncommon to see errors from the Windows Services Manager during bootup, saying "At least one service or driver failed during system startup. Use Event Viewer to examine the event log for details". It may be that the service you are trying to start is not responding fast enough and the Services Manager is flagging it as a timeout. In the Tivoli Security arena we typically see this if the ITDS service is marked for automatic start.

If you think this may be the case, look for a "7011" error in the event log indicating that Windows was waiting more than 30 seconds for a service to respond. If so, you can extend the time that the Service Manager will wait before it decides that a service is not going to start by creating or updating the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ServicesPipeTimeout registry setting. Details for doing this are described in the following Microsoft support article: http://support.microsoft.com/kb/922918.

• If you enable security in WAS, and then run in to problems - you can disable security in the security.xml file (<profile install path>/config/cells/<cell name>/security.xml) - set 'enabled="false"'
• After enabling security, if you have trouble stopping WAS due to SOAP related issues, check that you have the correct values defined in soap.client.properties (<profile install path>/properties/soap.client.properties). for example check the values for: com.ibm.SOAP.securityEnabled=true, loginUserid, loginPassword, keyStore and trustStore
• To encrypt the passwords in the soap.client.properties file, use the PropFilePasswordEncoder.sh utility. For example: eg. ./PropFilePasswordEncoder.sh ../properties/soap.client.properties com.ibm.SOAP.loginPassword,com.ibm.ssl.keyStorePassword,com.ibm.ssl.trustStorePassword
• Note there can be some issues with using JSSE2 for SSL (and error messages in WAS logs tend to be very specific if this is the problem). If feasible, I personally recommend using JSSE.
  

A few issues relating to IBM Tivoli Directory Integrator v6.1.1 that we have recently observed...

SAX Parser error

When trying to run an Feed of HR information via ITDI we saw a "Sax Parser Error, Line1" error. This was fixed by installing FP2 into the installation. Details for this fix pack can be found here.

global.properites & solution.properties

ITDI will generate a solution.properties file from the global.properties file if this file does not already exist. The default locations for the files is:

global.properties:- $(tdiinstalldir)/etc/global.properties
solution.properites:- $(tdiinstalldir)/solution/solution.properties

When configuring SSL make sure that keystores/passwords are stored in both properties files and are encrypted by the GUI.

Java.security file

Page 48 on the ITDI v6.1.1 Administration Guide states that the following lines need to be changed in the file <root>/jvm/lib/security/java.security:

security.provider.1=com.ibm.jsse.IBMJSSEProvider 

and 

ssl.ServerSocketFactory.provider=com.ibm.jsse.JSSEServerSocketFactory

However when this change is made and an SSL connection is attempted we fond that a "Class Not Found" exception was thrown. When enquiring on this issue with IBM we received the response that this java.security file update should actually be ommitted (i.e. the documentation is in error). On reversing this change we subsequently found that the SSL connection was successful.  Moving the ServerSocketFactory and SocketFactory into a default class which is automatically sourced by this version of ITDI solves the problem.