Comment 4 for bug 1919563

To speak to real world assessment here - there's a big push across many (US) gov't orgs and industry to deploy MFA. These requirements are not new, but many have not been enforced due to lack of compliance checks/certifications.

This is changing with new efforts in the US Gov't industry circles with regard to CMMC. This is an assessment/certification that industry must meet and maintain for contactual compliance, starting to roll out in the next year or so.

Likewise there's been a lot of focus lately on unclassified compliance with NIST policy. We have a number of customers, working toward or maintaining an MFA solution. All are struggling.

Many have lagged with pam_pkcs11 providing/satisfying most compliance requirements. But with RHEL8 and Ubuntu 20.04 adoption underway (with RHEL6 and 14.04 end of life) many are stuck working to cobble together an implementation.

Of course with the uptick in remote work, MFA has also resurged, also pushing along adoption of sssd MFA.

We noticed with the latest round of patching something was a-miss. and today tracked it down to this change. We're working with our customers to come up with a workaround.

I think there's a larger number of folks impacted here, but unfortunately, the number of possible ways to do MFA is very large, and because no one maintainer has completely documented/supported MFA well, sysadmins typically develop their MFA craft using what they can.

I don't discourage this change, in fact, will help push along the MFA adoption.

However, I think perhaps some preflight checks in the package could solve someone bricking their machine. (or a large quantity of machines). I'd also suggest that MFA support in general should be considered a core requirement for future versions of the LTS, and well tested, supported and documented. Adoption will only grow with time, and become more critical. This will help reduce the variations of implementations, and help drive folks to a known and supported configuration.

Reproduction of the issue:
In our circles, we see a fully Microsoft AD integrated Smartcard (with kerberos and PKINIT) implementation. This also bleeds over into pam_sss configuration issues with U20.04, (for which I should file another ticket)

Based on my diagnosis today, I think this is isolated to p11_child, and those with a nssdb with only issuing CA certs populated in the database. I don't think this issue matters for which directory is being used and if PKINIT is functioning, since all the MFA magic happens within p11_child.

I'm going to assume that you folks have some way test AD with MFA, and will try to summarize.

To reproduce, you'll need (at least) a 2 tier CA PKI chain. Root -> Issuing CA -> End user cert

(with old sssd version) configure for smart card auth
* do as you always do to join/setup sssd to a directory service
* verify user ID lookups, and login works as expected with password
* add any mapping/filter rules to the /etc/sssd/sssd.conf for p11_child
* upadte /usr/share/pam-configs/sss to Priority 800, rebuild pam stack, dpkg-divert /usr/share/pam-configs/sss
* add the root and issuing certs to /usr/local/share/ca-certificates, rebuild system trust store
* generate a new, empty nssdb
/usr/bin/certutil -N -d sql:/etc/pki/nssdb --empty-password
* when adding the certs to nssdb, only add the Issuing CA WITH CT,C,C flags
certutil -A -d /etc/pki/nssdb -n issuingCA.crt -t "CT,C,C" -i /usr/local/share/ca-certificates/issuingCA.pem
* enable openSC
modutil -force -dbdir /etc/pki/nssdb -add "OpenSC" -libfile opensc-pkcs11.so
* test PKI auth works
* login or:
/usr/libexec/sssd/p11_child --nssdb=/etc/pki/nssdb --pre -d 10 --debug-fd=1 --verify no_ocsp

* perform upgrade to latest sssd
* verify the /etc/sssd/pki/sssd_auth_ca_db.pem is populated only with the issuingCA
* test p11_child to see if it breaks
/usr/libexec/sssd/p11_child --debug-microseconds=0 --debug-timestamps=1 --debug-fd=23 --debug-level=0xf7f0 --pre --verify no_ocsp --nssdb /etc/sssd/pki/sssd_auth_ca_db.pem

fix it:
* add the /usr/local/share/ca-certificates/rootCA.pem >> /etc/sssd/pki/sssd_auth_ca_db.pem
* run p11_child again, observe that it works
* try to login

Brick your system procedure:
After above test procedure works:
* configure for MFA on old sssd
* populate the below to /usr/share/pam-configs/sss-smartcardonly
* pam-auth-update --package --enable sss-smartcardonly --remove sss --force
* verify only smart card is allowed to login
* apt upgrade
* reboot, login no longer allowed

Note that SSHing into the system may be allowed, depending on ssh configuration and if sss_ssh_authroizedkeys is enabled.

Name: SSS authentication - Requires Smartcard
Default: yes
Conflicts: sss
Priority: 800

Auth-Type: Primary
Auth:
 [success=end default=ignore] pam_sss.so use_first_pass require_cert_auth
Auth-Initial:
 [success=end default=ignore] pam_sss.so forward_pass require_cert_auth
Account-Type: Additional
Account:
 sufficient pam_localuser.so
 [default=bad success=ok user_unknown=ignore] pam_sss.so
Session-Type: Additional
Session-Interactive-Only: yes
Session:
 optional pam_sss.so
Password-Type: Primary
Password:
 sufficient pam_sss.so use_authtok
Password-Initial:
 sufficient pam_sss.so