Gerrard Geldenhuis wrote:
>> ________________________________________
>> From: 389-users-boun...@lists.fedoraproject.org
>> [389-users-boun...@lists.fedoraproject.org] on behalf of Rich Megginson
>> [rmegg...@redhat.com]
>> 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-us...@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
