How to Configure IBM Workload Tools and Single Sign On

Is your organization in the midst of setting up software automation to make your business run more simply and efficiently? If you’re looking at using IBM Workload Scheduler and Dynamic Workload Console, here are a few helpful deployment tips.

When deploying IBM Workload Scheduler (IWS) and the Dynamic Workload Console (DWC) on the same host, it is important to configure both WebSphere Application Server instances for Single Sign-On (SSO). SSO is an access control method that allows a user to gain access to the resources of multiple applications by authenticating only one time and sharing the same user registry. This means you can run queries on a plan or manage object definitions on the database by accessing the engine, without additional authentication, by automatically using the same credentials you used to login to the DWC. During the setup it is important that the user registry, RealmName, DNS Domain and the same LTPA key are used.

Sirius recently installed IWS and DWC on the same Linux host for a client, who also preferred installing agents as the TWSuser ID and added this user to LDAP. Our IWS/DWC server has PAM installed, and is configured to connect to support both the file for local users on linux (/etc/passwd), and LDAP at an OS level. Additionally, they also wanted LDAP to authentic at the WebSphere level. However, WebSphere cannot handle the same user in two different repositories (PAM and LDAP).

Since TWSuser was in both /etc/passwd (required during the IWS install) and in LDAP, the WebSphere Instance for IWS would not restart.

There are a couple options to prevent WebSphere from seeing a user in two repositories: