I found a part of the problem but i can not really figure if it is a bug
or if I am too tired to be intelligent...
Is it normal using a thing like
ctx.modifyAttributes("uid=admin",ctx.REPLACE_ATTRIBUTE, attrs);
with attrs containing "pass" like this :
Attribute pass = new BasicAttribute("userPassword", "newPass");
throws an exception from the AuthenticationService after having done
the modification and executing the assertHasEntry of the
ExceptionService calling itself again authenticate on
AuthenticationService .
It seems the REPLACE_ATTRIBUTE with only one attribute in it remove all
other attributes on the entry and the assertion does not fail on entry
non existance but on the authentication ... Do I miss something ?
I understodd in the sun doc that replacing attributes worked on
attribute(s) wich were given with their values and not on the others...
Am I wrong?
Finally I removed the old password attribute and add the new one and it
works.
"String[] searchedAttrs = new String [1];
searchedAttrs [0]="userPassword";
existingAttrs = ctx.getAttributes("uid=admin",searchedAttributes);
[...]
ctx.modifyAttributes("uid=admin",ctx.REMOVE_ATTRIBUTE, existingAttrs );
attrs = new BasicAttributes(true);
attrs.put(new BasicAttribute("userPassword", newPass));
ctx.modifyAttributes("uid=admin",ctx.ADD_ATTRIBUTE, attrs );"
So is it a bug or a mistake from me ?
Thanks for help.
Tony Blanchard
Tony Blanchard wrote:
Hello to the list.
After a long time without looking to the ApacheDS list, I decided to
upgrade my 9.1 version of the server to the 9.4.
Unfortunately I got problems with admin password. I look to the
archives of this list and saw there has been modifications on it.
My problem is this one :
Initially I had an installation process which took a template of the
xml configuration file and which filled it with the values entered by
the installation user.
Then it launched a windows service process which encapsulates the
start of the autonome server.
After that it populated the server with values I wanted.
I changed things to start with a temporary conf file containing
default password "secret".
Then I connected the admin with "secret" password, programatically
changed the "userPassword" attribute to the user value, and
programatically changed the conf file to contain the new value.
But doing this, the server stops with an authentication failure and
the service stops. I have tried a lot of sequences for those
operations but nothing seems to work...
Is there a known sequence of things to do to keep alive the autonome
server while changing pasword both in ldap backend and in conf file ?
Thanks,
Tony Blanchard
