Hi with the new 1.2.2-1 389* the user can resure the same password Again & Again, the passwordhistory stop to Work and not showing anymore. see my test below. It is the first time i get this kind of issue
[root@centos6 ~]# rpm -qa|grep 389 389-console-1.1.7-1.el6.noarch 389-adminutil-1.1.19-1.el6.x86_64 389-ds-console-1.2.6-1.el6.noarch 389-ds-1.2.2-1.el6.noarch 389-ds-base-libs-1.2.11.15-85.el6_8.x86_64 389-admin-1.1.35-1.el6.x86_64 389-admin-console-1.1.8-1.el6.noarch 389-ds-base-1.2.11.15-85.el6_8.x86_64
[root@centos6 scripts]# cat test_passwd_history.ksh #!/bin/ksh #Ldap test passwd if it is expired or not - tng 20170226 ldapsearch -xLLL -ZZ -b dc=nnit '(&(uid=tnng))' passwordRetryCount passwordExpWarned accountUnlockTime passwordExpirationTime passwordHistory createtimestamp modifytimestamp retryCountResetTime passwordAllowChangeTime nsRoleDN ldappasswd -s 123 -w 12345678 -x -ZZ -D cn='directory manager' cn='Tuan Nguyen,cn=unixtek,ou=Infrastructure,dc=nnit'
[root@centos6 scripts]# ./test_passwd_history.ksh dn: cn=Tuan Nguyen,cn=unixtek,ou=Infrastructure,dc=nnit passwordExpWarned: 0 passwordExpirationTime: 19700101000000Z createtimestamp: 20170114110541Z modifytimestamp: 20170226085143Z [root@centos6 scripts]# ./test_passwd_history.ksh dn: cn=Tuan Nguyen,cn=unixtek,ou=Infrastructure,dc=nnit passwordExpWarned: 0 passwordExpirationTime: 19700101000000Z createtimestamp: 20170114110541Z modifytimestamp: 20170226091223Z [root@centos6 scripts]# ./test_passwd_history.ksh dn: cn=Tuan Nguyen,cn=unixtek,ou=Infrastructure,dc=nnit passwordExpWarned: 0 passwordExpirationTime: 19700101000000Z createtimestamp: 20170114110541Z modifytimestamp: 20170226091224Z [root@centos6 scripts]#
policy [root@centos6 scripts]# ldapsearch -xLLL -ZZ -b cn='cn\3DnsPwPolicyEntry\2Cou\3DInfrastructure\2Cdc\3Dnnit,cn=nsPwPolicyContainer,ou=Infrastructure,dc=nnit' -s base '(&(objectclass=passwordpolicy))' dn: cn=cn\3DnsPwPolicyEntry\2Cou\3DInfrastructure\2Cdc\3Dnnit,cn=nsPwPolicyCon tainer,ou=Infrastructure,dc=nnit passwordStorageScheme: ssha passwordGraceLimit: 1 passwordChange: on passwordWarning: 86400 passwordMinAge: 0 passwordExp: on passwordMustChange: on passwordMaxAge: 86400 objectClass: ldapsubentry objectClass: passwordpolicy objectClass: top cn: cn=nsPwPolicyEntry,ou=Infrastructure,dc=nnit
Policy settings from GUI: www.chezmoi.dk/389-passwd-not-expire.png
I observer this one after the update of 389*
Starting dirsrv: NNIT...[26/Feb/2017:18:26:09 +0100] dse_read_one_file - The entry cn=schema in file /etc/dirsrv/slapd-NNIT/schema/75ppolicy.ldif (lineno: 1) is invalid, error code 20 (Type or value exists) - attribute type pwdMinAge: Does not match the OID "1.3.6.1.4.1.42.2.27.8.1.2". Another attribute type is already using the name or OID. [26/Feb/2017:18:26:09 +0100] dse - Please edit the file to correct the reported problems and then restart the server. [FAILED] *** Error: 1 instance(s) failed to start [root@centos6 dirsrv]#
notice: attribute type pwdMinAge: Does not match the OID
I need to remove it before I can start dirsrv.
that file is the same from here: [root@centos6 dirsrv]# ll /etc/dirsrv/schema/75ppolicy.ldif -rw-r--r-- 1 root root 4699 Feb 19 2013 /etc/dirsrv/schema/75ppolicy.ldif [root@centos6 dirsrv]#
So now my ldap slapd-NNIT doesn't had this schema 75ppolicy.ldif. I dont know if it has any affect.
Please help br Tuan
On Sun, 2017-02-26 at 17:53 +0000, tuan88@gmail.com wrote:
I observer this one after the update of 389*
Starting dirsrv: NNIT...[26/Feb/2017:18:26:09 +0100] dse_read_one_file - The entry cn=schema in file /etc/dirsrv/slapd-NNIT/schema/75ppolicy.ldif (lineno: 1) is invalid, error code 20 (Type or value exists) - attribute type pwdMinAge: Does not match the OID "1.3.6.1.4.1.42.2.27.8.1.2". Another attribute type is already using the name or OID. [26/Feb/2017:18:26:09 +0100] dse - Please edit the file to correct the reported problems and then restart the server. [FAILED] *** Error: 1 instance(s) failed to start [root@centos6 dirsrv]#
notice: attribute type pwdMinAge: Does not match the OID
I need to remove it before I can start dirsrv.
that file is the same from here: [root@centos6 dirsrv]# ll /etc/dirsrv/schema/75ppolicy.ldif -rw-r--r-- 1 root root 4699 Feb 19 2013 /etc/dirsrv/schema/75ppolicy.ldif [root@centos6 dirsrv]#
So now my ldap slapd-NNIT doesn't had this schema 75ppolicy.ldif. I dont know if it has any affect.
Please help br Tuan
Hi,
You may find that your schema has been corrupted or migrated from another server (ie sunds, or similar).
75ppolicy.ldif doesn't ship with directory server. We ship the password policy in 02common.ldif.
It may be a good idea to backup your schema directory:
# Stop directory server here, ie systemctl stop dirsrv@instance mv /etc/dirsrv/slapd-<instance>/schema /etc/dirsrv/slapd-<instance>/schema-backup cp -a /usr/share/dirsrv/schema /etc/dirsrv/slapd-<instance>/schema restorecon -r /etc/dirsrv/slapd-<instance> chown -R dirsrv: /etc/dirsrv/slapd-<instance>/schema # Start Directory Server here
This should restore a "correct" 389-ds-base provided schema to your instance.
Further issues from there are due to missing custom schema that you can extract from /etc/dirsrv/slapd-<instance>/schema-backup into /etc/dirsrv/slapd-<instance>/schema/99user.ldif as needed.
As I mention in my steps, I advise HIGHLY you backup your server before performing any operation in the interest of safety.
hi William thanks
I try your suggestion, still the same issue. I can use the same password Again and Again. Ok we have another instance which doesn't had 75ppolicy.ldif, it might be one of my old test.
I expect a few lines like this, but still none. What can it be.
passwordHistory: 20120406112810Z{MD5}n4FvoktOtH67j1hq0pOE7A== passwordHistory: 20120408114445Z{MD5}gHyopyulMLfEujDGXVT+Qg== passwordHistory: 20120409073023Z{MD5}yJg78a58b3n+TOrb/vdG5w== passwordHistory: 20120409150444Z{crypt}mpnaRmjC9mcbw
export from the database # entry-id: 35 dn: cn=Tuan Nguyen,cn=unixtek,ou=Infrastructure,dc=nnit passwordExpWarned: 0 passwordExpirationTime: 19700101000000Z passwordGraceUserTime: 0 modifyTimestamp: 20170227211857Z modifiersName: cn=server,cn=plugins,cn=config userPassword:: e1NTSEF9cVRnVG5BU3hlY1F0S2VDeVYweVZGVDRMU0dnam1raHJrUzIza3c9PQ= = cn: Tuan Nguyen gidNumber: 804 homeDirectory: /home/tnng loginShell: /bin/bash objectClass: top objectClass: posixaccount uidNumber: 1234 uid: tnng creatorsName: cn=directory manager createTimestamp: 20170114110541Z nsUniqueId: 449d3501-da4911e6-9d7ddec4-bc02e5f0
br Tuan
On 02/26/2017 10:57 AM, tuan88@gmail.com wrote:
Hi with the new 1.2.2-1 389* the user can resure the same password Again & Again, the passwordhistory stop to Work and not showing anymore.
passwordHistory is not set in your policy config, thus it is not being enforced:
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/ht...
see my test below. It is the first time i get this kind of issue
[root@centos6 ~]# rpm -qa|grep 389 389-console-1.1.7-1.el6.noarch 389-adminutil-1.1.19-1.el6.x86_64 389-ds-console-1.2.6-1.el6.noarch 389-ds-1.2.2-1.el6.noarch 389-ds-base-libs-1.2.11.15-85.el6_8.x86_64 389-admin-1.1.35-1.el6.x86_64 389-admin-console-1.1.8-1.el6.noarch 389-ds-base-1.2.11.15-85.el6_8.x86_64
[root@centos6 scripts]# cat test_passwd_history.ksh #!/bin/ksh #Ldap test passwd if it is expired or not - tng 20170226 ldapsearch -xLLL -ZZ -b dc=nnit '(&(uid=tnng))' passwordRetryCount passwordExpWarned accountUnlockTime passwordExpirationTime passwordHistory createtimestamp modifytimestamp retryCountResetTime passwordAllowChangeTime nsRoleDN ldappasswd -s 123 -w 12345678 -x -ZZ -D cn='directory manager' cn='Tuan Nguyen,cn=unixtek,ou=Infrastructure,dc=nnit'
[root@centos6 scripts]# ./test_passwd_history.ksh dn: cn=Tuan Nguyen,cn=unixtek,ou=Infrastructure,dc=nnit passwordExpWarned: 0 passwordExpirationTime: 19700101000000Z createtimestamp: 20170114110541Z modifytimestamp: 20170226085143Z [root@centos6 scripts]# ./test_passwd_history.ksh dn: cn=Tuan Nguyen,cn=unixtek,ou=Infrastructure,dc=nnit passwordExpWarned: 0 passwordExpirationTime: 19700101000000Z createtimestamp: 20170114110541Z modifytimestamp: 20170226091223Z [root@centos6 scripts]# ./test_passwd_history.ksh dn: cn=Tuan Nguyen,cn=unixtek,ou=Infrastructure,dc=nnit passwordExpWarned: 0 passwordExpirationTime: 19700101000000Z createtimestamp: 20170114110541Z modifytimestamp: 20170226091224Z [root@centos6 scripts]#
policy [root@centos6 scripts]# ldapsearch -xLLL -ZZ -b cn='cn\3DnsPwPolicyEntry\2Cou\3DInfrastructure\2Cdc\3Dnnit,cn=nsPwPolicyContainer,ou=Infrastructure,dc=nnit' -s base '(&(objectclass=passwordpolicy))' dn: cn=cn\3DnsPwPolicyEntry\2Cou\3DInfrastructure\2Cdc\3Dnnit,cn=nsPwPolicyCon tainer,ou=Infrastructure,dc=nnit passwordStorageScheme: ssha passwordGraceLimit: 1 passwordChange: on passwordWarning: 86400 passwordMinAge: 0 passwordExp: on passwordMustChange: on passwordMaxAge: 86400 objectClass: ldapsubentry objectClass: passwordpolicy objectClass: top cn: cn=nsPwPolicyEntry,ou=Infrastructure,dc=nnit
Policy settings from GUI: www.chezmoi.dk/389-passwd-not-expire.png _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
On 02/28/17 08:25 AM, tuan88@gmail.com wrote:
h
passwordHistory is not set in your policy config, thus it is not beingen forced:
yes it is, i had set it the last many years pls see the screendump in my first thread
Policy settings from GUI: www.chezmoi.dk/389-passwd-not-expire.png
bt Tuan _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
Hi all,
I can confirm that something is wrong, also in 389-ds-base-1.3.5.14 (e.g. also having same problem).
Some users are not forced to change password although it has been expired upon rules of our PP, and that is purely random situation... Moreover, I have not found anything which might cause it.
What would be best way to debug that (considering that it does not happen so often, so switching debug log to any of values from https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/h... could be not so useful)?
With best regards. Predrag Zečević
On 02/28/2017 04:25 AM, Predrag Zečević - Technical Support Analyst wrote:
On 02/28/17 08:25 AM, tuan88@gmail.com wrote:
h
passwordHistory is not set in your policy config, thus it is not beingen forced:
yes it is, i had set it the last many years pls see the screendump in my first thread
Policy settings from GUI: www.chezmoi.dk/389-passwd-not-expire.png
bt Tuan _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
Hi all,
I can confirm that something is wrong, also in 389-ds-base-1.3.5.14 (e.g. also having same problem).
Make sure you are NOT using Directory manager to change passwords. Directory manager bypasses password policies.
Some users are not forced to change password although it has been expired upon rules of our PP, and that is purely random situation... Moreover, I have not found anything which might cause it.
What would be best way to debug that (considering that it does not happen so often, so switching debug log to any of values from https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/h... could be not so useful)?
With best regards. Predrag Zečević
On 02/28/17 02:13 PM, Mark Reynolds wrote:
On 02/28/2017 04:25 AM, Predrag Zečević - Technical Support Analyst wrote:
On 02/28/17 08:25 AM, tuan88@gmail.com wrote:
h
passwordHistory is not set in your policy config, thus it is not beingen forced:
yes it is, i had set it the last many years pls see the screendump in my first thread
Policy settings from GUI: www.chezmoi.dk/389-passwd-not-expire.png
bt Tuan _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
Hi all,
I can confirm that something is wrong, also in 389-ds-base-1.3.5.14 (e.g. also having same problem).
Make sure you are NOT using Directory manager to change passwords. Directory manager bypasses password policies.
Thanks, that might be a reason. I will make note and check scripts.
With best regards. Predrag Zečević
Some users are not forced to change password although it has been expired upon rules of our PP, and that is purely random situation... Moreover, I have not found anything which might cause it.
What would be best way to debug that (considering that it does not happen so often, so switching debug log to any of values from https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/h... could be not so useful)?
With best regards. Predrag Zečević
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
On 02/28/2017 08:45 AM, Predrag Zečević - Technical Support Analyst wrote:
On 02/28/17 02:13 PM, Mark Reynolds wrote:
On 02/28/2017 04:25 AM, Predrag Zečević - Technical Support Analyst wrote:
On 02/28/17 08:25 AM, tuan88@gmail.com wrote:
h
passwordHistory is not set in your policy config, thus it is not beingen forced:
yes it is, i had set it the last many years pls see the screendump in my first thread
Policy settings from GUI: www.chezmoi.dk/389-passwd-not-expire.png
bt Tuan _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
Hi all,
I can confirm that something is wrong, also in 389-ds-base-1.3.5.14 (e.g. also having same problem).
Make sure you are NOT using Directory manager to change passwords. Directory manager bypasses password policies.
Thanks, that might be a reason. I will make note and check scripts.
On a side note - this is documented in the Administration guide.
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/ht...
This doc refers to the Directory Manager account as the root DN, which is correct but could be confusing. This could be "clearer" so I've opened a doc bug on this.
Regards, Mark
With best regards. Predrag Zečević
Some users are not forced to change password although it has been expired upon rules of our PP, and that is purely random situation... Moreover, I have not found anything which might cause it.
What would be best way to debug that (considering that it does not happen so often, so switching debug log to any of values from https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/h...
could be not so useful)?
With best regards. Predrag Zečević
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
On 02/28/17 03:15 PM, Mark Reynolds wrote:
I can confirm that something is wrong, also in 389-ds-base-1.3.5.14 (e.g. also having same problem).
Make sure you are NOT using Directory manager to change passwords. Directory manager bypasses password policies.
Thanks, that might be a reason. I will make note and check scripts.
On a side note - this is documented in the Administration guide.
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/ht...
This doc refers to the Directory Manager account as the root DN, which is correct but could be confusing. This could be "clearer" so I've opened a doc bug on this.
Regards, Mark
Hi Mark,
I have checked scripts and found following - for changing password we have 2 scenarios: a) user changes it self (via PHP web interface - that works fine BTW) b) member of group "Directory Administrators" (with proper ACI) changes it for user (from shell script - works fine)
I have cases that user IS able to authorize against LDAP even if password has been expired... In global password policy we have set this:
passwordMaxAge: 31536000 # 365 days (I guess that is default)
In local one (per user policy "cn=nsPwPolicyContainer,ou=people,dc=2e-systems,dc=com") we have redefined that value:
passwordMaxAge: 7776000 # which is 90 days
Can be that be a problem? User name is replaced in output below:
#========================================= Global PP Setup === # ldapsearch -xLLL -D "cn=Directory Manager" -b 'cn=config' -s base 'objectClass=*' '*' passwordHistory | grep ^password passwordInHistory: 7 passwordUnlock: on passwordGraceLimit: 3 passwordMustChange: off passwordWarning: 604800 passwordLockout: on passwordMinLength: 8 passwordMinDigits: 1 passwordMinAlphas: 1 passwordMinUppers: 1 passwordMinLowers: 1 passwordMinSpecials: 0 passwordMin8bit: 0 passwordMaxRepeats: 0 passwordMinCategories: 4 passwordMinTokenLength: 3 passwordMaxFailure: 3 passwordMaxAge: 31536000 passwordResetFailureCount: 1800 passwordIsGlobalPolicy: on passwordLegacyPolicy: on passwordTrackUpdateTime: off passwordChange: on passwordExp: off passwordSendExpiringTime: off passwordLockoutDuration: 3600 passwordCheckSyntax: on passwordMinAge: 0 passwordStorageScheme: SSHA passwordAdminDN: passwordHistory: on
#========================================= User PP setup === # ldapsearch -xLLL -D "cn=Directory Manager" -b "cn=nsPwPolicyContainer,ou=people,dc=2e-systems,dc=com" "(&(objectClass=ldapsubentry)(objectClass=passwordPolicy)(cn=*GivenName Surname*))" dn: cn=cn\3DnsPwPolicyEntry\2Ccn\3Dgivenname surname\2Cou\3Dpeople\2Cdc\3D2e-s ystems\2Cdc\3Dcom,cn=nsPwPolicyContainer,ou=People,dc=2e-systems,dc=com passwordInHistory: 5 passwordMinAge: 600 passwordChange: on passwordUnlock: on passwordLockoutDuration: 1800 passwordResetFailureCount: 600 passwordLockout: on passwordMaxFailure: 10 passwordMaxRepeats: 0 passwordStorageScheme: ssha passwordMaxAge: 7776000 passwordExp: on passwordGraceLimit: 6 passwordMin8bit: 0 passwordMinAlphas: 0 passwordMinSpecials: 1 passwordMinDigits: 1 passwordMinLowers: 1 passwordMinUppers: 1 passwordMinTokenLength: 5 passwordMinCategories: 4 passwordMinLength: 8 passwordCheckSyntax: on passwordMustChange: off objectClass: top objectClass: ldapsubentry objectClass: passwordpolicy cn: cn=nsPwPolicyEntry,cn=givenname surname,ou=people,dc=2e-systems,dc=com
#========================================= User DN Setup === # ldapsearch -xLLL -D "cn=Directory Manager" -b "dc=2e-systems,dc=com" "(&(objectclass=additionalPersonalData)(cn=GivenName Surname))" dn: cn=GivenName Surname,ou=People,dc=2e-systems,dc=com passwordExpirationTime: 20170223113208Z passwordExpWarned: 0 passwordGraceUserTime: 2 passwordRetryCount: 0 passwordAllowChangeTime: 20161125114208Z passwordHistory: 20151015062612Z{SSHA}yFVx6mQasMSPFIb1cgrEMPQoxDYgLk3Lnl5MWA== passwordHistory: 20160331065019Z{SSHA}kRLwA3OjzKnmsYwk31dIHHWEZWIO2P3RISBXxQ== passwordHistory: 20160622062736Z{SSHA}P8iQemcypxBwWaFOaqcJe+KLNTFyNrNxBT3VAw== passwordHistory: 20160915064325Z{SSHA}a9WrOm5IDrhc3mN+P9DmHGj6QZl4ZpWGLbRQ/w== passwordHistory: 20161125113208Z{SSHA}peCYxS8AY7t7HagqdDeyXTTTJHMNNErOkGHcEg==
In this last output one can see that password has expired at 20170223113208Z - but user still can log-in into LDAP?
What could be wrong here?
With best regards. Predrag Zečević
On 03/03/2017 10:23 AM, Predrag Zečević - Technical Support Analyst wrote:
On 02/28/17 03:15 PM, Mark Reynolds wrote:
I can confirm that something is wrong, also in 389-ds-base-1.3.5.14 (e.g. also having same problem).
Make sure you are NOT using Directory manager to change passwords. Directory manager bypasses password policies.
Thanks, that might be a reason. I will make note and check scripts.
On a side note - this is documented in the Administration guide.
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/ht...
This doc refers to the Directory Manager account as the root DN, which is correct but could be confusing. This could be "clearer" so I've opened a doc bug on this.
Regards, Mark
Hi Mark,
I have checked scripts and found following - for changing password we have 2 scenarios: a) user changes it self (via PHP web interface - that works fine BTW) b) member of group "Directory Administrators" (with proper ACI) changes it for user (from shell script - works fine)
I have cases that user IS able to authorize against LDAP even if password has been expired... In global password policy we have set this:
passwordMaxAge: 31536000 # 365 days (I guess that is default)
In local one (per user policy "cn=nsPwPolicyContainer,ou=people,dc=2e-systems,dc=com") we have redefined that value:
passwordMaxAge: 7776000 # which is 90 days
Can be that be a problem? User name is replaced in output below:
#========================================= Global PP Setup === # ldapsearch -xLLL -D "cn=Directory Manager" -b 'cn=config' -s base 'objectClass=*' '*' passwordHistory | grep ^password passwordInHistory: 7 passwordUnlock: on passwordGraceLimit: 3 passwordMustChange: off passwordWarning: 604800 passwordLockout: on passwordMinLength: 8 passwordMinDigits: 1 passwordMinAlphas: 1 passwordMinUppers: 1 passwordMinLowers: 1 passwordMinSpecials: 0 passwordMin8bit: 0 passwordMaxRepeats: 0 passwordMinCategories: 4 passwordMinTokenLength: 3 passwordMaxFailure: 3 passwordMaxAge: 31536000 passwordResetFailureCount: 1800 passwordIsGlobalPolicy: on passwordLegacyPolicy: on passwordTrackUpdateTime: off passwordChange: on passwordExp: off passwordSendExpiringTime: off passwordLockoutDuration: 3600 passwordCheckSyntax: on passwordMinAge: 0 passwordStorageScheme: SSHA passwordAdminDN: passwordHistory: on
#========================================= User PP setup === # ldapsearch -xLLL -D "cn=Directory Manager" -b "cn=nsPwPolicyContainer,ou=people,dc=2e-systems,dc=com" "(&(objectClass=ldapsubentry)(objectClass=passwordPolicy)(cn=*GivenName Surname*))"
dn: cn=cn\3DnsPwPolicyEntry\2Ccn\3Dgivenname surname\2Cou\3Dpeople\2Cdc\3D2e-s ystems\2Cdc\3Dcom,cn=nsPwPolicyContainer,ou=People,dc=2e-systems,dc=com passwordInHistory: 5 passwordMinAge: 600 passwordChange: on passwordUnlock: on passwordLockoutDuration: 1800 passwordResetFailureCount: 600 passwordLockout: on passwordMaxFailure: 10 passwordMaxRepeats: 0 passwordStorageScheme: ssha passwordMaxAge: 7776000 passwordExp: on passwordGraceLimit: 6 passwordMin8bit: 0 passwordMinAlphas: 0 passwordMinSpecials: 1 passwordMinDigits: 1 passwordMinLowers: 1 passwordMinUppers: 1 passwordMinTokenLength: 5 passwordMinCategories: 4 passwordMinLength: 8 passwordCheckSyntax: on passwordMustChange: off objectClass: top objectClass: ldapsubentry objectClass: passwordpolicy cn: cn=nsPwPolicyEntry,cn=givenname surname,ou=people,dc=2e-systems,dc=com
#========================================= User DN Setup === # ldapsearch -xLLL -D "cn=Directory Manager" -b "dc=2e-systems,dc=com" "(&(objectclass=additionalPersonalData)(cn=GivenName Surname))" dn: cn=GivenName Surname,ou=People,dc=2e-systems,dc=com passwordExpirationTime: 20170223113208Z passwordExpWarned: 0 passwordGraceUserTime: 2 passwordRetryCount: 0 passwordAllowChangeTime: 20161125114208Z passwordHistory: 20151015062612Z{SSHA}yFVx6mQasMSPFIb1cgrEMPQoxDYgLk3Lnl5MWA== passwordHistory: 20160331065019Z{SSHA}kRLwA3OjzKnmsYwk31dIHHWEZWIO2P3RISBXxQ== passwordHistory: 20160622062736Z{SSHA}P8iQemcypxBwWaFOaqcJe+KLNTFyNrNxBT3VAw== passwordHistory: 20160915064325Z{SSHA}a9WrOm5IDrhc3mN+P9DmHGj6QZl4ZpWGLbRQ/w== passwordHistory: 20161125113208Z{SSHA}peCYxS8AY7t7HagqdDeyXTTTJHMNNErOkGHcEg==
In this last output one can see that password has expired at 20170223113208Z - but user still can log-in into LDAP?
What could be wrong here?
you have configured a passwordGraceLimit: 6
which means the user can login 6 times after the pw expired
With best regards. Predrag Zečević
On 02/28/2017 02:25 AM, tuan88@gmail.com wrote:
h
passwordHistory is not set in your policy config, thus it is not beingen forced:
yes it is, i had set it the last many years pls see the screendump in my first thread
But you are using subtree policies, these override the global policy. You need set to passwordHistory in your subtree policy:
dn: cn=cn\3DnsPwPolicyEntry\2Cou\3DInfrastructure\2Cdc\3Dnnit,cn=nsPwPolicyContainer,ou=Infrastructure,dc=nnit passwordStorageScheme: ssha passwordGraceLimit: 1 passwordChange: on passwordWarning: 86400 passwordMinAge: 0 passwordExp: on passwordMustChange: on passwordMaxAge: 86400 objectClass: ldapsubentry objectClass: passwordpolicy objectClass: top cn: cn=nsPwPolicyEntry,ou=Infrastructure,dc=nnit *passwordHistory: 12*
Also it looks like the passwords were never reset by the actual user. Hence the passwordExpirationtime is still set to the EPOCH date.
Note - the Directory Manager account completely bypasses password policy. So if you change the password as directory manager it will let you do whatever you want. So make sure you always change passwords as a "database user" if you expect password policies to be enforced.
This is why client applications should NEVER use directory manager - it is an unrestricted account.
Policy settings from GUI: www.chezmoi.dk/389-passwd-not-expire.png
bt Tuan _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
hi all
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8....
thank for the tip I will try it
But you are using subtree policies, these override the global policy. You need set to passwordHistory in your subtree policy:
?? I set at the global (see again my screendump from the 1 thread) , at the "DATA" tree. YES it has been work at least 3 Y
So if you change the password as directory manager it will let you do whatever you want. So make sure you always change passwords as a
"database user" if you expect password policies to be enforced.
Not correct, below is a test from another LDAP instance with the same ldap version. This ldap setup passwordhistory work fortunately.
let us test again: the password is in the test script and I do it as directory manager (see the tes script at the first thread)
[root@centos ldap]# ./test_passwd_history.ksh dn: cn=Tuan Test,cn=unixtek,ou=Infrastructure,dc=centos passwordRetryCount: 0 passwordExpWarned: 0 passwordExpirationTime: 19700101000000Z passwordHistory: 20170227155538Z{crypt}6JpUMxrkKWlAE passwordHistory: 20170227155900Z{crypt}N3fSq/dQumt.M passwordHistory: 20170227155956Z{crypt}d9gk5RmC/p/mM passwordHistory: 20170227160009Z{crypt}VVdJ0STcpFZ5E passwordHistory: 20170227161428Z{crypt}3NiVtBZZRLt2c passwordHistory: 20170228164119Z{crypt}mBGEwcpLcNCgU passwordHistory: 20170301104202Z{crypt}LBI9oRjH/5Igs createtimestamp: 20170127162440Z modifytimestamp: 20170301105634Z retryCountResetTime: 20170207200155Z
succesful
[root@centos ldap]# ./test_passwd_history.ksh dn: cn=Tuan Test,cn=unixtek,ou=Infrastructure,dc=centos passwordRetryCount: 0 passwordExpWarned: 0 passwordExpirationTime: 19700101000000Z passwordHistory: 20170227155538Z{crypt}6JpUMxrkKWlAE passwordHistory: 20170227155900Z{crypt}N3fSq/dQumt.M passwordHistory: 20170227155956Z{crypt}d9gk5RmC/p/mM passwordHistory: 20170227160009Z{crypt}VVdJ0STcpFZ5E passwordHistory: 20170227161428Z{crypt}3NiVtBZZRLt2c passwordHistory: 20170228164119Z{crypt}mBGEwcpLcNCgU passwordHistory: 20170301104202Z{crypt}LBI9oRjH/5Igs passwordHistory: 20170301145159Z{crypt}8LrUk1IX67Ivg createtimestamp: 20170127162440Z modifytimestamp: 20170301145159Z retryCountResetTime: 20170207200155Z passwordAllowChangeTime: 20170302145159Z Result: Constraint violation (19) Additional info: Failed to update password
it failed second time due to passwordAllowChangeTime: . I deleted that entry now
[root@centos ldap]# ./test_passwd_history.ksh dn: cn=Tuan Test,cn=unixtek,ou=Infrastructure,dc=centos passwordRetryCount: 0 passwordExpWarned: 0 passwordExpirationTime: 19700101000000Z passwordHistory: 20170227155538Z{crypt}6JpUMxrkKWlAE passwordHistory: 20170227155900Z{crypt}N3fSq/dQumt.M passwordHistory: 20170227155956Z{crypt}d9gk5RmC/p/mM passwordHistory: 20170227160009Z{crypt}VVdJ0STcpFZ5E passwordHistory: 20170227161428Z{crypt}3NiVtBZZRLt2c passwordHistory: 20170228164119Z{crypt}mBGEwcpLcNCgU passwordHistory: 20170301104202Z{crypt}LBI9oRjH/5Igs passwordHistory: 20170301145159Z{crypt}8LrUk1IX67Ivg createtimestamp: 20170127162440Z modifytimestamp: 20170301160930Z retryCountResetTime: 20170207200155Z Result: Constraint violation (19) Additional info: Failed to update password
[root@centos ldap]#
failed due to passwordhistory, not allow to use the same password again
[root@centos ldap]# cat ./test_passwd_history.ksh #!/bin/ksh #Ldap test passwd if it is expired or not - tng 20170226 ldapsearch -xLLL -ZZ -b dc=centos '(&(uid=tnng2))' userPassword passwordRetryCount passwordExpWarned accountUnlockTime passwordExpirationTime passwordHistory createtimestamp modifytimestamp retryCountResetTime passwordAllowChangeTime nsRoleDN ldappasswd -s Ja#%==TNG8 -w SECRET! -x -ZZ -D cn='directory manager' cn='Tuan Test,cn=unixtek,ou=Infrastructure,dc=centos'
br Tuan
On 03/01/2017 08:15 AM, tuan88@gmail.com wrote:
So if you change the password as directory manager it will let you do whatever you want. So make sure you always change passwords as a "database user" if you expect password policies to be enforced.
Not correct, below is a test from another LDAP instance with the same ldap version.
...
ldappasswd -s Ja#%==TNG8 -w SECRET! -x -ZZ -D cn='directory manager' cn='Tuan Test,cn=unixtek,ou=Infrastructure,dc=centos'
Without trying to diagnose the reason that "Directory Manager" is not successfully changing the password in your tests, it remains true that "Directory Manager" is *designed* to bypass constraints. Until you can reproduce the problem of changing an LDAP password using a database user, you aren't providing evidence of a bug. The system is working the way it is supposed to.
If you can demonstrate the problem using a database user instead of "Directory Manager", we can troubleshoot further.
hi
Here you are. with those 2 pasword below I can use them to "passwd" again & Again as user "tnng" !Ca4nn12 !H0yda23
[tnng@centos6 ~]$ passwd Changing password for user tnng. Current Password: New password: Retype new password: passwd: all authentication tokens updated successfully. [tnng@centos6 ~]$ passwd Changing password for user tnng. Current Password: New password: Retype new password: passwd: all authentication tokens updated successfully. [tnng@centos6 ~]$ passwd Changing password for user tnng. Current Password: New password: Retype new password: passwd: all authentication tokens updated successfully. [tnng@centos6 ~]$ passwd Changing password for user tnng. Current Password: New password: Retype new password: passwd: all authentication tokens updated successfully. [tnng@centos6 ~]$
[root@centos6 scripts]# ldapsearch -xLLL -ZZ -b dc=centos '(&(uid=tnng))' passwordRetryCount passwordExpWarned accountUnlockTime passwordExpirationTime passwordHistory createtimestamp modifytimestamp retryCountResetTime passwordAllowChangeTime nsRoleDN
dn: cn=Tuan Nguyen,cn=unixtek,ou=Infrastructure,dc=centos passwordExpWarned: 0 passwordExpirationTime: 20170302203205Z createtimestamp: 20170114110541Z modifytimestamp: 20170301203205Z
# entry-id: 60 dn: cn=Tuan Nguyen,cn=unixtek,ou=Infrastructure,dc=centos passwordExpWarned: 0 passwordExpirationTime: 20170302204127Z passwordGraceUserTime: 0 modifyTimestamp: 20170301204127Z modifiersName: cn=server,cn=plugins,cn=config userPassword:: e1NTSEF9RVFlNlgva2o4cCsvdVNRZis3NDROQnJzdEx6a1EzWGN6clNTWlE9PQ= = loginShell: /bin/bash uidNumber: 1234 gidNumber: 804 uid: tnng objectClass: top objectClass: posixaccount cn: Tuan Nguyen homeDirectory: /home/tnng creatorsName: cn=directory manager createTimestamp: 20170301203823Z nsUniqueId: ffc94351-febe11e6-9d7ddec4-bc02e5f0
# entry-id: 61
enable log: 128 Access control list processing 2048 Log entry parsing. Logs schema parsing debugging information.
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/h...
stop dirsrv nsslapd-errorlog-level: 2176 (128+2048) (dse.ldif) start dirsrv
the log "errors" is attached OR at www.chezmoi.dk/div/errors
[root@centos6 slapd-centos]# cat /etc/sssd/sssd.conf [sssd] config_file_version = 2 services = nss, pam domains = default debug_level = 5 debug_to_files = true
[nss] enum_cache_timeout = 30 filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
[domain/default] auth_provider = ldap ldap_tls_cacertdir = /etc/openldap/cacerts #ldap_id_use_start_tls = True chpass_provider = ldap ldap_search_base = dc=CENTOS id_provider = ldap enumerate = True #cache_credentials = True offline_credentials_expiration = 3 ldap_uri = ldap://centos6.site,ldap://centos62.site
On 03/01/2017 04:25 PM, tuan88@gmail.com wrote:
hi
Here you are. with those 2 pasword below I can use them to "passwd" again & Again as user "tnng"
Can you paste some access log output showing these password updates? passwd could still be using Directory Manager to set the passwords.
!Ca4nn12 !H0yda23
[tnng@centos6 ~]$ passwd Changing password for user tnng. Current Password: New password: Retype new password: passwd: all authentication tokens updated successfully. [tnng@centos6 ~]$ passwd Changing password for user tnng. Current Password: New password: Retype new password: passwd: all authentication tokens updated successfully. [tnng@centos6 ~]$ passwd Changing password for user tnng. Current Password: New password: Retype new password: passwd: all authentication tokens updated successfully. [tnng@centos6 ~]$ passwd Changing password for user tnng. Current Password: New password: Retype new password: passwd: all authentication tokens updated successfully. [tnng@centos6 ~]$
[root@centos6 scripts]# ldapsearch -xLLL -ZZ -b dc=centos '(&(uid=tnng))' passwordRetryCount passwordExpWarned accountUnlockTime passwordExpirationTime passwordHistory createtimestamp modifytimestamp retryCountResetTime passwordAllowChangeTime nsRoleDN
dn: cn=Tuan Nguyen,cn=unixtek,ou=Infrastructure,dc=centos passwordExpWarned: 0 passwordExpirationTime: 20170302203205Z createtimestamp: 20170114110541Z modifytimestamp: 20170301203205Z
# entry-id: 60 dn: cn=Tuan Nguyen,cn=unixtek,ou=Infrastructure,dc=centos passwordExpWarned: 0 passwordExpirationTime: 20170302204127Z passwordGraceUserTime: 0 modifyTimestamp: 20170301204127Z modifiersName: cn=server,cn=plugins,cn=config userPassword:: e1NTSEF9RVFlNlgva2o4cCsvdVNRZis3NDROQnJzdEx6a1EzWGN6clNTWlE9PQ= = loginShell: /bin/bash uidNumber: 1234 gidNumber: 804 uid: tnng objectClass: top objectClass: posixaccount cn: Tuan Nguyen homeDirectory: /home/tnng creatorsName: cn=directory manager createTimestamp: 20170301203823Z nsUniqueId: ffc94351-febe11e6-9d7ddec4-bc02e5f0
# entry-id: 61
enable log: 128 Access control list processing 2048 Log entry parsing. Logs schema parsing debugging information.
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/h...
stop dirsrv nsslapd-errorlog-level: 2176 (128+2048) (dse.ldif) start dirsrv
the log "errors" is attached OR at www.chezmoi.dk/div/errors
[root@centos6 slapd-centos]# cat /etc/sssd/sssd.conf [sssd] config_file_version = 2 services = nss, pam domains = default debug_level = 5 debug_to_files = true
[nss] enum_cache_timeout = 30 filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
[domain/default] auth_provider = ldap ldap_tls_cacertdir = /etc/openldap/cacerts #ldap_id_use_start_tls = True chpass_provider = ldap ldap_search_base = dc=CENTOS id_provider = ldap enumerate = True #cache_credentials = True offline_credentials_expiration = 3 ldap_uri = ldap://centos6.site,ldap://centos62.site _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
On 03/01/2017 04:30 PM, Mark Reynolds wrote:
On 03/01/2017 04:25 PM, tuan88@gmail.com wrote:
hi
Here you are. with those 2 pasword below I can use them to "passwd" again & Again as user "tnng"
Can you paste some access log output showing these password updates? passwd could still be using Directory Manager to set the passwords.
!Ca4nn12 !H0yda23
[tnng@centos6 ~]$ passwd Changing password for user tnng. Current Password: New password: Retype new password: passwd: all authentication tokens updated successfully. [tnng@centos6 ~]$ passwd Changing password for user tnng. Current Password: New password: Retype new password: passwd: all authentication tokens updated successfully. [tnng@centos6 ~]$ passwd Changing password for user tnng. Current Password: New password: Retype new password: passwd: all authentication tokens updated successfully. [tnng@centos6 ~]$ passwd Changing password for user tnng. Current Password: New password: Retype new password: passwd: all authentication tokens updated successfully. [tnng@centos6 ~]$
[root@centos6 scripts]# ldapsearch -xLLL -ZZ -b dc=centos '(&(uid=tnng))' passwordRetryCount passwordExpWarned accountUnlockTime passwordExpirationTime passwordHistory createtimestamp modifytimestamp retryCountResetTime passwordAllowChangeTime nsRoleDN
I also don't see passwordhistory in your user entries - another sign that you are using directory manger to update the password, or you have not set the passwordHistory in your password policy. Like I said before you are using two passwords policies (local and global). The subtree policy(local policy) overrides the global policy. So if you don't add passwordHistory to your local subtree password policy, which appears to span all your users, then it's also not going to work.
I suggest you pick one or the other, but not both. Is there a reason you are using two policies?
dn: cn=Tuan Nguyen,cn=unixtek,ou=Infrastructure,dc=centos passwordExpWarned: 0 passwordExpirationTime: 20170302203205Z createtimestamp: 20170114110541Z modifytimestamp: 20170301203205Z
# entry-id: 60 dn: cn=Tuan Nguyen,cn=unixtek,ou=Infrastructure,dc=centos passwordExpWarned: 0 passwordExpirationTime: 20170302204127Z passwordGraceUserTime: 0 modifyTimestamp: 20170301204127Z modifiersName: cn=server,cn=plugins,cn=config userPassword:: e1NTSEF9RVFlNlgva2o4cCsvdVNRZis3NDROQnJzdEx6a1EzWGN6clNTWlE9PQ= = loginShell: /bin/bash uidNumber: 1234 gidNumber: 804 uid: tnng objectClass: top objectClass: posixaccount cn: Tuan Nguyen homeDirectory: /home/tnng creatorsName: cn=directory manager createTimestamp: 20170301203823Z nsUniqueId: ffc94351-febe11e6-9d7ddec4-bc02e5f0
# entry-id: 61
enable log: 128 Access control list processing 2048 Log entry parsing. Logs schema parsing debugging information.
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/h...
stop dirsrv nsslapd-errorlog-level: 2176 (128+2048) (dse.ldif) start dirsrv
the log "errors" is attached OR at www.chezmoi.dk/div/errors
[root@centos6 slapd-centos]# cat /etc/sssd/sssd.conf [sssd] config_file_version = 2 services = nss, pam domains = default debug_level = 5 debug_to_files = true
[nss] enum_cache_timeout = 30 filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
[domain/default] auth_provider = ldap ldap_tls_cacertdir = /etc/openldap/cacerts #ldap_id_use_start_tls = True chpass_provider = ldap ldap_search_base = dc=CENTOS id_provider = ldap enumerate = True #cache_credentials = True offline_credentials_expiration = 3 ldap_uri = ldap://centos6.site,ldap://centos62.site _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
hi mark
Again, never use the "local subtree password policy", I dont know how and I never want to use it. I prefer the global one, see Again this screendump
www.chezmoi.dk/389-passwd-not-expire.png
it is how I set the password policy, only one place not other place. I attach the ldif for the whole database here so you can see the settings.
www.chezmoi.dk/centos.new.ldif
On 03/02/2017 06:06 PM, tuan88@gmail.com wrote:
hi mark
Again, never use the "local subtree password policy",
Yes you are:
[root@centos6 scripts]# ldapsearch -xLLL -ZZ -b cn='cn\3DnsPwPolicyEntry\2Cou\3DInfrastructure\2Cdc\3Dnnit,cn=nsPwPolicyContainer,ou=Infrastructure,dc=nnit' -s base '(&(objectclass=passwordpolicy))' dn: cn=cn\3DnsPwPolicyEntry\2Cou\3DInfrastructure\2Cdc\3Dnnit,cn=nsPwPolicyCon tainer,ou=Infrastructure,dc=nnit
Remove this entry
dn: cn=cn\3DnsPwPolicyEntry\2Cou\3DInfrastructure\2Cdc\3Dnnit,cn=nsPwPolicyContainer,ou=Infrastructure,dc=nnit
I dont know how and I never want to use it. I prefer the global one, see Again this screendump
www.chezmoi.dk/389-passwd-not-expire.png
it is how I set the password policy, only one place not other place. I attach the ldif for the whole database here so you can see the settings.
www.chezmoi.dk/centos.new.ldif _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
hi All
thanks it is solved by now
Mark, sorry I didn't realized it was set at my home setup. I found it from GUI -> the organisation > right click -> manage passwrd policy -> subtree , it was SET
i had unflag, it Works now as it should. MANY thanks for your patience.
[root@centos6 ~]# ldapsearch -xLLL -ZZ -b dc=centos '(&(uid=tnng))' passwordRetryCount passwordExpWarned accountUnlockTime passwordExpirationTime passwordHistory createtimestamp modifytimestamp retryCountResetTime passwordAllowChangeTime nsRoleDN dn: cn=Tuan Nguyen,cn=unixtek,ou=Infrastructure,dc=centos passwordRetryCount: 0 passwordExpWarned: 0 passwordExpirationTime: 19700101000000Z passwordHistory: 20170304222529Z{SSHA}AojU851CxYPIxN/VzMyHy18iqPRc+s6TMbeveQ== passwordHistory: 20170304222549Z{SSHA}uhl3WQQzMweRzx/dK+OVrvJ+DcCnVlzT5J2QlA== createtimestamp: 20170301203823Z modifytimestamp: 20170304222549Z passwordAllowChangeTime: 20170305222549Z
On 03/04/2017 05:34 PM, tuan88@gmail.com wrote:
hi All
thanks it is solved by now
Mark, sorry I didn't realized it was set at my home setup. I found it from GUI -> the organisation > right click -> manage passwrd policy -> subtree , it was SET
i had unflag, it Works now as it should. MANY thanks for your patience.
No problem, glad you got it working
[root@centos6 ~]# ldapsearch -xLLL -ZZ -b dc=centos '(&(uid=tnng))' passwordRetryCount passwordExpWarned accountUnlockTime passwordExpirationTime passwordHistory createtimestamp modifytimestamp retryCountResetTime passwordAllowChangeTime nsRoleDN dn: cn=Tuan Nguyen,cn=unixtek,ou=Infrastructure,dc=centos passwordRetryCount: 0 passwordExpWarned: 0 passwordExpirationTime: 19700101000000Z passwordHistory: 20170304222529Z{SSHA}AojU851CxYPIxN/VzMyHy18iqPRc+s6TMbeveQ== passwordHistory: 20170304222549Z{SSHA}uhl3WQQzMweRzx/dK+OVrvJ+DcCnVlzT5J2QlA== createtimestamp: 20170301203823Z modifytimestamp: 20170304222549Z passwordAllowChangeTime: 20170305222549Z _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
here you are www.chezmoi.dk/access
Again it has been work the last 4 years and I dont had the same issue on another ldap instance with the same version
had tried to export (using GUI) -> clear -> import ldif . Nothing change same issue
389-users@lists.fedoraproject.org
-
Gordon Messmer -
Ludwig Krispenz -
Mark Reynolds -
Predrag Zečević - Technical Support Analyst -
tuan88＠gmail.com -
William Brown