[SSSD] should not return "x" for password when there is no shadow information

Stephen Gallagher sgallagh at redhat.com
Tue Nov 3 12:14:23 UTC 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/03/2009 12:49 AM, Brian J. Murrell wrote:
> I was going to file this as a bug in Trac but it's not clear how one
> creates an account there.

I'll update the wiki page, but the short version is that we're a
Fedorahosted project, so you just need a Fedora Account from
https://admin.fedoraproject.org/accounts/  You do not need to sign the
CLAs in order to file bugs.


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

- From passwd(5):
"If the encrypted password is set to an asterisk, the user will be
unable to login using login(1), but may still login using rlogin(1), run
existing processes and initiate new ones through rsh(1), cron(1), at(1),
or mail filters, etc"

On the other hand, an "x" indicates that the password is maintained in
the shadow map, which we do not export through SSSD and would therefore
imply denial for all attempts to authenticate.

This way we can do authentication using only the auth_provider specified
in the domain, without worrying about pam_unix.so stepping on our toes.

- -- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkrwHpoACgkQeiVVYja6o6NBrgCfU7tc22kMiLkaEtnw1F7bt2oq
Nb0An3gwpmrU03L2y3eRQ0Vz3ulGctyo
=ITny
-----END PGP SIGNATURE-----



More information about the sssd-devel mailing list