Script Query

[#1]

Hi All,

The script grabs the name of the currently logged in user, then passes the variable to the following command;

echo |kinit $username at QUT.EDU.AU

If I run this script locally – it works, flashes up the KerberosAgent windows asking the user for their password to renew a kerberos ticket.

If I run this script by calling; sudo jamf policy –trigger every15 – it works, flashes up the KerberosAgent window asking the user for their password to renew a kerberos ticket.

If I leave the JSS alone to run this every 15 minutes it fails. The script reports the user has a valid kerberos ticket – when they don’t - and says it is displaying the KerberosAgent window, it however doesn't.

I am quite literally stumped as to why the behaviour of this script is so different between running automatically and manually.

It has something to do with the way the echo |kinit command is being passed through.

Any ideas as to why the JSS is behaving in this manner?

Regards

Rhys Forrester
Queensland University of Technology

[milesleacy]

Hi Rhys,

How is the script grabbing the logged-in user's username?

As which user is the rest of the script being executed?

Scripts run via the Casper Suite run as root, and this may be why you're seeing behavior you didn't expect.

Does this clear up the issue?

--

Miles Leacy

Technical Training Manager

Mobile +1 347 277 7321

miles at jamfsoftware.com<mailto:miles at jamfsoftware.com>

....................................................................

JAMF Software

1011 Washington Ave. S

Suite 350

Minneapolis, MN 55415

....................................................................

Office: (612) 605-6625

Facsimile: (612) 332-9054

....................................................................

US Support: (612) 216-1296

UK Support +44.(0)20.3002.3907

AU Support +61.(0)2.8014.7469

....................................................................

http://www.jamfsoftware.com<http://www.jamfsoftware.com/>

[jarednichols]

You could instead do a sudo –u $username and run kinit. Perhaps that will work.

j
--
Jared F. Nichols
Desktop Engineer, Client Services
Information Services Department
MIT Lincoln Laboratory
244 Wood Street
Lexington, Massachusetts 02420
781.981.5436

[#4]

Unfortunately it hasn't. See below code. I'm really keen to know if others
can reproduce the problem because I'm still convinced there's something
I'm doing wrong.

Prior to the script being run; "klist: No credentials cache found while
getting the ccache principal"

#!/bin/bash
scriptuser=whoami
user=ls -l /dev/console | awk -F " " '{print $3}'
domain="QUT.EDU.AU"
logfile="/var/log/jamf.log"

/usr/bin/klist | grep -i krbtgt
kerberoscheck=$?

echo "DEBUGGING: Script is being executed by $scriptuser" >> $logfile
echo "DEBUGGING: Current logged in user is $user" >> $logfile
echo "DEBUGGING: KLIST output $kerberoscheck" >> $logfile

if [ $kerberoscheck -eq 0 ]
then echo "KERBEROS: Valid ticket exists for $user, exitingŠ" >>
$logfile exit 0
else echo "KERBEROS: No valid ticket exists for $user, displaying
Ticket ViewerŠ" >> $logfile echo |/usr/bin/kinit "$user"@"$domain" &
fi

exit 0

This is the log output;

Wed Apr 13 12:20:09 MACPACKAGER jamf[22388]: Running Script k5init.sh...
DEBUGGING: Script is being executed by root
DEBUGGING: Current logged in user is rhysf
DEBUGGING: KLIST output 1
KERBEROS: No valid ticket exists for rhysf, displaying Ticket ViewerŠ

Yet no Ticket Viewer. Ticket Viewer will ONLY display at this point if I
manually call the policy and/or run the script locally on the machine.

If I have a Kerberos ticket, the get the following in the log;

Wed Apr 13 12:34:20 MACPACKAGER jamf[25381]: Running Script k5init.sh...
DEBUGGING: Script is being executed by root
DEBUGGING: Current logged in user is rhysf
DEBUGGING: KLIST output 1
KERBEROS: No valid ticket exists for rhysf, displaying Ticket ViewerŠ

And again no Ticket Viewer. Ideas?

Regards

Rhys

[rmanly]

This may just be bad character encoding because I see Š in your email
a few times. But what are you trying to do with

echo |/usr/bin/kinit

?

# whoami
root

# kinit rmanly at GLENBROOK225.ORG
Please enter the password for rmanly at GLENBROOK225.ORG:

# echo |kinit rmanly at GLENBROOK225.ORG
kinit: Unable to acquire credentials for 'rmanly at GLENBROOK225.ORG':
Unable to display a user interface from this environment

Ryan M. Manly
Glenbrook High Schools

[rmanly]

p.s. This was ssh'd into a machine as the Casper management user and
then popped up to root to simulate what your script would be doing.

Ryan M. Manly
Glenbrook High Schools

[#7]

Hi Ryan,

Running "echo |kinit &" will display the KerberosAgent prompt (GUI). I
have no idea why or how, best guess is that because nothing is echoed the
window is displayed.

What I'm trying to accomplish is to not have to worry about people calling
the Helpdesk for printers or network drives due to a lack of a kerberos
ticket.

Helpdesk don't read doco, clients don't want to be educated. I figured
that checking if they have a valid ticket and prompting them is the lesser
of a few evils.

IF anyone knows of a better way?

Kind regards

Rhys

[golbiga]

Rhys,

There are more silent ways of making sure the user gets a ticket, you can edit /etc/authorization to make sure when they login it creates Kerberos TGT. You can also edit /etc/pam.d/screensaver so that the same occurs when the user puts in their screensaver password. You can even edit /System/Library/LaundAgents/com.apple.Kerberos.renew.plist to auto-renew the present ticket. From what I remember that plist has an option for auto-renew but doesn't work with the default command, something like /usr/bin/kinit -B, the -B needs to be replaced with -R. I'd definitely recommend testing first, but I've see this work in my environment.

Thanks
Allen

[rmanly]

What he said ;)

Instead of pushing a new /etc/authorization file (that I have had
overwritten with certain software updates) you can do this command.

#!/bin/bash

# allow creation of Kerberos TGT @ login per http://support.apple.com/kb/HT4100
/usr/libexec/PlistBuddy /etc/authorization -c "Add
rights:system.login.console:mechanisms: string
builtin:krb5store,privileged"

Ryan M. Manly
Glenbrook High Schools

[#10]

Good suggestions all round guys. Enforcing a screen saver and grabbing a
kerberos ticket is my plan B, but, it makes a few people around my neck of
the woods nervous.

That said, I've been successfully running the /etc/auth hack for about a
month or so now with no side effects.

We already do get kerberos tickets at login, the below script is for the
majority of our users who NEVER logout or restart their machines. I
regularly see uptimes of about a month when troubleshooting faults.

At this point I have to throw in the towel to my original problem
(extended leave tomorrow); but it remains a point of curiosity.

Kind regards

Rhys

[rmanly]

I have a feeling that I know what you are talking about re: nervous
people. I once set MCX to turn on screensavers after seeing student
accessible machines logged in with faculty credentials for hours.

The sheer volume of calls to the service desk was phenomenal.

If you can swing it politically perhaps you could check login time and then:

/System/Library/CoreServices/Menu
Extras/User.menu/Contents/Resources/CGSession -suspend

They won't lose their session (although they may be scared of this at
first) and they have to login again, I have not verified if this
refreshes Kerberos but if so it could be a way to go.

In fact I may do it myself...maybe...

;)

Good Luck,

Ryan M. Manly
Glenbrook High Schools