RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1402959 - [RFE] Universal Smart Card to Identity mapping
Summary: [RFE] Universal Smart Card to Identity mapping
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa
Version: 7.3
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: rc
: ---
Assignee: IPA Maintainers
QA Contact: Scott Poore
Aneta Šteflová Petrová
URL:
Whiteboard:
Depends On: 1430675
Blocks: 1399979 1411849 1411852 1411858 1430653
TreeView+ depends on / blocked
 
Reported: 2016-12-08 18:34 UTC by Petr Vobornik
Modified: 2017-08-01 09:44 UTC (History)
10 users (show)

Fixed In Version: ipa-4.5.0-5.el7
Doc Type: Enhancement
Doc Text:
IdM supports flexible mapping mechanisms for linking smart card certificates to user accounts Previously, the only way to find a user account corresponding to a certain smart card in Identity Management (IdM) was to provide the whole smart card certificate as a Base64-encoded DER string. With this update, it is possible to find a user account also by specifying attributes of the smart card certificates, not just the certificate string itself. For example, the administrator can now define matching and mapping rules to link smart card certificates issued by a certain certificate authority (CA) to a user account in IdM. For details, see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/smart-cards.html#sc-one-card-multiple-accounts-links.
Clone Of:
Environment:
Last Closed: 2017-08-01 09:44:33 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:2304 0 normal SHIPPED_LIVE ipa bug fix and enhancement update 2017-08-01 12:41:35 UTC

Description Petr Vobornik 2016-12-08 18:34:36 UTC
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/freeipa/ticket/6542

FreeIPA already supports Smart Card authentication: the user provides a Smart Card containing a certificate and the user lookup is performed with a binary match of the whole certificate (see User Certificates).

The goal is to extend this feature to support the following cases:

* the Smart Card contains multiple certificates. The administrator must be able to define Matching rules that will check which certificates are valid for authentication.
* the Smart Card contains multiple certificates that are valid for authentication. The user must be able to select the certificate he wants to use for login.
* the Certificate presented by the user is mapped to multiple accounts. The user must be able to disambiguate by providing a username.
* the mapping between a Certificate and a user account can be done either through binary match of the whole certificate or a match on custom certificate attributes (such as Subject + Issuer).

Comment 1 Martin Kosek 2016-12-16 11:25:30 UTC
Let me propose a more descriptive name.

Comment 2 Petr Vobornik 2017-01-20 17:47:31 UTC
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/6601

Comment 5 David Kupka 2017-03-08 15:35:04 UTC
Fixed upstream
master:
https://pagure.io/freeipa/c/ea34e17a46a60efb9c4dc81dab919a1639dec73b

Comment 6 Jan Cholasta 2017-03-13 07:59:01 UTC
Fixed upstream
master:
https://pagure.io/freeipa/c/0298ecf441ba38858d7909b8c3b4cc2b4c4e53c4

Comment 12 Scott Poore 2017-05-05 17:03:22 UTC
Ok, working on Verification and will have to post results in stages.

First stage here:

Tested with CAC cards with certmaprules and certmapdata successfully for GDM and SU.  With SSH we are limited to whole cert only.

Following scenarios tested for CAC cards

GDM and SU:

- card=[cac], certusers=[user1], testuser=user1 -> PASS

PASS - worked with whole cert and certmapdata

- card=[cac], certusers=[user1, user2], testuser=user1 -> PASS

PASS - worked with whole cert and certmapdata

- card=[cac], certusers=[user1, user2], testuser=user2 -> PASS

PASS - worked with whole cert and certmapdata

- card=[cac], certusers=[user1, user2], testuser=user3 -> FAIL

PASS - worked with whole cert and certmapdata

Comment 13 Scott Poore 2017-05-05 17:23:50 UTC
Also, testing basics with PKCS#15 card with IPA Certs:

[root@dhcp129-184 ~]# ipa certmaprule-find combined
-------------------------------------------
1 Certificate Identity Mapping Rule matched
-------------------------------------------
  Rule name: combined
  Mapping rule: (|(userCertificate;binary={cert!bin})(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500}))
  Matching rule: <ISSUER>CN=Certificate Authority,O=TESTRELM.TEST
  Enabled: TRUE
