Leverage Kerberos Authentication Protocol for submitting jobs with HCL Workload Automation

In Greek mythology, Kerberos is the ferocious three-headed guard dog of Hades to prevent the dead from leaving.

In computer science, it is a computer-network strong authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner. It provides a mutual authentication for client and services. Kerberos protocol messages are protected against eavesdropping and replay attacks. Kerberos builds on symmetric-key cryptography and requires a trusted third party, and optionally may use public-key cryptography during certain phases of authentication. Kerberos uses UDP port 88 by default.

HOW IT WORK?

The client authenticates itself to the Authentication Server which forwards the username to a Key Distribution  Center. This issues a Ticket-Granting Ticket, which is time stamped and encrypts it using the Ticket-Granting Server’s secret key and returns the encrypted result to the user’s workstation. This is done infrequently, typically at user logon; the Ticket-Granting Ticket expires at some point although it may be transparently renewed by the user’s session manager while they are logged in.

When the client needs to communicate with a service on another node (a “principal”, in Kerberos parlance), the client sends the Ticket-Granting Ticket to the Ticket-Granting Server, which usually shares the same host as the Key Distribution  Center. The service must have already been registered with the Ticket-Granting Server with a Service Principal Name (SPN). The client uses the SPN to request access to this service. After verifying that the Ticket-Granting Ticket is valid and that the user is permitted to access the requested service, the Ticket-Granting Server issues ticket and session keys to the client. The client then sends the ticket to the Service Server along with its service request.

INSTALLING THE INTEGRATION

• Stop the Dynamic Agent
• Copy the Kerberos library into <inst_dir>/TWS/bin folder and check file owner and permission
• Copy the Kerberos.ini file into <data_dir>/ITA/cpa/config folder and check file owner and permission
• Edit the JobManager.ini file and add, in [NativeJobLauncher] section, the AuthMethod and IsAuthMethodMandatory keywords
• Restart the Dynamic Agent

If IsAuthMethodMandatory = true then the job will fail as soon as the Kerberos authentication fails. Otherwise if IsAuthMethodMandatory = false then it will continue with other Auth Method provided by the service in use.

CONFIGURE THE INTEGRATION

If UseDefaultCache = false then an isolated cache for each job will be used. Otherwise with UseDefaultCache = true then Kerberos defined cache will be used.

If first authentication attempt fails, then Workload Automation can retry 2 times, after 10 seconds. The default is set to 0 attempts at 5 seconds of interval.

The [Kerberos.InitCredsOpts] section are internal Kerberos properties. It will override the corresponding Kerberos settings. Please refer to Kerberos documentation.

SAME USER FOR AUTHENTICATING TO KERBEROS AND RUNNING THE JOB

DIFFERENT USER FOR AUTHENTICATING TO KERBEROS AND RUNNING THE JOB

JOB EXECUTION

Submitting the 2 types of job (with same and different user), once they are in EXEC state, both ssh processes are launched with the respective user used in the job.