[OpenAFS-port-darwin] Tokens on login via ssh?
Henry B. Hotz
hotz@jpl.nasa.gov
Thu, 4 May 2006 10:31:39 -0700
On May 4, 2006, at 7:57 AM, hays@ibiblio.org wrote:
>
> 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.
Ah, yes. Jeffrey Altman set up a mailing list for us to discuss AD
renaming to remove this conflict. We needed to upgrade from W2K to
W2K3 first, and we won't finish that for another couple of weeks.
(You can't tell JPL.NASA.GOV to trust JPL.NASA.GOV and have any sane
code understand that they aren't the same to begin with. ;-)
> 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 behavior when I login via
> the loginwindow or screensaver, etc.
>
> And if I run a local terminal window, and kinit, I get the same
> behavior:
> 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 behavior to be
> the same, but then I'm easy to surprise since I don't really
> understand kerberos.
Interesting.
First question: Do you type a password when you ssh in? In other
words, is that tgt a forwarded one or a locally requested one?
Second, is your script using programs linked against Heimdal? If so
you can put
[libdefaults]
default_cc_name = API:
in your krb5.conf and probably force it to use the in-memory ccache.
As long as KRB5CCACHE (or whatever it is) is set properly it
shouldn't matter much. What you really care most about is that the
ccache be different for each ssh session and from the console.
Actually, it looks like that ccache name is being generated by ssh
itself, so that trumps what I just said.
> 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
------------------------------------------------------------------------
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu