On Fri, 2012-02-10 at 11:25 +0100, Sumit Bose wrote:
On Thu, Feb 09, 2012 at 08:45:26PM -0500, Jimmy Dorff wrote:
> On 2/9/12 5:02 PM, Stephen Gallagher wrote:
> >
> >If you set "access_provider = krb5", it should honor the .k5login as
you
> >expect.
> >
>
> [domain/default]
> ...
> id_provider = ldap
> auth_provider = krb5
> access_provider = krb5
> chpass_provider = krb5
> ...
>
> rpm versions:
> sssd-1.6.4-1.fc16.x86_64
> pam_krb5-2.3.13-1.fc16.x86_64
>
> If I use inotifywait ~test/.k5login, nothing is accessing
> ~test/.k5login when I attempt a console login as test user.
>
> Again, when username = kerberos name, everything works fine.
Currently sssd tries to determine the principal from an LDAP entry (see
ldap_user_principal config option) or if not found guesses it by adding
the realm to the user name. Using .k5login to determine the principal is
currently not implemented and I think it might not be the best idea to
use .k5login for this e.g. because .k5login can contain multiple names.
I think it would be better to have something like .k5principal to hold
the principal, although I have to think more carefully about the
security implication allowing the user to set his principal.
It's better to use libkrb5 mapping facility* to do arbitrary mappings,
then letting users do that, although .k5login files can be stored in non
user controlled locations.
In general we are in favor of deprecating .k5login where possible.
*see auth_to_local_names and auth_to_local in krb5.conf(5)
Simo.
--
Simo Sorce * Red Hat, Inc * New York