Bug 1378943 - [RFE] Allow authconfig to configure Smartcard authentication with SSSD
Summary: [RFE] Allow authconfig to configure Smartcard authentication with SSSD
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: authconfig
Version: 7.3
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: rc
: ---
Assignee: Pavel Březina
QA Contact: Roshni
Filip Hanzelka
URL:
Whiteboard:
Keywords: FutureFeature
Depends On:
Blocks: 1399979
TreeView+ depends on / blocked
 
Reported: 2016-09-23 15:12 UTC by Roshni
Modified: 2017-08-01 08:39 UTC (History)
7 users (show)

(edit)
"authconfig" can enable *SSSD* to authenticate users with smart cards

This new feature allows the "authconfig" command to configure the System Security Services Daemon (SSSD) to authenticate users with smart cards, for example:

    # authconfig --enablesssd --enablesssdauth --enablesmartcard --smartcardmodule=sssd --smartcardaction=0 --updateall

With this update, smart card authentication can now be performed on systems where "pam_pkcs11" is not installed. However, if "pam_pkcs11" is installed, the "--smartcardmodule=sssd" option is ignored. Instead, the first pkcs11_module defined in the `/etc/pam_pkcs11/pam_pkcs11.conf` is used as default.

For details, see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/auth-idm-client-sc.html.
Clone Of:
(edit)
Last Closed: 2017-08-01 07:27:56 UTC


Attachments (Terms of Use)
Add SSSD Smartcard support to authinfo.py (5.55 KB, patch)
2016-12-12 17:00 UTC, Sumit Bose
no flags Details | Diff
Show a warning if --enablerequiresmartcard is used with --smartcardmodule=sssd (587 bytes, patch)
2016-12-12 17:03 UTC, Sumit Bose
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:2285 normal SHIPPED_LIVE Moderate: authconfig security, bug fix, and enhancement update 2017-08-01 11:26:21 UTC

Description Roshni 2016-09-23 15:12:37 UTC
Description of problem:
Allow authconfig to configure Smartcard authentication with SSSD

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


How reproducible:


Steps to Reproduce:
Solution for some of the issues seen during smartcard authentication using sssd. For example

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

Actual results:


Expected results:


Additional info:

Comment 8 Roshni 2016-12-01 21:34:23 UTC
Patrick,

The following were a few issues we noticed on RHEL 7.3 when using sssd for smartcard authentication. Sumit said that there would some enhancements required from the authconfig side for these bugs to work without workarounds.

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

I will let you know if there are any other testcases in this area.

Comment 9 Roshni 2016-12-05 15:05:54 UTC
Patrick,

Does comment 8 give enough information that you needed for this bug?

Comment 11 Roshni 2016-12-09 16:49:27 UTC
Patrick,

I will be able to setup a test environment whenever you need. I am CC'ing Sumit as well if he can provide any input from the development perspective.

Comment 12 Sumit Bose 2016-12-12 17:00 UTC
Created attachment 1230854 [details]
Add SSSD Smartcard support to authinfo.py

With this patch SSSD Smartcard support can be enabled if --smartcardmodule is used with the value 'sssd' and the pam_pkcs11 package is not installed. E.g.

  authconfig --enablesssd --enablesssdauth --enablesmartcard --smartcardmodule=sssd --smartcardaction=0 --updateall

If pam_pkcs11 is installed the --smartcardmodule=sssd is ignored and the first pkcs11_module defined in /etc/pam_pkcs11/pam_pkcs11.conf is used as a default, as it is the current default behavior of authconfig.

Comment 13 Sumit Bose 2016-12-12 17:03 UTC
Created attachment 1230855 [details]
Show a warning if --enablerequiresmartcard is used with --smartcardmodule=sssd

Currently SSSD does not support Smartcard-only authentication. With this patch a warning is shown when using  --enablerequiresmartcard and --smartcardmodule=sssd together.

Comment 14 Sumit Bose 2016-12-12 17:08:41 UTC
Patrik,

I think from your side only regression-testing is needed.

If one of the SSSD specific changes will not work as expected Roshni would recognize them when she is not doing the currently required manual changes to the config file but just calls authconfig with the needed options.

HTH

bye,
Sumit

Comment 15 Patrik Kis 2016-12-13 08:14:32 UTC
Thank you Sumit for the sum up.

Comment 20 Roshni 2017-04-28 16:28:18 UTC
Yes Dalibor I can do that.

Sumit,

How should I test this? Not making any changes to sssd.conf and enabling smartcard login using authconfig only?

Comment 21 Sumit Bose 2017-04-28 17:06:36 UTC
Yes, just let authconfig to the work.

Comment 22 Scott Poore 2017-05-02 16:22:03 UTC
Verifying this with Roshni and Sumit.  I ran this:

[root@dhcp129-184 ~]# authconfig --enablesssd --enablesssdauth --enablesmartcard --smartcardmodule=sssd --smartcardaction=0 --updateall
[root@dhcp129-184 ~]# 
[root@dhcp129-184 ~]# diff /etc/sssd/sssd.conf ~/sssd.conf.oldone
26d25
< pam_cert_auth = True
[root@dhcp129-184 ~]# diff -r /etc/pam.d /etc/pam.backup_beforebugtest
diff -r /etc/pam.d/smartcard-auth /etc/pam.backup_beforebugtest/smartcard-auth
5a6
> auth        [success=done ignore=ignore default=die] pam_pkcs11.so nodebug wait_for_card
13a15
> password    required      pam_pkcs11.so
diff -r /etc/pam.d/smartcard-auth-ac /etc/pam.backup_beforebugtest/smartcard-auth-ac
5a6
> auth        [success=done ignore=ignore default=die] pam_pkcs11.so nodebug wait_for_card
13a15
> password    required      pam_pkcs11.so

Then Sumit found krb5kdc needed a restart on IPA server.  After that. gdm login with pin worked.

Comment 23 Roshni 2017-05-02 18:15:08 UTC
Some findings after additional testing :

Screen lock prompts for smartcard pin and accepts correct pin

The following issues were noticed:

1. [root@dhcp129-184 ~]# cat /etc/dconf/db/distro.d/10-authconfig

# Generated by authconfig on 2017/05/02 09:53:49

[org/gnome/login-screen]
enable-fingerprint-authentication=false

[org/gnome/settings-daemon/peripherals/smartcard]
removal-action='lock-screen'

but smartcard removal did not lock the screen.

2. Screen locked, smartcard removed - does not prompt to insert the smartcard. When smartcard is re-inserted, no prompt for smart card pin.

Comment 24 Sumit Bose 2017-05-03 09:45:45 UTC
I can see 

gnome-shell[9924]: JS ERROR: could not get remote objects for service org.gnome.SettingsDaemon.Smartcard path /org/gnome/SettingsDaemon/Smartcard: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SettingsDaemon.Smartcard was not provided by any .service files

in the logs. Looks like the settings are not properly picked up by gdm. Ping me so that we can debug this together.

Comment 25 Roshni 2017-05-03 20:33:17 UTC
Sumit, 

Using smartcard reader directly connected to the host, smartcard removal caused screen lock and re-insertion prompted for pin. Now the only question I have is there was no message to insert the card on the locked screen when the smartcard was not inserted.

Comment 26 Sumit Bose 2017-05-05 09:48:25 UTC
It turned out that the missing message to insert the card is due to some changes in gdm https://bugzilla.redhat.com/show_bug.cgi?id=1448209.

Since the feature is not related to authconfig and is covered by a different ticket I think this ticket can now be marked as Verified.

Comment 27 Roshni 2017-05-05 13:14:49 UTC
[root@dhcp129-184 ~]# rpm -qi authconfig
Name        : authconfig
Version     : 6.2.8
Release     : 23.el7
Architecture: x86_64
Install Date: Wed 03 May 2017 08:42:46 AM MDT
Group       : System Environment/Base
Size        : 2314510
License     : GPLv2+
Signature   : (none)
Source RPM  : authconfig-6.2.8-23.el7.src.rpm
Build Date  : Fri 28 Apr 2017 05:27:25 AM MDT
Build Host  : x86-030.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : https://fedorahosted.org/authconfig

Smartcard login is successful when smartcard login config is enabled using authconfig using the commands in comment 22. Screen lock prompts for pin as expected.

Comment 30 Pavel Březina 2017-05-12 08:19:44 UTC
I made slight changes.

Comment 31 Martin Kosek 2017-05-22 14:01:46 UTC
(In reply to Sumit Bose from comment #12)
> If pam_pkcs11 is installed the --smartcardmodule=sssd is ignored and the
> first pkcs11_module defined in /etc/pam_pkcs11/pam_pkcs11.conf is used as a
> default, as it is the current default behavior of authconfig.

I just read the documentation draft and I was a surprised about this behavior. Making the behavior to depend on pam_pkcs11 being installed or not seems error prone and customer could easily miss that "side channel" and be surprised that a configuration they explicitly asked for (--smartcardmodule=sssd) is not really working.

Is this worth Known Issue, Change Bugzilla or it is OK?

Comment 32 Sumit Bose 2017-05-22 14:07:20 UTC
This behavior is a pre-caution to really make sure not to break existing pam_pkcs11 setup. Since the behavior is mentioned in the docs and you have to read the docs to know about '--smartcardmodule=sssd' as well I think this is ok.

Comment 33 Martin Kosek 2017-05-22 14:52:39 UTC
Well, in my book, having to explicitly specify "--smartcardmodule=sssd" and not going with the defaults is a sufficient precaution that I really want SSSD SC module. As you said, you learn that flag from documentation, so you know what you are doing.

I thus do not understand why we would want to add extra hoops to jump through.

Comment 34 Sumit Bose 2017-05-23 11:44:59 UTC
I agree, the restriction is technically not needed. However authconfig has become a complex tool and the idea for the restriction was to minimize the risk of unexpected side-effects (unexpected in the sense that we do not have tests which cover them yet) of the change as we have seen them with other changes to authconfig in the past.

Comment 36 errata-xmlrpc 2017-08-01 07:27:56 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/RHSA-2017:2285


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