"Directory Manager" can't change user's password; result is an inaccessible account.

[Janet Houser]

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=int,dc=boulder,dc=nso,dc=edu"


I found the following page, 
http://directory.fedoraproject.org/docs/389ds/design/password-administrat..., 
but being fairly
new to 389-ds I wasn't sure how to create/define/add the ability to be a 
password administrator to an account.

Any suggestions would be appreciated.

Thanks,

/jh

[Noriko Hosoi]

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=int,dc=boulder,dc=nso,dc=edu" 
Do you see any error
messages in /var/log/dirsrv/slapd-INSTANCE/errors?

What does this access log file log for the operation?
/var/log/dirsrv/slapd-INSTANCE/access

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=int,dc=boulder,dc=nso,dc=edu
changetype: modify
replace: userPassword
userPassword: new_user_passwd
EOF

Is the user's password is set to new_user_passwd?

>  I found the following page, 
>  http://directory.fedoraproject.org/docs/389ds/design/password-administrat..., 
>  but being fairly
>  new to 389-ds I wasn't sure how to create/define/add the ability to be 
>  a password administrator to an account.
>
>  Any suggestions would be appreciated.
>
>  Thanks,
>
>  /jh
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org

[Janet Houser]

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.

Thanks for your help on this....
> > I found the following page, 
> > http://directory.fedoraproject.org/docs/389ds/design/password-administrat..., 
> > but being fairly
> > new to 389-ds I wasn't sure how to create/define/add the ability to 
> > be a password administrator to an account.
> >
> > Any suggestions would be appreciated.
> >
> > Thanks,
> >
> > /jh
> > _______________________________________________
> > 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org

[Noriko Hosoi]

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?
>  Thanks for your help on this....
> >
> >> I found the following page, 
> >> http://directory.fedoraproject.org/docs/389ds/design/password-administrat...,
>
> >> but being fairly
> >> new to 389-ds I wasn't sure how to create/define/add the ability to 
> >> be a password administrator to an account.
> >>
> >> Any suggestions would be appreciated.
> >>
> >> Thanks,
> >>
> >> /jh
> >> _______________________________________________
> >> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> >> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
> >
> > _______________________________________________
> > 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org

[Janet Houser]

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,

> >
> > Thanks for your help on this....
> >>
> >>> I found the following page, 
> >>>
> http://directory.fedoraproject.org/docs/389ds/design/password-administrat..., 
> >>> but being fairly
> >>> new to 389-ds I wasn't sure how to create/define/add the ability to 
> >>> be a password administrator to an account.
> >>>
> >>> Any suggestions would be appreciated.
> >>>
> >>> Thanks,
> >>>
> >>> /jh
> >>> _______________________________________________
> >>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> >>> To unsubscribe send an email to 
> >>> 389-users-leave(a)lists.fedoraproject.org
> >>
> >> _______________________________________________
> >> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> >> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
> > _______________________________________________
> > 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org

[Noriko Hosoi]

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".

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?
$ ssh jdoe@FQDN
password: 123abc!@garbage

But if let uid=jdoe himself change the password, the ssh is successful?

Could you share the access logs when the both failed and successful 
ssh/bind case?

Thanks!

[Janet Houser]

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 share the access logs when the both failed and successful 
>  ssh/bind case?
>
>  Thanks! 

>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org

[Noriko Hosoi]

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.

$ 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"

$ ldapsearch -h my389dsserver.domain.edu -p 389 -D 
"uid=jdoe,ou=People,dc=domain,dc=edu" -w new_jdoe_passwd -b "" -s
base

$ 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"

$ ldapsearch -h my389dsserver.domain.edu -p 389 -D 
"uid=jdoe,ou=People,dc=domain,dc=edu" -w new_user_password -b "" -s
base

Thanks.

> >
> > Could you share the access logs when the both failed and successful 
> > ssh/bind case?
> >
> > Thanks!
>
>
> > _______________________________________________
> > 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org

[Janet Houser]

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


>  Thanks.
>
> >
> >>
> >> Could you share the access logs when the both failed and successful 
> >> ssh/bind case?
> >>
> >> Thanks!
> >
> >
> >> _______________________________________________
> >> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> >> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
> > _______________________________________________
> > 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org

[Noriko Hosoi]

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?

[Janet Houser]

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

[Noriko Hosoi]

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?
--noriko

[Janet Houser]

On 9/27/16 3:39 PM, Noriko Hosoi wrote:
>  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