Learn more about Platform products at http://www.platform.com

[ Platform Documentation ] [ Title ] [ Contents ] [ Previous ] [ Next ] [ Index ]


Authentication

Controlling access to remote execution has two requirements:

This chapter describes user, host, and daemon authentication in LSF.

Contents

[ Top ]

About User Authentication

LSF recognizes UNIX and Windows authentication environments, including different Windows domains and individual Windows workgroup hosts.

User authentication options

To enable LSF users to execute commands remotely, you must specify the authentication method LSF uses to authorize remote execution across the network.

You have the following choices:

If you change the authentication type while the LSF daemons are running, you must shut down and restart the LSF daemons on each LSF server host, so that the daemons will use the new authentication method.

External authentication (eauth)

External authentication uses the LSF eauth executable installed in LSF_SERVERDIR. Optionally, you may choose to write your own eauth executable that uses some site-specific authentication method such as Kerberos or DCE client authentication using the GSSAPI.

Examples of these can be found in the LSF_MISC/examples/krb and LSF_MISC/examples/dce directories. Installation instructions are found in the README file in these directories.

By default, eauth uses an internal key to encrypt authentication data. To use an external key to improve security, configure the parameter LSF_EAUTH_KEY in the lsf.sudoers file. The default eauth program is installed without setuid permission. If you use LSF_EAUTH_KEY, eauth must be setuid.

The eauth mechanism can pass data (such as authentication credentials) from users to execution hosts. The environment variable LSF_EAUTH_AUX_DATA specifies the full path to a file where data, such as a credential, is stored. The mechanisms of eauth -c and eauth -s allow the LSF daemons to pass this data using a secure exchange.

LSF_EAUTH in lsf.conf

Installation with lsfinstall sets LSF_AUTH=eauth in lsf.conf automatically. To use another authentication mechanism, you must change the value of LSF_AUTH and restart all LSF daemons.

eauth -c host_name

When a command is invoked, the client program automatically executes eauth -c host_name to get the external authentication data, where host_name is the name of the host running the LSF daemon (for example, RES) on which the operation will take place. The external user authentication data is passed to LSF through the standard output of the eauth program.

eauth -s

When the LSF daemon receives the request, it executes eauth -s under the primary LSF administrator user ID to process the user authentication data.

If your site cannot run authentication under the primary LSF administrator user ID, configure the parameter LSF_EAUTH_USER in the /etc/lsf.sudoers file.

The LSF daemon expects eauth -s to write to standard output:

The same eauth -s process can service multiple authentication requests; if the process terminates, the LSF daemon will re-invoke eauth -s on the next authentication request.

See the Platform LSF Reference for information about configuring the lsf.sudoers file.

Standard input stream for the eauth program

User authentication data is passed to eauth -s via its standard input. The standard input stream to eauth has the following format:

uid gid user_name client_addr client_port user_auth_data_len user_auth_data

where:

Privileged ports authentication (setuid)

This is the mechanism most UNIX remote utilities use. The LSF commands must be installed as setuid programs and owned by root.

If a load-sharing program is owned by root and has the setuid bit set, the LSF API functions use a privileged port to communicate with LSF servers, and the servers accept the user ID supplied by the caller. This is the same user authentication mechanism as used by the UNIX rlogin and rsh commands.

When a setuid application calls the LSLIB initialization routine, a number of privileged ports are allocated for remote connections to LSF servers. The effective user ID then reverts to the real user ID. Therefore, the number of remote connections is limited.

An LSF utility reuses the connection to RES for all remote task executions on that host, so the number of privileged ports is only a limitation on the number of remote hosts that can be used by a single application, not on the number of remote tasks. Programs using LSLIB can specify the number of privileged ports to be created at initialization time.

LSF_EAUTH in lsf.conf

If you do not define LSF_AUTH in lsf.conf, privileged ports (setuid) authentication is the default user authentication used by LSF. Installation with lsfinstall sets LSF_AUTH=eauth automatically. To use setuid authentication, you must remove LSF_AUTH from lsf.conf.

Identification daemon (identd)

LSF also supports authentication using the RFC 931 or RFC 1413 identification protocols. Under these protocols, user commands do not need to be installed as setuid programs owned by root. You must install the identd daemon available in the public domain.

The RFC 1413 and RFC 931 protocols use an identification daemon running on each client host. RFC 1413 is a more recent standard than RFC 931. LSF is compatible with both. Using an identification daemon incurs more overhead, but removes the need for LSF applications to allocate privileged ports.

You should use identification daemons if your site cannot install programs owned by root with the setuid bit set, or if you have software developers creating new load-sharing applications in C using LSLIB.

An implementation of RFC 931 or RFC 1413 such as pidentd or authd can be obtained from the public domain. If you have Internet FTP access, a good source for identification daemons is host ftp.lysator.liu.se, directory pub/ident/servers.

LSF_EAUTH in lsf.conf

