Fedora directory users - Nov 2008 - Ubuntu not enforcing password policies

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

-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

http://www.spiritualoutreach.com
Making Christianity intelligible to secular society

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

-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

http://www.spiritualoutreach.com
Making Christianity intelligible to secular society

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
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

http://www.spiritualoutreach.com
Making Christianity intelligible to secular society

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
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

http://www.spiritualoutreach.com
Making Christianity intelligible to secular society

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
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

http://www.spiritualoutreach.com
Making Christianity intelligible to secular society