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.
Is there something I’m missing?
thanks,
-morgan
I am following up in hopes that maybe this was just missed the first time around. Is anyone using a subtree password policy in a recent version of 389 and does it work?
thanks,
-morgan
On May 11, 2016, at 16:51, Morgan Jones morgan@morganjones.org 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.
Is there something I’m missing?
thanks,
-morgan
389-users mailing list 389-users@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
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?
On May 19, 2016, at 19:04, William Brown wibrown@redhat.com wrote:
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?
William,
I believe this is what you’re looking for:
dn: cn=cn\3DnsPwPolicyEntry\2Cou\3Demployees\2Cdc\3Ddomain\2Cdc\3Dorg,cn=nsPw PolicyContainer,ou=employees,dc=domain,dc=org objectClass: ldapsubentry objectClass: passwordpolicy objectClass: top cn: cn=nsPwPolicyEntry,ou=employees,dc=domain,dc=org passwordMustChange: off passwordExp: off passwordMinAge: 0 passwordChange: off passwordCheckSyntax: on passwordStorageScheme: ssha passwordMaxRepeats: 0 passwordMinLength: 8 passwordMinAlphas: 0 passwordMinDigits: 0 passwordMinSpecials: 0 passwordMinLowers: 0 passwordMinCategories: 2 passwordMinUppers: 0 passwordMinTokenLength: 2 passwordMin8bit: 0
Here are some examples of setting passwords to shorter than 8 characters with corresponding logs. There is nothing (new) in errors:
[root@devldapm03 slapd-devldapm03]# ldapmodify -h localhost -D cn=directory\ manager -w pass dn: uid=morgan,ou=employees,dc=domain,dc=org changetype: modify replace: userpassword userpassword: 12345
modifying entry “uid=morgan,ou=employees,dc=domain,dc=org"
[root@devldapm03 slapd-devldapm03]#
[20/May/2016:18:16:42 -0400] conn=16 fd=68 slot=68 connection from 127.0.0.1 to 127.0.0.1 [20/May/2016:18:16:42 -0400] conn=16 op=0 BIND dn="cn=directory manager" method=128 version=3 [20/May/2016:18:16:42 -0400] conn=16 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [20/May/2016:18:17:05 -0400] conn=16 op=1 MOD dn="uid=morgan,ou=employees,dc=domain,dc=org" [20/May/2016:18:17:05 -0400] conn=16 op=1 RESULT err=0 tag=103 nentries=0 etime=0domain
[root@devldapm03 slapd-devldapm03]# ldapmodify -h localhost -D uid=morgan,ou=employees,dc=domain,dc=org -w pass dn: uid=morgan,ou=employees,dc=domain,dc=org changetype: modify replace: userpassword userpassword: 123
modifying entry "uid=morgan,ou=employees,dc=domain,dc=org" [root@devldapm03 slapd-devldapm03]#
[20/May/2016:18:26:29 -0400] conn=29 fd=68 slot=68 connection from 127.0.0.1 to 127.0.0.1 [20/May/2016:18:26:29 -0400] conn=29 op=0 BIND dn="uid=morgan,ou=employees,dc=domain,dc=org" method=128 version=3 [20/May/2016:18:26:29 -0400] conn=29 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=morgan,ou=employees,dc=domain,dc=org" [20/May/2016:18:26:51 -0400] conn=29 op=1 MOD dn="uid=morgan,ou=employees,dc=domain,dc=org" [20/May/2016:18:26:51 -0400] conn=29 op=1 RESULT err=0 tag=103 nentries=0 etime=0
thanks,
-morgan
Hello William,
Is this what you’re looking for? I’ve included the full entry below but it appears pwdPolicySubentry is operational.
[morgan@devldapm03 ~]$ ldapsearch -h localhost -D cn=directory\ manager -w pass -LLLb uid=morgan,ou=employees,dc=domain,dc=org pwdPolicySubentry dn: uid=morgan,ou=employees,dc=domain,dc=org pwdPolicySubentry: cn=cn\3DnsPwPolicyEntry\2Cou\3Demployees\2Cdc\3Ddomain\2Cd c\3Dorg,cn=nsPwPolicyContainer,ou=employees,dc=domain,dc=org
dn: uid=morgan,ou=employees,dc=domain,dc=org orgHomeOrg: TECHNOLOGY SERVICES orgSponsorHomeOrg: TECHNICAL OPERATIONS orgSponsorHomeOrgCD: x orgAcceptedTermsofUse: FALSE orgSponsorEIDN: x orgGAFEOverrideOrgUnit: /STAFF/x/x sambaSID: x mail: morgan@domain.org orgAccountActive: TRUE homeDirectory: /home/morgan gecos: Morgan Jones loginShell: /bin/bash uidNumber: x gidNumber: x orgEIDN: x orgHomeOrgCD: x givenName: Morgan sn: Jones cn: Morgan Jones objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: orgAssociate objectClass: orgZimbraPerson objectClass: shadowAccount objectClass: inetUser objectClass: ntUser objectClass: sambaSamAccount uid: morgan ntUserDomainId: morgan ntUserDeleteAccount: TRUE ntUserCreateNewAccount: TRUE orgAccountStatus: Active sambaNTPassword: pass orgDateAccountLastUpdated: 201407021744Z userPassword: pass
thanks,
-morgan
On May 22, 2016, at 19:10, William Brown wibrown@redhat.com wrote:
On Fri, 2016-05-20 at 18:30 -0400, Morgan Jones wrote:
uid=morgan,ou=employees,dc=domain,dc=org
I need to see the entry at this dn too, and looking for the attribute pwdPolicySubentry thanks.
-- Sincerely,
William Brown Software Engineer Red Hat, Brisbane
-- 389-users mailing list 389-users@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
On Mon, 2016-05-23 at 11:52 -0400, Morgan Jones wrote:
Hello William,
Is this what you’re looking for? I’ve included the full entry below but it appears pwdPolicySubentry is operational.
Hi,
Sorry to have taken so long.
Can you check:
cn=config nsslapd-pwpolicy-local: on
Without that setting, the fine grained password policy won't work,
Thanks,
William,
nsslapd-pwpolicy-local was indeed not set however setting it doesn’t make a difference. See below for details.
Thanks for the help with this.
thanks,
-morgan
larry:~ morgan$ ldapsearch -LLL -x -w pass -H ldap://devldapm03.domain.net -D cn=directory\ manager -b cn=config -s base objectclass=* nsslapd-pwpolicy-local dn: cn=config nsslapd-pwpolicy-local: off
larry:~ morgan$ ldapmodify -x -w pass -H ldap://devldapm03.domain.net -D cn=directory\ manager dn: uid=morgan,ou=employees,dc=domain,dc=org changetype: modify replace: userpassword userpassword: 123
modifying entry "uid=morgan,ou=employees,dc=domain,dc=org"
larry:~ morgan$ ldapsearch -LLL -x -w pass -H ldap://devldapm03.domain.net -D cn=directory\ manager -b cn=config -s base objectclass=* nsslapd-pwpolicy-local dn: cn=config nsslapd-pwpolicy-local: off
larry:~ morgan$ ldapmodify -x -w pass -H ldap://devldapm03.domain.net -D cn=directory\ manager dn: cn=config changetype: modify replace: nsslapd-pwpolicy-local nsslapd-pwpolicy-local: on
modifying entry "cn=config"
dn: uid=morgan,ou=employees,dc=domain,dc=org changetype: modify replace: userpassword userpassword: 1234
modifying entry "uid=morgan,ou=employees,dc=domain,dc=org"
larry:~ morgan$ ldapsearch -LLL -x -w pass -H ldap://devldapm03.domain.net -D cn=directory\ manager -b cn=config -s base objectclass=* nsslapd-pwpolicy-local dn: cn=config nsslapd-pwpolicy-local: on
larry:~ morgan$
On May 29, 2016, at 23:04, William Brown wibrown@redhat.com wrote:
On Mon, 2016-05-23 at 11:52 -0400, Morgan Jones wrote:
Hello William,
Is this what you’re looking for? I’ve included the full entry below but it appears pwdPolicySubentry is operational.
Hi,
Sorry to have taken so long.
Can you check:
cn=config nsslapd-pwpolicy-local: on
Without that setting, the fine grained password policy won't work,
Thanks,
Sincerely,
William Brown Software Engineer Red Hat, Brisbane
-- 389-users mailing list 389-users@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.or...
Hello,
I’m just checking in on this. Is no one using subtree based password policies in 389 directory?
-morgan
On May 31, 2016, at 15:14, Morgan Jones morgan@morganjones.org wrote:
William,
nsslapd-pwpolicy-local was indeed not set however setting it doesn’t make a difference. See below for details.
Thanks for the help with this.
thanks,
-morgan
larry:~ morgan$ ldapsearch -LLL -x -w pass -H ldap://devldapm03.domain.net -D cn=directory\ manager -b cn=config -s base objectclass=* nsslapd-pwpolicy-local dn: cn=config nsslapd-pwpolicy-local: off
larry:~ morgan$ ldapmodify -x -w pass -H ldap://devldapm03.domain.net -D cn=directory\ manager dn: uid=morgan,ou=employees,dc=domain,dc=org changetype: modify replace: userpassword userpassword: 123
modifying entry "uid=morgan,ou=employees,dc=domain,dc=org"
larry:~ morgan$ ldapsearch -LLL -x -w pass -H ldap://devldapm03.domain.net -D cn=directory\ manager -b cn=config -s base objectclass=* nsslapd-pwpolicy-local dn: cn=config nsslapd-pwpolicy-local: off
larry:~ morgan$ ldapmodify -x -w pass -H ldap://devldapm03.domain.net -D cn=directory\ manager dn: cn=config changetype: modify replace: nsslapd-pwpolicy-local nsslapd-pwpolicy-local: on
modifying entry "cn=config"
dn: uid=morgan,ou=employees,dc=domain,dc=org changetype: modify replace: userpassword userpassword: 1234
modifying entry "uid=morgan,ou=employees,dc=domain,dc=org"
larry:~ morgan$ ldapsearch -LLL -x -w pass -H ldap://devldapm03.domain.net -D cn=directory\ manager -b cn=config -s base objectclass=* nsslapd-pwpolicy-local dn: cn=config nsslapd-pwpolicy-local: on
larry:~ morgan$
On May 29, 2016, at 23:04, William Brown wibrown@redhat.com wrote:
On Mon, 2016-05-23 at 11:52 -0400, Morgan Jones wrote:
Hello William,
Is this what you’re looking for? I’ve included the full entry below but it appears pwdPolicySubentry is operational.
Hi,
Sorry to have taken so long.
Can you check:
cn=config nsslapd-pwpolicy-local: on
Without that setting, the fine grained password policy won't work,
Thanks,
Sincerely,
William Brown Software Engineer Red Hat, Brisbane
-- 389-users mailing list 389-users@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.or...
-- 389-users mailing list 389-users@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.or...
389-users@lists.fedoraproject.org
-
Morgan Jones -
William Brown