This site requires JavaScript to be enabled
An updated version of this article is available

Kerberos on a Macintosh System


6.0 - Updated on 2023-01-31 by Fang Wang

5.0 - Updated on 2021-12-14 by Fang Wang

4.0 - Updated on 2021-02-17 by Carlos Salazar (Inactive)

3.0 - Updated on 2020-11-17 by Fang Wang

2.0 - Updated on 2020-10-27 by Al Lilianstrom

1.0 - Authored on 2014-05-01 by Fang Wang

Intended for: Kerberos users

Scenario/Use case:

This article describes how to configure Kerberos for Mac OS X 10.7 and later in order to access Kerberized machines and encrypt your data transmissions.


Note: These instructions apply to Kerberos on Mac OS X 10.7 and later.

Client Configuration

Heimdal Kerberos is shipped as part of Mac OS X (as of the OS X 10.7 "Lion" release).  Heimdal Kerberos is an alternate implementation of the Kerberos protocol and (mostly) inter-operates with the more common MIT Kerberos (such as installed on Fermilab Linux systems).

In order to configure Kerberos on the Macintosh, obtain the Fermilab Kerberos configuration file krb5.conf from the Fermilab Security web site. The current version can be found at  The recommended practice is to rename 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, requires root privileges):



If the second file ( is present it needs to be deleted.  Fermilab's recommended practice is to reply on the /etc/krb5.conf Kerberos configuration file.

Make sure the Kerberos configuration file only exists in one of these two places!

If you commonly work from behind a NAT (Network Address Translation) router, as is typical of many cable and DSL internet users, you should also add to the [libdefaults] section of the Kerberos configuration the following line:

noaddresses = TRUE

Once you have set up Kerberos, you have:

You will not have Kerberized ftp, rlogin, and rsh.


Authenticate to Kerberos

To authenticate, use either the command line kinit as you would on a Linix 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


  1. Open Keychain Access (also in the /Applications/Utilities folder)and select Ticket Viewer from under the Keychain Access menu.
  2. Click Add Identity in the Ticket Viewer.

    Screenshot of Ticket Viewer              with Add Identity circled

  3. Check that your username is right and the realm is FNAL.GOV. Enter your Kerberos password and click OK.

    Screenshot of Ticket Viewer              Add Identity dialog box

  4. You'll see your principal name appear and a Time Remaining for your tickets. You can click the triangle to reveal a list of the tickets.

    Screenshot of Ticket Viewer              after Kerberos ticket acquired

  5. Now you are ready to connect to a Linix system with ssh, or to a Windows domain file server with the Finder's Command-K function. You can quit the Kerberos GUI application without losing your tickets.

SSH Client Configuration (To be able to Connect From your Macintosh to Fermilab systems)

In order to set up your Macintosh 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:

GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

You may want to add 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 Macintosh screen via the encrypted SSH tunnel:

ForwardX11Trusted yes
ForwardX11 yes

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.* *


SSH Server Configuration (To be able to Connect to your Macintosh

In order to set up your Macintosh 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 '#'). 

PasswordAuthentication no
PermitEmptyPasswords no

GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

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".

PubkeyAuthentication 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 Macintosh with the hostname fondulac. Just put fondulac in the box, even though your full domain name is

Log in to the Service Desk web portal and fill out the Additional Kerberos Items form. Select Host and FTP Principals under Check Item(s) Needed to request a "host principal" and provide the fully qualified domain name (i.e. in the provided box. In the Additional Information box at the bottom, specify that you do NOT need an ftp principal.

Once you get 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 Macintosh because the Heimdal-based kadmin utility present on the Macintosh 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 Macintosh 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/ -q "ktadd -k fondulac.keytab host/"

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/ ... added to keytab fondulac.keytab."  Use a secure method to transfer fondulac.keytab to your Macintosh to be saved as /etc/krb5.keytab.

Open System Preferences, pick "Sharing', 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.

Time Synchronization

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. Should you see this error, make sure your date and time are correct.

On a Macintosh, 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:

If the problem persists, restart your computer.

Password changes and kinit on the Macintosh

When you change your Kerberos password, you may find that using kinit on the Macintosh 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 datbase only on the Master KDC regardless of whether you are changing your password from the Macintosh, a Linux system or a Windows system.  Every 20 minutes the Kerberos database is propogated from the Master KDC to all the Slave KDCs which gets the updated password on all the KDCs.  Until this database propogation completes, the Slave KDCs have the old, pre-change password and a kinit done on the Macintosh which attempts to get Kerberos tickets from such a Slave KDC will get a password failure. On the Macintosh 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 Macintosh.

Note that 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 mades 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. 


See Also: