Bug 513308 - empty principal name used when using server to server sasl for db chaining
Summary: empty principal name used when using server to server sasl for db chaining
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Directory Server
Classification: Red Hat
Component: Security - SASL
Version: 9.0
Hardware: All
OS: Linux
high
high
Target Milestone: ---
: ---
Assignee: Rich Megginson
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks: 434914 389_1.2.3
TreeView+ depends on / blocked
 
Reported: 2009-07-22 22:56 UTC by Yi Zhang
Modified: 2016-05-06 14:30 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-05-06 14:30:20 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
patch (1.05 KB, patch)
2009-09-23 16:37 UTC, Rich Megginson
no flags Details | Diff
revised patch (1.79 KB, patch)
2009-09-23 17:12 UTC, Rich Megginson
no flags Details | Diff

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


Note You need to log in before you can comment on or make changes to this bug.