On 09/27/2016 02:36 PM, Janet Houser wrote:
>
>
> 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?
I'm not sure. I re-applied the exact same subtree
password policy and
things just started working. Perhaps something was just
confused in the database, and was cleared by removing and re-adding the
policy.
Thank you for all your help on this. I learned a great deal. I'm very
grateful.
--noriko
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org