About external authentication (eauth)

The external authentication feature uses an executable file called eauth. You can write an eauth executable that authenticates users, hosts, and daemons using a site-specific authentication method such as Kerberos or DCE Security Services client authentication. You can also specify an external encryption key (recommended) and the user account under which eauth runs.
Important:

LSF uses an internal encryption key by default. To increase security, configure an external encryption key by defining the parameter LSF_EAUTH_KEY in lsf.sudoers.

During LSF installation, a default eauth executable is installed in the directory specified by the parameter LSF_SERVERDIR in lsf.conf. The default executable provides an example of how the eauth protocol works. You should write your own eauth executable to meet the security requirements of your cluster.

Figure 1. Default behavior (eauth executable provided with LSF)
The eauth executable uses corresponding processes eauth -c host_name (client) and eauth -s (server) to provide a secure data exchange between LSF daemons on client and server hosts. The variable host_name refers to the host on which eauth -s runs; that is, the host called by the command. For bsub, for example, the host_name is NULL, which means the authentication data works for any host in the cluster.
Figure 2. How eauth works

One eauth -s process can handle multiple authentication requests. If eauth -s terminates, the LSF daemon invokes another instance of eauth -s to handle new authentication requests.

The standard input stream to eauth -s is a text string with the following format:
uid gid user_name client_addr client_port user_auth_data_len eauth_client eauth_server aux_data_file aux_data_status user_auth_data
where

The variable …

Represents the …

uid

User ID of the client user

gid

Group ID of the client user

user_name

User name of the client user

client_addr

IP address of the client host

client_port

Port number from which the client request originates

user_auth_data_len

Length of the external authentication data passed from the client host

eauth_client

Daemon or user that invokes eauth -c

eauth_server

Daemon that invokes eauth -s

aux_data_file

Location of the temporary file that stores encrypted authentication data

aux_data_status

File in which eauth -s stores authentication status. When used with Kerberos authentication, eauth -s writes the source of authentication to this file if authentication fails. For example, if mbatchd to mbatchd authentication fails, eauth -s writes "mbatchd" to the file defined by aux_data_status. If user to mbatchd authentication fails, eauth -s writes "user" to the aux_data_status file.

user_auth_data

External authentication data passed from the client host


The variables required for the eauth executable depend on how you implement external authentication at your site. For eauth parsing, unused variables are marked by '''.

User credentials

When an LSF user submits a job or issues a command, the LSF daemon that receives the request verifies the identity of the user by checking the user credentials. External authentication provides the greatest security of all LSF authentication methods because the user credentials are obtained from an external source, such as a database, and then encrypted prior to transmission. For Windows hosts, external authentication is the only truly secure type of LSF authentication.

Host credentials

LSF first authenticates users and then checks host credentials. LSF accepts requests sent from all hosts configured as part of the LSF cluster, including floating clients and any hosts that are dynamically added to the cluster. LSF rejects requests sent from a non-LSF host. If your cluster requires additional host authentication, you can write an eauth executable that verifies both user and host credentials.

Daemon credentials

Daemon authentication provides a secure channel for passing credentials between hosts, mediated by the master host. The master host mediates authentication by means of the eauth executable, which ensures secure passing of credentials between submission hosts and execution hosts, even though the submission host does not know which execution host will be selected to run a job.

Daemon authentication applies to the following communications between LSF daemons:
  • mbatchd requests to sbatchd

  • sbatchd updates to mbatchd

  • PAM interactions with res

  • mbatchd to mbatchd (in a MultiCluster environment)

Kerberos authentication

Kerberos authentication is an extension of external daemon authentication, providing authentication of LSF users and daemons during client-server interactions. The eauth executable provided with the Platform integration package uses Kerberos Version 5 APIs for interactions between mbatchd and sbatchd, and between pam and res. When you use Kerberos authentication for a cluster or MultiCluster, authentication data is encrypted along the entire path from job submission through to job completion.

You can also use Kerberos authentication for delegation of rights (forwarding credentials) when a job requires a Kerberos ticket during job execution. LSF ensures that a ticket-granting ticket (TGT) can be forwarded securely to the execution host. LSF also automatically renews Kerberos credentials by means of daemon wrapper scripts.

Scope


Applicability

Details

Operating system

  • UNIX

  • Windows (except for Kerberos authentication)

Allows for

  • Authentication of LSF users, hosts, and daemons

  • Authentication of any number of LSF users

Not required for

  • Authorization of users based on account permissions

Dependencies

  • UNIX and Windows user accounts must be valid on all hosts in the cluster, or the correct type of account mapping must be enabled:
    • For a mixed UNIX/Windows cluster, UNIX/Windows user account mapping must be enabled

    • For a cluster with a non-uniform user name space, between-host account mapping must be enabled

    • For a MultiCluster environment with a non-uniform user name space, cross-cluster user account mapping must be enabled

  • User accounts must have the correct permissions to successfully run jobs.

  • The owner of lsf.sudoers on Windows must be Administrators.