I'm interested in learning more about this as well. The "kinit" command seems to work in these situations to get a new kerberos ticket (after typing in the account password). To get it to "talk now" you could use a Self-Service policy or AppleScript, but I think you'd have to prompt the user for their password.

I'd prefer to keep the tickets valid in the background so it is transparent to the users....any tips would be appreciated.

For some years now there's been a small utility called SleepWatcher that can trigger shell scripts to run based on sleep/wake events and even idle time of the system. It looks like that utility is still being updated and the developer claims works with 10.10.x. You can find it here:
http://www.bernhard-baehr.de

Basically, its a LaunchDaemon that works in conjunction with an rc.sleep and an rc.wake file and a binary that calls them to detect when a system has woken up or is going to sleep, and can run a script.
I'm not sure if this would help your situation, but maybe look into it and test it out.

That said, I don't believe we run into this problem or at least not often enough for anyone to complain about it, so it may be that your AD/network admins need to do some tweaking to make kerberos refreshing work better with your Macs. Whenever we do have an expired ticket that hasn't refreshed yet, simply locking the screen and unlocking it while connected to the network seems to do the trick to get everything taking again.

I was just about to say the same thing! We use sleep watcher a lot. Particularly when we are running data syncing scripts on laptops and the users often close the lid before the task is finished.

Regarding kerberos tickets, they are normally valid for 8-10 hours and renewable for a lot longer. We have used a shell script in the past to prompt the user to get a new ticket. You're welcome to adjust it to you're requirements:

#!/bin/sh

ticketCheck=`klist 2> /dev/null | grep -c "$USER@KERBEROS_REALM.COM"`

if [ $ticketCheck == 1 ] ; then

echo "$USER already has a kerberos ticket" >> $logfile

else

echo "$USER does not have a kerberos ticket, running kinit" >> $logfile

userPassTemp=`osascript -e 'tell application "Finder"' -e "activate" -e "display dialog
 "Please enter your user account password:" default answer "" with hidden answer"
 -e 'end tell'`

userPassFinal=`echo $userPassTemp | sed 's/text returned://g' | sed 's/, button returned:OK//g'`

echo $userPassFinal | kinit --password-file=STDIN 2> /dev/null

if [ $? -ne 0 ] ; then

osascript -e 'tell application "Finder"' -e "activate" -e "display dialog "Incorrect password,
 please try again." buttons "Ok"" -e 'end tell' &> dev/null

exit 0

fi

fi

Thanks for the script!. I was hoping for a way to use the cached credentials as to not have to prompt the user at all. They already have to unlock their systems so I figure that should be enough. I believe using keytab *should* work, i'm just not sure how. Anything I try errors out.

It might depend on the sequence of events. If the Mac has just woken up and they unlock it, it might not have a network connection / or a VPN connection. You might find that if they were in the office with an ethernet cable plugged in it would all work fine. In this case it would be a networking problem, but not one you could really do much about. Asking users to wait a minute from waking their Macs from sleep before trying to unlock would be impossible to enforce.

The keytab method could work but you would be compromising the security benefits of kerberos to do it. It would also be quite hard to do! If you still wanted to look into it I would recommend the O'Reilly Kerberos book as a good starting point.

Maybe https://yourmacguy.wordpress.com/2014/12/17/announcing-kerbminder/?

I am unaware of any way you can use the keytab to refresh a kerberos ticket without requiring the user's password, that wouldn't be secure at all. Anyone with sudo privileges could get full access to masquerade as another user.

kerbminder combined with or without ADPassMon is very good solution ; however - if you have budget $$ laying around - check with your Apple Enterprise rep and inquire about "Enterprise Connect" (a solution from Apple Pro Services)

Being that the system re-establishes the tokens on its own it seems that there should be a way to provoke it to do so. I was hoping kind of a killall -HUP processname. Perhaps a rapid fire attempt and cancel of accessing a kerberos resource for N times.

@jcompton Is Enterprise Connect a service for OS X? I tried a quick web search but I don't see anything. I just pushed out ADPassMon to our organization in hopes of improving our password changes. Thanks in advance!

I've also been struggling with this.. one thing I'll share that's helped me is to create a keychain entry in the user's login keychain by leveraging the 'security add-generic-password' function.

My syntax looks like this:
security add-generic-password -a $userName -D "application password" -s "EXAMPLE.COM" -U -w $userPass -A -j "Created by Kerberos Agent" &> /dev/null

It creates an entry that looks like this in their Login Keychain
Attribute Tab
Name= EXAMPLE.COM
Kind= application password
Account = username
Where= EXAMPLE.COM
Password = User's Password

Access Control Tab
Allow all applications to access this item

If you create it with the 'Allow all applications to access this item' or by specifying only 'kinit' in the Access Control tab, you can then just run 'kinit' from terminal and it will obtain a new kerberos ticket without prompting for the user's password.

I have tied this logic into my user's password change process, so when they change their password I create this entry for them. Now when they login or unlock their screensaver they get a kerberos ticket.

What I'm trying to do is find a programmatic method where I can immediately detect if their kerberos ticket expires or simply doesn't yet exist, then run a script that will obtain one for them. So far I have been unable to figure that part out. Though one scenario I know I must address is when the computer wakes from sleep, as it doesn't seem to always renew their kerberos ticket even after they unlock their screen saver. All of my research keeps pointing back to 'SleepWatcher' for this type of thing. So while I'd rather avoid a 3rd party app for something that seems should be doable through LaunchD, I may be heading that way.