----------------------------
Number of entries returned 1
----------------------------


[root@dhcp129-184 ~]# ipa user-show scuser107
  User login: scuser107
  First name: f
  Last name: l
  Home directory: /home/scuser107
  Login shell: /bin/sh
  Principal name: scuser107
  Principal alias: scuser107
  Email address: scuser107
  UID: 576400135
  GID: 576400135
  Certificate mapping data: X509:<I>O=TESTRELM.TEST,CN=Certificate
                            Authority<S>O=TESTRELM.TEST,CN=scuser107
  Account disabled: False
  Password: True
  Member of groups: ipausers
  Kerberos keys available: True

[root@dhcp129-184 ~]# ipa user-show demosc2
  User login: demosc2
  First name: demosc2
  Last name: demosc2
  Home directory: /home/demosc2
  Login shell: /bin/sh
  Principal name: demosc2
  Principal alias: demosc2
  Email address: demosc2
  UID: 576400132
  GID: 576400132
  Certificate mapping data: X509:<I>O=TESTRELM.TEST,CN=Certificate
                            Authority<S>O=TESTRELM.TEST,CN=scuser107
  Account disabled: False
  Password: True
  Member of groups: ipausers
  Kerberos keys available: True

[root@dhcp129-184 ~]# su - demosc1 -c "su - demosc2 -c whoami"
PIN for scuser107 (OpenSC Card) for user demosc2
demosc2

[root@dhcp129-184 ~]# su - demosc1 -c "su - scuser107 -c whoami"
PIN for scuser107 (OpenSC Card) for user scuser107
scuser107

Comment 14 Scott Poore 2017-05-05 17:35:25 UTC
And testing PKCS#15 card with IPA certs revoked (reason=hold):

[root@auto-hv-02-guest08 ~]# ipa cert-revoke 0x64 --revocation-reason=6
  Revoked: True

Note these ask for Password, not PIN:

[root@dhcp129-184 ~]# su - demosc1 -c "su - scuser107 -c whoami"
Password: 
scuser107

[root@dhcp129-184 ~]# su - demosc1 -c "su - demosc2 -c whoami"
Password: 
demosc2

And with Revoke Hold Removed:

[root@dhcp129-184 ~]# ipa cert-remove-hold 0x64
  Unrevoked: True

These are asking for PIN as expected:

[root@dhcp129-184 ~]# su - demosc1 -c "su - scuser107 -c whoami"
PIN for scuser107 (OpenSC Card) for user scuser107
scuser107

[root@dhcp129-184 ~]# su - demosc1 -c "su - demosc2 -c whoami"
PIN for scuser107 (OpenSC Card) for user demosc2
demosc2

And with OCSP checking disabled on the client, we are able to still authenticate with the PIN as expected:

[root@dhcp129-184 ~]# grep no_ocsp /etc/sssd/sssd.conf
certificate_verification = no_ocsp

