SSO Kerberos Extension - how to refresh expired tickets?

hansjoerg_watzl
Contributor II

Hello

We have been using SSO Kerberos Extension with local accounts for a few months now (Big Sur). (Mac is not joined to the AD anymore).

It works fine, with one major exception:
If a user is connected to the corporate network for more than 10 hours, the Kerberos tickets expire and unfortunately are not renewed automatically!

kerberos_expired.png

 

The TTL period for a Kerberos ticket is 10 hours. This is normal. But if the user doesn't log out daily, he doesn't even notice that his tickets have expired.
You can delete the tickets manually in the terminal with kdestroy and recreate them with kinit, but of course most users don't know that. (Besides, this should work automatically).

I actually expected this SSO extension to notice itself when the tickets have expired and then automatically re-login to the AD in the background. (The credentials are stored locally anyway).
When connecting to the corporate network it does this automatically. Why can't it renew the tickets automatically?

Is this normal or have we configured something wrong?

Thanks for any hint!

11 REPLIES 11

sdagley
Honored Contributor II

@hansjoerg_watzl What versions of macOS are you seeing this on? And if it's not on the latest version of macOS, can you test a system running Monterey 12.0.1 to see if it behaves the same? Since the Kerberos SSO extension is part of the OS now, and no standalone installer exists, you may need to update to a newer version of macOS to get the fix for this problem.

Most of our users have the latest Big Sur installed. But some have older versions of Big Sur. (We don't have approved Monterey yet. Still in testing. But yes, should test this ticket issue with Monterey too.)

As far as I know, Apple Kerberos SSO has been built into the OS since macOS Catalina. So we should actually be safe with every Big Sur version.

jcaleshire
New Contributor III

I'm not certain, but this sounds like the issue is the monitorCredentialCache key in the SSO configuration. This is the key that dictates whether or not the SSO agent in macOS will automatically generate a new ticket when a request is made that matches an expired ticket. 

In Jamf Pro, this setting looks like this:

jcaleshire_0-1636477844315.png

I'd double-check and make sure that the option is set to Enforce in the admin console.

EDIT:

I didn't think about it before, but you could also use the command 'app-sso -a $REALM' on a Mac with an expired ticket to troubleshoot it, since it would manually initiate the action of renewing an expired ticket using the SSO extension. If the command completes without errors and shows a Kerberos summary, it would seem that the SSO agent is not being prompted to renew the Kerberos ticket when it is expired, and the issue is likely internal to the Mac itself. If that command doesn't work, then you may have an issue in the environment that is causing it to fail.

I also discovered this option later and was already hoping that this would be the reason. We then cloned the profile (with this option enforced) and deployed it on some devices. Unfortunately the Kerberos tickets remained expired.

Thanks for you hint about the 'app-sso -a $REALM' command. Will try it as soon as possible. 🙂

We have about 400 Macs with Kerberos SSO. Many users report this problem to us. But most of them don't even notice it or they restart the Mac before the 10 hours.
In the same AD we have almost the same number of Macs without Kerberos SSO (classic mobile accounts). Of course, the problem never occurs there. (Or with a Screensaver Unlock you can quickly authenticate yourself again on the AD).

spotmac
New Contributor III

I had the same issue and try to fix this with an launchagent

#!/bin/sh

REALM="DOMAIN.CORP.COM"
LogFile="Library/Logs/KerberosMontior.log"

writeToLog(){
NOW=$(date '+%Y-%m-%d %H:%M:%S')
echo "[$0] $NOW - $1" >> "$LogFile"
#echo "[$0] $NOW - $1"

}


DNS_SERVER=$(dig ${REALM} +short)

for dns_ip in ${DNS_SERVER//\\n/
}
do
ping -q -t2 -c1 $dns_ip >>/dev/null 2>&1
if [ $? -eq 0 ]; then
writeToLog "Directory Server ${dns_ip} is online.."
ACTIVE_DNS_SERVER=${dns_ip}
break
fi

done

if [ ! -z "$ACTIVE_DNS_SERVER" ]; then
writeToLog "Kerberos monitor started.."
else
writeToLog "No company network active exiting."
exit 0
fi


if ! klist -s >>/dev/null 2>&1
then
kdestroy >>/dev/null 2>&1
writeToLog "Kerberos ticket is not valid. Call Kerberos SSO agent.."
app-sso --authenticate $REALM >>/dev/null 2>&1
fi

Thanks for your script!

A guy from our company (not from my team) also tested such a script once. According to his statements, however, only with partial success. Therefore, I have not (yet) followed it up or tested this script myself, because I thought that this should surely work out-of-the-box.
But I will compare your script with the one from our company and test it. Maybe you use other commands.
Is your script in daily use and does it always work?

@spotmac Here's the script I mentioned before. I did not test it myself.

#!/usr/bin/env bash

# kclear - Clears expired Kerberos credential caches on MacOS
# Should be setup as a scheduled job in launchd (see launched.taademaq.kclear.plist)
# Dependencies: jq

set -o nounset
set -o errexit
set -o pipefail

readonly LOG_LEVEL=2

log() {
    echo "$(date +"%Y-%m-%dT%H:%M:%S%z") | $1 | $2" >&2
}

log_info() {
    if [ $LOG_LEVEL -ge 2 ]; then
        log "INFO" "$1"
    fi
}

log_debug() {
    if [ $LOG_LEVEL -ge 3 ]; then
        log "DEBUG" "$1"
    fi
}

log_debug "Starting"
expired_caches=$(klist -l --json | /usr/local/bin/jq -r '.[] | select(.Expired == "yes") | ."Cache name"')

for c in $expired_caches; do
    log_info "Destroying cache: $c"
    kdestroy -c "$c"
done

log_debug "Finished"

And here's the launchagent (e.g. ~/Library/LaunchAgents/launched.xy.kclear.plist):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>Label</key>
    <string>launched.xy.kclear</string>
    <key>ProgramArguments</key>
    <array>
      <string>sh</string>
      <string>-c</string>
      <string>./bin/kclear</string>
    </array>
    <key>StandardErrorPath</key>
    <string>./kclear.log</string>
    <key>StandardOutPath</key>
    <string>./kclear.out</string>
    <key>StartInterval</key>
    <integer>60</integer>
    <key>UserName</key>
    <string>xy</string>
    <key>WorkingDirectory</key>
    <string>/Users/xy</string>
  </dict>
</plist>

 

btw, how's the interval in your script/launchagent?

@fras same issue with macOS 12.0.1

spotmac
New Contributor III

@hansjoerg_watzl i recommend to watch the network relevant files and also check every 5 min. 

Grüße aus Berlin

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>de.company.kerberos</string>
<key>ProgramArguments</key>
<array>
<string>/Library/Application Support/Company/Scripts/kerberos.sh</string>
</array>
<key>WatchPaths</key>
<array>
<string>/etc/resolv.conf</string>
<string>/var/run/resolv.conf</string>
<string>/private/var/run/resolv.conf</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>StartInterval</key>
<integer>300</integer>
</dict>
</plist>

spotmac
New Contributor III

@hansjoerg_watzl i recommend to not use your posted script becasue it use external requirements (jq) and also it does not renew the tickets. 

@spotmac I know. I also prefer your script and launchagent plist. 😉

But I can confirm, that the kdestroy command alone (sometimes?) triggers a refresh/recreation of the tickets. Even if I don't use the app-sso --authenticate command.