Learn more about these different git repos.
Other Git URLs
Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1340711
Please note that this Bug is private and may not be accessible as it contains confidential Red Hat customer information.
[RFE] Use one smartcard and certificate for authentication to distinct logon accounts This is a general use case that enables the ability to use the same PIV (or other) credential (a hardware key based PKI authenticator) to strongly authenticate (two-factor authentication) multiple, distinct, user accounts on the same workstation, or server, or Kerberos realm. The princpal effeciency is that a single strong credential issued to individuals may be used to authenticate to various users contexts, in other words user accounts, where the user contexts may be distinct and isolated both laterally and in managing least elevated priviledge and priviledge isolation within an individuals assigned user accounts. The princpal benifit is the avoidance of issuing multiple PIV, Derived PIV, or other two-factor PKI credentials for the sole purpose of managing least elevated priviledge and priviledge isolation within an individuals assigned user accounts. The implemenation for this use case must be RFC 4556 "Public Key Crptography for Initial Authentication in Kerberos (PKINIT)" conformant. The new feature is to permit the user to select or enter an altertnate User Principal Name (UPN) for a Kerberos PKINIT Ticket Granting Ticket (TGT), among an authorized list of UPNs for the user, that securely binds the users PKI certificate in an authentication to that specific user account.
Fields changed
blockedby: => blocking: => changelog: => coverity: => design: => design_review: => 0 feature_milestone: => fedora_test_page: => mark: no => 0 milestone: NEEDS_TRIAGE => SSSD 1.16 beta review: True => 0 selected: => testsupdated: => 0
So is this the requirement to be able to select which account you want to login if you use the same cert for more than one account? Is the logic something like: user uses the card, server detects that there are more than one accounts mapped to this cert and returns the list, user chooses which account to use. Is this the expected workflow or something else? Or it is expected that user specifies the account he wants to login explicitly first?
I will leave the same comment in BZ.
I guess the username would have to be provided in one way or other, otherwise we can't know which user to map the cert to.
Replying to [comment:3 jhrozek]:
This is understood. The question is more bout the user experience expectations. Is it is expected to always ask for name or to ask for name only when there is ambiguity? The answer to this questions will dictate the technical solution. I am just trying to clarify the requirement.
I haven't really thought about the prompting, but PAM has the ability to prompt for username as well via PAM_ECHO_ON.
cc: => sbose
Most of the login processes ask for a name independently of PAM anyway before calling pam_authenticate, mainly because one of the arguments to pam_start() is the user name.
Currently I only know of gdm which can run in a mode where it detects that a Smartcard is inserted and hands over control directly to PAM. SSSD currently expects that the lookup by certificate returns only one user in this case. Nevertheless it would be possible to enhance SSSD to instruct pam_sss to prompt for a user name in this case as well.
Right. The question whether it will always prompt or only in the case where it detected a duplicate and needs to disambiguate.
milestone: SSSD Future releases (no date set yet) => SSSD 1.15.1 owner: somebody => sbose
priority: major => critical
Metadata Update from @jhrozek: - Issue assigned to sbose - Issue set to the milestone: SSSD 1.15.1
Since we are releasing 1.15.1 today, I'm moving all unfinished tickets from 1.15.1 to 1.15.2
Metadata Update from @jhrozek: - Custom field design_review reset - Custom field mark reset - Custom field patch reset - Custom field review reset - Custom field sensitive reset - Custom field testsupdated reset - Issue close_status updated to: None
Metadata Update from @jhrozek: - Custom field design_review reset - Custom field mark reset - Custom field patch reset - Custom field review reset - Custom field sensitive reset - Custom field testsupdated reset - Issue set to the milestone: SSSD 1.15.2 (was: SSSD 1.15.1)
master:
Metadata Update from @lslebodn: - Custom field design_review reset - Custom field mark reset - Custom field patch reset - Custom field review reset - Custom field sensitive reset - Custom field testsupdated reset
Metadata Update from @lslebodn: - Custom field design_review reset - Custom field mark reset - Custom field patch reset - Custom field review reset - Custom field sensitive reset - Custom field testsupdated reset - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Metadata Update from @lslebodn: - Custom field design_review reset - Custom field mark reset - Custom field patch reset - Custom field review reset - Custom field sensitive reset - Custom field testsupdated reset - Issue status updated to: Open (was: Closed)
Reopened; because it is still not fixed.
Metadata Update from @jhrozek: - Custom field design_review reset - Custom field mark reset - Custom field patch reset - Custom field review reset - Custom field sensitive reset - Custom field testsupdated reset - Issue set to the milestone: SSSD 1.15.3 (was: SSSD 1.15.2)
The certmap library patches: * c44728a * 49f8ec8 * b341ee5 * 81c564a * 70c0648 * 3994e87 * 31a6661 * db36dca * 8b7548f * 843bc50
Metadata Update from @jhrozek: - Custom field design_review reset - Custom field mark reset - Custom field patch reset - Custom field review reset - Custom field sensitive reset - Custom field testsupdated reset
python list method * a0b1bfa * 440797c
Metadata Update from @jhrozek: - Custom field design_review reset - Custom field mark reset - Custom field patch reset - Custom field review reset - Custom field sensitive reset - Custom field testsupdated reset - Issue status updated to: Closed (was: Open)
Additional fixes: * 8284375 * 2cf7bec * 415d931
Metadata Update from @jhrozek: - Custom field design_review reset (from false) - Custom field mark reset (from false) - Custom field patch reset (from false) - Custom field review reset (from false) - Custom field sensitive reset (from false) - Custom field testsupdated reset (from false) - Issue close_status updated to: Fixed
and openssl patch
Metadata Update from @lslebodn: - Custom field design_review reset (from false) - Custom field mark reset (from false) - Custom field patch reset (from false) - Custom field review reset (from false) - Custom field sensitive reset (from false) - Custom field testsupdated reset (from false)
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/4083
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.