Simple Steps to configure TDS Replication.

                   A lot of people have been asking me how TDS Replication works and what are the steps to configure it.

TDS or the Tivoli Directory Server is the IBM implementation of Lightweight Directory Access Protocol.

Its one the main components that are generally preferred to be used as a backend directory for most of the IBM related Products like ISIM and ISAM.

and Yes TDS does have the concept of High availability and Disaster Recovery, we call it as TDS replication.

Unlike HADR in DB2 we have the master to master replication and master-slave and slave-master replication which is similar to the primary-secondary and primary to primary configuration in DB2.

Below are the steps on how to configure tds replication between already existing two TDS servers:

1.Before you start the Replication configuration do make sure the SALT and SEED values are same in both the TDS Servers.

command to check the salt and seed values:

Go to ldap bin folder and run the command--

ldapsearch -D <username> -w <Password> -h <hostname/IP of the TDS server> -p <port number> -s base -b cn=crypto,cn=localhost cn=*

so the final command will look like this

ldapsearch -D <cn=root -w password -h mytdsserver -p 389 -s base -b cn=crypto,cn=localhost cn=*

Run this on both the server machines and take care that the ibm-slapdcrytosync and ibm-slapdcrytosalt are same for both the servers.

2.Copy the v3.modifiedschema file (from old LDAP server if doing migration) to both the servers.

3.Make sure you have the suffixes created with the same names it should be exact till the minute detail like the uppercase and lowercase characters.

4. To start the replication click on manage topology and select ADD subtree.

5. Browse for the entry.

6. Select the suffix entry for which replication is to be configured for Ex: dc-com.

7. click on Browse button and add the subtree like dc=com and the enter the master server ldap url and click OK.

8. Select the entry dc=com and click on show topology.

9. Select the server and click on Add master if you are configuring master replication.

10. Select the hostname and server ID of the second server for which replication is to be configured.

11.  Select the Credentials object and add the credentials of your choice.

12. Click on the Additional tab and Enter the Consumer credentials and click OK.

13. Now click OK on the message that is being displayed.

14.Select the location for credentials as dc=com and add the consumer credentials information.

15. Click ok on the message that is getting displayed.

16. With this the replication topology has been configured.

17. Now on clicking the manage topology it should show the proper replication structure as below.

18. Now export the data that is present in the primary LDAP using the command 

idsdb2ldif -o firstdata.ldif -S "dc=com" -I <TDSinstancename>

19. Now import the data that was exported from the first LDAP to the secondary LDAP using the command.

idsldif2db -r no -i firstdata.ldif -I <TDSinstancename>

20. After completing the export and import of LDIF data now click on manage queues and then select the secondary ldap server and click on the button SUSPEND/RESUME button.

With this the replication has been configured.

Hope this helps......... 

ISAMESSO : Replacing the IBM HTTP Server SSL certificate with an SSL certificate signed by a third-party CA

Make sure that:

• you have installed and configured WebSphere® Application Server 7.0 with minimum fix pack 5 in your computer
• you have installed and configured IBM® HTTP Server 7.0 in your computer
• you have a copy of the third-party CA certificate file, in Base64-encoded ASCII or binary DER format
• you have a copy of the SSL certificate signed by the third-party CA and its corresponding private key
  Note: the SSL certificate and its private key must be stored in a keystore file with any one of the following supported types:

  • JKS
  • JCEKS
  • PKCS11
  • PKCS12
  • CMSKS
  • PKCS12JarSigner
• the third-party CA certificate has been distributed to the computers where AccessAgent is installed, and
• the certificate must be imported into the Trusted Root Certification Authorities container of the Computer account in the Windows® Certificate Store
  Note: AccessAgent does not work if the third-party CA that signs the IBM HTTP Server SSL certificate is not trusted by Windows, on which the AccessAgent is installed.

Procedure