Installation with lsfinstall sets LSF_AUTH=eauth in lsf.conf automatically. To use identd authentication, you must set LSF_AUTH=ident in lsf.conf.

How LSF determines the user authentication method

LSF uses the LSF_AUTH parameter in the lsf.conf file to determine which type of authentication to use:

If LSF_AUTH is ... LSF uses ...
eauth
External authentication (eauth)
Not defined
Privileged ports (setuid)
ident
Identification daemon (identd)

LSF_AUTH=eauth

LSF_AUTH=eauth is set automatically during installation with lsfinstall. LSF runs the external executable eauth in the LSF_SERVERDIR directory to perform the authentication.

If a load-sharing application is not setuid to root, library functions use a non- privileged port. If the LSF_AUTH parameter is not set in lsf.conf, the connection is rejected.

LSF_AUTH=ident or undefined

If LSF_AUTH is defined to be ident, RES on the remote host, or mbatchd in the case of a bsub command, contacts the identification daemon on the local host to verify the user ID. The identification daemon looks directly into the kernel to make sure the network port number being used is attached to a program being run by the specified user.

LSF allows both the setuid and identification daemon methods to be in effect simultaneously. If the effective user ID of a load-sharing application is root, then a privileged port number is used in contacting RES. RES always accepts requests from a privileged port on a known host even if LSF_AUTH is defined to be ident. If the effective user ID of the application is not root, and the LSF_AUTH parameter is defined to be ident, then a normal port number is used and RES tries to contact the identification daemon to verify the user's identity.

setuid permission on LSF administration commands

The LSF administration commands (lsadmin and badmin, etc.) are installed setuid by default. All other LSF commands except the administration commands can be run without setuid permission if an identification daemon is used.

If your file server does not permit setuid permission, you should install LSF_BINDIR on a file system that does allow setuid.

Security of LSF authentication

All authentication methods supported by LSF depend on the security of the root account on all hosts in the cluster. If a user can get access to the root account, they can subvert any of the authentication methods. There are no known security holes that allow a non-root user to execute programs with another user's permission.

Some system adminstrators have particular concerns about security schemes involving RFC 1413 identification daemons. When a request is coming from an unknown host, there is no way to know whether the identification daemon on that host is correctly identifying the originating user.

LSF only accepts job execution requests that originate from hosts within the LSF cluster, so the identification daemon can be trusted.

The system environment variable LSF_ENVDIR is used by LSF to obtain the location of lsf.conf, which points to the LSF configuration files. Any user who can modify system environment variables can modify LSF_ENVDIR to point to their own configuration and start up programs under the lsfadmin account.

All external binaries invoked by the LSF daemons (such as esub, eexec, elim, eauth, and queue level pre- and post-execution commands) are run under the lsfadmin account.

UNIX

By default, external authentication is installed on UNIX. If you use the identification protocol (identd) for authentication, LSF uses a port in the UNIX privileged port range, so it is not possible for an ordinary user to start a hacked identification daemon on an LSF host.

On UNIX, this means that authentication is done using privileged ports and binaries that need to be authenticated (for example, bsub) are installed setuid to root.

Windows

By default, external authentication is installed on Windows. You may disable external authentication by disabling the LSF_AUTH parameter in the lsf.conf file.

On Windows, privileged ports authentication does not provide any security because Windows does not have the concept of setuid binaries and does not restrict which binaries can use privileged ports. A security risk exists in that a user can discover the format of LSF protocol messages and write a program that tries to communicate with an LSF server. The LSF default external authentication should be used where this security risk is a concern.

Only the parameters LSF_STARTUP_USERS and LSF_STARTUP_PATH are used on Windows. You should ensure that only authorized users modify the files under the %SYSTEMROOT% directory.

Once the LSF services on Windows are started, they will only accept requests from LSF cluster administrators. To allow other users to interact with the LSF services, you must set up the lsf.sudoers file under the directory specified by the %SYSTEMROOT% environment variable.

See the Platform LSF Reference for the format of the lsf.sudoers file.

Correcting user authentication errors

If LSF cannot verify the user's identity, the error message User permission denied is displayed by LSF commands.

This error has several possible causes:

Password problem notification on Windows

A Windows job may not be able to run because of a problem with the user's LSF password (entered and updated using lspasswd). If LSF does not recognize the password, the problem could be:

If a job is in PEND state and LSF cannot run it because of a password problem, by default, LSF puts the job into USUSP and then notifies the user via email. The user can fix the problem, and then use bresume to release the job from USUSP.

[ Top ]

About Host Authentication

When a batch job or a remote execution request is received, LSF first determines the user's identity. Once the user's identity is known, LSF decides whether it can trust the host from which the request comes from.

Trust LSF host