Good luck!

kerbminder may help too.

For 10.10 at least...
Found this on the internet and testing to see how it goes, initialy looks pretty good, when you klist after waking or coming back from screensaver it shows a brand new ticket was issued.
More testing is required as there might be implications (although I don't think so) when for some reason it tries to renew the ticket and is unable to.
Edit the first auth line of /etc/pam.d/screensaver so the file reads as follows.

# screensaver: auth account
auth       optional       pam_krb5.so use_first_pass use_kcminit default_principal
auth       required       pam_opendirectory.so use_first_pass nullok
account    required       pam_opendirectory.so
account    sufficient     pam_self.so
account    required       pam_group.so no_warn group=admin,wheel fail_safe
account    required       pam_group.so no_warn deny group=admin,wheel ruser fail_safe

The changes are the word optional and default_principal

The original internet source is below, the other parts of it relate to general authentication and kerberos stuff which can break your ability to login with a network account so use with care...
http://clc.its.psu.edu/UnivServices/itadmins/mac/kerbldaplogins/macosxkerbauthsetup

@warrengottlieb -- EC won't show up on any web searches. It's actually an OS X app (runs as a menu item) that is developed and distributed by Apple Professional Services. You have to contact your Apple rep to get more info. I LOVE IT.

Enterprise Connect seems to only be available to corporate customers? Apple reps have indicated it's not available to edu? Issues for us are largely 10.10.x and 802.1x/Login Window related ... overall reliability and reconnect from sleep with Yosemite.

@CGundersen

Enterprise Connect seems to only be available to corporate customers?

I have Apple Pro Services coming on-site this Thursday and Friday to assist in the setup of Enterprise Connect in our environment. I will ask him if this is something available to edu and post back.

Yeah - I question that statement from your SE. That doesn't make any sense. You pay for a service contract for Apple Pro Services. You don't even really pay for the app.

The one catch - I think it's only supported for 10.9 and up. (Maybe 10.8) Maybe your SE knows that you are running older OS's ?

We are 10.9.5+ at this point ... well, not 10.10 yet (unless HW or 10.10 specific app required). Relations with Apple are not what they were (changes at both institutions), but we still have very high numbers. That said, Apple reps and Apple Enterprise support understand the complications we've had with Yosemite (tickets open many months) and what we are looking to achieve (fairly modest goals). Very nice folks all around and we are always happy to test and give feedback. However, it does seem like we are paying vendors more and more to identify defects and work through very basic testing that should be occurring back at corporate HQ. I really do hope that the process improves.

I look forward to hearing more about Enterprise Connect ... perhaps I'll just email consulting services directly to avoid confusion.

@CGundersen

I asked our Apple Engineer we had helping us implement Enterprise Connect about it's availability for edu and as you suspected it is for Enterprise customers only at this time. It sounds like they may add support for edu at some point but there was no indication as to when this would happen.

Aaron

@FritzsCorner

Thanks for the info and I appreciate your inquiry. The confirmation is disappointing but expected. We have a CC with Apple tomorrow although communication is generally "blah blah good impact data blah blah" these days. Thanks again!

Why would we purchase a service to fix a bug?

@chris.hotte

Good question. I don't really expect EC to fix bugs as much as simplify/streamline a bit of the AD integration process. There is also the thought that engineering might actually test around/for a workflow that Apple Pro services is selling/supporting? Maybe?

This has been an issue for me since moving to AD. Getting the Kerberos to 'just work'. Checking and prompting for a password looks feasible. Unfortunately I have to adhere to a 3 attempt lockout policy so that is calculated.

# screensaver: auth account
auth       optional       pam_krb5.so use_first_pass use_kcminit default_principal

I check and use sed to fix the above since 10.7 I believe. I have some client software that modifies the same file for its own purposes, so I live a in a break-fix circle on that particular point.

Getting people to log out of their machines every now and again.... is ... I give up. They don't learn and the ticket goes non-renewable I suppose after enough time passes. So catching that condition and using the above prompt in that case will help.

However I can't help but want to MAKE them learn and log out. But then again, do I log out? No. I just drop to the prompt and type kinit. :)

@Look

Posted: 6/7/15 at 6:45 PM by Look

For 10.10 at least...
Found this on the internet and testing to see how it goes, initialy looks pretty good, when you klist after waking or coming back from screensaver it shows a brand new ticket was issued.
More testing is required as there might be implications (although I don't think so) when for some reason it tries to renew the ticket and is unable to.
Edit the first auth line of /etc/pam.d/screensaver so the file reads as follows.

screensaver: auth account

auth optional pam_krb5.so use_first_pass use_kcminit default_principal
auth required pam_opendirectory.so use_first_pass nullok
account required pam_opendirectory.so
account sufficient pam_self.so
account required pam_group.so no_warn group=admin,wheel fail_safe
account required pam_group.so no_warn deny group=admin,wheel ruser fail_safe
The changes are the word optional and default_principal

The original internet source is below, the other parts of it relate to general authentication and kerberos stuff which can break your ability to login with a network account so use with care...
http://clc.its.psu.edu/UnivServices/itadmins/mac/kerbldaplogins/macosxkerbauthsetup

This seems to work for me. Now I am wondering on the best way to deploy this to all users.... any thoughts? I am still fairly new to JAMF... can you deploy these type of files like you can .plist ?