Bug 1267358 - [RFE] extra setting for krb5_map_user to require principal in .k5login
[RFE] extra setting for krb5_map_user to require principal in .k5login
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: sssd (Show other bugs)
rawhide
All Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Sumit Bose
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-29 15:07 EDT by Pat Riehecky
Modified: 2018-04-12 09:52 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-04-11 12:01:55 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Pat Riehecky 2015-09-29 15:07:42 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”.
Comment 1 Jakub Hrozek 2015-09-30 05:27:10 EDT
Can you please test if setting:
access_provider = krb5 

helps here?
Comment 2 Jakub Hrozek 2015-10-07 08:12:35 EDT
ping, did the access_provider help?
Comment 3 Jakub Hrozek 2015-10-08 16:57:39 EDT
Reassigning to Sumit per his request, as this might be related to https://fedorahosted.org/sssd/ticket/2707
Comment 4 Pat Riehecky 2015-11-30 09:35:27 EST
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.
Comment 5 Fabiano Fidêncio 2018-04-11 12:01:55 EDT
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.
Comment 6 Fabiano Fidêncio 2018-04-11 12:06:39 EDT
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).
Comment 7 Pat Riehecky 2018-04-11 12:14:04 EDT
I am still interested in this feature.
Comment 8 Sumit Bose 2018-04-11 12:22:32 EDT
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
Comment 9 Pat Riehecky 2018-04-11 12:33:47 EDT
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
Comment 10 Sumit Bose 2018-04-12 09:52:50 EDT
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

Note You need to log in before you can comment on or make changes to this bug.