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

["Douglas E. Engert" <deengert@anl.gov>]

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.

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

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.

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