Bug 1378943

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.

Patrick,

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

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.

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.

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.

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

Thank you Sumit for the sum up.

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?

Yes, just let authconfig to the work.

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.

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.

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.

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.

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.

[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.

I made slight changes.

(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?

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.

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.

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.

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