Platform LSF Administration Guide Version 6.2

About User Authentication
Administering Platform LSF
570
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:
◆ The LSF applications are not installed setuid.
◆ The NFS directory is mounted with the nosuid option.
◆ The identification daemon is not available on the local or submitting host.
◆ External authentication failed.
◆ You configured LSF to use ruserok() and the client host is not found in either
the
/etc/hosts.equiv or the $HOME/.rhosts file on the master or remote
host.
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:
◆ The user never gave their Windows user account password to LSF (lspasswd).
◆ The user changed their password in Windows but did not update LSF (lspasswd).
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.