Central principal->user at host management?

Douglas E. Engert deengert at anl.gov
Wed Oct 3 07:44:49 EST 2007



Jos Backus wrote:
> On Tue, Oct 02, 2007 at 08:45:33AM -0500, Douglas E. Engert wrote:
>> Jos Backus wrote:
>>> On Mon, Oct 01, 2007 at 11:22:57AM -0500, Douglas E. Engert wrote:
>>>> In addition to the ~.k5login, sounds like what you would like would be a
>>>> krb5.conf  [realm] auth_to_local=LDAP:.... option. But I don't know
>>>> if one exists. (Would be nice if it did...)  There is a auth_to_local=DB:...
>>>> option that uses a local database.
>>> Using a local db would be tantamount to managing .k5login files so that
>>> doesn't really help. 
>> The main differences are the ~/.k5login is under control of the user,
>> and may be located in a NFS shared home directory. The db is under control
>> of the admin.
>  
> Sure. But it's still something to be managed on the machine itself, rather
> than centrally.
> 
>>> Regarding LDAP support, one consideration is that sshd
>>> would have to be able to authenticate the LDAP server (using Kerberos) to
>>> prevent spoofing. 
>> I think you said you where using LDAP. This situation is no different from
>> using nss-ldap, to replace the passwd and group files. The libnss-ldap has
>> to authenticate the ldap server to avoid spoofing. The k5login could be just
>> another nisMap with nisObjects table much like autofs can use ldap.
>  
> We are using nss-ldap at present for that puprpose. And frankly I'm not that
> worried about the spoofing part since all this is on an internal network.
> 
> So are you saying I could stick .k5login data in LDAP and thus not have to
> manage local .k5login files? That would be a reasonable soltion. Any pointers
> on how to set this up?
> 

But the code has not been written as far as I know.
I would add it to the krb5 libs, and add another auth_to_local= option
for LDAP...

This should be moved to the kerberos at mit.edu list...


>> This adds yet more complexity.
>>
>> The complexity should be in the krb5 libs under the krb5_kuserok routine,
>> so sshd has no changes. But the code has not been written as far as I know.
>  
> Agreed.
> 
> Thanks for your response, Douglas.
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444


More information about the openssh-unix-dev mailing list