Hi Carlo, I changed the value and it continues to fail. Please remember that the login process works, but the change password process fail. Maybe the sso server encrypts the entered password in a different way, but when logging in, it uses the same process as apacheds.
I'm trying to read and understand a little bit what's going on in the backend... Thanks again On Thu, Jan 31, 2013 at 1:19 PM, <[email protected]> wrote: > Hi, the case differences between your policy definition of the password > attribute and the actual name 'userpassword' might be causing a problem. > > pwdAttribute: userPassword > > attribute name 'userpassword' > > > -----Original Message----- > From: Patricio Demitrio [mailto:[email protected]] > Sent: Thursday, January 31, 2013 5:14 AM > To: [email protected]; [email protected] > Subject: Re: [ApacheDS] Error 56 > > Hi Emmanuel, > > Here's the user full profile, according to apache directory studio: > ---- > dn: uid=user1,ou=people,dc=example,dc=com > objectClass: organizationalPerson > objectClass: person > objectClass: pwdPolicy > objectClass: inetOrgPerson > objectClass: top > cn: user1 > pwdAttribute: userPassword > sn: user1 > pwdAllowUserChange: true > pwdMustChange: true > uid: user1 > userpassword:: > e1NTSEF9NGx1QXphMkwrMFh5dXQvSWxlNllLZmxnR09LVlZtM2F3SHFZN0E9P > Q== > createTimestamp: 20130129134743Z > creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system > entryCSN: 20130130121851.729000Z#000000#000#000000 > entryParentId: 4 > entryUUID:: MzUyZGZhZmQtNDQ3My00M2Q4LWJkZDQtYTUxNzBiODFiNjZi > modifiersName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system > modifyTimestamp: 20130130121851Z > pwdHistory:: > MjAxMzAxMjkxMzQ3NDNaIzEuMy42LjEuNC4xLjE0NjYuMTE1LjEyMS4xLjQwIzE > yI2NHRnpjM2R2Y21RPQ== > pwdHistory:: > MjAxMzAxMzAxMTE4MjJaIzEuMy42LjEuNC4xLjE0NjYuMTE1LjEyMS4xLjQwIzE > yI2NHRnpjM2R2Y21ReA== > pwdHistory:: > MjAxMzAxMzAxMTI2MjNaIzEuMy42LjEuNC4xLjE0NjYuMTE1LjEyMS4xLjQwIzE > yI2NHRnpjM2R2Y21Reg== > pwdHistory:: > MjAxMzAxMzAxMTI5MzdaIzEuMy42LjEuNC4xLjE0NjYuMTE1LjEyMS4xLjQwIzE > yI2NHRnpjM2R2Y21RMA== > pwdHistory:: > MjAxMzAxMzAxMjE4NTFaIzEuMy42LjEuNC4xLjE0NjYuMTE1LjEyMS4xLjQwIzE > yI2NHRnpjM2R2Y21RMQ== > pwdReset: true > ---------- > > the user password is: password5. > I'm trying to change it to: password6 (not used before) > > > If I disable the pwdReset flag, the user logs properly to the system, so > the password is the correct one. > Thanks > > > On Thu, Jan 31, 2013 at 10:44 AM, Emmanuel Lécharny <[email protected] > >wrote: > > > Le 1/31/13 10:27 AM, Patricio Demitrio a écrit : > > > Hi Emanuel, thanks for your answer. > > > > > > I'm using apacheds-2.0.0-M9. > > > > > > The modify request comes from openam 10.0.1, a sso server that gives > > > you the option to reset the user password when pwdReset in pwdPolicy > is true. > > > > > > Is there some specific clue that I can give you here? > > > > AFAICT, the only reason to get this reason is that the value you are > > trying to remove is not present in the atribute. Like, say, you want > > to remove 'secret' when the password is 'magic' or anything but 'secret'. > > > > What would help is to provide the entry with all its attributes, so > > that we can compare with the modification you want to apply (of > > course, be careful to 'anonymize' the passwords :) > > > > Another possibility - but unlikely - is that we have a bug in teh way > > we check for the presence of a value in a binary AttributeType. > > > > -- > > Regards, > > Cordialement, > > Emmanuel Lécharny > > www.iktek.com > > > > >
