External authentication with IBM® Spectrum LSF (eauth)
The external authentication feature uses an executable file called eauth. You can write an eauth executable that authenticates users, hosts, and daemons that use 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.
The hostsetup --setuid command enables the setuid bit for the following LSF executable files: badmin, lsadmin, egosh, utmpreg, swtbl_api, ntbl_api, lstbl_nid, and swtbl_poe.
During LSF installation, a default eauth executable is installed in the directory that is specified by the parameter LSF_SERVERDIR (set by cshrc.lsf and profile.lsf). The default executable provides an example of how the eauth protocol works. Write your own eauth executable based on this example to meet the security requirements of your cluster.
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.
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
|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 that is passed from the client host.|
|eauth_client||Daemon or user that invokes the eauth -cc command.|
|eauth_server||Daemon that invokes the eauth -s command.|
|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 that is passed from the client host.|
The variables that are required for the eauth executable depend on how you implement external authentication at your site. For eauth parsing, unused variables are marked by empty quotation marks (").
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.
LSF first authenticates users and then checks host credentials. LSF accepts requests that are sent from all hosts that are 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 host that is not running LSF. If your cluster requires extra host authentication, you can write an eauth executable that verifies both user and host credentials.
Daemon authentication provides a secure channel for passing credentials between hosts, mediated by the management host. The management host mediates authentication by using 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 is selected to run a job.
- mbatchd requests to sbatchd
- sbatchd updates to mbatchd
- PAM interactions with res
- mbatchd to mbatchd (for the LSF multicluster capability)
|Not required for||Authorization of users based on account permissions|