Quick follow-up on my previous post about authconfig with more info.
So it turns out that this was intentional, and the change was made because 2-facter authententication support was added to SSSD.
This was added as a fix for RHEL bug 1204864, with the following comment:
With the current configuration pam_unix will always prompt the user for a password. Letting SSSD ask users of 2FA again for the password will lead to a bad user experience. Letting SSSD only ask for the second factor will make it hard for applications like gdm to show specific 2FA dialogs.
This means that if you use a mix of local (
/etc/shadow) and remote (via
sssd) user information for a particular user, then the user in question will only auth against their local password.
If they don’t have a local password then they will be unable to authenticate.
This seems a particularly odd thing to change during a point-release of RHEL, as I would expect that using a mix of local and remote user information is more common than using 2FA with sssd…
I thought this was worth stating separately from the previous post, as it’s more general than just when performing hackery to change UIDs — any local user entry will cause this to happen when used in conjunction with sssd.
The code in sssd which enforces this is as follows (from
authconfig-6.2.8/authinfo.py in the current CentOS 7.x git sources, line 3812):
# do not continue to following modules if authentication fails if name == "unix" and stack == "auth" and (self.enableSSSDAuth or self.implicitSSSDAuth or self.enableIPAv2) and (not self.enableNIS): logic = LOGIC_FORCE_PKCS11 # make it or break it logic
..so this is specifically for when you are using SSSD and not NIS, not any other remote authn/authz methods such as KRB5 without SSSD.