Chaining woes again v2 - solutions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
>   



[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux