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