[389-users] Chaining woes again v2 - solutions

Gerrard Geldenhuis Gerrard.Geldenhuis at betfair.com
Thu Oct 21 14:11:35 UTC 2010

Just a quick follow-up regarding this thread. 

We discovered the real problem.... encryption of the password. 

We have the following line in the ldif file to 
nsmultiplexorcredentials: {SSHA}VItDJ0gykk1q8rzsJmIkkj64mAW1kkaZY

We got one server working with chaining and the other not. The difference turned out to be how the password was stored and on the one box we changed the password via the console to make sure it was correct.

We have noted asmall inconsistencies which we would like to verify

On our production system the entry in dse.ldif looks like follows:
nsmultiplexorcredentials:: e0RFU31ZczJMghghdtZkpTakl5Y29OYVIwc0NUdnpMVmFUU1JDd1

and on our test system it looks like follows:
nsmultiplexorcredentials: {DES}slo6RKJHfEqtcfbpLWHdgQ==

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. In both cases we used the 389-console to make the changes. 

The version differences is: (test on the left, prod on the right)

389-admin-1.1.11-1.el5                                             |  389-admin-1.1.11-0.6.rc2.el5                                       
  389-admin-console-1.1.5-1.el5                                      |  389-admin-console-1.1.5-1.el5
  389-admin-console-doc-1.1.5-1.el5                                  |  389-admin-console-doc-1.1.5-1.el5
  389-adminutil-1.1.8-4.el5                                          |  389-adminutil-1.1.8-4.el5
  389-console-1.1.4-1.el5                                            |  389-console-1.1.4-1.el5
  389-ds-1.2.1-1.el5                                                 |  389-ds-1.2.1-1.el5
  389-ds-base-                                          |  389-ds-base-1.2.6-0.11.rc7.el5                                     
  389-ds-console-1.2.3-1.el5                                         |  389-ds-console-1.2.3-1.el5
  389-ds-console-doc-1.2.3-1.el5                                     |  389-ds-console-doc-1.2.3-1.el5
  389-dsgw-1.1.5-1.el5                                               |  389-dsgw-1.1.5-1.el5

On the client when we tried to do a password change the error we would see was operations error which is not very usefull. We did not see authentication issues on the consumer server with chaining setup nor on the provider server. I can double check it again, could you recommend a specific log level that would catch it. If I don't see the error message I will raise it as an enhancement request in bugzilla for the some more informative error messages for this particular problem. I will also add some relevant notes to the 389 wiki. 

Lastly I have been "reprimanded" for this on the list before and have paid the prices as explained above, but just to be perfectly clear and for the sake of writing a small bit on the wiki regarding this issue what is the policy regarding putting passwords in ldif files?

For system settings like chaining should the password always be in clear text in the ldif file? 

Can/should you use pre-encrypted DES strings for passwords for system settings.

Does the password encryption setting in the 389-console only apply to user passwords?

Is all system passwords encrypted to DES by default?

Can the system default if there is one by change to SSHA or whatever?

Best Regards

In order to protect our email recipients, Betfair Group use SkyScan from 
MessageLabs to scan all Incoming and Outgoing mail for viruses.


More information about the 389-users mailing list