>________________________________________
>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.
>> 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. 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.
>> 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?
And is there a global setting available that would control whether DES or some
other encoding is used. Thus if I add ldif entries with clear text for "system"
related configuration like replication, chaining etc. will they all be encoded
in DES?
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