1. Log on to the IBM Integrated Solutions Console.
2. Add the third-party CA certificate to the WebSphere Application Server truststores.
   Note:

   • If you are using a standalone WebSphere Application Server, complete step 2 for the NodeDefaultTrustStore.
   • If you are using a WebSphere Application Server Network Deployment cluster, complete step 2 for the CellDefaultTrustStore and every NodeDefaultTrustStore.
   1. On the Integrated Solutions Console left navigation pane, select Security > SSL certificate and key management.
   2. Under Related Items, click Key stores and certificates.
   3. Click the <truststore name>. For example, NodeDefaultTrustStore or CellDefaultTrustStore.
   4. Under Additional Properties, click Signer certificates.
   5. Click Add.
   6. In the Alias field, enter an alias name for the third-party CA certificate. For example, rootca.
   7. In the File name field, enter the file path to the third-party CA certificate file. For example, C:\rootca.der.
   8. From the Data type list, select the format of the certificate file.
   9. Click OK.
   10. Changes have been made to the local configuration. Click Save.
3. If you are using a standalone WebSphere Application Server, restart the WebSphere Application Server.
   If you are using a WebSphere Application Server Network Deployment cluster, perform a full resynchronization of the nodes; restart the cluster; and start the IMS Server.
   To perform a full resynchronization of the nodes:

   1. On the Integrated Solutions Console left navigation pane, select System administration > Nodes.
   2. Select the check boxes of the nodes where the IMS Server is installed.
   3. Click Full Resynchronize.
   To restart the cluster:

   1. On the Integrated Solutions Console left navigation pane, select Servers > Clusters > Websphere Application server clusters.
   2. Select the check box of the cluster.
   3. Click Stop.
   4. Select the check box of the cluster.
   5. Click Start.
   To start the IMS Server:

   1. On the Integrated Solutions Console left navigation pane, click Applications > Application Types > WebSphere enterprise applications.
   2. Select the TAM E-SSO IMS check box from the list of applications.
   3. Click Start.

Note: Complete steps 4-7 for all IBM HTTP Servers configured to front the WebSphere Application Servers.

4. Delete the current IBM HTTP Server SSL certificate.
   1. On the Integrated Solutions Console left navigation pane, select Servers > Server Types > Web servers.
   2. Click the Web server name whose SSL certificate is to be replaced.
   3. Under Additional Properties, click Plug-in properties.
   4. Under Plug-in properties, click Manage keys and certificates.
   5. Under Additional Properties, click Personal certificates.
   6. Select the check box of the default certificate.
   7. Click Delete.
   8. Changes have been made to the local configuration. Click Save.
5. Import the new IBM HTTP Server SSL certificate.
   1. Still on the same page, click Import.
   2. Select Key store file.
   3. In the Key file name field, enter the path to the keystore file that contains the new SSL certificate. For example, C:\keystore.p12.
   4. From the Type list, select the keystore type.
   5. In the Key file password field, enter the keystore password.
   6. Click Get Key File Aliases.
   7. Select the certificate alias to be imported from the list. For example, sslcert.
   8. In the Imported certificate alias field, enter default.
   9. Click OK.
   10. Changes have been made to the local configuration. Click Save.
6. Synchronize the change to IBM HTTP Server.
   1. On the Integrated Solutions Console left navigation pane, select Servers > Server Types > Web servers.
   2. Click the Web server name.
   3. Under Additional Properties, click Plug-in properties.
   4. Under Plug-in properties, click Copy to Web server key store directory.
7. Restart the IBM HTTP Server. 

How to speed up development and testing of ACIs

The product maintains an ACI cache for performance reasons. By default, the ACI cache is automatically refreshed every 10 minutes. The interval is controlled by the following property in enRole.properties:
###########################################################
## AccessControlList refreshInterval - minutes to wait
## before cached ACIs are checked for changes and reloaded.
###########################################################
enrole.accesscontrollist.refreshInterval=10

The result of this default setting in a development environment is that any time a change is made to an ACI as part of a development effort, it will take up to 10 minutes for the change to be effected. Often when multiple iterative changes are being made it's not at all clear what changes did or did not go into effect thus slowing down the development effort.

