[OpenAFS-port-darwin] Tokens on login via ssh?
hays@ibiblio.org
hays@ibiblio.org
Thu, 04 May 2006 10:57:03 -0400
Thanks, comments below.
--On Wednesday, May 3, 2006 1:13 PM -0700 "Henry B. Hotz"
<hotz@jpl.nasa.gov> wrote:
> The following assumes you are logging in with a password. I have not
> tested any of this specifically, so be warned.
>
> Authorization Services doesn't have the concept of a "session" plug- in
> vs an "auth" plug-in, and I don't think the Kerberos loginLogout plug-in
> gets called if it's just a forwarded tgt (though I might be wrong on
> that and should test). If it does get called then that would be very
> nice.
>
> If Apple has fixed the "builtin:krb5login" method, then you should
> modify /etc/authorization to:
>
> <key>system.login.tty</key>
> <dict>
> <key>class</key>
> <string>evaluate-mechanisms</string>
> <key>mechanisms</key>
> <array>
> <string>push_hints_to_context</string>
> <string>authinternal</string>
> <string>builtin:krb5login,privileged</string>
> </array>
> <key>tries</key>
> <integer>1</integer>
> </dict>
>
>
> Then install Ragnar's Kerberos loginLogout plug-in. (Look earlier on
> the openafs-dev list.)
I'm using a hacked version of that which only calls aklog via a script
(since I couldn't get his to work against our cell, which is K4 only)
>
> If this doesn't work then you need to dl/install the kerberos
> Authorization Services example plug-in from Apple. Apply the following
> patch and make that "kerberos:login,privileged" in the above mod.
It works on 10.4.6 without the patch, sort of.
We've got an AD K5 realm named CS.UNC.EDU, and the AFS cell is also named
cs.unc.edu. There's no trust relationship that I know of between the K5 and
K4 systems. The AD realm has service records in DNS, the afs cell does not,
but I have the afs servers listed as K4 realms in the edu.mit.kerberos file.
When I get tickets via the kerberos gui app, I get a K5 TGT from AD, a K4
TGT from the afs servers. And the plugin gets called, aklog runs, and I get
an AFS token.
With builtin:krb5login,privileged set for system.login.done and
authenticate keys (and the system.login.tty, but this worked this way
before I added that), I get the same behaviour when I login via the
loginwindow or screensaver, etc.
And if I run a local terminal window, and kinit, I get the same behaviour:
gilgamesh:~ hays$ kinit
Please enter the password for hays@CS.UNC.EDU:
afslogscript.loginLogout: Attempted to run
/usr/local/bin/afslogscript.loginLogout.sh:
gilgamesh:~ hays$ klist
Kerberos 5 ticket cache: 'API:Initial default ccache'
Default principal: hays@CS.UNC.EDU
Valid Starting Expires Service Principal
05/04/06 10:43:48 05/04/06 20:43:48 krbtgt/CS.UNC.EDU@CS.UNC.EDU
renew until 05/11/06 10:43:48
Kerberos 4 ticket cache: 'Initial default ccache'
Default Principal: hays@CS.UNC.EDU
Issued Expires Service Principal
05/04/06 10:43:49 05/05/06 12:10:10 krbtgt.CS.UNC.EDU@CS.UNC.EDU
05/04/06 10:43:49 05/05/06 12:10:10 afs@CS.UNC.EDU
But, if I when I come in from a remote computer via ssh, I only get the K5
tickets from AD (and the cache location is different).
gilgamesh:~ hays$ klist
Kerberos 5 ticket cache: 'FILE:/tmp/krb5cc_502_T5CbvTHAdW'
Default principal: hays@CS.UNC.EDU
Valid Starting Expires Service Principal
05/04/06 10:48:16 05/04/06 20:48:17 krbtgt/CS.UNC.EDU@CS.UNC.EDU
renew until 05/05/06 10:48:16
klist: No Kerberos 4 tickets in credentials cache
This surprises me a bit, I would have expected the behaviour to be the
same, but then I'm easy to surprise since I don't really understand
kerberos.
In any case, looks like this would work fine in a modern k5 system with
10.4.6, but I'm still stuck at the moment.
I guess I'll trim the wick on the kerosene lamp and do some more poking
around--I hear there's a new fangled resource call the "web", maybe I can
get there in the buggy if my mule's not too tired.
Thanks again for the pointer, I'll test it against the k5 cell for main
campus later....
bil
--
________________________
bil hays
Network Manager
Computer Science, UNC CH