Bug 1623624 - [RFE] SSSD, Group accounts, Kerberos, and prompt_principal
Summary: [RFE] SSSD, Group accounts, Kerberos, and prompt_principal
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: sssd
Version: 8.1
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: 8.1
Assignee: SSSD Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-08-29 18:41 UTC by Pat Riehecky
Modified: 2020-08-25 08:47 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-08-25 08:47:39 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)
Video demonstrating login process (837.40 KB, video/mp4)
2018-08-29 18:41 UTC, Pat Riehecky
no flags Details

Description Pat Riehecky 2018-08-29 18:41:36 UTC
Created attachment 1479559 [details]
Video demonstrating login process

Description of problem:
I'm looking for a way to emulate the existing group account login system we are using within SSSD.

I believe this is an RFE as the features do not exist currently within SSSD


Version-Release number of selected component (if applicable): sssd-2.0


How Reproducible: Always

Steps to Reproduce:
These are the things that I'd like to perform.
 1. Able to do local login with user "testuser" and a local password
 2. Able to do a local login/unlock screen for user "testuser" using the Kerberos Principal and Kerberos Password of a third party (Kerberos Principal must be in ~/.k5login)
 3. Able to do a local login/unlock screen for user "testuser" using the Kerberos Principal and Kerberos Password of a different person (Kerberos Principal must be in ~/.k5login)
 4. Able to do a local login/unlock screen for user "testuser" via PKinit of a smartcard for a Kerberos Principal of yet another different person (Kerberos Principal must be in ~/.k5login)

Removal of user from ~/.k5login revokes their login/unlock access.

Attached video demonstrates steps 1-3 on the alternate pam_krb5

Actual Results:
I find no clear way to configure SSSD to support Steps 2-4


Expected Results:
Able to setup these complex login methods (SSSD already supports #1).
After login the user receives their own kerberos ticket and not the ticket of a previous user.
Kerberos ticket is stored according to default_ccache_name (or setting from pam_env KRB5CCNAME) from krb5.conf/[libdefaults]


Additional Information:

Features provided by:
 https://www.eyrie.org/~eagle/software/pam-krb5/

Builds off of:
 https://docs.pagure.org/SSSD.sssd/design_pages/matching_and_mapping_certificates.html
 https://docs.pagure.org/SSSD.sssd/design_pages/smartcard_authentication_pkinit.html
 https://docs.pagure.org/SSSD.sssd/design_pages/prompting_for_multiple_authentication_types.html

Comment 5 Tomas Halman 2020-08-25 08:45:51 UTC
Upstream ticket:
https://github.com/SSSD/sssd/issues/5293


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