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?