Kerberized UNIX System Administration Issues

Intended for:

Kerberos users.

Scenario/Use case:

This article provides instructions on how to resolve some UNIX system administration issues related to the installation and use of Kerberos software.

Instructions:

Note: The location of the script makehostkeys in SLF 7.x has changed to /usr/sbin/makehostkeys.

Setting Defaults for Tickets/Applications

The /etc/krb5.conf file, described in The Kerberos Configuration File: krb5.conf, contains configuration information needed by the Kerberos V5 library. This includes information describing the default Kerberos realm and the locations of the KDCs. You can use it to set default flags for tickets (e.g., forwardable, renewable) and application parameters (e.g., tell application to forward "forwardable" tickets). If your machine is in a domain other than fnal.gov, you'll need to add your domain to the [domain_realm] section of the file (see section Additional UNIX Sysadmin Information for Off-Site Installations). For complete information, refer to the MIT Kerberos Documentation: krb5.conf.

The /etc/hosts File

In the /etc/hosts file, the first-listed name for the local system must be the full name, including the domain, and must not be a nickname. The line should be of the form:

<IP address> <node>.<domain> <node>

E.g.,:

<131.225.11.11> mynode.fnal.gov mynode

or, depending on your home institution, something like

<111.111.11.11> mynode.myuniv.edu mynode

Note regarding tcpwrappers: If in /etc/hosts.deny there is an entry ALL : ALL, then all tcp connections are disabled, unless explicitly enabled in /etc/hosts.allow.

Register yourself as an Administrator

If you need to allow remote logins to your machine or offer services, you need host and ftp principals for the machine. First register yourself in the database of system administrators. This is part of the System Registration form, be sure to fill out the primary system administrator information. Check your system administrator information in the System Administrator Database (SERVICES password required).

User Accounts and Passwords

User Account Names

Set up each user's account such that the account name (login id) is the same as the person's principal. Otherwise, the user is subject to the problems listed in If your Principal and Login Name do not Match.

Determine if a Particular Principal Exists

If you need to check whether a principal has been created for a user, run the kinit command with the principal name you want to test. Enter at least one character at the password prompt. The text of the error message will indicate whether the principal exists or not. If the principal exists, it will give a message indicating the password is wrong:

% kinit realuser

Password for realuser@FNAL.GOV: x
kinit: Preauthentication failed while getting initial 
credentials

If the principal doesn't exist, it will give a "Client not found..." message instead:

% kinit nosuchuser

Password for nosuchuser@FNAL.GOV: x
kinit: Client not found in Kerberos database while getting 
initial credentials

User Passwords

A Kerberized machine uses the Kerberos login program by default, and that login program accepts Kerberos passwords. Standard UNIX passwords can be used for non-Kerberos-authenticated login at the console. If a user will only access the gateway remotely, the user's account doesn't need a local UNIX password. Using !! in the password field for that account in /etc/shadow will disable local and ssh logins.

Disable NIS passwords. There should be no passwords in the yp password files. Standard UNIX passwords can be used for non-Kerberos-authenticated login at the console.

Providing Access to Sensitive Accounts

You as the system administrator can choose to require that users of the root account and/or any other sensitive accounts obtain a root instance of their principal. Use of /root principals for root access is recommended to prevent privileged access to systems should the regular principal be compromised. This is described in section Using Root Instance of your Principal.

To allow authorized users to log in directly to a sensitive account via ssh, telnet, rsh, rlogin or ftp, add the person's principal (or the person's /root principal if you use that method) to the .k5login file in the account's home directory (/root/ for Linux, / for the other supported flavors). This file is described in section Account Access by Multiple Users.

For the root account, an alternative is for the authorized user to log in to the machine under his own login id, and use ksu (instead of su) to run as root. For this, the user must have a forwardable ticket on the machine and his principal must be entered in the root account's .k5login or .k5users file.

Non-user Accounts

There are often accounts maintained for file ownership/permissions reasons, and people don't log into these accounts. Typically these accounts have names that don't correspond to user names (e.g., "products"), but it is best to prevent accidental login in case a user's principal matches this account name. To do so, create an empty .k5login file in the account's home directory (see section The .k5login File).

Searching KDC Log Files and the Principal List

The KDC log files and the list of principals are available in NFS space for users who are registered system administrators (see section Register yourself as an Administrator). If you are a registered system administrator and can't access the KDC logs as described here, please submit a Service Desk General Requst.

The NFS area /Operations/k/k5logs/ contains various KDC log files and a list of KDC principals. These files can be used by system administrators to understand error messages and to diagnose problems. All the directories referred to below reside under this directory.

The princ/, kdc/, log/ and adm/ directories contain subdirectories for the year and month. The format for the names of these directories is YYYY-MM (e.g., 2001-08). Under each YYYY-MM directory are the actual log files as listed here:

princ/

contains the weekly list of KDC principals

kdc/

contains the daily KDC transaction log files (the transaction records for each KDC are maintained in separate files)

log/

contains the daily KDC log files (not much here)

adm/

contains the daily KDC administration log files

The format for the names of the log files in these directories is i-krb-<n>.YYYY-MM-DD (e.g.,. i-krb-9.2014-03-15). The meaning of i-krb-<n> is the DNS CNAME for a KDC as shown in the KDC List.

The list of principals under the princ/ directory is only maintained for the master KDCs, i-krb-2 (PILOT) and i-krb-10 (FNAL.GOV production). The list of principals includes the attributes for each principal and the expiration dates for the principal and password. Each principal record has comma-separated fields. The format of the records is as follows:

