I was going to file this as a bug in Trac but it's not clear how one
creates an account there.
Witness the difference between nss_ldap and sssd (0.7.1) with regard to
the password in passwd map entries:
nss_ldap $ getent passwd brian
brian:*:1001:1001:Brian J. Murrell:/home/brian:/bin/bash
sssd $ getent passwd brian
brian:x:1001:1001:Brian J. Murrell:/home/brian:/bin/bash
Notice that sssd is reporting an "x" in the password field when nss_ldap
is reporting an "*". The reason nss_ldap is reporting an "*" is
because
there is no password information for this user in LDAP because this user
authenticates with kerberos.
The way nss_ldap knows whether to return an "x" or an "*" for the
password entry is based on whether the ldap entry has a shadowAccount
object class defined. It all makes sense doesn't it?
So, sssd needs to be doing the same thing. The reason is that the
pam_unix pam module's account personality does sanity checks on the
shadow information (password expired, going to expire?, etc.) when the
passwd entry says there is shadow information by specifying "x" in the
password field. If there is no shadow information, which there is not
when there is no authentication data in ldap, then the sssd NSS module
should be returning something other than an "x".
I'd be happy to test a patch, or even do the hacking myself if somebody
wants to point me to where this "hardcoding" of the "x" is.
Cheers,
b.