Re: Behavioural differences in Heimdal and MIT [was: Re: API differences between Heimdal and MIT]

["Henry B. Hotz" <hotz@jpl.nasa.gov>]

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  
does.

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  
> better
> 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  
>>> (LDAP,
>>> RDBMS etc.) for getting the information that is now contained in the
>>> .k5login file. That would allow completely avoiding file system  
>>> access
>>> 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  
>>> more
>>>    general but applications may need to implement more logic than  
>>> with
>>>    the first approach.
>>>
>>> Gabor
>>>
>>> -- 
>>>      ---------------------------------------------------------
>>>      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