Central principal->user at host management?

[Jos Backus]

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?

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

-- 
Jos Backus
jos at catnook.com