Hello, all. We're continuing to dive ever deeper into DS. Our thanks to the developers for such a powerful product.
Our integration with the RedHat family has gone well but now we're working on Ubuntu. Most is working well but we are finding Ubuntu is not enforcing password policies. For example, we require a user to change their password after a reset. When a user logs into a RedHat system, they are prompted for the change. However, Ubuntu just lets them right in again and again with the same reset password.
Any pointers on what to look for to fix this in our configuration before we scour the world for a solution? We've already done quite a bit of googling.
We've tried enabling pam_lookup_policy but that didn't work. /etc/pam.d/common-password reads:
password requisite pam_cracklib.so retry=3 minlen=8 difok=3 password [success=2 default=ignore] pam_unix.so obscure use_authtok try_first_pass sha512 password [success=1 user_unknown=ignore default=die] pam_ldap.so use_authtok try_first_pass # here's the fallback if no module succeeds password requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already; # this avoids us returning an error just because nothing sets a success code # since the modules above will each just jump around password required pam_permit.so
We've also tried disabling that last pam_permit.so. That didn't help. Where should we look? Thanks - John
On Fri, Nov 28, 2008 at 12:49:11AM -0500, John A. Sullivan III wrote:
Hello, all. We're continuing to dive ever deeper into DS. Our thanks to the developers for such a powerful product.
Our integration with the RedHat family has gone well but now we're working on Ubuntu. Most is working well but we are finding Ubuntu is not enforcing password policies. For example, we require a user to change their password after a reset. When a user logs into a RedHat system, they are prompted for the change. However, Ubuntu just lets them right in again and again with the same reset password.
Any pointers on what to look for to fix this in our configuration before we scour the world for a solution? We've already done quite a bit of googling.
We've tried enabling pam_lookup_policy but that didn't work. /etc/pam.d/common-password reads:
password requisite pam_cracklib.so retry=3 minlen=8 difok=3 password [success=2 default=ignore] pam_unix.so obscure use_authtok try_first_pass sha512 password [success=1 user_unknown=ignore default=die] pam_ldap.so use_authtok try_first_pass # here's the fallback if no module succeeds password requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already; # this avoids us returning an error just because nothing sets a success code # since the modules above will each just jump around password required pam_permit.so
We've also tried disabling that last pam_permit.so. That didn't help. Where should we look? Thanks - John
When using PAM, the calling application "knows" that the user's password needs to be changed because the account management modules signal it, so you'll want to check the "account" portions of the PAM configuration.
Specifically, you want to ensure that pam_ldap.so is being used, and that some other module isn't causing the account management function to return a success code before pam_ldap.so gets a chance to check on the user's account and return a password-needs-changing code.
Just a guess, but going on what I get on my Fedora system, it might look something like this:
account required pam_unix.so account sufficient pam_succeed_if.so uid < 500 quiet account [[default=bad success=ok user_unknown=ignore] pam_ldap.so account required pam_permit.so
HTH,
Nalin
On Mon, 2008-12-01 at 13:36 -0500, Nalin Dahyabhai wrote:
On Fri, Nov 28, 2008 at 12:49:11AM -0500, John A. Sullivan III wrote:
Hello, all. We're continuing to dive ever deeper into DS. Our thanks to the developers for such a powerful product.
Our integration with the RedHat family has gone well but now we're working on Ubuntu. Most is working well but we are finding Ubuntu is not enforcing password policies. For example, we require a user to change their password after a reset. When a user logs into a RedHat system, they are prompted for the change. However, Ubuntu just lets them right in again and again with the same reset password.
Any pointers on what to look for to fix this in our configuration before we scour the world for a solution? We've already done quite a bit of googling.
We've tried enabling pam_lookup_policy but that didn't work. /etc/pam.d/common-password reads:
password requisite pam_cracklib.so retry=3 minlen=8 difok=3 password [success=2 default=ignore] pam_unix.so obscure use_authtok try_first_pass sha512 password [success=1 user_unknown=ignore default=die] pam_ldap.so use_authtok try_first_pass # here's the fallback if no module succeeds password requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already; # this avoids us returning an error just because nothing sets a success code # since the modules above will each just jump around password required pam_permit.so
We've also tried disabling that last pam_permit.so. That didn't help. Where should we look? Thanks - John
When using PAM, the calling application "knows" that the user's password needs to be changed because the account management modules signal it, so you'll want to check the "account" portions of the PAM configuration.
Specifically, you want to ensure that pam_ldap.so is being used, and that some other module isn't causing the account management function to return a success code before pam_ldap.so gets a chance to check on the user's account and return a password-needs-changing code.
Just a guess, but going on what I get on my Fedora system, it might look something like this:
account required pam_unix.so account sufficient pam_succeed_if.so uid < 500 quiet account [[default=bad success=ok user_unknown=ignore] pam_ldap.so account required pam_permit.so
HTH,
Nalin
--
<snip> Thank you. That was it. It had autoconfigured with ldap first:
account sufficient pam_ldap.so account required pam_unix.so
On Mon, 2008-12-01 at 14:33 -0500, John A. Sullivan III wrote:
On Mon, 2008-12-01 at 13:36 -0500, Nalin Dahyabhai wrote:
On Fri, Nov 28, 2008 at 12:49:11AM -0500, John A. Sullivan III wrote:
Hello, all. We're continuing to dive ever deeper into DS. Our thanks to the developers for such a powerful product.
Our integration with the RedHat family has gone well but now we're working on Ubuntu. Most is working well but we are finding Ubuntu is not enforcing password policies. For example, we require a user to change their password after a reset. When a user logs into a RedHat system, they are prompted for the change. However, Ubuntu just lets them right in again and again with the same reset password.
Any pointers on what to look for to fix this in our configuration before we scour the world for a solution? We've already done quite a bit of googling.
We've tried enabling pam_lookup_policy but that didn't work. /etc/pam.d/common-password reads:
password requisite pam_cracklib.so retry=3 minlen=8 difok=3 password [success=2 default=ignore] pam_unix.so obscure use_authtok try_first_pass sha512 password [success=1 user_unknown=ignore default=die] pam_ldap.so use_authtok try_first_pass # here's the fallback if no module succeeds password requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already; # this avoids us returning an error just because nothing sets a success code # since the modules above will each just jump around password required pam_permit.so
We've also tried disabling that last pam_permit.so. That didn't help. Where should we look? Thanks - John
When using PAM, the calling application "knows" that the user's password needs to be changed because the account management modules signal it, so you'll want to check the "account" portions of the PAM configuration.
Specifically, you want to ensure that pam_ldap.so is being used, and that some other module isn't causing the account management function to return a success code before pam_ldap.so gets a chance to check on the user's account and return a password-needs-changing code.
Just a guess, but going on what I get on my Fedora system, it might look something like this:
account required pam_unix.so account sufficient pam_succeed_if.so uid < 500 quiet account [[default=bad success=ok user_unknown=ignore] pam_ldap.so account required pam_permit.so
HTH,
Nalin
--
<snip> Thank you. That was it. It had autoconfigured with ldap first:
account sufficient pam_ldap.so account required pam_unix.so
Oops! I spoke too soon. Now, after changing the password, I cannot log in. If I change it back to the original order, I can. I'll have to dig a little further - John
On Mon, 2008-12-01 at 14:36 -0500, John A. Sullivan III wrote:
On Mon, 2008-12-01 at 14:33 -0500, John A. Sullivan III wrote:
On Mon, 2008-12-01 at 13:36 -0500, Nalin Dahyabhai wrote:
On Fri, Nov 28, 2008 at 12:49:11AM -0500, John A. Sullivan III wrote:
Hello, all. We're continuing to dive ever deeper into DS. Our thanks to the developers for such a powerful product.
Our integration with the RedHat family has gone well but now we're working on Ubuntu. Most is working well but we are finding Ubuntu is not enforcing password policies. For example, we require a user to change their password after a reset. When a user logs into a RedHat system, they are prompted for the change. However, Ubuntu just lets them right in again and again with the same reset password.
Any pointers on what to look for to fix this in our configuration before we scour the world for a solution? We've already done quite a bit of googling.
We've tried enabling pam_lookup_policy but that didn't work. /etc/pam.d/common-password reads:
password requisite pam_cracklib.so retry=3 minlen=8 difok=3 password [success=2 default=ignore] pam_unix.so obscure use_authtok try_first_pass sha512 password [success=1 user_unknown=ignore default=die] pam_ldap.so use_authtok try_first_pass # here's the fallback if no module succeeds password requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already; # this avoids us returning an error just because nothing sets a success code # since the modules above will each just jump around password required pam_permit.so
We've also tried disabling that last pam_permit.so. That didn't help. Where should we look? Thanks - John
When using PAM, the calling application "knows" that the user's password needs to be changed because the account management modules signal it, so you'll want to check the "account" portions of the PAM configuration.
Specifically, you want to ensure that pam_ldap.so is being used, and that some other module isn't causing the account management function to return a success code before pam_ldap.so gets a chance to check on the user's account and return a password-needs-changing code.
Just a guess, but going on what I get on my Fedora system, it might look something like this:
account required pam_unix.so account sufficient pam_succeed_if.so uid < 500 quiet account [[default=bad success=ok user_unknown=ignore] pam_ldap.so account required pam_permit.so
HTH,
Nalin
--
<snip> Thank you. That was it. It had autoconfigured with ldap first:
account sufficient pam_ldap.so account required pam_unix.so
Oops! I spoke too soon. Now, after changing the password, I cannot log in. If I change it back to the original order, I can. I'll have to dig a little further - John
Seem to have it now. The Ubuntu host did not like the settings copied in from Fedora. However, simply reversing the default Ubuntu settings so that they are now:
account required pam_unix.so account sufficient pam_ldap.so
seemed to do the trick. Thanks again - John
On Tue, Dec 02, 2008 at 11:22:44PM -0500, John A. Sullivan III wrote:
Seem to have it now. The Ubuntu host did not like the settings copied in from Fedora. However, simply reversing the default Ubuntu settings so that they are now:
account required pam_unix.so account sufficient pam_ldap.so
Please be careful about this. If this is the entire set of "account" modules, then I think the end-result when pam_ldap.so fails might be undefined (in particular, the user may be allowed access anyway, even if pam_ldap.so indicates that the user should not have access, because no "required" modules have indicated problems).
Cheers,
Nalin
On Wed, 2008-12-03 at 12:57 -0500, Nalin Dahyabhai wrote:
On Tue, Dec 02, 2008 at 11:22:44PM -0500, John A. Sullivan III wrote:
Seem to have it now. The Ubuntu host did not like the settings copied in from Fedora. However, simply reversing the default Ubuntu settings so that they are now:
account required pam_unix.so account sufficient pam_ldap.so
Please be careful about this. If this is the entire set of "account" modules, then I think the end-result when pam_ldap.so fails might be undefined (in particular, the user may be allowed access anyway, even if pam_ldap.so indicates that the user should not have access, because no "required" modules have indicated problems).
<snip> Thanks very much. I'm trusting the Ubuntu folks know what they're doing. This is part of an included pam file. However, I should double-check. Should pam_deny.so be at the end of the chain? - John
389-users@lists.fedoraproject.org
-
John A. Sullivan III -
Nalin Dahyabhai