25.06.2015 Views

Administering Platform LSF - SAS

Administering Platform LSF - SAS

Administering Platform LSF - SAS

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

About User Authentication<br />

About User Authentication<br />

User authentication options<br />

<strong>LSF</strong> recognizes UNIX and Windows authentication environments, including<br />

different Windows domains and individual Windows workgroup hosts.<br />

◆ In a UNIX environment, user accounts are validated at the system level, so<br />

your user account is valid on all hosts.<br />

◆ In a Windows domain environment, user accounts are validated at the<br />

domain level, and your user account is valid on all hosts in your domain<br />

(and might be valid in other domains, if there is a trust relationship).<br />

◆ In a Windows workgroup environment, each host authenticates the user<br />

account, so your local account is only valid on one host.<br />

To enable <strong>LSF</strong> users to execute commands remotely, you must specify the<br />

authentication method <strong>LSF</strong> uses to authorize remote execution across the<br />

network.<br />

You have the following choices:<br />

◆ External authentication (eauth)<br />

◆ Privileged ports (setuid)<br />

◆ Identification daemon (identd)<br />

If you change the authentication type while the <strong>LSF</strong> daemons are running, you<br />

must shut down and restart the <strong>LSF</strong> daemons on each <strong>LSF</strong> server host, so that<br />

the daemons will use the new authentication method.<br />

External authentication (eauth)<br />

<strong>LSF</strong>_EAUTH in<br />

lsf.conf<br />

External authentication uses the <strong>LSF</strong> eauth executable installed in<br />

<strong>LSF</strong>_SERVERDIR. Optionally, you may choose to write your own eauth<br />

executable that uses some site-specific authentication method such as Kerberos<br />

or DCE client authentication using the GSSAPI.<br />

Examples of these can be found in the <strong>LSF</strong>_MISC/examples/krb and<br />

<strong>LSF</strong>_MISC/examples/dce directories. Installation instructions are found in the<br />

README file in these directories.<br />

By default, eauth uses an internal key to encrypt authentication data. To use<br />

an external key to improve security, configure the parameter <strong>LSF</strong>_EAUTH_KEY<br />

in the lsf.sudoers file. The default eauth program is installed without<br />

setuid permission. If you use <strong>LSF</strong>_EAUTH_KEY, eauth must be setuid.<br />

The eauth mechanism can pass data (such as authentication credentials) from<br />

users to execution hosts. The environment variable <strong>LSF</strong>_EAUTH_AUX_DATA<br />

specifies the full path to a file where data, such as a credential, is stored. The<br />

mechanisms of eauth -c and eauth -s allow the <strong>LSF</strong> daemons to pass this<br />

data using a secure exchange.<br />

Installation with lsfinstall sets <strong>LSF</strong>_AUTH=eauth in lsf.conf automatically. To use<br />

another authentication mechanism, you must change the value of <strong>LSF</strong>_AUTH and<br />

restart all <strong>LSF</strong> daemons.<br />

494<br />

<strong>Administering</strong> <strong>Platform</strong> <strong>LSF</strong>

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!