[SSSD-users] Need help configuring fine grained password policy enforcement on RHEL6 using sssd

Jakub Hrozek jhrozek at redhat.com
Thu Sep 12 09:46:00 UTC 2013


On Wed, Sep 11, 2013 at 05:02:41PM -0400, Dmitri Pal wrote:
> On 09/11/2013 04:06 PM, Bright, Daniel wrote:
> >
> > Jakub,
> >
> >  
> >
> > Thanks for the quick response, to answer your question I am using the
> > built-in password policy features of 389-ds that allows us to use
> > these features:
> >
> >  
> >
> > Maximum Number of Failures
> >
> > Password Change After Reset
> >
> > User-Defined Passwords
> >
> > Password Expiration
> >
> > Expiration Warning
> >
> > Grace Login Limit
> >
> > Password Syntax Checking
> >
> > Password Length
> >
> > Password Minimum Age
> >
> > Password History
> >
> > Password Storage Schemes
> >
> > Password Last Change Time
> >
> >  
> >
> > Here is a sanitized version of ldap.conf that is used in our current
> > environment:
> >
> >  
> >
> > ===========================================================================
> >
> >  
> >
> > host ldap1 ldap2
> >
> > URI ldap://ldap1:389 ldap://ldap2:389
> >
> >  
> >
> > base dc=some,dc=company,dc=com
> >
> > #bind_timelimit 5
> >
> > #>>
> >
> > bind_timelimit 3
> >
> > bind_policy soft
> >
> > timelimit 3
> >
> > #^^
> >
> > ldap_version 3
> >
> >  
> >
> > pam_lookup_policy yes
> >
> > pam_filter objectclass=posixAccount
> >
> > pam_password md5
> >
> >  
> >
> > nss_base_passwd ou=People,dc=some,dc=company,dc=com?one
> >
> > nss_base_passwd ou=Disabled Users,dc=some,dc=company,dc=com?one
> >
> > nss_base_shadow ou=People,dc=some,dc=company,dc=com?one
> >
> > nss_base_group 
> > ou=Groups,dc=some,dc=company,dc=com?one?|(host=\2A)(host=osd)
> >
> > #>>
> >
> > nss_initgroups_ignoreusers root,ldap
> >
> > #^^
> >
> >  
> >
> > ssl start_tls
> >
> > #ssl on
> >
> > tls_cacertdir /etc/openldap/cacerts
> >
> >  
> >
> > ===========================================================================
> >
> >  
> >
> > Thanks,
> > Daniel Bright
> >
> >
> >
> > _______________________________________________
> > sssd-users mailing list
> > sssd-users at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/sssd-users
> 
> I would leave this for Jakub to comment in the morning however if you
> use 389 DS it should be enforcing your password policy.
> SSSD leaves it to central server to enforce. It does not do any possword
> policy checking locally to the best of my knowledge except trying to
> deal with shadow.
> 
> ldap_pwd_policy (string)
>                Select the policy to evaluate the password expiration on the
>                client side. The following values are allowed:
> 
>                none - No evaluation on the client side. This option cannot
>                disable server-side password policies.
> 
>                shadow - Use shadow(5) style attributes to evaluate if the
>                password has expired.
> 
>                mit_kerberos - Use the attributes used by MIT Kerberos to
>                determine if the password has expired. Use
> chpass_provider=krb5
>                to update these attributes when the password is changed.
> 
>                Default: none
> 
> 
> I think commenting shadow is the right step.
> When you try with this setting removed (and SSSD restarted) do you see
> actually the change happening on the central server? Have you checked
> the 389 DS logs?
> Can it be that password change actually does not go to the DS server but
> captured by some other PAM module in your stack?

I agree with Dmitri's assessment. In general the SSSD should
authenticate with the old password and then change to the new one using
an extended LDAP operation. Password constraint errors come from the
server in the response to the extended operation.

I would also add ldap_account_expire_policy=rhds to your configuration
to leverage the nsAccountLock attribute for checking whether the account
is expired or not.

As Dmitri said, pairing the SSSD domain logs with server logs would shed
more light. If you're going to generate the SSSD logs, then unfortunately
you need to use debug_level at least 7, for some messages even 9 to get
the info. Look for messages from sdap_exop_modify_passwd_done

You can send the logs to me privately if you don't like
sanitizing them and posting them to a public list.


More information about the sssd-users mailing list