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

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

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.

* 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?

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