Authentication and Authorization
LSF uses authentication and authorization to ensure the security of your cluster. The authentication process verifies the identity of users, hosts, and daemons, depending on the security requirements of your site. The authorization process enforces user account permissions.
Contents
Authentication options
During LSF installation, the authentication method is set to external authentication (eauth
), which offers the highest level of security. To change the authentication method used by LSF, configure the parameter LSF_AUTH
in lsf.conf
.
Authentication method
|
Description
|
Configuration
|
Behavior
|
External authentication
|
- A framework that enables you to integrate LSF with any third-party authentication product-such as Kerberos or DCE Security Services-to authenticate users, hosts, and daemons. This feature provides a secure transfer of data within the authentication data stream between LSF clients and servers. Using external authentication, you can customize LSF to meet the security requirements of your site.
|
LSF_AUTH =eauth
|
- LSF uses the default
eauth executable located in LSF_SERVERDIR . 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. For a detailed description of the external authentication feature and how to configure it, see the Platform LSF Configuration Reference .
|
Identification daemon (identd )
|
- Authentication using the
identd daemon available in the public domain.
|
LSF_AUTH =ident
|
- LSF uses the
identd daemon available in the public domain.
- LSF supports both RFC 931 and RFC 1413 protocols.
|
Privileged ports (setuid )
|
- User authentication between LSF clients and servers on UNIX hosts only. An LSF command or other executable configured as
setuid uses a reserved (privileged) port number (1-1024) to contact an LSF server. The LSF server accepts requests received on a privileged port as coming from the root user and then runs the LSF command or other executable using the real user account of the user who issued the command.
|
LSF_AUTH not defined
|
- For UNIX hosts only, LSF clients (API functions) use reserved ports 1-1024 to communicate with LSF servers.
- The number of user accounts that can connect concurrently to remote hosts is limited by the number of available privileged ports.
LSF_AUTH must be deleted or commented out and LSF commands must be installed as setuid programs owned by root .
|
note:
If you change the authentication method while LSF daemons are running, you must shut down and restart the daemons on all hosts in order to apply the changes.
When the external authentication (eauth
) feature is enabled, you can also configure LSF to authenticate daemons by defining the parameter LSF_AUTH_DAEMONS
in lsf.conf
.
All authentication methods supported by LSF depend on the security of the root
account on all hosts in the cluster.
UNIX user and host authentication
The primary LSF administrator can configure additional authentication for UNIX users and hosts by defining the parameter LSF_USE_HOSTEQUIV
in the lsf.conf
file. With LSF_USE_HOSTEQUIV
defined, mbatchd
on the master host and RES on the remote host call the ruserok
(3) function to verify that the originating host is listed in the /etc/hosts.equiv
file and that the host and user account are listed in the $HOME/.rhosts
file. Include the name of the local host in both files. This additional level of authentication works in conjunction with eauth
, privileged ports (setuid
), or identd
authentication.
caution:
Using the /etc/hosts.equiv
and $HOME/.rhosts
files grants permission to use the rlogin
and rsh
commands without requiring a password.
Strict checking protocol in an untrusted environment
To improve security in an untrusted environment, the primary LSF administrator can enable the use of a strict checking communications protocol . When you define LSF_STRICT_CHECKING
in lsf.conf
, LSF authenticates messages passed between LSF daemons and between LSF commands and daemons. This type of authentication is not
required in a secure environment, such as when your cluster is protected by a firewall.
important:
You must shut down the cluster before adding or deleting the LSF_STRICT_CHECKING
parameter.
Authentication failure
If authentication fails (the user's identity cannot be verified), LSF displays the following error message after a user issues an LSF command:
User permission denied
This error has several possible causes depending on the authentication method used.
Authentication method
|
Possible cause of failure
|
eauth
|
- External authentication failed
|
identd
|
- The identification daemon is not available on the local or submitting host
|
setuid
|
- The LSF applications are not installed
setuid
- The NFS directory is mounted with the
nosuid option
|
ruserok
|
- The client (local) host is not found in either the
/etc/hosts.equiv or the $HOME/.rhosts file on the master or remote host
|
Authorization options
Operating system authorization
By default, an LSF job or command runs on the execution host under the user account that submits the job or command, with the permissions associated with that user account. Any UNIX or Windows user account with read and execute permissions for LSF commands can use LSF to run jobs-the LSF administrator does not need to define a list of LSF users. User accounts must have the operating system permissions required to execute commands on remote hosts. When users have valid accounts on all hosts in the cluster, they can run jobs using their own account permissions on any execution host.
All external executables invoked by the LSF daemons, such as esub
, eexec
, elim
, eauth
, and pre- and post-execution commands, run under the lsfadmin
user account.
Windows passwords
Windows users must register their Windows user account passwords with LSF by running the command lspasswd
. If users change their passwords, they must use this command to update LSF. A Windows job does not run if the password is not registered in LSF. Passwords must be 31 characters or less.
For Windows password authorization in a non-shared file system environment, you must define the parameter LSF_MASTER_LIST
in lsf.conf
so that jobs run with correct permissions. If you do not define this parameter, LSF assumes that the cluster uses a shared file system environment.
LSF authorization
As an LSF administrator, you have the following authorization options:
- Enable one or more types of user account mapping
- Specify the user account used to run
eauth
and eexec
executables or pre- and post-execution commands
- Control user access to LSF resources and functionality
Enabling user account mapping
You can configure different types of user account mapping so that a job or command submitted by one user account runs on the remote host under a different user account.
Type of account mapping
|
Description
|
Between-host
|
Enables job submission and execution within a cluster that has different user accounts assigned to different hosts. Using this feature, you can map a local user account to a different user account on a remote host.
|
Cross-cluster
|
Enables cross-cluster job submission and execution for a MultiCluster environment that has different user accounts assigned to different hosts. Using this feature, you can map user accounts in a local cluster to user accounts in one or more remote clusters.
|
UNIX/Windows
|
Enables cross-platform job submission and execution in a mixed UNIX/Windows environment. Using this feature, you can map Windows user accounts, which include a domain name, to UNIX user accounts, which do not include a domain name, for user accounts with the same user name on both operating systems.
|
For a detailed description of the user account mapping features and how to configure them, see the Platform LSF Configuration Reference
.
Specifying a user account
To change the user account for ...
|
Define the parameter ...
|
In the file ...
|
eauth
|
LSF_EAUTH_USER
|
lsf.sudoers
|
eexec
|
LSF_EEXEC_USER
|
Pre- and post execution commands
|
LSB_PRE_POST_EXEC_USER
|
Controlling user access to LSF resources and functionality
If you want to ...
|
Define ...
|
In the file ...
|
Section ...
|
Specify the user accounts with cluster administrator privileges
|
ADMINISTRATORS
|
lsf.cluster. cluster_name
|
ClusterAdmins
|
Allow the root user to run jobs on a remote host
|
LSF_ROOT_REX
|
lsf.conf
|
N/A
|
Allow specific user accounts to use @ for host redirection with lstcsh
|
LSF_SHELL_AT_USERS
|
lsf.conf
|
N/A
|
Allow user accounts other than root to start LSF daemons
tip:
For information about how to configure the LSF daemon startup control feature, see the Platform LSF Configuration Reference .
|
LSF_STARTUP_USERS
LSF_STARTUP_PATH
|
lsf.sudoers
|
N/A
|
Authorization failure
Symptom
|
Probable cause
|
Solution
|
User receives an email notification that LSF has placed a job in the USUSP state.
|
The job cannot run because the Windows password for the job is not registered with LSF.
|
The user should
- Register the Windows password with LSF using the command
lspasswd .
- Use the
bresume command to resume the suspended job.
|
LSF displays one of the following error messages:
findHostbyAddr/<proc>: Host <host>/<port> is unknown by <myhostname>
function: Gethostbyaddr_(<host>/<port>) failed: error
main: Request from unknown host <host>/<port>: error
function: Received request from non-LSF host <host>/<port>
|
The LSF daemon does not recognize host as part of the cluster. These messages can occur if you add host to the configuration files without reconfiguring all LSF daemons.
|
Run the following commands after adding a host to the cluster:
u lsadmin reconfig
u badmin mbdrestart
If the problem still occurs, the host might have multiple addresses. Match all of the host addresses to the host name by either:
- Modifying the system hosts file (
/etc/hosts ). The changes affect all software programs on your system.
- Creating an LSF hosts file (
EGO_CONFDIR/hosts ). Only LSF resolves the addresses to the specified host.
|
doacceptconn: getpwnam(<username>@<host>/<port>) failed: error
doacceptconn: User <username> has uid <uid1> on client host <host>/<port>, uid <uid2> on RES host; assume bad user
authRequest: username/uid <userName>/<uid>@<host>/<port> does not exist
authRequest: Submitter's name <clname>@<clhost> is different from name <lname> on this host
|
RES assumes that a user has the same UNIX user name and user ID on all LSF hosts. These messages occur if this assumption is violated.
|
If the user is allowed to use LSF for interactive remote execution, make sure the user's account has the same user ID and user name on all LSF hosts.
|
doacceptconn: root remote execution permission denied
authRequest: root job submission rejected
|
The root user tried to execute or submit a job but LSF_ROOT_REX is not defined in lsf.conf .
|
To allow the root user to run jobs on a remote host, define LSF_ROOT_REX in lsf.conf .
|
resControl: operation permission denied, uid = <uid>
|
The user with user ID uid is not allowed to make RES control requests. By default, only the LSF administrator can make RES control requests.
|
To allow the root user to make RES control requests, define LSF_ROOT_REX in lsf.conf .
|
do_restartReq: Failed to get hData of host <host_name>/<host_addr>
|
mbatchd received a request from sbatchd on host host_name , but that host is not known to mbatchd . Either
- The configuration file has been changed but
mbatchd has not been reconfigured.
host_name is a client host but sbatchd is running on that host.
|
To reconfigure mbatchd , run the command
badmin reconfig
To shut down sbatchd on host_name , run the command
badmin hshutdown host_name
|