Gerrard Geldenhuis wrote:
>> ________________________________________
>> From: 389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx [389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx] on behalf of Rich Megginson [rmeggins@xxxxxxxxxx]
>> Sent: 21 October 2010 15:22
>> To: General discussion list for the 389 Directory server project.
>> Subject: Re: [389-users] Chaining woes again v2 - solutions
>>
>> Gerrard Geldenhuis wrote:
>>
>>> Hi
>>> 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
>>>
>>>
>> That's very bad. This looks as though the password was set manually to
>> the output of pwdhash. You must always submit a clear text password to
>> the directory server in an ldap add or modify request for this attribute.
>>
>>> 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
>>> hZNfsadfasdfsaZY143NkduYmJRenBK33sdfsadffdssiRUpvDlvQjRvUWR4ai9uZ2lWbzJQejduWj
>>> NMcHE4UWR4Sw==
>>>
>>>
>> This is base64 encoded - it should usually not be base64 encoded when
>> output by ldapsearch, but the decoded version is quite strange:
>> python
>>
>>>>> import base64
>>>>>
>>>>>
>> base64.b64decode('e0RFU31ZczJMghghdtZkpTakl5Y29OYVIwc0NUdnpMVmFUU1JDd1hZNfsadfasdfsaZY143NkduYmJRenBK33sdfsadffdssiRUpvDlvQjRvUWR4ai9uZ2lWbzJQejduWjNMcHE4UWR4Sw==')
>> '{DES}Ys2L\x82\x18!v\xd6d\xa56\xa4\x97\x966\xf4\xe6\x15#\x0745Gg\xa4\xc5f\x15E5$7u\x85\x93_\xb1\xa7_j\xc7_\xb1\xa6X\xd7\x8d\xcd\x91\xdb\x98\x98\x94^\x9c\x12\xb7\xde\xc7_\xb1\xa7_}\xdb,\x89\x15)\xbc9oB4oQdxj/ngiVo2Pz7nZ3Lpq8QdxK'
>> and the length is 106. I'm not sure what this is or how it got there.
>>
>
> sorry that is my mistake, I modified it by hand, adding and removed characters.
>
>
>>> and on our test system it looks like follows:
>>> nsmultiplexorcredentials: {DES}slo6RKJHfEqtcfbpLWHdgQ==
>>>
>>>
>> This is correct.
>>
>
> The question still remains why we would have DES and base64 encoding if we used the exact same method to change the password.
>
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.
>
>>> 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.
>>
> That is probably not that big a worry but the inconsitency should be noted.
Not really - see above.
> If you want I can test this again to see if this is a version issue or something else. Maybe it is length related... I will test that too.
>
No - see above.
>
>>> 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-1.2.6.1-1.el5 | 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.
>>>
>> 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.
>
>
>>> 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?
>>>
>>>
>> I'm not sure what you mean?
>>
>
> It was meant as joke, in a previous unrelated thread I was told that I should always use unencrypted passwords which I have not done. I run into this bug/issue because I used pre-encrypted passwords.
>
>
>>> For system settings like chaining should the password always be in clear text in the ldif file?
>>>
>>>
>> When adding/updating the nsmultiplexorcredentials attribute, in an add
>> or modify request, you must provide the clear text password, and let the
>> directory server encrypt it. Anything else will surely lead to problems.
>>
>>> Can/should you use pre-encrypted DES strings for passwords for system settings.
>>>
>>>
>> No.
>>
>>> Does the password encryption setting in the 389-console only apply to user passwords?
>>>
>>>
>> Yes.
>>
>>> Is all system passwords encrypted to DES by default?
>>>
>>>
>> nsmultiplexorcredentials and the replication credentials are -
>> everything else uses the regular password hashing scheme
>>
>>> Can the system default if there is one by change to SSHA or whatever?
>>>
>>>
>> You mean using the regular password policies?
>>
>
> I mean, does other system entries like nsDS5ReplicaCredentials also use DES?
Just nsmultiplexorcredentials and nsDS5ReplicaCredentials - nothing else
> And is there a global setting available that would control whether DES or some other encoding is used.
No, not really.
> Thus if I add ldif entries with clear text for "system" related configuration like replication, chaining etc. will they all be encoded in DES?
>
Yes.
> 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
>
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
