directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Zoerner (JIRA)" <j...@apache.org>
Subject [jira] Closed: (DIRSERVER-1001) Changes to userPassword attribute not reflected by server immediately, if performed by another user
Date Sat, 18 Aug 2007 07:52:30 GMT

     [ https://issues.apache.org/jira/browse/DIRSERVER-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Stefan Zoerner closed DIRSERVER-1001.
-------------------------------------


I have checked the described test case with the current 1.0.3 SNAPSHOT. Thanks to Ersin, It
works just fine. I therefore close this issue. 

> Changes to userPassword attribute not reflected by server immediately, if performed by
another user
> ---------------------------------------------------------------------------------------------------
>
>                 Key: DIRSERVER-1001
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-1001
>             Project: Directory ApacheDS
>          Issue Type: Bug
>    Affects Versions: 1.0.2, 1.5.0
>         Environment: * ApacheDS 1.5.1 (SNAPSHOT)
> * Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
> * Windows XP Professional SP2
>            Reporter: Stefan Zoerner
>            Assignee: Ersin Er
>             Fix For: 1.5.1, 1.0.3
>
>         Attachments: changePwd.ldif, DIRSERVER-1001-fix.patch, tori.ldif
>
>
> Changes to userPassword attribute seem not to be reflected by server immediately, if
performed by another user. Here is what I did:
> (1) Add this entry to the directory:
> ---
> dn: cn=Tori Amos,dc=example,dc=com
> sn: Amos
> objectClass: person
> objectClass: top
> cn: Tori Amos
> userpassword: secret
> ---
> $ ldapmodify -h localhost -p 10389 -D "uid=admin,ou=system" -w secret -a -f tori.ldif
> adding new entry cn=Tori Amos,dc=example,dc=com
> (2) Check, that Tori can authenticate
> $ ldapsearch -h localhost -p 10389 -D "cn=Tori Amos,dc=example,dc=com" -w secret -b ""
-s base "(objectClass=*)" vendorName
> version: 1
> dn:
> vendorName: Apache Software Foundation
> (3) Modify Tori's password
> LDIF-File:
> ---
> dn: cn=Tori Amos,dc=example,dc=com
> changetype: modify
> replace: userPassword
> userPassword: geheim
> -
> ---
> $ ldapmodify -h localhost -p 10389 -D "uid=admin,ou=system" -w secret -f changePwd.ldif
> modifying entry cn=Tori Amos,dc=example,dc=com
> Note, that I use the admin account to perform this operation!
> (4) Check, whether it works
> $ ldapsearch -h localhost -p 10389 -D "cn=Tori Amos,dc=example,dc=com" -w geheim -b ""
-s base "(objectClass=*)" vendorName
> ldap_simple_bind: Invalid credentials
> ldap_simple_bind: additional info: Bind failed: null
> $ ldapsearch -h localhost -p 10389 -D "cn=Tori Amos,dc=example,dc=com" -w secret -b ""
-s base "(objectClass=*)" vendorName
> version: 1
> dn:
> vendorName: Apache Software Foundation
> I think this behavior is not correct, because the new password "geheim" should work immediately
(as you assume as well). Note that the problem does not occur, if the user "Tori Amos" changes
her password herself. In this case, the new password is valid immediately. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message