TWS & TDWC MS AD integration

In this post I will describe how to set-up a MS AD (Microsoft Active Directory) users integration for TWS & TDWC directly using WebSphere (for Windows machine there is another way using the OS capabilities).

Prerequisites: A MS AD (Microsoft Active Directory) account (service account preferred) that will be used to connect to MS AD and read its repository.
For both TWS and TDWC the set-up is identical (if they both run on the same WebSphere it needs to be performed only once).

To set-up the TWS / TDWC and MS AD integration:
   

   1. Login to WebSphere admin page:

• Directly: https://:31124/ibm/console/secure/securelogon.do?action=force (this si the default link)
• From TDWC:

                    

   2. Go to Security -- Global Security, and under User account repository set Current realm definition as Standalone LDAP registry (to use a single repository, e.g. MS AD only) or Federated  repositories (to use multiple repositories, e.g. MS AD, Local Server Account).

!!!!! Important: If the account name is not unique across Federated  repositories the user WILL NOT be authenticated, be very very careful with this.  

 
   3. Then go to Configure ... -- Manage repositories (Under Related Items) and click Add

   4. On LDAP server under Directory type select Microsoft Windows Active Directory and fill in the data as:

• Repository identifier -- just a display name
• Primary host name -- your Microsoft Active Directory (MS AD) domain controller server name (DNS name) or fully qualified domain name (FQDN) or  IP address
• Port -- the server port that will be used to connect to MS AD in order to get users data (default: 389)
•  Bind distinguished name -- specify the distinguished name for the application name to use when binding to the MS AD repository 

e.g. CN=user_name,OU=IT,OU=TM,OU=RO,DC=europe,DC=ad,DC=company_name,DC=com

• Bind password -- specify the password for the application server to use when binding to the MS AD repository (in short: the password for user_name on the Bind distinguished name field)

Press OK and if you opted for Standalone LDAP registry go to the last step (8).

   

   5. Go to Global Security -- Federated  repositories -- Repositories in the realm: -- Add Base entry to Realm...

   6. On Repository reference select:

• Repository -- The one you created at step 4.
• Distinguished name of a base entry that uniquely identifies this set of entries in the realm -- specify the distinguished name of a base entry that uniquely identifies this set of entries in the realm

e.g. DC=ad,DC=company_name,DC=com

Press OK

   7. Press Apply and Save directly to the master configuration.

   8. Restart the WebSphere.

Now the users authentication is performed using MS AD (only MS AD or and MS AD). Also you may use MS AD groups or DL (distributions lists) to grant rights in TWS and / or TDWC.

Multiple-masters domain enSwFaultTol set-up

The multiple-masters domain (e.g. containing back-up / DR masters and/or "FULLSTATUS ON" FTA's) biggest challenge is to make sure there is no loss on jobs details (messages) in case the primary master is out of order and we need to promote another master or "FULLSTATUS ON" FTA's to primary master.

There is a global variable called: enSwFaultTol enable or disable the fault-tolerant switch manager feature which basically does changes the flow of communication inside TWS environment:

 enSwFaultTol / sw = NO The FTA's are connected and are sending the jobs data to primary master and other masters and / or "FULLSTATUS ON" FTA's are getting in sync with primary master.

enSwFaultTol / sw = YES The FTA's are connected and are sending the jobs data to each master and / or "FULLSTATUS ON" FTA's independently.

Below is  a diagram representing only the communication channels that are impacted by the above variable.

Default is NO but my recommendation is to change it to YES, even if IBM recommends NO (I've had several meetings with IBM support on this topic but they did not convince me to use it as NO).

Why?

• enSwFaultTol / sw = NO biggest downsize is that in case of primary master being in a freeze state you will lose all the jobs messages sent to it by FTA's until the new primary master promotion. It happened to me several times and we lost up to several hours worth of data. 
• enSwFaultTol / sw = YES the above scenario won't happen as all the other masters or "FULLSTATUS ON" FTA's are receiving all the jobs messages but its small disadvantage is an increase network traffic as the data is sent to multiple servers. 

 My strong recommendation, even is it against IBM one, is to use enSwFaultTol / sw = YES on a multiple-masters domain.

Master (MDM or DM) switch (promotion)

In case of any failure on primary master (MDM or DM) TWS has the option to promote a new master in real time.

There are 2 cases that we will go thru:
          1) Temporary switch (the new master will act as a primary master until the FINAL job stream is set to run).
          2) Permanent switch (the new master will act as a primary master until a switchmgr command is performed).

