Kerberos destory script?

[#1]

Little help on scripting please.

I'm trying to get a logout script that will destroy the Kerberos ticket cache at logout. I can make it work in Terminal but when pushed with Casper Remote or a policy it does nothing.

This is all I have:

#!/bin/sh
##################################
# Destroy the Kerberos ticket of current user.
# Nathaniel Lindley for SPPS, April 10, 2009
##################################

kdestroy -a

What else do I need? Strange thing is that this is the default behavior in 10.4 (to destroy kerberos ticket at logout) but not in 10.5, by design according to Apple. The problem is that at one school, students login with a "student" generic local account and then connect to a server using their AD credentials from 10.5 client. Then student logs out, and another student logs in, trys to Connect to Server and is already logged in as the previous student whose ticket is retained for 10 hours.

Thanks for the help,
-Nathaniel

[#2]

Looks like the problem is that this script is run as root, who doesn't have a kerberos ticket to destroy. To run it as the logging out user use 'su' and $3 for the username:

su $3 -c "kdestroy -a"

That should do it.

Ryan Harter
UW - Stevens Point
Workstation Developer
715.346.2716
Ryan.Harter at uwsp.edu

[#3]

I could be wrong about this, but doesn't Casper use login and logout hooks to fire off scripts at login or out? Since you can only have one of each hook, that means that if you replace Casper's hooks with this, you would no longer be able to fire off policies at login/out.

That may work for you, but would be unacceptable for me.

Ryan Harter
UW - Stevens Point
Workstation Developer
715.346.2716
Ryan.Harter at uwsp.edu

[#4]

Have you tried setting this script as a login or logout hook? So rather than having Casper execute a policy it is just something that OS X will do every time someone logs into or out of the machine.

Here is an Apple KB article on how to do this... http://support.apple.com/kb/HT2420. This particular article is about making a Login Hook, but you should be able to change the command text 'LoginHook' to 'LogoutHook' if it is something that you want to happen on logout instead.

Andy Hakala
Technology Support
Hopkins High School
Hopkins, MN

[#5]

One thing to remember is that loginhooks are run as root, so you would need to add the "su $currentUser -c "kdestroy -a"". While adding this to the hooks would probably work, it would be pretty similar to how Casper's loginhooks already fire it off, but you would lose that centralized aspect that Casper brings to the table. Running this as a policy triggered by login or logout is really the best solution IMHO.

As long as you add the su it should be a fairly simple matter.

Ryan Harter
UW - Stevens Point
Workstation Developer
715.346.2716
Ryan.Harter at uwsp.edu

[#6]

Just because you only have one login/logout hooks, doesn't mean they On Apr 13, 2009, at 2:34 PM, Ryan Harter wrote:
can't fire off multiple scripts based on different criteria.

[#7]

Just so I understand.. you can only have one policy set to trigger on log in and one to log out? The rest need to be startup or shutdown or the other one's?

---

Kathie Iorizzo
Lower School Technician
The Latin School of Chicago
kiorizzo at latinschool.org
312.582.6136

[#8]

I think I should clarify the difference between login policies within Casper and loginhooks.

A loginhook (and a logouthook) has nothing to do with Casper. These are built in features of Mac OS X whereby you can add a setting to a plist that points to a script and, depending on whether its a login or logout hook, that script will be run as root at the given time, regardless of which user is logging in or out.

Casper utilizes this feature to allow login triggers on scripts. There is a script at /etc/scripts/loginhook.sh that contains:

#!/bin/sh

## Log the event to the JSS
/usr/sbin/jamf log -action login -username $1

## Check for policies on the JSS
/usr/sbin/jamf policy -action login -username $1

You can see that this script merely logs the login and then looks for policies triggered by "login".

You can have as many login policies as you want, but the plist that controls the loginhook only allows one entry. If you change the loginhook setting then Casper will no longer be able to trigger policies on login. The best thing to do if you want to run something at login is just make a policy triggered by login.

Hope it helps.

Ryan Harter
UW - Stevens Point
Workstation Developer
715.346.2716
Ryan.Harter at uwsp.edu

[#9]

sorry, that I'm not responding more timely, other duties.

I tried the suggestion
"su $3 -c "kdestroy -a"
didn't work and the error said. unknown argument, I think. I shouldn't need to have root enabled on the client to tell the script to run as the user. . I'll keep trying it.

I like using the logout action as a policy so that it is easy to remove from the computers remotely rather than further modifying the machine. -Nathaniel

Re: [Casper] Kerberos destory script?

Ryan Harter to:
Kathie Iorizzo
04/13/2009 09:08 PM

[#10]

We have a policy set to advance on all managed machines and it's simply
kdestroy -a

---

Kathie Iorizzo
Lower School Technician
The Latin School of Chicago
kiorizzo at latinschool.org
312.582.6136

[Bukira]

why are your tickets not destroyed when you logout

ive never had this problem, when a user logs out their ticket goes

Criss Myers
Senior Customer Support Analyst (Mac Services)
Apple Certified Technical Coordinator v10.5
LIS Business Support Team
Library 301
University of Central Lancashire
Preston PR1 2HE
Ex 5054
01772 895054

[#12]

My problem is that the tickets do get destroyed on 10.4 and not on 10.5, which is the way that apple wants it to work apparently.

Re: [Casper] Kerberos destory script?

Criss Myers to:
Kathie Iorizzo, casper-bounces, NATHANIEL.LINDLEY
04/14/2009 08:52 AM

[#13]

More changed is 10.5: apparently su no longer has the -c option (run command). You could use sudo -u $3 command

That will run command as the user provided by $3.

Ryan Harter
UW - Stevens Point
Workstation Developer
715.346.2716
Ryan.Harter at uwsp.edu

[dustydorey]

Odd, we have the same problem here with 10.5 and Generic Student
accounts and the problem was solved by creating a policy that runs at
logout, and is ongoing, and all we use for the command is: kdestroy

no additional flags of any kind. I just tested it again to make sure
I wasn't crazy, and that it was working for us. I wasn't the
originator of the policy here so I just went back and checked up on use
of the optional -a, -A, -q, -c, -p flags that can be used and I'm a bit
miffed now as to why just "kdestroy" is working for us as it is without
specifying current user and to destroy all caches. But it is. Maybe
because the default action if credentials aren't specified is to destroy
the default cache? So I'm thinking I'm not going to mess with it
needlessly.

Any thoughts?

-Dusty-

Dustin Dorey

Technology Support Cluster Specialist

Independent School District 196

Rosemount-Apple Valley-Eagan Public Schools

dustin.dorey at district196.org

651|423|7971

[dustydorey]

BTW Sorry about re submitting this to the list months later, I was
cleaning some old stuff out of my mailbox that I had saved before to
come back to and in digging around a bit I ran into this one. Since
we've been dealing with some Kerberos stuff and keychain stuff lately
it had gotten me interested again.

-Dusty-

[#16]

A quick look at the man page reveals "If the credentials cache is not specified, the default credentials cache is destroyed." The -a (or -A) param just tells kdestroy to destroy all caches, but without the default cache will be destroyed. Perhaps the user's cache, being the only one, is the default one. I'm a bit surprised that this is having the root user, in theory, destroy all kerberos caches.

Ryan Harter
UW - Stevens Point
Workstation Developer
715.346.2716