Shell script with output if there is a kerberos ticket

that can change from one minute to the next, not sure how valuable an extension attribute would be.

Yeah, tickets can be created and destroyed on a regular basis. An Extension Attribute is only gathered during recon, so by the time you see it it may be gone already, or a new one would be there.

If you can elaborate on why you might need to know about the Kerberos tickets there may be a better way to do what you're looking for.

I need to verify if a machine has a Kerberos ticket we are implementing single signon and if there is no ticket sso will fail.

Ok, so if the machine doesn't have a Kerberos ticket, what action is it that you plan to take on it?
Do you simply want to be alerted to that fact? Or something else?

I guess I'm just wondering what value an EA would be for you in this instance. If you were looking to run a policy on it to correct the issue, maybe a Launchd job to track the SSO state and run some script would make more sense?

Basically would like a yes or a no if a machine has a ticket for a specific domain. I want to identify machines that are not generating tickets so I can apply a policy to correct.

Basically would like a yes or a no if a machine has a ticket for a specific domain. I want to identify machines that are not generating tickets so I can apply a policy to correct.

that is so likely going to be solved by logging out and logging back in, or like @mm2270 said, just run a launch agent that runs every 10 minutes and have it use cocoa dialog or something like that help the user to generate a new ticket. the inventory/EA is going to be so far out of date it will be irrelevant, and if you run more inventory to make it relevant your DB will likely grow ridiculously large.

If you want real-time data (that is, your customer is seeing auth prompts, so you want to know if he currently have a kerberos ticket) then you'll not be able to rely on an EA. If you really want to go down this path, you could have a policy triggered by "any" that runs a script to look for a kerberos ticket and echoes back some information. That way, the policy logs for that system would tell you whether it had a kerberos ticket.

The script would look something like

#!/bin/sh

kticket=`klist | grep your.domain`


if [ -n "$kticket" ]; then
    echo $kticket
else
    echo "No ticket"
    exit 1
fi

The exit 1 would give you red logs when $kticket was null, so you could tell without looking into each log whether they had one last time it ran.

I haven't tested this. Edit: I see that you had hoped to scope on this result; perhaps whatever your fix is could be implemented within the else case above. What are you doing to fix Macs that aren't pulling tickets?

To fix macs that arent pulling I plan on implementing a script I found initialized by a launch agent. So far I have only found one machine however I want to prepare for the eventuality that there may be more.

there are so many events that should be renewing your kerberos tickets it seems odd to have to worry about it. connecting to the network via vpn, unlocking the screensaver, logging in should all automatically create a new ticket if the old one is expired, a least that is my understanding on how the whole kerberos thing works.

Works locally however when run through Casper I get the following, In this instance I know the user has a ticket.

Running script kerberostest.sh...
Script exit code: 1
Script result: klist: krb5_cc_get_principal: No credentials cache file found
No ticket
Submitting log to https://casper.hbgusa.com:8443/
Finished.

thats because the kerberos ticket is owned by the logged in user, and when you run through Casper its being run as root.

ok so I have some users at least one but like I said I want to prepare for the eventuality that there may be more that are for whatever reason not getting kerberos tickets at all even though the user is properly bound to AD and is logging into an internal network. I need to identify if there are more users exhibiting the same behavior.

i.e implementing sso and need to be positive it works on all machines , if there is no ticket sso fails. this is a corporate environment so being able to say i am 100% covered is important.

Excellent point; you could use it in the launch agent though, and have it always run and either a) do nothing because there's a ticket, or b) go through the repair steps if no ticket is found.

Could you post the script you have for repairing?

I get that, is there any way to run it against the logged in user? I have been trying to figure that out for the better part of the day.

this is the script, found it in another thread.

try -- test for Kerberos ticket presence and attempt to renew do shell script "/usr/bin/klist | /usr/bin/grep krbtgt" do shell script "/usr/bin/kinit -R"
on error -- offer to renew Kerberos ticket set response to (display dialog "No Kerberos ticket was found. Do you want to renew it?" with icon 2 buttons {"No", "Yes"} default button "Yes") if button returned of response is "Yes" then try set thePassword to text returned of (display dialog "Enter your password:" default answer "" with hidden answer) do shell script "/bin/echo '" & thePassword & "' | /usr/bin/kinit -l 10h -r 10h --password-file=STDIN" display dialog "Kerberos ticket acquired." with icon 1 buttons {"OK"} default button 1 on error try set thePassword to text returned of (display dialog "Password incorrect. Please try again:" default answer "" with icon 2 with hidden answer) do shell script "/bin/echo '" & thePassword & "' | /usr/bin/kinit -l 10h -r 10h --password-file=STDIN" display dialog "Kerberos ticket acquired." with icon 1 buttons {"OK"} default button 1 on error display dialog "Too many incorrect attempts. Stopping to avoid account lockout." with icon 2 buttons {"OK"} default button 1 end try end try else -- if No is clicked quit end if
end try

If you already have a LaunchAgent that will trigger a fix, I'd suggest rolling the entire thing into a LaunchAgent then. Have the agent detect when there is an issue and fix it.
You could also implement some kind of logging functionality into your script to save a log file somewhere locally, and then have an EA pick up the contents of the log file. That way you could keep track of which systems needed fixing without needing to rely on potentially stale data from the JSS.

To be fair, the issue of out of date information exists for any policy really. For ex, I could be trying to install an application update based on a Smart Group populated by nearly one day old inventory, but the end user may have already installed said update manually. There are some ways to help avoid this, but its always a potential issue we face.

OK, by the time I posted the above the conversation has moved on, sorry.

So does anyone know if its possible to run the script provided by JPDyson as the logged in user vs root?

#!/bin/sh

kticket=klist | grep your.domain

if [ -n "$kticket" ]; then echo $kticket
else echo "No ticket" exit 1
fi

Launch agents run in the user context; they are distinct in this way from launch daemons, which run in the system context.