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(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org