[ 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.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel