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.