On 9/27/16 2:26 PM, Noriko Hosoi wrote:
On 09/27/2016 07:32 AM, Janet Houser wrote:
On 9/26/16 4:23 PM, Noriko Hosoi wrote:
On 09/26/2016 09:44 AM, Janet Houser wrote:
On 9/26/16 10:14 AM, Noriko Hosoi wrote:
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".
yes. I was ssh-ing to another LDAP client.
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?
No, that command appeared to be successful. It would return the
output:
modifying entry "uid=jdoe,ou=People,dc=domain,dc=edu"
But after the command was executed, ssh would then fail with
"Permission denied" errors.
$ ssh jdoe@FQDN
password: 123abc!@garbage
But if let uid=jdoe himself change the password, the ssh is
successful?
Yes. The user (or root) could change the password if
"cn=Directory Manager" was replaced with
"uid=jdoe,ou=People,dc=domain,dc=edu" and the user's
old password was supplied in the command.
Detailed summary:
On an LDAP client, the users root and jdoe could successfully
change jdoe's password by using the following command:
(1) ldappasswd -h my389dsserver.domain.edu -p 389 -ZZ -D
"uid=jdoe,ou=People,dc=domain,dc=edu" -w -s current_jdoe_passwd -s
new_jdoe_passwd "uid=jdoe,ou=People,dc=domain,dc=edu"
However, on the same LDAP client, using the command:
(2) ldappasswd -h my389dsserver.domain.edu -p 389 -ZZ -D
"cn=Directory Manager" -w directorymanager_password -s
new_user_password "uid=jdoe,ou=People,dc=domain,dc=edu"
would "appear" to change the password, but would simply render the
password unusable. Both the old and new passwords would fail with
"Permission Denied" errors when ssh was used to
login to another LDAP client.
This process was attempted with the subtree password policy applied
at the domain level, but with the "Password Syntax" disabled.
Deleting the subtree password policy, and re-adding the same policy
to the domain corrected the issue.
Give me a little time to dig out the data in the access logs. I'll
sanitize the output and send it along.
Could you try the following command lines and share the test steps
as well as the access log associated with the operations?
When setting a new_jdoe_passwd/new_user_password, please avoid shell
sensitive character such as '!' for this testing.
Sure! For this testing, I left the subtree password policy on the
domain, but disabled the password syntax so that I could create
simple text passwords.
$ ldappasswd -h my389dsserver.domain.edu -p 389 -ZZ -D
"uid=jdoe,ou=People,dc=domain,dc=edu" -w current_jdoe_passwd -s
new_jdoe_passwd "uid=jdoe,ou=People,dc=domain,dc=edu"
I ran this command as the jdoe user. No additional output was
generated. ssh to an ldap client was successful with the new password.
$ ldpsearch -h my389dsserver.domain.edu -p 389 -D
"uid=jdoe,ou=People,dc=domain,dc=edu" -w new_jdoe_passwd -b "" -s base
$ ldapsearch -h my389dsserver.domain.edu -p 389 -D
"uid=jdoe,ou=People,dc=domain,dc=edu" -w testing123 -b "" -s base
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: ALL
#
#
dn:
objectClass: top
defaultnamingcontext: dc=domain,dc=edu
dataversion: 020160826133802020160826133802
netscapemdsuffix: cn=ldap://dc=my389dsserver,dc=domain,dc=edu:389
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
$ ldappasswd -h my389dsserver.domain.edu -p 389 -ZZ -D "cn=Directory
Manager" -w directory manager_password -s new_user_password
"uid=jdoe,ou=People,dc=domain,dc=edu"
$ ldappasswd -h my389dsserver.domain.edu -p 389 -ZZ -D "cn=Directory
Manager" -w directory_manager_passwd -s 123testing
"uid=jdoe,ou=People,dc=domain,dc=edu"
no output generated. ssh into ldap client successful with new
password.
$ ldapsearch -h my389dsserver.domain.edu -p 389 -D
"uid=jdoe,ou=People,dc=domain,dc=edu" -w new_user_password -b "" -s
base
$ ldapsearch -h my389dsserver.domain.edu -p 389 -D
"uid=jdoe,ou=People,dc=domain,dc=edu" -w 123testing -b "" -s base
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: ALL
#
#
dn:
objectClass: top
defaultnamingcontext: dc=domain,dc=edu
dataversion: 020160826133802020160826133802
netscapemdsuffix: cn=ldap://dc=my389dsserver,dc=domain,dc=edu:389
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
Thank you, Janet. Your test shows ldappasswd both run by uid=jdoe as
well as Directory Manager correctly changed the password of uid=jdoe.
Now, ssh with the new password 123testing works or fails?
Hi Noriko,
ssh with the new password 123testing works.
Everything started working after I removed the subtree password policy
on my domain on Saturday, and re-added the policy.
Thank you for all your help.
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