[root@dhcp129-184 ~]# !systemctl
systemctl stop sssd; rm -rf /var/lib/sss/{db,mc}/*; systemctl start sssd

[root@dhcp129-184 ~]# ipa cert-revoke 0x64 --revocation-reason=6
  Revoked: True

[root@dhcp129-184 ~]# su - demosc1 -c "su - scuser107 -c whoami"
PIN for scuser107 (OpenSC Card) for user scuser107
scuser107

[root@dhcp129-184 ~]# su - demosc1 -c "su - demosc2 -c whoami"
PIN for scuser107 (OpenSC Card) for user demosc2
demosc2

Comment 17 Scott Poore 2017-05-19 19:49:36 UTC
Verified.

Note that the mixed IPA and AD User scenario still needs to be resolved in this bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1445445

Version ::

ipa-server-4.5.0-11.el7.x86_64

Results :: 

See comments above:

comment #12
comment #13
comment #14

Also, 


########## SSH Tests with Certificate for multiple users #################
########## SSH requires whole certificate ################################

[root@dhcp129-184 ~]# ipa user-add-cert demosc1 --certificate=$(cat /root/testing/demosc1_cert1.crt|sed '/CERT/d'|tr -d '\r\n')
------------------------------------
Added certificates to user "demosc1"
------------------------------------
  User login: demosc1
  Certificate: MII...


[root@dhcp129-184 ~]# ipa user-add-cert demosc2 --certificate=$(cat /root/testing/demosc1_cert1.crt|sed '/CERT/d'|tr -d '\r\n')
------------------------------------
Added certificates to user "demosc2"
------------------------------------
  User login: demosc2
  Certificate: MII...

[root@dhcp129-184 ~]# ipa certmap-match /root/testing/demosc1_cert1.crt
---------------
2 users matched
---------------
  Domain: TESTRELM.TEST
  User logins: demosc1, demosc2
----------------------------
Number of entries returned 1
----------------------------

[root@dhcp129-184 ~]# ssh -I /usr/lib64/opensc-pkcs11.so -l demosc1 $(hostname) whoamiEnter PIN for 'demosc1 (OpenSC Card)': 
demosc1

[root@dhcp129-184 ~]# ssh -I /usr/lib64/opensc-pkcs11.so -l demosc2 $(hostname) whoami
Enter PIN for 'demosc1 (OpenSC Card)': 
demosc2

[root@dhcp129-184 ~]# ssh -I /usr/lib64/opensc-pkcs11.so -l demosc3 $(hostname) whoami
no such identity: /root/.ssh/id_ed25519: No such file or directory
Password: 
demosc3

########## SSH Tests with Revoked Certificate #################

[root@dhcp129-184 ~]# ipa cert-revoke 0x65 --revocation-reason=6
  Revoked: True

[root@dhcp129-184 ~]# systemctl stop sssd; rm -rf /var/lib/sss/{db,mc}/*; systemctl start sssd

[root@dhcp129-184 ~]# ssh -I /usr/lib64/opensc-pkcs11.so -l demosc1 $(hostname) whoamino such identity: /root/.ssh/id_ed25519: No such file or directory
Password: 
demosc1

[root@dhcp129-184 ~]# ssh -I /usr/lib64/opensc-pkcs11.so -l demosc2 $(hostname) whoami
no such identity: /root/.ssh/id_ed25519: No such file or directory
Password: 
demosc2


########## SSH Tests with Revoke Hold Removed #################

[root@dhcp129-184 ~]# ipa cert-remove-hold 0x65
  Unrevoked: True

[root@dhcp129-184 ~]# systemctl stop sssd; rm -rf /var/lib/sss/{db,mc}/*; systemctl start sssd

[root@dhcp129-184 ~]# ssh -I /usr/lib64/opensc-pkcs11.so -l demosc1 $(hostname) whoami
Enter PIN for 'demosc1 (OpenSC Card)': 
demosc1

[root@dhcp129-184 ~]# ssh -I /usr/lib64/opensc-pkcs11.so -l demosc2 $(hostname) whoami
Enter PIN for 'demosc1 (OpenSC Card)': 
demosc2

#### And other test results summarized


#####################################################################
# WebUI Test cases from CLIENT with prompt=True
#####################################################################

############# single-user tests ######################################
#
1. card=[1 valid], certusers=[user1], testuser=None -> PASS

PASS

2. card=[1 valid], certusers=[user1], testuser=user1 -> PASS

PASS

3. card=[1 valid], certusers=[user1], testuser=user2 -> FAIL

PASS (Failed as expected)

############# multi-user tests ######################################
# showing sssd and ipa file both users for cert:
# [root@auto-hv-02-guest08 testing]# dbus-send --system --print-reply --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe/Users org.freedesktop.sssd.infopipe.Users.ListByCertificate string:"$(cat /root/testing/demosc1_cert1.crt)" uint32:10
# method return sender=:1.786 -> dest=:1.787 reply_serial=2
#    array [
#       object path "/org/freedesktop/sssd/infopipe/Users/testrelm_2etest/576400131"
#       object path "/org/freedesktop/sssd/infopipe/Users/testrelm_2etest/576400132"
#    ]
# 
# [root@auto-hv-02-guest08 testing]# ipa certmap-match demosc1_cert1.crt
# ---------------
# 2 users matched
# ---------------
#   Domain: TESTRELM.TEST
#   User logins: demosc1, demosc2
# ----------------------------
# Number of entries returned 1
# ----------------------------

4. card=[1 valid], certusers=[user1, user2], testuser=None -> FAIL

PASS (Failed as expected)

5. card=[1 valid], certusers=[user1, user2], testuser=user1 -> PASS

PASS

6. card=[1 valid], certusers=[user1, user2], testuser=user2 -> PASS

PASS

7. card=[1 valid], certusers=[user1, user2], testuser=user3 -> FAIL
 
PASS (Failed as expected)

################## promptusername=False
#
#
# [root@auto-hv-02-guest08 testing]# ipa certmapconfig-mod --promptusername=False
#   Prompt for the username: FALSE
#
# [root@auto-hv-02-guest08 testing]# systemctl stop sssd; rm -rf /var/lib/sss/{db,mc}/*; systemctl start sssd
#
# [root@auto-hv-02-guest08 testing]# ipa user-remove-certmapdata demosc2 --certificate=$(cat demosc1_cert1.crt|sed '/CERT/d'| tr -d '\r\n')
# ------------------------------------------------
# Removed certificate mappings from user "demosc2"
# ------------------------------------------------
#   User login: demosc2
#
#


######### single-user tests
#
1. card=[1 valid], certusers=[user1], testuser=None -> PASS

PASS

2. card=[1 valid], certusers=[user1], testuser=user1 -> PASS

PASS

3. card=[1 valid], certusers=[user1], testuser=user2 -> FAIL

PASS (Failed as expected)

######### multi-user tests
#
4. card=[1 valid], certusers=[user1, user2], testuser=None -> FAIL

PASS (Failed as expected but did not show error...still didn't login)

5. card=[1 valid], certusers=[user1, user2], testuser=user1 -> PASS

PASS

6. card=[1 valid], certusers=[user1, user2], testuser=user2 -> PASS

PASS

7. card=[1 valid], certusers=[user1, user2], testuser=user3 -> FAIL

PASS (Failed as expected)


#############################################################
# ipa generated cert 
#############################################################

- card=[1 valid], certusers=[aduser1], testuser=aduser1 -> PASS

GDM: PASS
SU:  PASS
SSH: PASS

- card=[1 valid], certusers=[user1, aduser1], testuser=user1 -> PASS

FAIL: https://bugzilla.redhat.com/show_bug.cgi?id=1445445

- card=[1 valid], certusers=[user1, aduser1], testuser=aduser1 -> PASS

FAIL: https://bugzilla.redhat.com/show_bug.cgi?id=1445445

- card=[1 valid], certusers=[user1, aduser1], testuser=aduser2 -> FAIL

CANNOT TEST: https://bugzilla.redhat.com/show_bug.cgi?id=1445445

- card=[1 valid], certusers=[aduser1, aduser2], testuser=aduser1 -> PASS

GDM: PASS
SU:  PASS
SSH: PASS

- card=[1 valid], certusers=[aduser1, aduser2], testuser=aduser2 -> PASS

GDM: PASS
SU:  PASS
SSH: PASS

- card=[1 valid], certusers=[aduser1, aduser2], testuser=aduser3 -> FAIL

GDM: PASS (Failed as expected)
SU:  PASS (Failed as expected)
SSH: PASS (Failed as expected)

Comment 18 Martin Kosek 2017-05-26 09:39:47 UTC
Please note that Red Hat officially released public RHEL-7.4 Beta this week, as announced here:
https://www.redhat.com/en/about/blog/red-hat-enterprise-linux-74-beta-now-available

The new RHEL-7.4 release includes a lot of new IdM functionality, including this RFE. Highlights can be found in RHEL-7.4 Release Notes, especially in the Authentication & Interoperability chapter:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html/7.4_Release_Notes/new_features_authentication_and_interoperability.html

IdM Engineering team would like to encourage everyone interested in this new functionality (and especially customers or community members requesting it) to try Beta and provide us with your feedback!

Comment 19 errata-xmlrpc 2017-08-01 09:44:33 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2304


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