[389-users] Yum update disabled ability for user's to update password

2018-05-14 Thread Janet Houser

Hi,

I don't post often so it seems I attached this to an old thread. Sorry 
folks.


I'm using ds-389 (Version 1.3.4.0; Build number 2015.343.1254) on a 
CentOS 7 Server (release 7.4.1708).   A week ago I  performed a "yum 
update" on my system
and now I'm finding  that I can't update (or set) user passwords using 
the "passwd" or  "ldappasswd" commands when the "Password Syntax" (i.e. 
Check password syntax)

policies are enabled.

 I can authenticate fine to a server which is slaved into the ds-389 
server, but issuing the command "passwd" gives the following error:


   --$ passwd
   Changing password for user jdow.
   (current) LDAP Password:
   New password:
   Retype new password:
   password change failed: Constraint violation
   passwd: Authentication token manipulation error

Likewise, I use to be able to run the following command to update a 
user's password from a server:


   ldappasswd  -h themaster  -p 389 -ZZ -D "cn=Directory Manager" -w
   AdminsPassword -s 'UserPassword' "uid=jdoe,ou=People,dc=mydomain,dc=edu"


This command now fails with the erro

   Result: Constraint violation (19
   Additional info: Failed to update password



I had a password policy enabled on my domain subtree but I removed it.   
I then went under "Configuration --> Data" and tried to configure a global
password policy instead.   Each result in the same errors shown above 
whenever I try to enable "Check password syntax".


There's not a great deal of info in /var/log/dirsrv, but in the access 
file I see the following when I run the ldappasswd command:


[14/May/2018:10:37:03.173038139 -0600] conn=104 fd=110 slot=110 
connection from 172.18.194.60 to 172.18.194.4
[14/May/2018:10:37:03.173283856 -0600] conn=104 op=0 EXT 
oid="1.3.6.1.4.1.1466.20037" name="start_tls_plugin"
[14/May/2018:10:37:03.173454544 -0600] conn=104 op=0 RESULT err=0 
tag=120 nentries=0 etime=0

[14/May/2018:10:37:03.267493753 -0600] conn=104 TLS1.2 256-bit AES
[14/May/2018:10:37:03.267938436 -0600] conn=104 op=1 BIND 
dn="cn=Directory Manager" method=128 version=3
[14/May/2018:10:37:03.268224050 -0600] conn=104 op=1 RESULT err=0 tag=97 
nentries=0 etime=0 dn="cn=directory manager"
[14/May/2018:10:37:03.268672168 -0600] conn=104 op=2 EXT 
oid="1.3.6.1.4.1.4203.1.11.1" name="passwd_modify_plugin"
[14/May/2018:10:37:03.269346086 -0600] conn=104 op=2 RESULT err=19 
tag=120 nentries=0 etime=0

[14/May/2018:10:37:03.269832211 -0600] conn=104 op=3 UNBIND
[14/May/2018:10:37:03.269850488 -0600] conn=104 op=3 fd=110 closed - U1


Which looks like it must be failing when the passwd_modify_plugin is run.

I noticed in /etc/dirsrv/slapd-myserver  that there were new schema ldif 
files added during the yum update and I'm wondering if one is stepping 
on my password

policy.

I'm going to try to remove them from the directory (and store them 
elsewhere) to see if the issue disappears, but I'd rather not use a 
hammer to fix a problem.

(update:   Removing the new .ldif files made no difference in the behavior)

I'm grateful for any suggestions.

Thanks,
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org


[389-users] Yum update disabled ability for user's to update password

2018-05-14 Thread Janet Houser

Hi,

I'm using ds-389 (Version 1.3.4.0; Build number 2015.343.1254) on a 
CentOS 7 Server (release 7.4.1708).   A week ago I  performed a "yum 
update" on my system
and now I'm finding  that I can't update (or set) user passwords using 
the "passwd" or  "ldappasswd" commands when the "Password Syntax" (i.e. 
Check password syntax)

policies are enabled.

 I can authenticate fine to a server which is slaved into the ds-389 
server, but issuing the command "passwd" gives the following error:


   --$ passwd
   Changing password for user jdow.
   (current) LDAP Password:
   New password:
   Retype new password:
   password change failed: Constraint violation
   passwd: Authentication token manipulation error

Likewise, I use to be able to run the following command to update a 
user's password from a server:


   ldappasswd  -h themaster  -p 389 -ZZ -D "cn=Directory Manager" -w
   AdminsPassword -s 'UserPassword' "uid=jdoe,ou=People,dc=mydomain,dc=edu"


This command now fails with the erro

   Result: Constraint violation (19
   Additional info: Failed to update password



I had a password policy enabled on my domain subtree but I removed it.   
I then went under "Configuration --> Data" and tried to configure a global
password policy instead.   Each result in the same errors shown above 
whenever I try to enable "Check password syntax".


There's not a great deal of info in /var/log/dirsrv, but in the access 
file I see the following when I run the ldappasswd command:


[14/May/2018:10:37:03.173038139 -0600] conn=104 fd=110 slot=110 
connection from 172.18.194.60 to 172.18.194.4
[14/May/2018:10:37:03.173283856 -0600] conn=104 op=0 EXT 
oid="1.3.6.1.4.1.1466.20037" name="start_tls_plugin"
[14/May/2018:10:37:03.173454544 -0600] conn=104 op=0 RESULT err=0 
tag=120 nentries=0 etime=0

[14/May/2018:10:37:03.267493753 -0600] conn=104 TLS1.2 256-bit AES
[14/May/2018:10:37:03.267938436 -0600] conn=104 op=1 BIND 
dn="cn=Directory Manager" method=128 version=3
[14/May/2018:10:37:03.268224050 -0600] conn=104 op=1 RESULT err=0 tag=97 
nentries=0 etime=0 dn="cn=directory manager"
[14/May/2018:10:37:03.268672168 -0600] conn=104 op=2 EXT 
oid="1.3.6.1.4.1.4203.1.11.1" name="passwd_modify_plugin"
[14/May/2018:10:37:03.269346086 -0600] conn=104 op=2 RESULT err=19 
tag=120 nentries=0 etime=0

[14/May/2018:10:37:03.269832211 -0600] conn=104 op=3 UNBIND
[14/May/2018:10:37:03.269850488 -0600] conn=104 op=3 fd=110 closed - U1


Which looks like it must be failing when the passwd_modify_plugin is run.

I noticed in /etc/dirsrv/slapd-myserver  that there were new schema ldif 
files added during the yum update and I'm wondering if one is stepping 
on my password

policy.

I'm going to try to remove them from the directory (and store them 
elsewhere) to see if the issue disappears, but I'd rather not use a 
hammer to fix a problem.


I'm grateful for any suggestions.

Thanks,
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org