FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Directory

 
 
LinkBack Thread Tools
 
Old 10-21-2010, 02:11 PM
Gerrard Geldenhuis
 
Default Chaining woes again v2 - solutions

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

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:: e0RFU31ZczJMghghdtZkpTakl5Y29OYVIwc0NUdnpMVmFUU1JD d1
hZNfsadfasdfsaZY143NkduYmJRenBK33sdfsadffdssiRUpvD lvQjRvUWR4ai9uZ2lWbzJQejduWj
NMcHE4UWR4Sw==

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-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. 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.

__________________________________________________ ______________________
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 10-21-2010, 02:22 PM
Rich Megginson
 
Default 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:: e0RFU31ZczJMghghdtZkpTakl5Y29OYVIwc0NUdnpMVmFUU1JD d1
> hZNfsadfasdfsaZY143NkduYmJRenBK33sdfsadffdssiRUpvD lvQjRvUWR4ai9uZ2lWbzJQejduWj
> 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('e0RFU31ZczJMghghdtZkpTakl5Y29OYV Iwc0NUdnpMVmFUU1JDd1hZNfsadfasdfsaZY143NkduYmJRenB K33sdfsadffdssiRUpvDlvQjRvUWR4ai9uZ2lWbzJQejduWjNM cHE4UWR4Sw==')
'{DES}Ys2Lx82x18!vxd6dxa56xa4x97x966xf4xe6x15#x074 5Ggxa4xc5fx15E5$7ux85x93_xb1xa7_jxc7_xb1xa6Xxd7x8d xcdx91xdbx98x98x94^x9cx12xb7xdexc7_xb1xa7_}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@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 10-21-2010, 02:49 PM
Gerrard Geldenhuis
 
Default Chaining woes again v2 - solutions

>________________________________________
>From: 389-users-bounces@lists.fedoraproject.org [389-users-bounces@lists.fedoraproject.org] on behalf of Rich Megginson [rmeggins@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:: e0RFU31ZczJMghghdtZkpTakl5Y29OYVIwc0NUdnpMVmFUU1JD d1
>> hZNfsadfasdfsaZY143NkduYmJRenBK33sdfsadffdssiRUpvD lvQjRvUWR4ai9uZ2lWbzJQejduWj
>> 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('e0RFU31ZczJMghghdtZkpTakl5Y29OY VIwc0NUdnpMVmFUU1JDd1hZNfsadfasdfsaZY143NkduYmJRen BK33sdfsadffdssiRUpvDlvQjRvUWR4ai9uZ2lWbzJQejduWjN McHE4UWR4Sw==')
>'{DES}Ys2Lx82x18!vxd6dxa56xa4x97x966xf4xe6x15#x07 45Ggxa4xc5fx15E5$7ux85x93_xb1xa7_jxc7_xb1xa6Xxd7x8 dxcdx91xdbx98x98x94^x9cx12xb7xdexc7_xb1xa7_}xdb,x8 9x15)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-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 10-21-2010, 03:27 PM
Rich Megginson
 
Default Chaining woes again v2 - solutions

Gerrard Geldenhuis wrote:
>> ________________________________________
>> From: 389-users-bounces@lists.fedoraproject.org [389-users-bounces@lists.fedoraproject.org] on behalf of Rich Megginson [rmeggins@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:: e0RFU31ZczJMghghdtZkpTakl5Y29OYVIwc0NUdnpMVmFUU1JD d1
>>> hZNfsadfasdfsaZY143NkduYmJRenBK33sdfsadffdssiRUpvD lvQjRvUWR4ai9uZ2lWbzJQejduWj
>>> 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('e0RFU31ZczJMghghdtZkpTakl5Y29OYV Iwc0NUdnpMVmFUU1JDd1hZNfsadfasdfsaZY143NkduYmJRenB K33sdfsadffdssiRUpvDlvQjRvUWR4ai9uZ2lWbzJQejduWjNM cHE4UWR4Sw==')
>> '{DES}Ys2Lx82x18!vxd6dxa56xa4x97x966xf4xe6x15#x074 5Ggxa4xc5fx15E5$7ux85x93_xb1xa7_jxc7_xb1xa6Xxd7x8d xcdx91xdbx98x98x94^x9cx12xb7xdexc7_xb1xa7_}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@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 10-22-2010, 11:15 AM
Gerrard Geldenhuis
 
Default Chaining woes again v2 - solutions

>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.

I viewed the settings in dse.ldif, is that also base64 encoded?

>>
>>>> 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.

>>>
>>> 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.
>>
>>

Changing the password on the client appears as follows:
New UNIX password:
Retype new UNIX password:
LDAP password information update failed: Operations error


I have enabled the following log levels in isolation on both the supplier and the consumer server which is chaining to the supplier.
I performed the password change request on the client seperately for each log level. The client connects to the consumer which chains back
to the supplier server.

Log Levels Enabled:
~~~~~~~~~~~~~~~~~~~
Acces Control Summary
Plug-ins
Heavy Trace Output
Connection Management
Log Communications with shell databases

In all cases there is nothing whatsoever in the logs to indicate an authentication failure. I have carefully checked them. I will gladly do
the test again with any or all log levels required and provide a link to view them.

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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 10-22-2010, 04:00 PM
Rich Megginson
 
Default Chaining woes again v2 - solutions

Gerrard Geldenhuis wrote:
>> 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.
>>
>
> I viewed the settings in dse.ldif, is that also base64 encoded?
>
If it has nsmultiplexorcredentials::somevalue
then yes, it is base64 encoded - the :: means the value is base64 encoded
>
>>>>> 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.
>>>>
>
>
>>>> 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.
>>>
>>>
>>>
>
> Changing the password on the client appears as follows:
> New UNIX password:
> Retype new UNIX password:
> LDAP password information update failed: Operations error
>
>
> I have enabled the following log levels in isolation on both the supplier and the consumer server which is chaining to the supplier.
> I performed the password change request on the client seperately for each log level. The client connects to the consumer which chains back
> to the supplier server.
>
> Log Levels Enabled:
> ~~~~~~~~~~~~~~~~~~~
> Acces Control Summary
> Plug-ins
> Heavy Trace Output
> Connection Management
> Log Communications with shell databases
>
> In all cases there is nothing whatsoever in the logs to indicate an authentication failure. I have carefully checked them. I will gladly do
> the test again with any or all log levels required and provide a link to view them.
>
> 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@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 

Thread Tools




All times are GMT. The time now is 01:55 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org