[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