To eliminate this bottleneck, setting enrole.accesscontrollist.refreshInterval to 0 will mean that ACI changes will be effected immediately. A restart of the application is required after making this change.

Warning: Do not do this in a production environment as the performance benefit of having the ACI caching mechanism will be lost.

Modifying labels in ITIM UI

For Account/Service field labels modify the $ITIM_HOME/data/CustomLabels.properties file. Find the attribute whose label that needs to be modify/create.

Example: To change the label for the erUid attribute, from 'User Id' to 'Account ID', change the following line from:


erUid=User Id

To:

erUid=Account ID

For General UI labels modify the $ITIM_HOME/data/Labels.properties file. 

Example: To change the wording "Create Password" (on the Password Management screen), to "Have ITIM Create a Random Password" modify the line:


generatePassword=Create Password

To:

generatePassword=Have ITIM Create a Random Password

Check for existing ID's via the ITIM Identity Policies and increasing Max Search results from 1000 objects.

In the Default Identity Policy, the line following checks for ID's in All services and in the Recycle Bin:

IdentityPolicy.userIDExists(baseidentity, true, true);

The first boolean expression is for CheckAllServices, the second is for CheckRecycleBin.

Setting either of these values to false will disable ID checking in that area. When CheckAllServices is set to true, it will only create a new ID for that user on a service if no other user has that ID on any service.

To increase the Max Search Results, modify the "enrole.ui.maxSearchResults" line in the $ITIM_HOME/data/ui.properties file (shown below)

enrole.ui.maxSearchResults=1000

Unable to access IMS Configuration Utility after IMS server machine IP address is changed

Steps to resolve this issue.

1. Go to network connection in the PC, and change the network setting of 
IP Environment: TAM ESSO IMS> 
Solution: 
If the IP address has changed, you will need to modify a tomcat 
configuration file as follow: 
1. Go to [IMS Server installation folder]\conf 
2. Open server.xml 
3. Search for "WebConfigurator-Service" - this should be the "name" 
attribute value of the element node "Service" 
4. Within the "Service" node, edit the second IP address in the 
attribute node "allow" of the element node "Value" 
5. Save the xml file 
6. Restart the IMS Server

Hooked Reports/Custom Reports in IBM Security Identity Manager

One of the most important and popular concept of every Identity Management product is the Reporting.

And Yes IBM identity manager also provides concept of reporting.

The report system in ISIM provides a set of default reports that show historical activity in Tivoli

Identity Manager, current entities, and data elements present in the Tivoli Identity Manager

LDAP directory. You can also create custom reports using the report tools.

One of the most interesting concepts in ISIM is the creation of Custom Reports also called as Hooked reports in most of the Countries.

You can refer to this example to create more customized Hooked Report.

Steps to create a Hooked report.

1. Develop a servlet or a JSP page to take the User Input from User as Report criterion.

2. If a servlet is developed, then place the servlet mapping entries in the web.xml file of enRole application present in

   <WAS_HOME>\profiles\<profile-name>\config\cells\<node-name>\applications\ITIM.ear\deployments\ITIM\itim_console.war\WEB-INF

   and

   <WAS_HOME>\profiles\<profile-name>\installedApps\<node-name>\ITIM.ear\itim_console.war\WEB-INF directory.

3. Write java code in the servlet itself or in any new java file to query the database depending upon the user input

4. Also write code to display the results to the user in the form of CSV or PDF form.

5. Add the report entry into the report.xml present under <ITIM-HOME>\data

6. If custom java or servlet is developed, then put the class files (or archived jar files) in the class path

   One can edit the MANIFEST file present under <WAS_HOME>\profiles\<profile-name>\installedApps\<node-name>\ITIM.ear\itim_console.war\META-INF\    directory by adding the name of the custom jar file to place the custom jar file in the Application Server classpath.

7. Restart the Application Server.

8. The report name "Hooked Report" mentioned in the report.xml file above will appear in the Run Report Tab of Report component of ITIM GUI under section "Custom Reports".

