Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 513308

Summary: empty principal name used when using server to server sasl for db chaining
Product: Red Hat Directory Server Reporter: Yi Zhang <yzhang>
Component: Security - SASLAssignee: Rich Megginson <rmeggins>
Status: CLOSED CURRENTRELEASE QA Contact: Viktor Ashirov <vashirov>
Severity: high Docs Contact:
Priority: high    
Version: 9.0CC: dpal, jgalipea, nhosoi
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-05-06 14:30:20 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 434914, 519216    
Attachments:
Description Flags
patch
none
revised patch none

Description Yi Zhang 2009-07-22 22:56:53 UTC 
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
Comment 2 Yi Zhang 2009-07-22 23:15:29 UTC 
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
Comment 3 Rich Megginson 2009-09-23 16:37:40 UTC 
Created attachment 362328 [details]
patch
Comment 4 Rich Megginson 2009-09-23 17:12:13 UTC 
Created attachment 362330 [details]
revised patch
Comment 5 Rich Megginson 2009-09-23 17:48:58 UTC 
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
Comment 6 Yi Zhang 2010-05-29 05:26:13 UTC 
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