KerbMinder is a tool for Mac OS X that keeps a logged-in user’s Kerberos ticket current by attempting to renew or refresh it automatically any time a user logs in or the network state changes. It only presents a UI if it needs the user to supply a password.


The password can be saved to the keychain so all subsequent renewals can use it. Should the saved password get out of sync with the domain — e.g. after the user changes their password — the keychain will automatically remove the old saved password and the user will be prompted to enter one.

KerbMinder is designed to provide a seamless, single sign-on (SSO) experience in in environments where

  • users have network-authenticated mobile accounts and often work off of corporate networks via VPN.
  • users would like the benefits of Kerberos SSO without having to bind the computer to a directory service.

That’s right! With KerbMinder, you can do away with binding Macs to Active Directory. If KerbMinder detects that you are not bound to AD, the first time it runs it will prompt for a username and domain.


If you want to skip the details, download the installer now.


The largest share of gratitude goes to Purdue Pharma L.P. for the following reasons:

  • inspiring and funding the development of KerbMinder.
  • providing a clear project scope.
  • testing the software through its stages of development.
  • agreeing to the project’s release as open source.

Portions of KerbMinder were inspired by code written by these fine humans (links point to the inspiring code, where possible):

I’d also like to thank

  • Allister Banks for pointing out an effective dig command to test for domain reachability.
  • Tim Sutton for telling me about Pashua.


  • Mac OS X 10.8.5 or newer, including El Capitan (10.11.x)
  • Python 2.7 (part of OS)
  • crankd (PyMacAdmin, included as a submodule)
  • Pashua (included)

How It Works

KerbMinder has a few components that operate in tandem.

KerbMinder logs its activity to the system log. You can open up and filter for “kerbminder” to see what it’s up to.

Part of the PyMacAdmin project, crankd is an always-on LaunchDaemon configured to look for network changes. Specifically, it monitors the System Configuration framework’s State:/Network/Global/IPv4 subkey, which blips any time a network interface gains or loses an IPv4 address. When a change is detected, it calls the following script.

This script’s main purpose is to determine if any ethernet interface (e.g. en0, en1, etc.) has an ip address. When called, it first sleeps for 30 seconds, allowing sufficient time for a wi-fi or VPN connection to be established. Then (with the help of networksetup -listnetworkserviceorder) it gets a list of ethernet interfaces in service priority order and goes down that list looking for the first one with an ip address.

If an interface with an IP address is found, it touches a trigger file (/Library/Application Support/crankd/kmfiles/trigger) that the following script watches. This handoff in duties is necessary because this script runs as a LaunchDaemon in the root context, but Kerberos ticket renewals must be done in the user’s context.

This script runs both when the user logs in, and as a triggered LaunchAgent. It refreshes or renews Kerberos tickets based on their discovered status. Before attempting a renewal, it first checks for domain reachability.

If a ticket is refreshable and non-expired, it is refreshed silently. If a ticket is expired or nor present, the script checks if the password has been saved in the keychain. If a keychain entry exists, the saved password is used to retrieve a ticket. If an entry does not exist, the user is prompted for their password (using a secure entry dialog box) and allowed two tries to reduce the chances of account lockout. Two incorrect password attempts results in a warning dialog. If an incorrect attempt results in a locked account, the user is informed that their account is locked.

If the password is correct the ticket is renewed and, if the user has checked the Remember this password in my keychain option, that password is saved to the keychain so future renewals can occur without user interaction. If the password becomes out of sync with the domain — e.g. after the domain password has been changed — then the stored keychain item is purged and the user is prompted for their password. and

Pashua is a tool for creating native Aqua dialog windows. KerbMinder uses it to display a password prompt window with a checkbox to optionally save the password.


The simple way

Download a KerbMinder release package and run it. No reboot or logout is necessary, but admin privileges are required.

The manual way

First, clone or download & unzip the KerbMinder repo to your computer, and cd into the repo from the terminal. (All subsequent paths that do not start with a slash are relative to the root of this repo.) Next, install crankd by running the installer in the pymacadmin directory using root privileges:

Copy files from the repo to their correct locations:

Download, mount the disk image, copy to the correct location, and remove the quarantine attribute:

Set the correct permissions:

Finally, start the LaunchDaemon and LaunchAgent. (Note the lack of sudo on the second command):

ADPassMon Integration

The latest release of my ADPassMon software lets users enable/disable KerbMinder via a menu item.

6 thoughts on “KerbMinder

  1. Peter – I’m using both ADPassMon and KerbMinder to force Kerberos to “wake up” and keep tickets fresh after coming back onto the network. This is truly great work. I’ve installed, uninstalled and installed KerbMinder manually using the master repo, all using my mobile network account (let’s call it UID 502).

    However, Pashua generates the window under my local user account (UID 501), which I obviously don’t see until maybe later in the day, when I don’t need it any longer. I’ve triple-checked permissions and locations of the LaunchAgents/etc and can’t seem to find out why everything insists on running as the wrong user (the one that doesn’t need Kerberos). Have you gotten any other reports of this? Thanks in advance and keep up the good work on both KerbMinder and ADPassMon.

    • This is the first I’ve heard of this issue, Paul. So I understand you correctly, the local user account logged in when this happens, and the LaunchAgent is running under the mobile account? I’ll look at how I’m spawning the Pashua window to see if there’s anything I can do to ensure it launches in the correct context.

  2. Peter – sorry about the late reply (I thought I had notifications turned on!) but thanks for getting back to me. You’re correct about the user contexts. If the sole local user account (which is also admin) is logged in when network state changes, it gets the window prompting for the AD account’s password.

    I can’t seem to find logging to indicate what it’s doing when the local account is NOT signed in when network state changes. Ticket Viewer and klist show valid TGTs but I’m having SSO issues, but it’s hard to tell if it’s just bad Web design and not Kerberos.

    The LaunchAgent is installed as global (/Library/LaunchAgents) so will that mean KerbMinder and Pashua could run as the wrong user, since launchd scans the agent directories if the local account logs in first? Should I move the .plist under /Users/mobileusername/Library/LaunchAgents where it’s forced to run in the right context?

    • Ok, so if the local admin account AND a mobile account are both logged in at the same, then each of them has a kerbminder launch agent running. That’s the root of the issue, since I did not have that scenario in mind. The launch agents are each watching the same trigger file which gets touched any time the network state changes, so this probably create a race condition and the local account is winning more often than not.

      I will need to modify kerbminder so it handles this better.

      • I can confirm no KerbMinder dialog (via Pashua) when the network state changes and the local account is NOT logged in. Perhaps I got one back-when and the password was saved to the mobile account’s Keychain. Can I assume this item exists as “GSS kGSSAttrClassKerberos password?” If so, my most recent entry is 6/2/15, so I thought it could be related to the local account trapping the password prompt before the correct account could “respond,” as you noted above. I am having SSO issues logging into a couple of Intranet sites but as I said above, perhaps it’s just bad Web design. At any rate, seems like this is reproducible and testable whenever you have a new build ready. Thanks!

        • Yes, Paul, the password is stored as a ‘GSS kGSSAttrClassKerberos’ item in the keychain of the account that was active when you got the kerbminder prompt and clicked the “Remember this password in my keychain” box. Can you test what happens when you delete that keychain item, kdestroy your kerberos ticket, then turn off your network connection and turn it back on? Before you do that, open up and filter for “kerbminder” so you can watch the log.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s