>Did you use ldapsearch to output the value of nsmultiplexorcredentials?
>If so, then it automatically base64 encodes values that have
>non-printable characters. So it's not the actual value in the directory
>server, it's just what ldapsearch displays.
I viewed the settings in dse.ldif, is that also base64 encoded?
>>
>>>> Apart from the length which is due to use using a much longer password in production why does the test system use a {DES} and the production system does not.
>>>>
>>> Well, they both use a {DES} it's just that one is base64 encoded for
>>> some reason.
>>>
>>> On the client when we tried to do a password change the error we would see was operations error which is not very usefull.
>>>>
>>> How did you attempt the password change, what was the exact error
>>> message you saw, what was in the directory server access and errors logs
>>> for the password change operation?
>>>
>>
>> I will need to recreate the env and conditions. I will post the detail here tomorrow.
>>
>>
Changing the password on the client appears as follows:
New UNIX password:
Retype new UNIX password:
LDAP password information update failed: Operations error
I have enabled the following log levels in isolation on both the supplier and the consumer server which is chaining to the supplier.
I performed the password change request on the client seperately for each log level. The client connects to the consumer which chains back
to the supplier server.
Log Levels Enabled:
~~~~~~~~~~~~~~~~~~~
Acces Control Summary
Plug-ins
Heavy Trace Output
Connection Management
Log Communications with shell databases
In all cases there is nothing whatsoever in the logs to indicate an authentication failure. I have carefully checked them. I will gladly do
the test again with any or all log levels required and provide a link to view them.
Best Regards
________________________________________________________________________
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.
________________________________________________________________________
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
