If you specify an LSF user domain, the default user mapping is enabled. For a multiple-domain Windows environment on a UNIX-Windows mixed cluster, you can specify an unlimited number of Windows domains as the LSF user domain.
In a mixed UNIX-Windows environment, if your Windows account in the LSF user domain has the same user name as your UNIX account, LSF’s default user mapping lets LSF schedule and track jobs from both accounts as if they belong to a single user. On the execution host, LSF automatically runs the job using whichever of the two accounts is appropriate for that host.
To submit cross-platform jobs when your accounts have different user names in different environments, you should configure user account mapping for individual users.
To run jobs, the existing domain trust relationships apply in LSF, so if the execution domain trusts the submission domain, your job can run in the execution domain under your submission account.
Accounts with the same user name in different domains are still treated as separate users by LSF.
You can use the environment variable LSF_EXECUTE_DOMAIN to specify only one of the domains listed in LSF_USER_DOMAIN. When you specify an execution domain, LSF runs the job using the specified domain user account, without trying all of the domain accounts in the order listed in LSF_USER_DOMAIN.
If your local account has the same user name and password on every Windows host, LSF’s default user mapping lets LSF schedule and track jobs from all hosts as if they belong to a single user. On the execution host, LSF automatically runs the job using the local user account.
If your accounts have different user names in different environments, you should configure user account mapping.
In the following examples, assume you are User1, and you have a valid user account in 3 Windows domains as well as a valid UNIX account. Not all the accounts can be used with LSF. Depending on the type of cluster, and the way you install the cluster, here are the different ways that LSF is configured:
No mapping. You have one UNIX account, and LSF recognizes 1 user:
No mapping. You have 3 Windows accounts. For purposes of fairshare, per-user job slot limits, displaying statistical data, and so on, LSF recognizes 3 separate users:
You must enable default user mapping for one of your Windows accounts (such as Domain A) so that you can run cross-platform jobs between UNIX and Windows. LSF recognizes 3 separate users:
You can specify multiple domains when you define LSF_USER_DOMAIN, which will allow users to submit jobs from a UNIX host in a multiple-domain Windows environment.
Unless a Windows user account belongs to the LSF user domain (LSF_USER_DOMAIN in lsf.conf), the combination of domain name and user name specifies a Windows domain user in LSF. The syntax is:
Type the domain name in capital letters. Use a period (.) instead of a domain name to specify a local account instead of a domain account.
UNIX systems interpret the single backslash as a special character, so on UNIX you have to use a double backslash to specify the domain name in the command line:
LSF recognizes UNIX and Windows authentication environments, including different Windows domains and individual Windows workgroup hosts.
In a Windows domain environment, user accounts are validated at the domain level, and your user account is valid on all hosts in your domain (and might be valid in other domains, if there is a trust relationship).
In a Windows workgroup environment, each host authenticates the user account, so your local account is only valid on one host.
You must use lspasswd or wgpasswd to register and update user names and passwords. You must run lspasswd from an LSF server host. You cannot run the command from an LSF client host. The password must be 31 characters or less.
You can run lspasswd on Windows in a non-shared file system environment. You must define the parameter LSF_MASTER_LIST in lsf.conf so that jobs will run with the correct permissions. If this parameter is not defined, LSF assumes that the cluster uses a shared file system environment.
You can also run lspasswd to check that the password is valid for the specified user, or to remove a user entry from the password database.
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.
Whenever you make any change to default user mapping, you affect users in the old LSF user domain and in the new LSF user domain. If you specify a new LSF user domain, users in both domains will have to use lspasswd to register their new names and passwords.
If users in the old and new LSF user domain have the same user name (such as olddomain\user1 and newdomain\user1), then the user1 account is already registered with LSF, and the user from the new LSF user domain has to change the password. To change the password, he must input the current password, which was set by the old user.
In Administering Platform LSF and other LSF documentation, a user name is represented by the syntax:
If your cluster includes Windows hosts, the full syntax for a user account on Windows is: