|Strong Authentication at Fermilab|
Chapter 17: Kerberized UNIX System Administration Issues
Chapter 17: Kerberized UNIX System Administration Issues
Chapter 17: Kerberized UNIX System Administration Issues
In this chapter we discuss some UNIX system administration issues related to the installation of Kerberos software.
17.1 Alterations Made to your System when Fermi Kerberos is Installed
When you issue one of the ups install ... commands to complete the installation of the kerberos product (e.g., see step 5 of section 14.2 Installing Fermi Kerberos using UPS/UPD), the following changes are made to your environment:
- new directory /usr/krb5 and directories/files underneath are created
- some service (port) definitions are added to /etc/services (if not already present). Note that these changes must be made known to the system: for Sun and Linux, make sure /etc/nsswitch.conf points to the correct services file.
- /etc/krb5.conf and /etc/krb5.keytab files are added
- /etc/inetd.conf is altered to enable Kerberized services and disable non-Kerberized ones, then SIGHUP is sent to inetd1. The default kerberos install preserves pre-existing usage of tcpwrappers on a service-by-service basis.
- if ups install-keep-ssh isn't chosen, /etc/sshd_config is also altered
17.2 Setting Defaults for Tickets/Applications
The /etc/krb5.conf file, described in Chapter 16: 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 location of the KDC. 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 Chapter 18: Additional UNIX Sysadmin Information for Off-Site Installations). For complete information, refer to http://www.osxfaq.com/man/5/krb5.conf.ws.
Note that as of January 2001, the current krb5.conf file available from KITS does not turn on ticket forwarding by default (for applications that check this file, e.g., telnet, rlogin, FTP, rsh). This was changed in response to users' concerns about inadvertently forwarding credentials to an untrustworthy machine. However if the sysadmin turns it on by editing krb5.conf, a later update or re-installation will leave that change alone.
17.3 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.,:<184.108.40.206> mynode.fnal.gov mynode
or, depending on your home institution, something like<220.127.116.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.
17.4 Portal Mode Configuration
A UNIX host running kerberos v1_0 or later performs the portal function by default when accessed via telnet or FTP from the untrusted realm, unless this mode is specifically disabled. Host and FTP principals must exist for the node in order to enable portal mode.
In the inetd.conf file (which resides in either /etc or /etc/inet) you should find a line for telnet similar to:telnet stream tcp nowait root /usr/krb5/sbin/telnetd telnetd -Pa valid
And for FTP:ftp stream tcp nowait root /usr/krb5/sbin/ftpd ftpd -aP
The P flag in these lines enables portal mode. To disable this mode, remove the P flag. (This still leaves unencrypted rsh and rlogin open2.)
17.5 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. Go to System Administrator Registration at http://miscomp.fnal.gov/sysadmindb/ to register.
17.6 User Accounts and Passwords
17.6.1 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 C.2 If your Principal and Login Name do not Match.
17.6.2 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 realuserPassword 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 nosuchuserPassword for nosuchuser@FNAL.GOV: x kinit: Client not found in Kerberos database while getting initial credentials
17.6.3 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 login, while leaving remote Kerberos login available.
Disable NIS passwords and AFS 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.
17.6.4 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. This is described in section 9.4 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 9.3 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.
17.7 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 9.3.1 The .k5login File).
17.8 Searching KDC Log Files and the Principal List
The KDC log files and the list of principals are available in AFS space for users who are registered system administrators (see section 17.5 Register yourself as an Administrator). If you are a registered system administrator and can't access the KDC logs as described here, please contact firstname.lastname@example.org
The AFS directory /afs/fnal.gov/files/data/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:
- contains the weekly list of KDC principals, plus the diag_user.pl which allows you to look at yesterday's log file.
- contains the daily KDC transaction log files (the transaction records for each KDC are maintained in separate files)
- contains the daily KDC log files (not much here)
- 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-3.2001-08-15). The meaning of i-krb-<n> is the DNS CNAME for a KDC as follows:
- Pilot realm (PILOT.FNAL.GOV) master KDC (alias krb-pilot-1)
- Production realm (FNAL.GOV) master KDC (alias krb-fnal-1)
- FNAL.GOV realm backup KDC (alias krb-fnal-2)
- FNAL realm backup located in D0 (alias krb-fnal-5)
- FNAL realm backup located in CDF (alias krb-fnal-4)
- FNAL realm backup located in BD (alias krb-fnal-3)
- FNAL realm backup located in Soudan (alias krb-fnal-6)
The list of principals under the princ/ directory is only maintained for the master KDCs, i-krb-2 and i-krb-3. 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:
Field number Field value Description 1 principal name full principal name including realm 2 principal expiration number of days till principal expires, "*" for no expiration, "E" for expired 3 password expiration same as for principal expiration 4 and beyond principal attributes
Most principal attributes are self explanatory such as "DISALLOW_FORWARDABLE". The attribute "DISALLOW_ALL_TIX" is used to disable a principal (except in the case of CRYPTOCard principals4).
The KDC transaction log files reside under the tmp/ and kdc/ directories:
- contains the real-time KDC transaction log file, plus recent historical transaction log files, so look there to diagnose a problem in real-time.
- contains the KDC transaction log files which are at least one day old.
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 johndoeERROR->No such file or directory - pa verify failure 08:30:31=>AS_REQ from fnkerb.fnal.gov(18.104.22.168) 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.
17.9 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 http://computing.fnal.gov/cd/forms/extra_kerb_req_form.html. When you get them, follow one of these procedures to change your node name.
17.9.1 Using UPS
If you have installed Fermi Kerberos, have UPS running and don't mind an interruption, the easiest way to change your node name is to:
- Change the node name
- Delete /etc/krb5.keytab
- Run the command: ups install-hostkeys kerberos and provide the new password(s) when prompted.
17.9.2 Using Kerberos Utilities
If you're not running UPS, you'll need to use the native Kerberos utilities. You can avoid interruptions of service during the name change if you want to prepare in advance.
Once you get your new service principals, follow the procedure outlined in section 17.10 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:% /usr/krb5/sbin/ktutil ktutil: rkt /etc/krb5.keytab ktutil: listslot 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.GOVktutil: 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
17.10 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. 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.% /usr/krb5/sbin/kadmin -p host/<hostname.domain> \ -q "ktadd host/<hostname.domain>" [-r <REALM>]Enter password: <type in host principal's password>% /usr/krb5/sbin/kadmin -p ftp/<hostname.domain> \ -q "ktadd ftp/<hostname.domain>" [-r <REALM>]Enter password: <type in ftp principal's password>
17.11 Configuration to allow use of CRYPTOCard with OpenSSH
Configuring OpenSSH to work with a CRYPTOCard requires the use of a PAM configuration file. The following is a file /etc/pam.d/sshd for Linux. (Solaris uses a /etc/pam.conf file. The sshd lines will be similar to those of the linux /etc/pam.d/sshd.)#%PAM-1.0 auth required pam_env.so auth sufficient pam_krb5.so use_opt_hwauth use_shmem=sshd existing_ticket=true auth required pam_nologin.so account required pam_stack.so service=system-auth password required pam_stack.so service=system-auth session required pam_limits.so session required pam_unix.so session sufficient pam_krb5.so external use_shmem=sshd session required pam_loginuid.so
The use_shmem=sshd existing_ticket=true line is a continuation of the previous, and in the file, should continue on the same line.
- Tells pam to do CRYPTOCards with kerberos.
- Tells pam to store the ticket from the KDC (in shared memory) during the 'auth' step. This information is then needed during the 'session' step.
- Tells pam to skip the CRYPTOCard login if the user already has valid credentials.
In addition, the following must be set in the /etc/ssh/sshd_config file.PasswordAuthentication no ChallengeResponseAuthentication yes
By default they are set with the yes and no values swapped. The shown settings are required in order for the system to display the challenge to the user.
17.12 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.
17.13 Multiple IP Addresses or Node Names
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.
The feature that sets laptops apart as regards authentication is the fact that they may have different host names and/or IP addresses depending on where they're being used. Install the Kerberos product on it as you would on any other machine, but first decide whether you want a static IP address or if you want to use DHCP.
1If two inetd processes are running, some nonKerberized services like rlogin may get handled by a different file than /etc/inetd.conf and thus won't be disabled by the kerberos installation script as they should be.
2To eliminate those, take out the klogin service from inetd (leave eklogin) and add an 'e' flag to the kshell service.
3 If your AFS username is different than your email username, it's likely that the script that built the AFS group that controls access to the KDC log files doesn't have your correct username and you can't access the files.
4Every user in possession of a CRYPTOCard has an "RB1" instance associated with his or her principal (e.g., username/RB1@FNAL.GOV), which we call a "CRYPTOCard principal". CRYPTOCard principals are given the "DISALLOW_ALL_TIX" attribute because the credentials obtained via a CRYPTOCard are associated with the principal name "username@FNAL.GOV".
|View/print PDF file | Back to Strong Auth Index Page | Computing Division | Fermilab at Work | Fermilab Home|