[Ineligible for community support] How to configure LDAP tag_queries in new format??

[jsimao71]

Describe the bug

Configuration of LDAP tag_queries in new RabbitMQ configuration format, does not seam to work or it is not documented.
In traditional configuration this is the supported configuration:
[
{rabbitmq_auth_backend_ldap, [
{tag_queries, [{administrator, {constant, false}}]}
]}
].

But what is the equivalent configuration in new format?!?
This example file does not have (it is commented with broken syntax):
Is there any other way to configure this when using bitnami rabbitmq helmchart?!?
Using:

• new simplified configuration
• set properties of the server with rabbitmqctl eval
• env vars
• other way
  ...

Expected behavior

Should be possible to configure ldap tag_queries with new configuration format.
e.g.
auth_ldap.tag_queries = "[{administrator, {constant, false}}]"

Additional context

We are using bitnami rabbitmq helmchart:
https://github.com/bitnami/charts/tree/main/bitnami/rabbitmq

[lukebakken]

You must use the advanced.config file to configure tag_queries, as documented here:

https://www.rabbitmq.com/ldap.html#authorisation

[jsimao71]

BTW, these auth_backends.* settings were done by bitnami chart did automatically.

[jsimao71]

@lukebakken we found a way. Thanks for your help.
With this advanced config:
(2 times ldap: ldap for auth, and authz as first provider, and internal as second provider)

[{rabbit,[{auth_backends, [{rabbit_auth_backend_ldap,rabbit_auth_backend_ldap},rabbit_auth_backend_internal]}]},{rabbitmq_auth_backend_ldap, [{vhost_access_query, {constant, true}}, {resource_access_query, {constant, true}},{topic_access_query, {constant, true}},{tag_queries , [{administrator, {constant,true}}]}]}].

[michaelklishin]

Is that snippet really easy to read? Do you expect that our team will take the time to format it for you?

[
  {rabbit,[
    {auth_backends, [
      {rabbit_auth_backend_ldap, rabbit_auth_backend_ldap}, rabbit_auth_backend_internal]
    }]},

  {rabbitmq_auth_backend_ldap, [
    {vhost_access_query, {constant, true}}, 
    {resource_access_query, {constant, true}},
    {topic_access_query, {constant, true}},
    {tag_queries , [{administrator, {constant,true}}]}
  ]}
].

[michaelklishin]

The rabbit.auth_backends part can be moved to rabbitmq.conf as @lukebakken demonstrates above.

The rabbitmq_auth_backend_ldap part must remain in advanced.config as it does not have a rabbitmq.conf equivalent (it uses complex data structures with arbitrary nesting depth).

[michaelklishin]

Also, what @lukebakken's example above has is NOT an equivalent of

{rabbit_auth_backend_ldap, rabbit_auth_backend_ldap}, rabbit_auth_backend_internal]

The advanced.config version is an equivalent of

auth_backends.1.authn = ldap
auth_backends.1.authz = ldap
auth_backends.2 = internal

which can be simplified to just

auth_backends.1 = ldap
auth_backends.2 = internal

Therefore, "use LDAP first for both authN and authZ, then try the internal backend for both authN and authZ".

[michaelklishin]

I'm afraid our team does not have the resources to troubleshoot LDAP servers, schemas, queries for non-paying users.

You can enable LDAP query logging and even logging of completely unfiltered LDAP (client) traffic. That alone makes most common problems easy to spot.

If you still need help with troubleshooting LDAP queries and schema, your org can buy commercial support.

[jsimao71]

No worries @michaelklishin ! We solved the issue. Thanks!