9. Run the report as any other ITIM report.

Please note****: ITIM Administrator can define ACI on the Hooked Report. However, other ACI enforcement in the ITIM will not be applicable for the data displayed on the Hooked Report. Therefore please be cautious when defining ACI to run the Hooked Report to the non-admin users as the user can see any data that will be displayed on the Hooked Report.

To work with the example Hooked Report:

1. Copy the HookedReport.jsp into <WAS_HOME>\profiles\<profile-name>\installedApps\<node-name>\ITIM.ear\itim_console.war\report(Create new folder report)

2. Edit the HookedReport.jsp and replace the values of the variables (jdbcdriver, jdbcurl, dbuser and dbpassword) with correct values

3. Copy the HookedReport.jar into <WAS_HOME>\profiles\<profile-name>\installedApps\<node-name>\ITIM.ear

4. Add the entry, HookedReport.jar into  <WAS_HOME>\profiles\<profile-name>\installedApps\<node-name>\ITIM.ear\itim_console.war\META-INF\MANIFEST.INF file

5. Place the servlet url mapping in the web.xml present under folder

<WAS_HOME>\profiles\<profile-name>\config\cells\<node-name>\applications\ITIM.ear\deployments\ITIM\itim_console.war\WEB-INF

and

<WAS_HOME>\profiles\<profile-name>\installedApps\<node-name>\ITIM.ear\itim_console.war\WEB-INF

            <servlet>

                        <servlet-name>HookedReportGeneratorServlet</servlet-name>

                        <description>HookedReportGeneratorServlet</description>

                        <servlet-class>com.ibm.itim.hookedreport.HookedReportGeneratorServlet</servlet-class>

            </servlet>

            <servlet-mapping >

                        <servlet-name>HookedReportGeneratorServlet</servlet-name>

                        <url-pattern>HookedReport_Generator_Servlet</url-pattern>

            </servlet-mapping>

6. Edit the report.xml present under <ITIM-HOME>\data and add entry the following entry:

            <report name="Hooked Report" action="popup">

                        <url>./HookedReport.jsp</url>

            </report>

7. Copy the HookedReport.jar file in ITIM Lib folder

8. Add the entry(${ITIM_HOME}/lib/HookedReport.jar) in the shared library(ITIM-LIB) in Websphere console

9. Re-start the Application Server and go to Report->Run Report. Make sure that "Hooked Report" is present under "Custom Report" section.

Note: For Cluster setup, repeat steps 1 to 6 mentioned above for each node in the cluster, then restart the cluster.

                                                                                                By Nandavaram Pavan Kumar

Forgot the password and cannot access WebSphere Application Server administrative console.

There are 2 possible methods for disabling security:

By way of wsadmin command:

1. <WAS_INSTALL_DIR>/bin/> wsadmin -conntype NONE
2. wsadmin> securityoff
3. wsadmin> exit
4. Restart the servers.
5. Enable the security from administrative console.
6. Restart the servers.

By way of manual edit of security.xml file, which is typically located in <WAS_POFILE_HOME>/config/cells<CELL_NAME> /:

1. Create a copy for security.xml file, in case you need to roll back.
2. Disable the security from the security.xml file (change the very first occurrence of... enabled="true" to enabled="false")
3. Restart the servers.
4. Enable the security from administrative console.
5. Restart the servers.

If your websphere is installed in cluster environment then you will need to change the security.xml file present in 

DMGR  ----  <WAS_HOME>/Dmgr/config/cells<CELL_NAME> /:

and all Application servers ---- <WAS_HOME>/Appsrv01/config/cells<CELL_NAME> /:

WARNING: Please use this as the last resort and make sure the server is not in the middle of processing any transactions.

Linux red hat 6.4 Pre-requisities for installing any ibm product (IBM Db2, TDS, ISIM, ISAM-eb, ISAMESSO, TFIM, TSPM, Websphere)

For Linux red hat 6.4, ensure as a first task install the below 32 and 64 bit packages. This is irrespective of the product you are installing.

 

