Subject: Re: Centralized User and Password Management
To: None <email@example.com>
From: Tillman Hodgson <firstname.lastname@example.org>
Date: 11/29/2004 09:55:15
On Mon, Nov 29, 2004 at 03:29:59PM +0100, Pavel Cahyna wrote:
> On Sun, 28 Nov 2004 22:52:47 +0000, Tillman Hodgson wrote:
> > This, in a
> > Kerberos environment, pam_krb5 is a stop-gap measure.
> > I like PAM. However, pam_krb5 doesn't do what you seem to think it does
> > ;-)
> Say there is a screen-locking program like xlock or xscreensaver,
> which requires a password to unlock the screen. Isn't pam_krb5 the right
> way in this situation to ensure that this password is consistent with the
> password used to login?
Yes, but that's because a screen locking application is one of the only
instances where single-sign-on and ticket caching is /not/ useful. Even
then it has the limitation that it has to be *my* password that's
entered ... what if I want to allow other principals to use my computer
(as they can via network shells and ~/.k5login)? Their password won't
unlock my screen. This isn't really hypothetical: with cross-realm
trusts, I may not even know my local credentials and thus I'd be
required to use my principal from another Kerberos realm.
With traditional network services, pam_krb5 isn't a great solution
because it doesn't understand tockets and that's why I called it a
stop-gap measure. It gets the job done, in it's own fashion, and so I've
used it to kick off a ->Kerberos migration where I knew that an odd
application or two would be retired in the near future anyway.
There is no reality -- only our own order imposed on everything.
- Basic Bene Gesserit Dictum