Red Hat Bugzilla – Bug 1267358
[RFE] extra setting for krb5_map_user to require principal in .k5login
Last modified: 2016-05-31 21:28:17 EDT
Description of problem:
When setting up krb5_map_user, I'd like to optionally set an additional constraint - the kerberos principal which maps to the UNIX username must be present in .k5login.
I'd expect this setting to be optional and off by default.
Version-Release number of selected component (if applicable): sssd 1.13.0
How reproducible: New feature request
Steps to Reproduce:
1. create user account example on myhostname
2. echo 'someuser@EXAMPLE.COM' > ~example/.k5login
3. configure sssd setting krb5_map_user = example:otheruser
4. enable ssh login with kerberos authentication
5. kinit someuser@EXAMPLE.COM
6. ssh example@myhostname
7. login via GDM into an X session as example on myhostname with password of otheruser
8. kinit otheruser@EXAMPLE.COM
9. ssh example@myhostname
10. user is prompted for password
Access is denied for otheruser's kerberos ticket, but not for password.
Authentication occurring over ssh via $HOME/.k5login has no method to ensure consistency with krb5_map_user.
Sys Admin ends up with odd questions from users which are somewhat difficult to debug.
Ultimately, I'm trying to ensure that the mapping put into place by root can be specifically disabled by the end user.
man sssd-krb5 (sssd v.1.13.0):
The list of mappings is given as a comma-separated list of pairs “username:primary” where “username” is a UNIX user name and “primary” is a user part of a kerberos principal. This mapping is used when user is authenticating using “auth_provider = krb5”.
krb5_realm = REALM
krb5_map_user = joe:juser,dick:richard
“joe” and “dick” are UNIX user names and “juser” and “richard” are primaries of kerberos principals. For user “joe” resp. “dick” SSSD will try to kinit as “juser@REALM” resp. “richard@REALM”.
Can you please test if setting:
access_provider = krb5
ping, did the access_provider help?
Reassigning to Sumit per his request, as this might be related to https://fedorahosted.org/sssd/ticket/2707
The change in access_provider does allow the listed login to work, but I worry that users trained to review .k5login for who has access to a given account will still have incomplete information.
A boolean (defaulting to off so nothing breaks) to force the username from krb5_map_user to appear in .k5login would ensure the end user can configure access to their account as though krb5_map_user were not in use.