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.
> and on our test system it looks like follows:
> nsmultiplexorcredentials: {DES}slo6RKJHfEqtcfbpLWHdgQ==
>
This is correct.
> 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.
> 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?
> 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?
> 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?
> 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@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