LSF normally allows remote execution by all users except root, from all hosts in the LSF cluster; LSF trusts all hosts that are configured into your cluster. The reason behind this is that by configuring an LSF cluster you are turning a network of machines into a single computer. Users must have valid accounts on all hosts. This allows any user to run a job with their own permission on any host in the cluster. Remote execution requests and batch job submissions are rejected if they come from a host not in the LSF cluster.

A site can configure an external executable to perform additional user or host authorization. By defining LSF_AUTH to be eauth in lsf.conf, the LSF daemon will invoke eauth -s when it receives a request that needs authentication and authorization. For example, eauth can check if the client user is on a list of authorized users or if a host has the necessary privilege to be trusted.

/etc/hosts.equiv (UNIX)

If the LSF_USE_HOSTEQUIV parameter is set in the lsf.conf file, LSF uses the same remote execution access control mechanism as the rsh command. When a job is run on a remote host, the user name and originating host are checked using the ruserok(3) function on the remote host.

The ruserok(3) function checks in the /etc/hosts.equiv file and the user's $HOME/.rhosts file to decide if the user has permission to execute jobs.

The name of the local host should be included in this list. RES calls ruserok() for connections from the local host. mbatchd calls ruserok() on the master host, so every LSF user must have a valid account and remote execution permission on the master host.

The disadvantage of using the /etc/hosts.equiv and $HOME/.rhosts files is that these files also grant permission to use the rlogin and rsh commands without giving a password. Such access is restricted by security policies at some sites.

For more information

See the hosts.equiv(5) and ruserok(3) man pages for details on the format of the files and the access checks performed.

[ Top ]

About Daemon Authentication

Daemon authentication

By default, LSF calls the eauth program only for user authentication (authenticate LSF user requests to either RES or mbatchd).

LSF can also authenticate the following communications between daemons, using the same eauth program:

The eauth can use these environment variables to provide context:

Configuring daemon authentication

Set LSF_AUTH_DAEMONS in lsf.conf. For example, 

LSF_AUTH_DAEMONS=1

[ Top ]

LSF in Multiple Authentication Environments

In some environments, such as a UNIX system or a Windows domain, you can have one user account that works on all hosts. However, when you build an LSF cluster in a heterogeneous environment, you can have a different user account on each system, and each system does its own password authentication.

This means that LSF cannot always use the submission account to run a job, because the job will fail if the execution host cannot validate the password of the account you used on the submission host.

In an environment of multiple authentication systems, user mapping determines which account LSF uses when it runs your job. User mapping can be defined all of the following ways:

[ Top ]

User Account Mapping

LSF allows user account mapping across a non-uniform user name space.

By default, LSF assumes uniform user accounts throughout the cluster. This means that jobs will be executed on any host with exactly the same user ID and user login name.

The LSF administrator can disable user account mapping.

For information about account mapping between clusters in a MultiCluster environment, see the Using Platform LSF MultiCluster.

Configuring user-level account mapping (.lsfhosts)

  1. Set up a hidden .lsfhosts file in your home directory that tells what accounts to use when you send jobs to remote hosts and which remote users are allowed to run jobs under your local account. This is similar to the .rhosts file used by rcp, rlogin and rsh.
  2. Specify each line in the form: 
    host_name user_name [send|recv]

    where send indicates that if you send a job to host host_name, then the account user_name should be used, and recv indicates that your local account is enabled to run jobs from user user_name on host host_name. If neither send nor recv are specified, your local account can both send jobs to and receive jobs from the account user_name on host_name. Lines beginning with `#' are ignored. A plus sign (+) in the host_name or user_name field indicates any LSF host or user respectively.

  3. Set the permission on your .lsfhosts file to read/write only by the owner. Otherwise, your .lsfhosts file is silently ignored

MultiCluster

The cluster name can be substituted for host_name in a MultiCluster environment. For more information, see the Using Platform LSF MultiCluster.

Example 1

For example, assume that hostB and hostA in your cluster do not share the same user name/user ID space. You have an account user1 on host hostB and an account ruser_1 on host hostA. You want to be able to submit jobs from hostB to run on hostA. Set up your .lsfhosts files as follows:

On hostB: 

% cat ~user1/.lsfhosts
hostA ruser_1 send

On hostA: 

% cat ~ruser_1/.lsfhosts
hostB user1 recv

Example 2

As another example, assume you have account user1 on host hostB and want to use the lsfguest account when sending jobs to be run on host hostA. The lsfguest account is intended to be used by any user submitting jobs from any LSF host. Set up your .lsfhosts files as follows:

On hostB: 

% cat ~user1/.lsfhosts
hostA lsfguest send

On hostA: 

% cat ~lsfguest/.lsfhosts
+  + recv

[ Top ]

[ Platform Documentation ] [ Title ] [ Contents ] [ Previous ] [ Next ] [ Index ]

      Date Modified: January 12, 2004
Platform Computing: www.platform.com

Platform Support: support@platform.com
Platform Information Development: doc@platform.com

Copyright © 1994-2004 Platform Computing Corporation. All rights reserved.