64 bit:

yum install compat-libstdc++-33-3.2.3-69.el6.x86_64

yum install compat-db-4.6.21-15.el6.x86_64

yum install libXp-1.0.0-15.1.el6.x86_64

yum install libXmu-1.1.1-2.el6.x86_64

yum install libXtst-1.2.1-2.el6.x86_64

yum install pam-1.1.1-13.el6.x86_64

yum install libXft-2.3.1-2.el6.x86_64

yum install gtk2-2.18.9-12.el6.x86_64

yum install gtk2-engines-2.18.4-5.el6.x86_64

 

32 bit:

yum install compat-libstdc++-33-3.2.3-69.el6.i686

yum install compat-db-4.6.21-15.el6.i686

yum install libXp-1.0.0-15.1.el6.i686

yum install libXmu-1.1.1-2.el6.i686

yum install libXtst-1.2.1-2.el6.i686

yum install pam-1.1.1-13.el6.i686

yum install libXft-2.3.1-2.el6.i686

yum install gtk2-2.18.9-12.el6.i686

yum install gtk2-engines-2.18.4-5.el6.i686

ADT Issue - Save Failed org/apache/xml/serialize/OutputFormat

This issue is one of the most common Issue faced after installing ADT (Adapter Development Tool).

Why the issue is caused:
Mismatch in the Version of IBM Java.
ADT uses 32x IBM Java where as the TDI installed is of 64x which uses 64x bit IBM Java.

Steps to Fix:
The best way is to copy the JRE folder from the TDI to the ADT install folder. That way the ADT works even if your ADT dev machine's TDI is 64-bit (though this means you have to get the 32-bit java from another TDI installation).
Place the jre folder in the ADT home directory.

User cannot log into Websphere console due to SRVE0260E error

When administrative user tries to log into newly configured Network Deployment console for WebSphere Process Server, browser shows error and does not proceed to the console. Page refresh and dmgr restart do not resolve this issue.

Error Page Exception
SRVE0260E: The server cannot use the error page specified for your application to handle the Original Exception printed below.

Original Exception:
Error Message: java.lang.NullPointerException
Error Code: 500
Target Servlet:
Error Stack:
java.lang.NullPointerException
     at com.ibm.isclite.container.provider.PortletContainerContextProvider.addContainerService(PortletContainerContextProvider.java:101)

This happens because of Open files limit set to too low value

Steps to resolve this:

Raise open files OS limit on linux systems to 8192

$> ulimit -n 8192

and restart the deployment manager server afterwards.

Configuring a websphere cluster to run as a service (Windows)

 Steps to be executed:
 

1. Configure your node agent or node agents, to run as a service by using the WASService command line tool.

The following example code uses the Local System account, SYSTEM, as the default user ID. If you want to use a different account, you can specify your own user ID by using the -userid option.

C:\IBM\WebSphereND855\AppServer\bin>WASService

-add "myNode01" -servername nodeagent

-profilePath C:\IBM\WebSphereND855\AppServer\profiles\Custom01

-wasHome C:\IBM\WebsphereND855\Appserver

-logFile C:\IBM\WebSphereND855\AppServer\profiles\Custom01\

  logs\nodeagent\startNode.log

-logRoot C:\IBM\WebSphereND855\AppServer\profiles\Custom01\logs\nodeagent

-restart true -startType automatic

Adding Service: ImyNode01

        Config Root: C:\IBM\WebSphereND855\AppServer\profiles\Custom01\config

        Server Name: nodeagent

        Profile Path: C:\IBM\WebSphereND855\AppServer\profiles\Custom01

        Was Home: C:\IBM\WebsphereND855\Appserver\

        Start Args:

        Restart: 1

IBM WebSphere Application Server V8.5.5 - myNode01 service successfully added.

2. Configure your cluster members to restart automatically:

1. Log in to the WebSphere administrative console.
2. Click Servers > Application Servers > server_name.
3. Expand Java and Process Management and select Monitoring Policy.
4. Change the node restart state to RUNNING.
5. Click OK and Save.

