Kerberos Support in FBSNG v1.2
There are two major features of FBSNG functionality where Kerberos is used. First feature is FBSNG client authentication. Second – is creating of initial Kerberos credentials for batch processes. These two features can be configured independently, depending on installation-specific security requirements. This document gives describes both features and outlines procedures for their configuration. For more details on FBSNG configuration and maintenance refer to FBSNG Administration and Installation Guide.
FBSNG client authentication is the procedure used by FBSNG components to authenticate FBSNG user or administrator. Client authentication is performed only when the client attempts to submit or change status of a batch job or modify FBSNG configuration. Client authentication is not required to perform such operations as obtaining run-time, historical or configuration information. FBSNG uses UNIX username of the client to determine client permissions.
Depending on the configuration, FBSNG can request the client to present Kerberos credentials to verify that UNIX username of the client matches the name of the client as a Kerberos principal. It is required that user’s principal is in one of two forms:
<username>@<realm>
<username>/…@<realm>
Whether Kerberos is used for client authentication is determined by parameter named “client_auth_required” in “kerberos” set of FBSNG configuration file fbs.cfg.
Normally, FBSNG requires that the UNIX username of the client matches the username part of the Kerberos principal. However, sometimes it is desirable to allow certain Kerberos principals to use UNIX accounts with different user names. For example, often is necessary to allow a group of users to use single “group” account. In such cases it is not always practical to have a Kerberos principal for such group account. FBSNG allows the administrator to define a list of users allowed to submit and run batch jobs under group UNIX account, using their own personal Kerberos principals for the authentication. It is important to note that the batch processes always have identity and credentials corresponding to the username used to submit the job, not necessarily those of the personal principal of the user who submitted the job.
For example, FBSNG configuration can allow users Alice and Bob to use their own Kerberos identity to submit and run jobs under UNIX account “production”. In this case, Bob may log in to a farm node as user “production”, obtain Kerberos credentials representing him as principal “bob”, then submit a job as user “production”. Later, when the job starts, it will assume the identity of “production”, and FBSNG will create “production” Kerberos credentials for the job’s processes.
Proxy lists can be used to allow FBSNG to accept Kerberos credentials from “foreign” Kerberos realms.
Proxy lists are configured in “user_profile” set of fbs.cfg file.
In Kerberos environment, it is necessary for batch processes to have Kerberos credentials to be able to use such “kerberized” services as rcp, rsh, etc. Unike interactive sessions, batch processes do not go through normal log in Kerberos authentication procedure. Instead, FBSNG component named Launcher, running under privileged account, creates batch processes simply using standard UNIX fork-setuid-exec sequence.
FBSNG can be configured to create Kerberos credentials for batch processes. In this case, before the batch process is created, FBSNG creates Kerberos credentials cache file for the process. To create the credentials, instead of using plain text user password, FBSNG uses Kerberos keytab files. Since no Kerberos principal can have plain text password and a keytab file in the same time, FBSNG cannot create credentials representing principals used by the user interactively. That is why, along with regular (personal) Kerberos principal, FBSNG user must have another, special, principal, which will be used for batch processes. In most cases, FBSNG requires that special principal has the following format:
<username>/<constant>@<realm>
Here, <constant> and <realm> must be the same for all farm users, and <username> is UNIX user name of the account the batch job was submitted and is running under. It is recommended to use this format:
<username>/<farm name>/farm@<realm>
This is responsibility of the administrator to create keytab file for each special principal to be used on the farm. Due to security considerations, keytab files must be protected in such a way that the user has no read access to them. When the batch process exits, the credentials cache file created by FBSNG is deleted.
FBSNG configuration, along with configuration setting of local Kerberos realm, determines the lifetime and the expiration time of the ticket-granting ticket (TGT) created with the credentials. This is a responsibility of the batch process to renew TGT before it expires. TGT cannot be renewed beyond its lifetime. To renew the ticket, the batch process must issue “kinit –R” command before it expires. Typical expiration time and lifetime of a TGT is around 24 and 96 hours respectively. Therefore, the batch process should issue “kinit –R” command at least once per day. Actual values of these time parameters are defined in Kerberos realm configuration on per-principal basis and by FBSNG configuration on per-node basis. Obviously, and unfortunately, limited TGT lifetime imposes a practical limit on lifetime of a batch process, but only if the process uses any kerberized services.
The administrator can configure FBSNG whether to create credentials for batch processes and how to treat failures to create such credentials on per-user basis. There are 3 options:
· “do not create” – FBSNG will not attempt to create credentials for batch processes running under the user’s account. This option can be useful in cases when batch jobs do not use any kerberized services, and therefore, do not need Kerberos credentials;
· “required” – FBSNG will attempt to create credentials for processes of this user, and failure to create the credentials (e.g. in case when the keytab file is missing or corrupted) will be treated as an error. The batch process will not start, it will be considered failed. The farm node where the failure occurs will be held until the administrator investigates and fixes the problem;
· “optional” – FBSNG will attempt to create credentials and ignore failure to do so.
“user_profile” set of fbs.cfg determines which option will be used for each user.
This is summary of the effects of Kerberos environment on FBSNG batch job.
· Kerberos credentials are independently created for each individual batch process and all its subprocesses;
· Credentials life time and expiration time are determined by FBSNG and the Kerberos realm configuration;
· FBSNG does not renew credentials. This is batch process’ responsibility;
· There is no known way to renew the batch process’ credentials beyond their life time;
· Credentials authenticate batch processes as special, not personal Kerberos principal;
· K5CCACHE environment variable points to a credentials cache file created by FBSNG. This file will be deleted when the batch process exit;
· FBSNG does not include Kerberos-related directories into batch process’ execution path defined with PATH environment variable. Definition of appropriate execution path is patch process’ responsibility;
· In case when proxy list was used for job submission, it is possible that the client that submitted the job had credentials authenticated it as a user with a name different from the UNIX username under which the batch process will run. In this case, the batch process will have credentials of the principal corresponding to the username the job runs under, not the principal used to authenticate the user at the job submission time.