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

Brian J. Murrell brian at interlinx.bc.ca
Mon Nov 9 12:55:13 UTC 2009


On Thu, 2009-11-05 at 16:27 -0500, Brian J. Murrell wrote: 
> 

I didn't see any response to the following.  As far as I can see and
have explained this is still a problem.  If you disagree, please present
your argument so that I can take it back to the pam_unix folks for their
consideration.  But so far, as far as I can tell, pam_unix is doing what
it should and it's sssd that's in error.

Cheers,
b.

> 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/20091109/fbfadb67/attachment.sig>


More information about the sssd-devel mailing list