Mailing-List: contact users-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@directory.apache.org
Received-SPF: pass (herse.apache.org: domain of chris.custine@gmail.com
 designates 64.233.162.224 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth;
        b=WCqr6kHv3K7cRJPjD7w5g4fxPi5YKZkdruRJJNu2eiH+Yrc5Jgj1rOErEBKYTYJd0nBkJhaEZ1Fwi1Kkm/fzJbr89el537hM30Jy6T/5DqAEyZsu+PHoOFceFxGUyLgyJ8aHl7ymsxUf/DtfEG/2oJ9GEDGcArlopJwbP5pG3Cg=
Message-ID: <43b026c70707200917x2e3e47c8sedf0d402924d1401@mail.gmail.com>
Date: Fri, 20 Jul 2007 10:17:48 -0600
From: "Chris Custine" <ccustine@apache.org>
Sender: chris.custine@gmail.com
To: users@directory.apache.org
Subject: Re: ApacheDS 1.5.1 :: Does ApacheDS internally cache modified object
 properties, like changed user password
In-Reply-To: <46A0DCFB.50405@labeo.de>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_127718_21385886.1184948268432"
References: <46A0D63E.10903@webunity.de> <46A0DCFB.50405@labeo.de>

------=_Part_127718_21385886.1184948268432
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Yes, I can reproduce this as well.  The password does not seem to update
immdiately when bound as another user (uid=admin,ou=system), but does update
immediately when bound as that user.

So who wants to file the Jira?  :-)

Chris

On 7/20/07, Stefan Zoerner <stefan@labeo.de> wrote:
>
> Markus Pohle wrote:
> > I use ApacheDS-1.5.1-SNAPSHOT release on my computer and figured out the
> > following:
> >
> > 1. started my webapp
> > 2. tried to login to my webapp, which tries to authenticate myself
> > against apacheds
> > 3. login is successful
> >
> > 4. used LDAP Studio to modify my users password
> > 5. started my webapp again and tried to login with modified password
> > with no success
> > 6. tried the old password and thats successful
> >
> > 7. stopped ApacheDS and started again and tried then to use the new
> > password and now it is successful
> >
> > Can anybody tell me, why that happens? Looked in server.xml for reason
> > and found only these two tags:
> > <property name="synchPeriodMillis" value="15000" />
> > <property name="synchOnWrite" value="true" />
> >
> > Help would be really appreciated.
> > TIA
> > Markus
>
> I tried to reproduce, and I could. I only used ApacheDS 1.5.1-SNAPSHOT
> and an LDAP client, and the change to the password did not work
> immediately.
>
> This 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 to perform the 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.
>
> Others?
>
>
>
>
>

------=_Part_127718_21385886.1184948268432--