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
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1919563
Title:
updated sssd with smart cards now brick systems without full cert
chain
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1919563/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
