Bug 1267358 - [RFE] extra setting for krb5_map_user to require principal in .k5login
Summary: [RFE] extra setting for krb5_map_user to require principal in .k5login
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: sssd
Version: rawhide
Hardware: All
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Sumit Bose
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-09-29 19:07 UTC by Pat Riehecky
Modified: 2021-02-23 10:39 UTC (History)
10 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2021-02-23 10:39:12 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Pat Riehecky 2015-09-29 19:07:42 UTC
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/.k5login
3. configure sssd setting krb5_map_user = example:otheruser
4. enable ssh login with kerberos authentication
5. kinit someuser
6. ssh example@myhostname
7. login via GDM into an X session as example on myhostname with password of otheruser
8. kinit otheruser
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 09:27:10 UTC
Can you please test if setting:
access_provider = krb5 

helps here?

Comment 2 Jakub Hrozek 2015-10-07 12:12:35 UTC
ping, did the access_provider help?

Comment 3 Jakub Hrozek 2015-10-08 20:57:39 UTC
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 14:35:27 UTC
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 16:01:55 UTC
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 16:06:39 UTC
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 16:14:04 UTC
I am still interested in this feature.

Comment 8 Sumit Bose 2018-04-11 16:22:32 UTC
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 16:33:47 UTC
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 13:52:50 UTC
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

Comment 11 Sumit Bose 2021-02-23 10:39:12 UTC
Hi,

if I understood the use case correctly it should be solved with the help of sssd_krb5_localauth_plugin.so, hence I'll close this ticket. Feel free to reopen or open a new ticket if the use case is not covered.

bye,
Sumit


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