OpenLDAP: Result Code 32 "No Such Object"

[JRial95]

Rancher Server Setup

• Rancher version: v2.6.2
• Installation option (Docker install/Helm Chart): Helm Chart
  • If Helm Chart, Kubernetes Cluster and version (RKE1, RKE2, k3s, EKS, etc): RKE2
• Proxy/Cert Details:

Information about the Cluster

• Kubernetes version: v1.21.5+rke2r2
• Cluster Type (Local/Downstream): Local

Describe the bug

When I try to configure the OpenLDAP authentication provider, I get an error: Result Code 32 "No Such Object".

To Reproduce

1. Go to Rancher's OpenLDAP authentication provider configuration page.

2. Fill these following fields:

   • Hostname
   • Port
   • TLS (check)
   • Certificate
   • Service Account Distinguished Name
   • Service Account Password
   • User Search Base

3. Use a valid LDAP user for the test.

4. Submit form by clicking on "Enable" button.

Result

Check Rancher logs using the following command:

kubectl -n cattle-system logs -l app=rancher -c rancher --follow

You should see something like this:

2021/10/25 09:51:20 [ERROR] API error response 401 for POST /v3/openLdapConfigs/openldap?action=testAndApply. Cause: LDAP Result Code 32 "No Such Object":

Expected Result

The OpenLDAP authentication should be enabled.

Additional context

By investigating the code and from my understanding, I think the problem comes from the request that is made on lines 71 to 78 in ldap_client.go. Unfortunately, I don't know how to solve the problem. Do you have an idea?

rancher/pkg/auth/providers/ldap/ldap_client.go

Lines 71 to 78 in 64c748d

	searchOpRequest := ldapv2.NewSearchRequest(userDN,
	ldapv2.ScopeWholeSubtree, ldapv2.NeverDerefAliases, 0, 0, false,
	fmt.Sprintf("(%v=%v)", ObjectClass, config.UserObjectClass),
	operationalAttrList, nil)
	opResult, err := lConn.Search(searchOpRequest)
	if err != nil {
	return v3.Principal{}, nil, httperror.WrapAPIError(err, httperror.Unauthorized, "authentication failed") // need to reload this error
	}

[JRial95]

Duplicate of #17854

[MbolotSuse]

I'm re-opening this to track the newest PR submitted for this issue - #38736.

[MbolotSuse]

Release note

Credit goes to github user @JRial95 for developing the fix to this issue.

[MbolotSuse]

Validation Template

Root Cause

Users on certain LDAP setups do not have the permissions to search as their user. This lead to the error outlined in the issue (Result code 32), since Rancher attempted to bind as their user to perform searches (in order to show the user only the groups/users that they could see as part of their auth configs).

What was fixed, or what change have occurred

The code to login as a user now has a fallback case where, if it gets a 32 result code on attempting to search under the user's authority, it will bind/search as the service account instead.

Areas or cases that should be tested

Basic LDAP functionality on a LDAP setup which does not give users permission to search the LDAP setup, including:

• User login
• User search (i.e. add a user to a cluster or project, make sure that you can see search results with no errors in the logs)
• Group search (same idea as user search, but with groups)
• User refresh (Add a user to a group or remove a user from a group, manually refresh the user, make sure the new permissions applied)

Basic regression test (above scenarios should work) on a standard LDAP setup where users can search.

What areas could experience regressions

Basic ldap functionality (user login, user/group search, user refresh).

Are the repro steps accurate/minimal?

No. They are included here:

1. Create an LDAP setup. Restrict users from performing a search.
2. Integrate with rancher. Attempt to login.
3. Note that there is an error in the log (error code 32 during search), and user login does not work.

[MbolotSuse]

After further review of the user-submitted PR, we've decided to pull this out and re-evaluate the functionality. There were some concerns raised that the current functionality could cause adverse impacts, outlined below, that made us uncertain about leaving this in. We do intend to re-evaluate Rancher's functionality in this area in the future, and hopefully present a better solution.

For background, Rancher today (in the case of most auth providers) always attempts to scope its searches to the permissions of the requesting user. It does this so that when users attempt to add new permissions to a user/group for a cluster/project, they can only see the objects that they could see outside of Rancher. This way, Rancher doesn't become an "attack vector", allowing users to effectively escalate their permissions in the auth providers.

However, we recognize that this approach does not account for typical setups (such as LDAP) where users have no permissions in the authentication provider and the service account is used as a way of tightly controlling read permissions from the application. We see these configurations as legitimate use cases, and want to better support them.

To this end, we are going to consider a more comprehensive solution to this issue. One potential solution would be to expose a field on the auth config (search_using_service_account, a bool) which will cause Rancher to always use the service account (and never the user) to search for users/groups. This value will default to false, to keep Rancher's current behavior for our existing consumers. This will allow users who use the more typical setups to use Rancher in the method that they desire, and implementing an explicit behavior will give us the chance to ensure that this behavior is consistent and up to our standards of quality.

I apologize to users who have been waiting for this functionality, and hope that we can fix this issue soon.

[AndrewHoffmanQA]

test plan:

perquisite

• stand up local cluster
• configure LDAP auth and restrict the users from doing a search

bug scope

• when users can successfully configure and save an LDAP auth in a rancher instance this bug will be fixed. the rest of the test plan is a targeted regression to ensure existing functionality

Basic LDAP functionality on a LDAP setup which does not give users permission to search the LDAP setup, including:

regression areas-

• User login
• User search (i.e. add a user to a cluster or project, make sure that you can see search results with no errors in the logs)
• Group search (same idea as user search, but with groups)
• User refresh (Add a user to a group or remove a user from a group, manually refresh the user, make sure the new permissions applied)

[Jono-SUSE-Rancher]

@MbolotSuse and @martyav - Since we've release v2.7.7 and the release notes PR was merged, are we able to close this issue or does it need to be moved to a future milestone? Otherwise 2.7.7 is already tagged for community use, so I'd like to close that milestone if possible.

[martyav]

@Jono-SUSE-Rancher I'm ok with closing. From my perspective, it's already in a published page and is also mentioned in the now-closed PR if we want to track it down later from GH.

[MKlimuszka]

As the issue has been release noted, and it's not a simple bug fix. I am closing this issue in favor of a feature ticket.
#43064