Red Hat Bugzilla – Bug 1267358
[RFE] extra setting for krb5_map_user to require principal in .k5login
Last modified: 2018-04-12 09:52:50 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. Actual results: 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. Expected results: Ultimately, I'm trying to ensure that the mapping put into place by root can be specifically disabled by the end user. Additional info: man sssd-krb5 (sssd v.1.13.0): krb5_map_user (string) 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”. example: 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 helps here?
ping, did the access_provider help?
Reassigning to Sumit per his request, as this might be related to https://fedorahosted.org/sssd/ticket/2707
Hello, 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.
As the issue was solved by setting `access_provider = krb5` and we have an upstream ticket that is related to this I'd like to close this one as UPSTREAM. Sumit, Pat, Please, feel free to re-open this bugzilla in case you think it's needed.
After talking to Sumit on SSSD's IRC I've learned that: - We should check whether Pat is still interested in the fix; - We should get more details on how the feature should work; I'm moving this one back to "ASSIGNED" (and assigning it to Sumit).
I am still interested in this feature.
Hi, if I understood it correctly you are looking for an option to make SSSD check the .k5login file for the user of the principal given in the krb5_map_user options is available in the .k5login file. I wonder what should happen if the principal is not listed in .k5login, should access be denied completely, even with password? bye, Sumit
My expectation is for the following "workflow" SSSD sees kerberos ticket SSSD checks it against krb5_map_user SSSD checks for new "krb5_map_user_in_k5login = yes" SSSD checks to see if kerberos identity is in k5login If yes, done If no, SSSD prompts for password. Pat
This won't work because SSSD does not "see" the Kerberos ticket. The Kerberos or better GSSAPI authentication part is completely handled by sshd similar like ssh key based authentication. This includes checking if the principal from the Kerberos ticket is listed in .k5login or not. This leaves the oddness that although krb5_map_user maps a user name to principal ssh GSSAPI authentication will only work if the principal is listed in .k5login as well. Here adding: [plugins] localauth = { module = sssd:/usr/lib64/sssd/modules/sssd_krb5_localauth_plugin.so } to /etc/krb5.conf might help. After the first attempt where is password might still be requested, SSSD should have added the principal to it cache and for the second attempt sssd_krb5_localauth_plugin.so should be able to tell libkrb5 and sshd that the principal belongs to the given user. HTH bye, Sumit