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 _______________________________________________ sssd-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/sssd-devel
