Description of problem: when using server to server sasl for db chaining, empty principal name used by DS server for kerberos server verification. Here is detail explain from Rich: The bug that Yi encountered was that it was using the wrong principal. The default username that chaining uses is "". The server to server kerberos code allows you to pass in a principal name in the username field. It attempts to determine if the principal name is a DN or not. Since "" does not look like a DN (it has no = in it) it assumes it is a principal name. The fix to this will be to make sure username[0] is valid. The workaround is to specify an nsMultiplexorBindDn in the chaining config. It doesn't matter what it is, as long as it is a valid DN. Version-Release number of selected component (if applicable): 8.1 How reproducible: always Steps to Reproduce: 1. following doc for server to server sasl db chaining configuration. Actual results: user searching for chained db would fail, Expected results: searching success Additional info: i will post detailed test/verification steps later on
more explain from Rich: (copied from irc) <richm> The problem is that bind operations do not use the starttls or gssapi mechanism * deon (~dlackey.redhat.com) has joined #dirsec <richm> the design of chaining is such that the only way to protect bind operations is with ldaps <richm> so if you chain a BIND operation, and you think you have made it secure by using starttls or gssapi, you can still see the cleartext password being sent on the wire in the chained BIND operation <richm> subsequent operations will use starttls or gssapi - it's just the initial BIND operation
Created attachment 362328 [details] patch
Created attachment 362330 [details] revised patch
To ssh://git.fedorahosted.org/git/389/ds.git 7f9f261..3d735f3 master -> master commit 3d735f37cf613e68e10ab916f6752fbe3ffc0e1a Author: Rich Megginson <rmeggins> Date: Wed Sep 23 10:39:00 2009 -0600 Reviewed by: nhosoi (Thanks!) Fix Description: Change the logic to check if the username is a valid principal name. A valid principal name in this context will be a non-empty string that does not contain the '=' character (which will be a bind DN in this context) . Platforms tested: RHEL5 x86_64 Flag Day: no Doc impact: no
the verification took me some time. but it is finally done. bug closed 3 host used: data server : RHEL 5 x86_64 link server 1: RHEL 5 x86_64 link server 2: RHEL 5 i386