1) Temporary switch
The new promoted master will act as a primary master until the FINAL job stream runs after, it will be reverted back to "old" primary master.
To make the switch / promotion run on the target (the command is instant and you will see in CPU screen at "NODE" column the new "MASTER"):

./<TWS_home>/switchmgr

!!! Applicable to any master or to any FTA which has in it's "TYPE" definition column "FULLSTATUS ON"

2) Permanent switch
The new master will act as a primary master until a switchmgr command should be performed on another master only (Back-up, DR etc). 

a) Cancel the FINAL job stream from the current plan.

./<TWS_home>/bin/conman "cancel @#final;noask"

b) Edit and update the FINAL job stream so it can run on the new primary master.

./<TWS_home>/bin/composer "mo @#final;full"

!!! NOTE change the Job Stream Workstation, Job Workstation and the script path

c) Submit to plan the new "FINAL" job stream

./<TWS_home>/bin/conman "sbs @#final;noask"

!!! NOTE If the "FINAL" job stream update was performed using CLI (as above) MAKE sure you will be deleting the "original" "FINAL" job stream. CLI is not replacing the objects is the workstation is change, instead it creates another item

d) Change in the workstation definition the "TYPE" option of the current master from "MANAGER" to fault-tolerant agent "FTA". 

./<TWS_home>/bin/composer "mo cpu <current master>" 

CPUNAME <current master> 
  DESCRIPTION "MASTER CPU"
  OS UNIX
  NODE master.tws.com TCPADDR 31234
  DOMAIN MASTERDM
  FOR MAESTRO
    TYPE MANAGER #change it to FTA
    AUTOLINK ON
    BEHINDFIREWALL OFF
    FULLSTATUS ON
END

e) Change in the workstation definition the "TYPE" option of the master or the fault-tolerant agent "FTA" which will be promoted to primary master to "MANAGER".

./<TWS_home>/bin/composer "mo cpu <future master>" 

CPUNAME <future master>
  DESCRIPTION "BACK-up MASTER CPU"
  OS UNIX
  NODE back-up-master.tws.com TCPADDR 31234
  DOMAIN MASTERDM
  FOR MAESTRO
    TYPE FTA #change it to MANAGER
    AUTOLINK ON
    BEHINDFIREWALL OFF
    FULLSTATUS ON
END

f) Copy the Security file from the <current master> to the <future master>, by doing this we want to make sure the users will have the same rights.

g) Use "switchmgr" function on <future master> to switch the <future master> as the current master.

./<TWS_home>/switchmgr

Optional a) Use "switcheventprocessor" on <future master> to switch the event rules processing server to the <future master> master (only if the event rules are being used and are active on <current master>).

./<TWS_home>/conman switcheventprocessor

Optional b) On the <future master>, edit the "globalopts" file and change the master option to the name of the <future master> workstation (this is used mainly for reports).

vi /<TWA_home>/TWS/mozart/globalopts 

# TWS globalopts file on the TWS Master defines attributes
# of the TWS network.
#
#----------------------------------------------------------------------------
company                     =TWS
master=<current master> # change it to <future master>
start                       =0000

!!! IMPORTANT: The multiple-masters domain (e.g. back-up / DR masters and/or "FULLSTATUS ON" FTA's) global settings and its behavior.