Repeat this step for each server in the cluster.

3. Shut down your node agents by using the stopNode command:

4. Shut down your cluster by using the WebSphere administrative console.
5. Start your node agents by using the Windows Services Console. Your cluster will automatically restart.

Note: Your node agents and cluster members must now run in the context of the Local System account instead of your own user account, unless you specified a different account when you ran the WASService command in step 1

You can now safely log out of your Windows user account and your cluster will continue to run.

How to customize the login page of WebSEAL to render the images properly

Customizing the login.html pages :
1. Open webseal configuration file and search for stanza [content-mime-types] add line as shown below
css = text/css
2. Go to webseal docs directory (Eg :/opt/pdweb/www-webseald/docs/) and place all the css, image files or folders.
3. Change the permission of the folder to 750 (Eg: chmod 750 icons)
4. Change the permission of the images and css file to 440 (Eg: chmod -R 440 * or chmod 440 * r chmod 440 icon-phone-red.png)
5. Change the owner name of all the folders of images and css to ivmgr (Eg: chown ivmgr:ivmgr * )
6. Customize the page as required
7. login to pdadmin
8. Attach unauth ACL to the folders or images (Eg : acl attach /WebSEAL/myssoenv-webseald/_CSS unauth)
Note : Steps 3, 4, and 5 required only if WebSEAL is installed on linux or AIX servers.

By
Nandavaram Pavan Kumar

How to Configure extended attributes in WebSEAL

Steps to Configure extended attributes

1 Login to WebSEAL server.
2 Open the WebSEAL instance configuration file.
Location: /web/pdweb/etc/webseald-<instance-name>.conf
3 In the [aznapi-entitlement-services] stanza, add the property
ISAM_CRED_ATTRS_IDS = azn_ent_cred_attrs
4 In the [aznapi-configuration] stanza, add the property
cred-attribute-entitlement-services= ISAM_CRED_ATTRS_IDS
5 At the end of the file, add the following lines of properties

[ISAM_CRED_ATTRS_IDS]
user = azn_cred_registry_id
[ISAM_CRED_ATTRS_IDS:user]
tagvalue_credattrs_givenname = givenname
tagvalue_credattrs_sn = sn
tagvalue_credattrs_uid = uid


Run the below commands to set the extended attributes at the junction level

pdadmin sec_master> object list /WebSEAL
pdadmin sec_master> object modify /WebSEAL/myssoenv-mywebinst1/MyJct set attribute HTTP-Tag-Value credattrs_uid=SM_USER
or
pdadmin sec_master> object modify /WebSEAL/myssoenv-mywebinst1/MyJct set attribute HTTP-Tag-Value credattrs_uid=uid
pdadmin sec_master> object modify /WebSEAL/myssoenv-mywebinst1/MyJct set attribute HTTP-Tag-Value credattrs_sn=sn
pdadmin sec_master> object show /WebSEAL/myssoenv-mywebinst1/MyJct                                                

Where MyJct is my Junction name

By

Nandavaram Pavan Kumar

How to call ISIM API from ITDI

How to call ISIM API from ITDI

To call the ISIM APIs from within an ITDI Assembly Line, the following jar files must be placed in the ITDI classpath (e.g. $ITDI_HOME/jars/3rdparty/IBM/isim):

• <ISIM_HOME>/lib/api_ejb.jar
• <ISIM_HOME>/lib/itim_api.jar
• <ISIM_HOME>/lib/itim_common.jar
• <ISIM_HOME>/lib/itim_server.jar
• <ISIM_HOME>/lib/itim_server_api.jar
• <ISIM_HOME>/lib/jlog.jar
• <ISIM_HOME>/lib/com.ibm.cv.kmip.ext.jar
• <WAS_HOME>/plugins/com.ibm.ws.ejbportable.jar
• <WAS_HOME>/plugins/com.ibm.ws.emf.jar
• <WAS_HOME>/plugins/com.ibm.ws.runtime.jar
• <WAS_HOME>/runtimes/com.ibm.ws.admin.client_7.0.0.jar
• <WAS_HOME>/runtimes/com.ibm.ws.webservices.thinclient_7.0.0.jar
•  