Most principal attributes are self-explanatory such as "DISALLOW_FORWARDABLE". The attribute "DISALLOW_ALL_TIX" is used to disable a principal.

The KDC transaction log files reside under the tmp/ and kdc/ directories:

tmp/

contains the real-time KDC transaction log file, plus recent historical transaction log files (both in tmp/ and slightly older ones in tmp/old/), so look there to diagnose a problem in real-time. The current log file is named kdc.log and older files named kdc.log.<n> starting with 0 through 10.  The real-time logs include all the KDCs.

kdc/

contains the KDC transaction log files which are at least one day old. These archived logs are separated by KDC with names i-krb-<n>.<yyyy-mm-dd> and may be compressed with gzip and have .gz attached to the file name.

The format of a KDC transaction log file is variable. The diag_user.pl perl script in the tmp/ directory can be used to view the KDC transaction log file for a specific user. For example, if user johndoe is having a problem, try the command (from the directory tmp/):

% ./diag_user.pl johndoe

This command uses grep to search the current KDC transaction log file kdc.log for records with the string johndoe. The command will also output specific error records from the log file that pertain to "johndoe" transactions. The error records appear immediately before the transaction record and are missed if the standard grep command is used. Interpreting these KDC error messages is more art than science. For example, here is an error that indicates johndoe is using the wrong password (from the tmp/ directory)

% ./diag_user.pl johndoe

ERROR->No such file or directory - pa verify failure
08:30:31=>AS_REQ from fnkerb.fnal.gov(131.225.68.13) PREAUTH_FAILED 
johndoe@FNAL.GOV for krbtgt/FNAL.GOV@FNAL.GOV, Preauthentication failed

The "No such file or directory" output means wrong password. The next record containing "Preauthentication failed" is the message user johndoe receives.

There is another version of the diag_user.pl tool in the princ/ directory. If used from there, the tool defaults to looking at yesterday's log file.

Changing a Machine's Node Name

If you need to change the node name of a Kerberized machine, the host and FTP service principals and keys, if any, must also be changed. There is no "rename" function on the principal database, so the old service keys must be deleted and new ones added. Request new service principals host/<newname>.<domain> and ftp/<newname>.<domain> using the form at the ServiceNow Service Catalog: Accessing Kerberized Machines. When you get them, follow one of these procedures to change your node name.

Once you get your new service principals, follow the procedure outlined in section Installing Service Host Keys to install the new keys.

Then change the node name, and reboot as necessary. You may delete the old host and FTP keys from the keytab using the ktutil command:

% ktutil
ktutil:  rkt /etc/krb5.keytab
ktutil:  list

                slot KVNO Principal
                ---- ---- -------------------------------------------------
<                  1    2     host/oldname.domain@FNAL.GOV
<                  2    2      ftp/oldname.domain@FNAL.GOV
<                  3    2     host/newname.domain@FNAL.GOV
<                  4    2      ftp/newname.domain@FNAL.GOV

;

ktutil:  delent 2
ktutil:  delent 1

Note: Delete entry 2 before entry 1 because they all drop down a slot after delent. Continue:

ktutil:  wkt /etc/krb5.keytab.new
ktutil:  quit
% mv /etc/krb5.keytab.new /etc/krb5.keytab

Done.

Installing Service Host Keys

With new host and FTP service principals and their assigned password(s) in hand, log in as root and run the /usr/krb5/config/makehostkeys script (installed by either the krb5-fermi-config or the krb5-fermi-krb5.conf RPM package). The location of the script makehostkeys in SLF 7.x has changed to /usr/sbin/makehostkeys. Or, run the kadmin command as shown below to install the keys (use appropriate values of hostname, domain and REALM). Note that Kerberos clients append the machine's default realm to the principal names typed in the kadmin command (hostname.domain). If the default realm of the machine does not match the realm for which the principals/keys were created, then include the -r <REALM> option.

% kadmin -p host/<hostname.domain> \
  -q "ktadd host/<hostname.domain>" [-r <REALM>]

Enter password: <type in host principal's password> 

% kadmin -p ftp/<hostname.domain> \
  -q "ktadd ftp/<hostname.domain>" [-r <REALM>]

Enter password: <type in ftp principal's password>

Static IP vs. DHCP Addresses

You can get host and FTP principals for a DHCP-based machine, but your service principals will work only for your nominal node name (e.g., host/mynode.dhcp.fnal.gov and ftp/mynode.dhcp.fnal.gov). Whenever that name does not resolve to your current IP address, then the service principal is of no use, and you can't authenticate to your host (you can still authenticate yourself to other hosts). A different machine using your node name cannot impersonate your node or steal Kerberized connections intended for your machine, so there's no risk, just inconvenience. However, if you plan to offer reliable services, a static IP address is the better solution.

Multiple IP Addresses or Node Names or Load-Balanced Nodes

If your machine is configured to have two or more active (static) IP addresses, as long as there's just one node name, you do not need multiple service principals. Just make sure all the IP addresses are listed in DNS. There should be no problems using credentials which have been forwarded to such a single-named host.

If you have multiple node names (which are not nicknames), get a host service principal for each name. This will take care of telnet and the r-commands. FTP will not work properly under these circumstances, and credentials forwarded to such a host will be only partly usable.

If you have multiple nodes behind a load balancer and you want users to be able to access the systems via the load balancer name as well as the individiaul node names, then see the article Kerberized SSH and Systems Behind Load Balancers.

See Also:

• Strong Authentication at Fermilab