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: NEW
Product: Fedora
Classification: Fedora
Component: sssd (Show other bugs)
rawhide
All Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Sumit Bose
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-29 15:07 EDT by Pat Riehecky
Modified: 2016-05-31 21:28 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
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.

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