[389-users] Chaining woes again v2 - solutions

Rich Megginson rmeggins at redhat.com
Fri Oct 22 16:00:35 UTC 2010


Gerrard Geldenhuis wrote:
>> 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?
>   
If it has nsmultiplexorcredentials::somevalue
then yes, it is base64 encoded - the :: means the value is 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 at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>   




More information about the 389-users mailing list