Kerberos on a Mac Computer
This article describes how to configure Kerberos for Mac OS X 10.7 and later to access Kerberized machines and encrypt your data transmissions.
Heimdal Kerberos is shipped as part of Mac OS X (as of the OS X 10.7 "Lion" release). Heimdal Kerberos is an alternative implementation of the Kerberos protocol and mostly inter-operates with the more common MIT Kerberos (such as those installed on Fermilab Linux systems).
In order to configure Kerberos on a Mac computer, obtain the Fermilab Kerberos configuration file krb5.conf from this Fermilab webpage: http://authentication.fnal.gov/krb5conf/. The recommended practice is to save the file to /etc/krb5.conf. The system expects to find the Kerberos configuration file in one of two places. Check for the existence of either of the following two files. (/etc is a private directory and requires root privileges to access):
If the second file (edu.mit.Kerberos) is present, it needs to be deleted. Fermilab's recommended practice is to rely on the /etc/krb5.conf Kerberos configuration file.
Make sure the Kerberos configuration file only exists in one of these two places!
If you normally work from behind a NAT (Network Address Translation) router, as is typical of many cable and DSL internet users, you should also add the following line to the [libdefaults] section of the Kerberos configuration:
noaddresses = TRUE
Once you have set up Kerberos, you have:
- Kerberized telnet and ssh clients
- A Kerberized ssh server (see SSH Server Configuration section below for details)
- Kerberized access to FERMI.WIN.FNAL.GOV Windows servers
You will not have Kerberized ftp, rlogin, and rsh.
To authenticate, use either the command line kinit as you would on a Linux system, or use the OS X GUI application Ticket Viewer.
Command Line kinit
Open a terminal window and run the command kinit. See section kinit.
- Open Keychain Access (also in the /Applications/Utilities folder)and select Ticket Viewer from under the Keychain Access menu.
- Click Add Identity in the Ticket Viewer.
- Check that your username is right and the realm is FNAL.GOV. Enter your Kerberos password and click OK.
- You'll see your principal name and the expiration date and time for your tickets. You can click the triangle to reveal a list of the tickets.
- Now you are ready to connect to a Linux system with ssh, or to a Windows domain file server with the Finder's Command-K function. You can exit from the Kerberos GUI application without losing your tickets.
SSH Client Configuration (To be able to connect from your Mac to Fermilab systems)
To set up your Mac for outgoinging SSH connections that comply with Fermilab security policies and allow you to connect to Fermilab systems, you will need to edit /etc/ssh_config and make the following settings as listed here (you might also need to uncomment lines by removing the leading '#').
The following 2 lines enable Kerberos authentication and forward your credentials to the remote system:
You may want to add the following 2 lines if you run X-Windows programs on the remote system. These lines will forward the window displayed by the program back to your Mac screen via the encrypted SSH tunnel:
The following line can be used in front of the above parameter lines (and will be in effect until the next Host line or the end of the file). This will limit the following configuration parameters to be effective only when connecting to systems on the Fermilab networks. This is useful if you also connect to non-Kerberized non-Fermilab systems as well as to Fermilab Kerberized systems:
Host 131.225.* *.fnal.gov
SSH Server Configuration (To be able to connect to your Mac)
In order to set up your Mac for incoming SSH connections that comply with Fermilab security policies, you will need to edit /etc/sshd_config and make the following settings as listed here (you might also need to uncomment lines by removing the leading '#').
Public key authentication method is insecure and is not permitted by Fermilab Secure Authentication policy. Fermilab actively scans and blocks servers that allow public key authentication. You must explicitly disable public key authentication. Uncomment (remove leading #) and change this setting to "no".
If your Mac is a DHCP client, make sure it gets a stable hostname when connected. Go to System Preferences, click Network, choose each network interface in turn that you intend to use (probably just "Ethernet" and "Airport"or "Wi-Fi"). For each one, click Advanced, go to the TCP/IP tab, and fill in the "DHCP Client ID" box with just your hostname (not the fully qualified name). For example, let's suppose you've registered your Mac with the hostname fondulac. Just put fondulac in the box, even though your full domain name is fondulac.dhcp.fnal.gov.
Log in to the Service Desk web portal and fill out the Access to Kerberized Machines form. Select Host Principals under Check Item(s) Needed to request a "host principal" and provide the fully qualified domain name (i.e., fondulac.dhcp.fnal.gov) in the provided box.
Once you get an email back with an initial host principal password, you need to create a keytab file to hold the principal key but you will not be able to do this on your Mac because the Heimdal-based kadmin utility present on the Mac will not inter-operate with the kadmin server on the Master KDC. Instead you will have to log into a Linux system and create the keytab there and then securely transport the file back to your Mac where it will be stored as the file /etc/krb5.keytab (you can use the SSH file copy utility scp to accomplish this). On the Linux system, run this command:
kadmin -p host/fondulac.dhcp.fnal.gov -q "ktadd -k fondulac.keytab host/fondulac.dhcp.fnal.gov"
Provide the password when prompted -- it can only be used one time. If successful the terminal will display a message to the effect of "Entry for principal host/fondulac.dhcp.fnal.gov ... added to keytab fondulac.keytab." Use a secure method to transfer fondulac.keytab to your Mac to be saved as /etc/krb5.keytab.
Open System Preferences, select "Sharing", and click Remote Login to enable incoming SSH. Make sure your correct hostname (not the fully qualified name) is in the Computer Name field.
Add a .k5login file to the home directory of any account to which you want to be able to log in remotely, and include the appropriate principals which are allowed to log into the account (full principal name with no spaces along with the Kerberos realm name in upper case). This file must be writable only by the account itself and/or root.
If you get the error "KDC reply did not match expectations" or "Clock skew too great while getting initial credentials", your computer's date and time are too different than the date and time on the Kerberos server. If you see this error, make sure your date and time are correct.
On a Mac, the Date and Time in the System Preferences or Control Panel has an option for using a network time server. To set the date and time:
- First close all applications that use Kerberos.
- Follow these instructions to set the date and time on your Mac.
If the problem persists, restart your computer.
When you change your Kerberos password, you may find that using kinit on the Mac will fail due to an incorrect password. This can happen when kinit attempts to get a ticket from a Slave KDC before the Kerberos database on the Slave KDC has been updated from the Master KDC. Password changes are made in the Kerberos database only on the Master KDC regardless of whether you are changing your password from the Mac, a Linux system or a Windows system. Every 20 minutes the Kerberos database is propagated from the Master KDC to all the Slave KDCs which gets the updated password on all the KDCs. Until this database propagation completes, the Slave KDCs have the old, pre-change password and a kinit done on the Mac which attempts to get Kerberos tickets from such a Slave KDC will get a password failure. On the Mac the way to avoid this problem is to get Kerberos credentials before changing your password or wait 20 minutes after changing your password before attempting to get credentials on the Mac.
NOTE: This delay is not needed by Linux users since the MIT version of kinit used on the Linux systems behaves a bit differently. If the MIT kinit gets an error when attempting to get credentials from a Slave KDC, it treats this failure as a possible communications failure and immediately makes another attempt to get credentials from the Master KDC. In the case of a changed password, an incorrect password failure from a Slave KDC results in getting the credentials from the Master KDC which succeeds since the Kerberos database on the Master KDC has the newly changed password.