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.
Congratulations, Janet! So, it
was an issue caused by the broken
subtree password policy?
--noriko