[OpenAFS-port-darwin] aklog/afslog at console login and Mac OS 10.2

[David Botsch]

So, your trick sets up a pagsh for the windowserver (under which loginwindow
runs, etc). Now, what happens to that pagsh when the loginwindow decides to
become the user as which someone has logged in? You seemt to imply that
essentially a su user takes place?

Add to the above a kerberos login plugin similar to what was posted that just
does an aklog, and we have tokens now. But, is it too late as far as afs home
directories are concerned, here?

You also mention afs kernel extensions not being present during the first
login. Aren't these loaded when the startupscript starts afs as the Mac OS X
machine starts?

As much as I hate to say this, are there any replacements out there for
loginwindow? For instance, it would be great to just be able to pop in gdm,
have gdm auth with pam, then go into a normal OS X gui session.

On Tue, Oct 08, 2002 at 12:00:37AM +0200, Ragnar Sundblad wrote:
> 
> 
> --On den 7 oktober 2002 17:25 -0400 David Botsch <dwb7@ccmr.cornell.edu> 
> wrote:
> 
> > If we are authing against kerberos, which we can do, where does this fit
> > into that process? Before or after the auth takes place? Ie could one
> > just insert the "aklog" command after the pagsh command and thereby get
> > tokens (looks like I need to find some docs on what does what when here)?
> > As a later email said, we are shooting for home directories in afs space.
> 
> The windowserver is (re)started at the same time as loginwindow is
> putting up its login panel, I don't think you can use that trick
> for home directories in AFS (see previous posts) since there
> is no good way (as I know of at least) to get tokens early enough.
> 
> For now I'd recommend using Alexei Kosut's kerberos plugin
> which seems to be well written and people say it works,
> I haven't tried it myself yet.
> (Mine works too but is somewhat more complicated, not in
> my code but in that it also uses heimdal krb5 and the
> krbafs lib - I had trouble getting krbafs+MIT-krb4 to work
> when I worked on it, but now it seems to work fine. Oh well.).
> 
> We still need something to renew tickets.
> 
> At KTH we have previously been using the old loginwindow plugin
> api and done it all ourselves with heimdal and kthkrb, but think
> we should migrate to using the built in kerberos things now
> that it seems to be possible.
> We have an app to renew tickets that could be modified to
> monitor and renew Apple/MIT kerberos tickets instead.
> Are there any better suggestions for handling this?
> 
> (Our renew app works like this:
> We check out krb5 tickets that are valid for 24 hours and
> renewable for 2 weeks. When half the ticket lifetime has past
> the app starts trying to renew them - giving it 12 hours
> to succeed. When half the renewable time has past it puts
> up a password dialog, giving the user one week to see the
> dialog and get new tickets. The times choosen are, of course,
> completely arbitrary.
> The krb4 tgt and afs tokens are also monitored and new are
> checked out when half their lifetime has passed.)
> 
> /ragge
> 
> 

-- 
********************************
David William Botsch
Consultant/Advisor II
CCMR Computing Facility
dwb7@ccmr.cornell.edu
********************************