Hi Janet,
On 09/26/2016 06:08 AM, Janet Houser wrote:
On 9/23/16 4:35 PM, Noriko Hosoi wrote:
On 09/23/2016 03:16 PM, Janet Houser wrote:
Hi Noriko,
thanks for the quick response.
On 9/23/16 3:37 PM, Noriko Hosoi wrote:
On 09/23/2016 02:24 PM, Janet Houser wrote:
Hi folks,
I'm fairly new to 389-ds and I ran into an issue when trying to
update a user's password via the command line.
I was able to change a password "as" the user via the command line
using the following syntax without issue:
ldappasswd -h my389dsserver.domain.edu -p 389 -ZZ -D
"uid=jdoe,ou=People,dc=domain,dc=edu" -w current_user_passwd -s
new_user_passwd "uid=jdoe,ou=People,dc=domain,dc=edu"
However, when I tried doing the same thing as the Directory
Manager, it changes the password hash, but it doesn't update the
password. In fact, after
issuing the following command (see below), both the old and new
passwords don't work:
ldappasswd -h my389dsserver.domain.edu -p 389 -ZZ -D "cn=Directory
Manager" -w directorymanager_passwd -s new_user_passwd
"uid=jdoe,ou=People,dc=domain,dc=edu"
Do you see any error messages in
/var/log/dirsrv/slapd-INSTANCE/errors?
No errors reported in /var/log/dirsrv/slapd-INSTANCE/errors when I
run the ldappasswd command with "cn=Directory Manager".
What does this access log file log for the operation?
/var/log/dirsrv/slapd-INSTANCE/access
[23/Sep/2016:15:54:44 -0600] conn=27891 fd=125 slot=125 connection
from XXX.X.XX.10 to XXX.XX.XXX.4
[23/Sep/2016:15:54:44 -0600] conn=27891 op=0 EXT
oid="1.3.6.1.4.1.1466.20037" name="startTLS"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=0 RESULT err=0 tag=120
nentries=0 etime=0
[23/Sep/2016:15:54:44 -0600] conn=27891 TLS1.2 256-bit AES
[23/Sep/2016:15:54:44 -0600] conn=27891 op=1 BIND dn="cn=Directory
Manager" method=128 version=3
[23/Sep/2016:15:54:44 -0600] conn=27891 op=1 RESULT err=0 tag=97
nentries=0 etime=0 dn="cn=directory manager"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=2 EXT
oid="1.3.6.1.4.1.4203.1.11.1" name="passwd_modify_extop"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=2 RESULT err=0 tag=120
nentries=0 etime=0
[23/Sep/2016:15:54:44 -0600] conn=27891 op=3 UNBIND
[23/Sep/2016:15:54:44 -0600] conn=27891 op=3 fd=125 closed - U1
What happens if you run this command line?
$ ldapmodify -h my389dsserver.domain.edu -p 389 -ZZ -D
"cn=Directory Manager" -w directorymanager_passwd << EOF
dn: uid=jdoe,ou=People,dc=domain,dc=edu
changetype: modify
replace: userPassword
userPassword: new_user_passwd
EOF
Is the user's password is set to new_user_passwd?
No, the password fails to be set, and both passwords, old and new,
are now invalid. The output is:
----- keystrokes of issued command ----
# ldapmodify -h my389dsserver.domain.edu -p 389 -ZZ -D "cn=Directory
Manager" -w directorymanager_passwd << EOF
> dn: uid=jdoe,ou=People,dc=domain,dc=edu
> changetype: modify
> replace: userPassword
> userPassword: 123abc!@garbage
> EOF
modifying entry "uid=jdoe,ou=People,dc=domain,dc=edu"
--- end of output ---
I'm puzzled. So, it "acts" like it changes the password by telling
me it is "modifying the entry", but it inserts something into the
password
because the old password and the new password don't work.
Hi Janet,
Could you tell us how you are testing the new password?
Hi Noriko,
Sure! I have several flavors of linux systems all using 389ds as the
authentication server.
I've been testing the new password by trying to ssh to a LDAP system
with the new password (and the old) and both would be rejected with a
"Permission denied" error.
During my testing, I had disabled the Password Syntax, but left the
general Subtree Password Policy applied to my domain.
In an act of desperation, I removed the subtree password policy and
tried to change the password via the command line and it worked! I
was able to
ssh into my servers slaved into LDAP.
I then re-added the identical subtree password policy for my domain
and I could *still* change the password via the command line.
The policy is *exactly* as it was before and is applied to the subtree
of my main domain.
I don't have an explanation. Perhaps something re-initialized by
removing and re-adding the policy.
I tested this procedure again this morning and removed my subtree
password policy on my domain and re-added it. Things still work and I
can ssh into various LDAP clients after I change the user's password
via the command line.
If there's any info you'd like me to gather from my system for you to
analyze, please let me know.
Thanks for all your help!
Cheers,
So, when testing the password, you are using "ssh".
Let me double check your steps.
Using this example:
# ldapmodify -h my389dsserver.domain.edu -p 389 -ZZ -D "cn=Directory
Manager" -w directorymanager_passwd << EOF
> dn: uid=jdoe,ou=People,dc=domain,dc=edu
> changetype: modify
> replace: userPassword
> userPassword: 123abc!@garbage
EOF
This command line fails with "Permission denied" error?
$ ssh jdoe@FQDN
password: 123abc!@garbage
But if let uid=jdoe himself change the password, the ssh is successful?
Could you share the access logs when the both failed and successful
ssh/bind case?
Thanks!
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