The "jaas_login_was.conf" file can be found in $ISIM_HOME/extensions/6.0/examples/apps/bin, and has the contents:

WSLogin {
com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy required delegate=com.ibm.ws.security.common.auth.module.WSLoginModuleImpl;
};

The "sas.client.props" and "ssl.client.props" files can be found in $WAS_HOME/AppServer/profiles/<your_profile>/properties. If ITDI is on a separate machine from WebSphere, those files will need to be copied to the ITDI machine. "sas.client.props" should have settings of:

com.ibm.CORBA.securityEnabled=true
com.ibm.CORBA.authenticationTarget=BasicAuth
com.ibm.CORBA.authenticationRetryEnabled=true
com.ibm.CORBA.authenticationRetryCount=3
com.ibm.CORBA.validateBasicAuth=true
com.ibm.CORBA.securityServerHost=isimsvr
com.ibm.CORBA.securityServerPort=2809
com.ibm.CORBA.loginTimeout=300
com.ibm.CORBA.loginSource=prompt

# RMI/IIOP user identity
com.ibm.CORBA.loginUserid=
com.ibm.CORBA.loginPassword=

"com.ibm.CORBA.securityServerHost" should be the hostname of your WebSphere server. It must be resolvable from the ITDI machine. You can use "ping hostname" to check if the machine can be found on the network with that name. "com.ibm.CORBA.securityServerPort" should be set to the port number listed for BOOTSTRAP_ADDRESS in the WebSphere Admin console under: Servers -> Server types -> WebSphere application servers -> <your_appserver> -> Ports.

If ITDI is on a separate machine from WebSphere, you will need to edit the "ssl.client.props" file to refer to local copies of the key and truststores.

The "appServerURL" used in the example code should match this line from your enRole.properties file:
enrole.appServer.url=corbaloc:iiop:isimsvr:2809

When defining the CORBA and SSL ConfigURL settings in the example code, it is VERY important that the values be prefixed with "file:". The WebSphere client code is expecting a correctly formatted URL string, and leaving out the "file:" protocol string will cause it to fail.

If you are experiencing errors when setting this up, please enable client tracing for the WebSphere jar files used by ITDI. Edit %ITDI_HOME%\ibmdisrv.bat [Windows] or $ITDI_HOME/ibmdisrv [UNIX] to add the following JVM flags:

-Dcom.ibm.CORBA.Debug=true -Dcom.ibm.CORBA.CommTrace=true -Dcom.ibm.CORBA.Debug.Output=client.log -DtraceSettingsFile=/path/to/TraceSettings.properties

The original JVM string from ibmdisrv.bat:
"%TDI_JAVA_PROGRAM%" -classpath "%TDI_HOME_DIR%\IDILoader.jar" %ENV_VARIABLES% com.ibm.di.loader.ServerLauncher %*

The DEBUG JVM string from ibmdisrv.bat:
"%TDI_JAVA_PROGRAM%" -classpath "%TDI_HOME_DIR%\IDILoader.jar" %ENV_VARIABLES% -Dcom.ibm.CORBA.Debug=true -Dcom.ibm.CORBA.CommTrace=true -Dcom.ibm.CORBA.Debug.Output=client.log -DtraceSettingsFile=c:/IBM/Solutions/TraceSettings.properties com.ibm.di.loader.ServerLauncher %*

An example "TraceSettings.properties" file can be found in $WAS_HOME/AppServer/properties. For this case, it should have the following contents:

traceFileName=MyTraceFile.log
com.ibm.ws.security.*=all=enabled
com.ibm.websphere.security.*=all=enabled

Unless a full path is specified, "MyTraceFile.log" and "client.log" will be written to whatever directory was chosen as the $SOLUTION_DIR when starting ITDI.