On Wed, 2016-05-11 at 16:51 -0400, Morgan Jones wrote:
Hello,
We are configuring password policy in 389 directory. We’re running what I believe is the latest stable version form the Epel repository on CentOS 6:
[root@devldapm03 ~]# rpm -qa|grep 389 389-admin-1.1.35-1.el6.x86_64 389-console-1.1.7-1.el6.noarch 389-ds-console-doc-1.2.6-1.el6.noarch 389-ds-base-libs-1.2.11.15-72.el6_7.x86_64 389-admin-console-doc-1.1.8-1.el6.noarch 389-ds-base-1.2.11.15-72.el6_7.x86_64 389-adminutil-1.1.19-1.el6.x86_64 389-ds-1.2.2-1.el6.noarch 389-admin-console-1.1.8-1.el6.noarch 389-ds-console-1.2.6-1.el6.noarch 389-dsgw-1.1.11-1.el6.x86_64 [morgan@devldapm03 ~]$ uname -a Linux devldapm03.philasd.net 2.6.32-573.26.1.el6.x86_64 #1 SMP Wed May 4 00:57:44 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux [morgan@devldapm03 ~]$ cat /etc/redhat-release CentOS release 6.7 (Final) [morgan@devldapm03 ~]$
I just did a yum update, rebooted and installed 389 anew.
The password policy works well if configured globally (from the Data node under Configuration) However when I attempt to create a subtree level policy (Directory->domain->employees, right click Manage Password Policy->for subtree) under ou=employees,dc=domain,dc=org the effect is as if there is no policy. If I subsequently disable the subtree policy I cannot get the global policy to take over. In fact the only way I’ve been able to get the global policy to work is to re-install from scratch.
I also tried command line configuration and was unable to get the policy working at all though I have more confidence of my understanding of the process via the console.
We’ve tried different policy settings but for testing purposes I’m just setting a minimum password length of 8 characters.
It would be good to get a look at the object that is affected here. Can you show me: pwdpolicysubentry from the affected user entry?
Then can you also show the contents of the dn listed by that pwdpolicysubentry?
Is there anything in your error logs that looks suspicious?