Multiple LDAP requests at a time

[dlange4]

Describe the bug

When LDAP is enabled, the server makes 11 sets of LDAP request (bind/lookup/query check) upon connecting with the admin UI, and upon each refresh. Why are multiple requests required, and is there some way to prevent it?

I tried enabling the backend cache package to see if it would prevent the issue, but it does not.

Attached is a sample from our log indicating the sequence of requests that occur.

log.txt

Here are the LDAP settings from our rabbitmq.conf and advanced.config (with some values masked):

auth_backends.1 = rabbit_auth_backend_ldap
auth_ldap.servers.1 = xx.xx.xxxx.net
auth_ldap.user_dn_pattern = ${username}@xyz.org
auth_ldap.dn_lookup_attribute = userPrincipalName 
auth_ldap.dn_lookup_base      = DC=xx,DC=xx,DC=xxxx,DC=net

[
{
	rabbit,
	[
		{auth_backends,
		[
			rabbit_auth_backend_ldap
		]}
	]
},
{
	rabbitmq_auth_backend_ldap,
	[   
		{servers, ["xx.xx.xxxx.net"]},
		{dn_lookup_base, "DC=xx,DC=xx,DC=xxxx,DC=net"},
		{dn_lookup_attribute, "userPrincipalName"},
		{user_dn_pattern, "${username}@xyz.org"},
		{log, on},
		{
			tag_queries, [
				{administrator, {in_group,  "CN=GGGGGG, OU=ZZZZZZ, OU=YYYYYY, OU=XXXXXX, DC=xx, DC=xx, DC=xxxx, DC=net","member"}},
				{management,    {constant, true}}
			]
		}
	]
}
].

Reproduction steps

1. Enable LDAP (including logging).
2. Connect to rabbit using the admin UI browser app.
3. Observe the sequence of requests in the log.
4. Refresh the admin UI.
5. Observe the same sequence of requests in the log.

Expected behavior

One request sequence (bind/lookup/query check) per login or refresh.

[lukebakken]

Please don't open an issue unless you are certain you have found a bug.

Using the cache backend is the correct solution, but you don't provide any information on how you tried to use it.

Please see the docs - https://www.rabbitmq.com/docs/ldap#query-caching

If you continue to have issues, provide your COMPLETE configuration files using the cache backend in combination with LDAP.

[michaelklishin]

Our Community Support policy explicitly states that we will not troubleshoot LDAP installations of non-paying and non-contributing users.

However, @lukebakken has generously explained what the solution is: a separate plugin that caches LDAP requests and is absolutely essential in production environments, or one day RabbitMQ cluster LDAP requests are guaranteed to put very non-trivial load on your LDAP server. We have seen this many times over the years.

"One sequence of LDAP connections" will not work for one simple reason: there are N entities that
may be performing permissions checks concurrently and completely independently: on different connections, that can even be to different virtual hosts.

[michaelklishin]

I tried enabling the backend cache package to see if it would prevent the issue, but it does not

Yes, it does after a short burst at first, when the cache is empty. Then for N minutes, or at least some 30-60 seconds, all repeated permission checks will use the cached responses.

This solution is very easy to reason about and has been around for a close to a decade, working at very large scale. We have no plans to try to "synchronize" LDAP client requests across different connections.