[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Behavioural differences in Heimdal and MIT [was: Re: API differences between Heimdal and MIT]
On Feb 15, 2006, at 11:02 AM, Douglas E. Engert wrote:
> Henry B. Hotz wrote:
>> For the systems that support PAM I'm guessing we should have a
>> no-.k5login pam_krb5 (required*) followed by a pam_ldap (or
>> pam_dbm, or whatever) that only does authorization, not password
>> checking (required or sufficient). pam_afs *should* only be a
>> session module to get the token and set the PAG, but that may
>> only work on Solaris.
> There is a pam_afs2 that uses the newly obtained or forwarded
> Kerberos 5
> ticket of the user to get the token, and set the PAG.
Yes, I know. I was just trying to be generic. No slight was
intended, and anyone interested should google for pam_afs2.
That pam module ought to be part of the OpenAFS distribution and
built when aklog is built. I wish you luck trying to get them to
take it on.
My personal opinion, as I said at the conference we were both at, is
that the aklog program ought to be a library like the obsolete kafs
lib that MIT distributes, or Heimdal's krbafs. It ought to be in the
OpenAFS distribution, and it ought to be used by all the various OS-
specific things that need to do that function as part of login: a
pam module on Solaris and Linux, a kinit plugin on MacOS, and who-
knows-what-else on any other OS. Oh, and you use it to build an
aklog program like the current one as well.
>> * A correctly configured ssh will get a forwarded tgt before you
>> get to the PAM chain. Anyone know of any pam_ldap's that can be
>> told to just do authorization, maybe even to use a kerberized
>> bind to do the lookups?
> The kerberized bind should be binding using the host's credentials,
> not the
> yet-to-be-authorized user's credentials.
Authorization gets more into local policy issues than Kerberos itself
Hypothetically you might get a cross-realm ticket and you want to
allow/disallow login based on whether the ldap server allows a
kerberized bind. (The LDAP server knows who is/isn't allowed in from
the specific foreign realms.) Alternatively, hypothetically you may
not want to give the host any special LDAP credentials and you need
information from LDAP that isn't publicly available.
> And providing alternatives to the .k5login for mapping principals
> to accounts
> sounds like a good thing to have, as it could give the local admin
> control over the use of accounts.
I think we agree that we could use some more alternatives, and LDAP
seems like one that almost could work now.
Off Topic: Anyone used mod_auth_kerb in combination with
mod_authnz_ldap in Apache 2.2 yet? There was a presentation on this
at the last ApacheCon, but the person who saw it said it was all
theory and smoke and mirrors. No real example config.
>> On Feb 15, 2006, at 2:52 AM, Gabor Gombas wrote:
>>> On Tue, Feb 14, 2006 at 03:29:57PM -0800, Henry B. Hotz wrote:
>>>> The AFS token-not-yet-available issues are just another example of
>>>> the same old problem we've always had with getting OS's to deal
>>>> properly with AFS.
>>> Maybe the proper solution would be to allow different backends
>>> RDBMS etc.) for getting the information that is now contained in the
>>> .k5login file. That would allow completely avoiding file system
>>> until the authentication/authorization process has finished.
>>> I see two possible approaches:
>>> 1. Provide a callback that can be used to replace just the
>>> reading of
>>> the .k5login file, leaving the content parsing/decision making in
>>> Heimdal, or
>>> 2. Moving the decision making completely to the callback. This is
>>> general but applications may need to implement more logic than
>>> the first approach.
>>> MTA SZTAKI Computer and Automation Research Institute
>>> Hungarian Academy of Sciences
> Douglas E. Engert <DEEngert@anl.gov>
> Argonne National Laboratory
> 9700 South Cass Avenue
> Argonne, Illinois 60439
> (630) 252-5444