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

Brian J. Murrell brian at interlinx.bc.ca
Thu Nov 5 21:27:48 UTC 2009


[ Apologies if this winds up being a duplicate.  I have tried to post
  this a few times and not seen it distributed despite waiting
  days.  Probably getting lost somewhere.  No worries. ]

On Tue, 2009-11-03 at 07:14 -0500, Stephen Gallagher wrote: 
> - From passwd(5):
> "If the encrypted password is set to an asterisk, the user will be
> unable to login using login(1),

Hrm.  Is this supposed to be cause or effect?  i.e. should an encrypted
value for a password being an "*" actually mean to any login programs
that this account is locked, or does it just mean that there is no way
that pam_unix (or any-other crypt-style login process) will be able
decyrpt this as a password and the side effect of that is that the user
will not be able to login [using a crypt-style login]?

I read "If the encrypted password is set to an asterisk, the user will
be unable to login using login(1)," more as effect than cause.

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

Which I think further validates that an "*" doesn't mean "no login
allowed", just "login through decrypting a password will not be
possible".

The summary being that an "*" should be perfectly viable for a non-crypt
based authentication scheme, like, oh, say, kerberos.  :-)

> On the other hand, an "x" indicates that the password is maintained in
> the shadow map,

Right!

> which we do not export through SSSD and would therefore
> imply denial for all attempts to authenticate.

I'm not sure what point you are trying to make here.

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

But pam_unix.so will step on your toes.  When used in the account mode,
pam_unix sees the "x" for the password and that tells it that there
should be shadow information available and it wants to verify the
details of the shadow information to see if the account is in good
standing, not in need of a password change, etc.

But because we have (and we shouldn't in fact have -- so this is the
proper operation IMHO) no shadow information when using the kerberos
auth_provider, it's erroneous to tell pam_unix.so that there is shadow
information available by sending an "x" in the password field of the
passwd entry.

Try it.  Create a configuration that allows you to login without a
shadow entry (i.e. kerberos, or maybe ldap even) and configure your nss
provider to not provide a shadow entry and then put a pam_unix.so entry
in your account configuration such as:

account [success=1 new_authtok_reqd=done default=ignore]        pam_unix.so 
account requisite                       pam_deny.so
account required                        pam_permit.so
account [default=bad success=ok user_unknown=ignore] pam_sss.so

And then see what difference is made by an * and an x in the password
entry of the passwd map when there is no shadow entry available.

Here it's the difference between being allowed to ssh in and get to a
and being authenticated, but still denied acceess (because of the failed
attempt to verify the shadow information.

Once you have confirmed the latter effect, comment out the first two
lines of the pam account settings above and try again.  You will now be
allowed to log in without a shadow entry.

If you want further proof, change your id provider to make the password
field of your passwd entry a "*" instead of the "x", reinstate the first
two lines of the pam account above and try to log in again without a
shadow entry.  It will succeed.

b.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20091105/382e7aab/attachment.sig>


More information about the sssd-devel mailing list