Bug 1399781

Summary:	[3.3] oadm groups sync fails if member DNs contain extra spaces
Product:	OpenShift Container Platform	Reporter:	Josep 'Pep' Turro Mauri <pep>
Component:	apiserver-auth	Assignee:	Jordan Liggitt <jliggitt>
Status:	CLOSED ERRATA	QA Contact:	Chuan Yu <chuyu>
Severity:	high	Docs Contact:
Priority:	medium
Version:	3.3.1	CC:	aos-bugs, dmcphers, erich, jokerman, mmccomas, pweil, sauchter, sdodson, skuznets
Target Milestone:	---	Keywords:	Reopened
Target Release:	3.3.1
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:	Previously, LDAP group synchronization would fail if member DNs contained extra spaces. This has been corrected and group synchronization now works correctly with DNs that contain spaces.	Story Points:	---
Clone Of:
Clones:	1401553 (view as bug list)		Environment:
Last Closed:	2017-01-26 20:42:29 UTC	Type:	Bug
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:	1401553

Description Josep 'Pep' Turro Mauri 2016-11-29 17:44:26 UTC

Description of problem:

When spaces are part of the relative distinguished names (RDN), oadm groups sync fails to recognize the DNs as valid and therefore ignore them.

Version-Release number of selected component (if applicable):
OCP 3.3.1

How reproducible:
Always

Steps to Reproduce:
1. create LDAP sync configuration as per:

   https://docs.openshift.com/container-platform/3.3/install_config/syncing_groups_with_ldap.html

   let's say our baseDN is ou=users,dc=example,dc=com

2. Have a group in LDAP that matches the config above (i.e. that is going to be sync'd) and contains members in the form:

    uniqueMember: uid=user01, ou=users, dc=example, dc=com
    uniqueMember: uid=user02,ou=users,dc=example, dc=com
    uniqueMember: uid=user03, ou=users, dc=example, dc=com

3. Attempt to sync groups: oadm groups sync --sync-config=config.yaml

Actual results:
only user02 is processed; user01 and user03 are skipped with a message like:

For group "cn=mygroup,ou=groups,dc=example,dc=com", ignoring member "uid=user01, ou=users, dc=example, dc=com": search for entry with dn="uid=user01, ou=users, dc=example, dc=com" would search outside of the base dn specified (dn="ou=users,dc=example,dc=com")

Expected results:
All the entries above would be processed.

Additional info:

The problematic check seems to be here:

https://github.com/openshift/origin/blob/v1.3.0/pkg/auth/ldaputil/query.go#L111

	if !strings.Contains(attributeValue, o.BaseDN) {
	   return nil, NewQueryOutOfBoundsError(attributeValue, o.BaseDN)
	}

the comparison there should take into account that RDNs can contain optional spaces between the components.

Comment 1 Stuart Auchterlonie 2016-12-01 09:56:31 UTC

Customer had to use "tolerateMemberOutOfScopeErrors: true"

"without putting that flag to on it was stopping when hitting
the first DN with spaces... (Considering it as Out of scope)"

in order to even import the records without spaces.

Comment 2 Eric Rich 2016-12-01 14:17:58 UTC

(In reply to Josep 'Pep' Turro Mauri from comment #0)
> The problematic check seems to be here:
> 
> https://github.com/openshift/origin/blob/v1.3.0/pkg/auth/ldaputil/query.
> go#L111
> 
> 	if !strings.Contains(attributeValue, o.BaseDN) {
> 	   return nil, NewQueryOutOfBoundsError(attributeValue, o.BaseDN)
> 	}
> 
> the comparison there should take into account that RDNs can contain optional
> spaces between the components.

I would say that this line of code does look to be the issue, as https://golang.org/pkg/strings/#Contains is doing a literal string comparison and not the LDAP defined string comparison as defined in https://docs.ldap.com/specs/rfc4517.txt (Section 4.2.23)

Comment 3 Jordan Liggitt 2016-12-01 21:43:39 UTC

Fixed upstream in https://github.com/openshift/origin/pull/12105

Comment 4 Jordan Liggitt 2016-12-05 03:26:03 UTC

fixed in origin master in https://github.com/openshift/origin/pull/12105
fixed in origin 1.4 in https://github.com/openshift/origin/pull/12108
fixed in ose 3.3 in https://github.com/openshift/ose/pull/491

Comment 9 Chuan Yu 2016-12-22 07:43:06 UTC

Checked with the latest puddle, the issue was fixed.

# openshift version
openshift v3.3.1.8
kubernetes v1.3.0+52492b4
etcd 2.3.0+git

Comment 14 errata-xmlrpc 2017-01-26 20:42:29 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:0199