vhost in tag queries not work

[spham]

Hi
I have created 2 groups
host_administrator and host_monitoring

and it's with tihs pattern,

"CN=${vhost}_administrator,OU=RabbitMQ,OU=SVC,OU=France,DC=toto,DC=com"

and it return false .

my rabbitmq 3.9.5 on centos 7.
Active Directory

when i do this is ok

{rabbitmq_auth_backend_ldap,[
    {tag_queries, [
           {administrator,  {in_group,"CN=role_administrator ,OU=RabbitMQ,OU=lsi,OU=France,DC=toto,DC=com"}},
           {monitoring,     {in_group,"CN=role_monitoring ,OU=RabbitMQ,OU=lsi,OU=France,DC=toto,DC=com"}}
    ]},
    {vhost_access_query, {in_group, "CN=${vhost},OU=RabbitMQ,OU=lsi,OU=France,DC=toto,DC=com"}}
  ]}].

but with $vhost in tag queries, is not work

{
    rabbitmq_auth_backend_ldap, [
    {tag_queries, [
           {administrator,  {in_group,"CN=${vhost}_role_administrator ,OU=RabbitMQ,OU=lsi,OU=France,DC=toto,DC=com"}},
           {monitoring,     {in_group,"CN=${vhost}_role_monitoring ,OU=RabbitMQ,OU=lsi,OU=France,DC=toto,DC=com"}}
    ]},
    {vhost_access_query, {in_group, "CN=${vhost},OU=RabbitMQ,OU=lsi,OU=France,DC=toto,DC=com"}}

in log, i see this that ${vhost} is not evaluated in tag_queries.

my idea is created many group in ldap

vhostA_role_administrator.
vhostA_role_monitor.
vhostB_role_administrator.
vhostB_role_monitor.

So user can be administrator on vhostA, but only monitor in vhostB

but tag_queries failed

return this in log

LDAP evaluated in_group for "CN=${vhost}_role_monitoring_group ,OU=RabbitMQ,OU=lsi,OU=France,DC=toto,DC=com": {error, noSuchObject} LDAP DECISION: does [email protected] have tag monitoring? {error,noSuchObject}

it should return vhostA_role_monitoring_group

[michaelklishin]

I will convert this issue to a GitHub discussion. Currently GitHub will automatically close and lock the issue even though your question will be transferred and responded to elsewhere. This is to let you know that we do not intend to ignore this but this is how the current GitHub conversion mechanism makes it seem for the users :(

[michaelklishin]

We cannot comment on much with this amount of information. You can enable LDAP query logging to see if the plugin performs the queries you expect. Whether those queries are "correct", we don't know.

One thing that stands out is #{vhost}}} which certainly does not seem correct due to the trailing curly braces.

[spham]

I update my question, it's maybe clear now ?

[lukebakken]

https://www.rabbitmq.com/ldap.html#in-group-query

As you see in the docs, this should work. For us to assist, you must provide the following information:

• Erlang and RabbitMQ version
• Operating system version
• LDAP server being used
• Complete, un-edited configuration files. In your examples some of the vhost names end with _group and some don't, which suggests errors in how you're reporting this issue
• Complete log files, or at least more LDAP logging than what you have provided

[lukebakken]

${vhost}_{{ rabbit_group_suf }}

Can you explain {{ rabbit_group_suf }}? That syntax is not supported by the LDAP plugin.

[spham]

I remove it, it's a just an ansible tag
because my config is in jinja template.

[lukebakken]

@spham here's what is happening. When you bring up the management UI for the very first time and log in, there is no vhost specified. I ran a trace and you can see it here:

(rabbit@bakkenl-z01)2> redbug:start("rabbit_access_control:check_user_login/2").
{11,1}
                       
% 16:27:15 <0.1280.0>(dead)
% rabbit_access_control:check_user_login(<<"guest">>, [{password,<<"guest">>}])

Note that there is no vhost to pass into the LDAP plugin to use in the ${vhost} template.

Since your LDAP query depends on this, you'll always get a failure. Apparently this is a scenario that people don't run into because it's unusual to give a broad number of user accounts access to the Management UI.

I'm pretty sure you can work around this by using the internal auth backend as a "backup". For any user who must have access to the management UI, add them to RabbitMQ's internal database. You don't need to give them a password, just the correct vhost permissions and tags. Let's say frank is a management user and susie is an administrator. You would add them with these two commands (PASSWORD would be an un-guessable value):

rabbitmqctl add_user frank PASSWORD
rabbitmqctl add_user susie PASSWORD
rabbitmqctl set_user_tags frank management
rabbitmqctl set_user_tags susie administrator

(Note: the HTTP API can also be used for the above)

Then, you'll still see the same LDAP "not found" but the internal DB should be used as a backup for looking up tags (https://www.rabbitmq.com/access-control.html#combined-backends)

You won't have to do this for all of your vhosts because as soon as the user logs in and chooses a different vhost they'll use that vhost for auth.

Let me know if the above works, and I'll ask the team if we should consider this a bug or not. I think to fix it we'd have to add a vhost selector to the login screen.

[michaelklishin]

This has nothing to do with LDAP. Management UI can issue requests without a virtual host "attached", which means this information won't be available to authN/authZ backends, including LDAP.

If you choose a specific virtual host in the management UI, all requests will be scoped to that virtual host (at least as much as possible).
Some operations are not associated with a virtual host at all, though.

[lukebakken]

That list of vhosts is never filtered. Only operations that use that vhost are checked for access.

[spham]

how about this issue ? vhost substitution

rabbitmq/rabbitmq-auth-backend-ldap#13

[spham]

[lukebakken]

My suggestion may be your only option.

can you check for add vhost selector @lukebakken ukebakken ?

Do you mean and vhost selector? I don't understand.

At this point, the best way to help us help you would be to provide files to load into an OpenLDAP instance to simulate your environment. Provide complete RabbitMQ configuration files that you are using, and provide exact steps describing what you're trying to accomplish.

I can guess but the time it would take me to set up an LDAP environment is time I could spend helping you.

[spham]

it's you tell me about selector " I think to fix it we'd have to add a vhost selector to the login screen."
how can cost this issue or evolution ?

[spham]

about your suggestion, I already use combined backend like this

auth_backends.1 = ldap
auth_backends.2 = internal

[spham]

hi
@lukebakken , you have suggested create user

rabbitmqctl add_user frank PASSWORD
rabbitmqctl add_user susie PASSWORD
rabbitmqctl set_user_tags frank management
rabbitmqctl set_user_tags susie administrator

but issue is not in tags, but in vhost,
how to grant permission in vhost ?

what i wish :

rabbitmqctl set_permissions -p vhost1 user1 'administrator'
rabbitmqctl set_permissions -p vhost2 user1 ''monitoring'

I try this
sudo rabbitmqctl set_user_tags user1 'administrator','monitoring'
but i can't tel for wich vhost is administrator

[lukebakken]

My suggestion is to use the combined backend and LDAP. As I said before, please provide an LDAP environment I can set up using OpenLDAP. I also have access to Active Directory Lightweight DS on Windows.

I have an idea of what you're trying to do but I don't have the time to try and set up users and groups the same way you have.

Tags are not per-vhost in the internal backend but they could be in others.

[spham]

[lukebakken]

https://groups.google.com/g/rabbitmq-users/c/BBvqEfogmp0/m/qEkQwr62AgAJ

Setting tags per-vhost is not supported in that way. It should be possible using the LDAP and other backends. I will try to come up with something using my local LDAP server.

[spham]

How make customers work on many project and don't want to share all vhost ?

[spham]

in fact i dont get why it's not work

sudo rabbitmqctl set_user_tags -p vhost1 user1 'administrator'
sudo rabbitmqctl set_user_tags -p vhost2 user1 'monitoring'

if command are set like this

[lukebakken]

The management UI was never intended to have permissions like this. You may just have to give everyone access and trust them to do the right thing.

Like I said, I'm going to try to come up with a solution. Please be patient. There is no need to continually ask the same questions over and over. The RabbitMQ team has much more important work to prioritize.

[lukebakken]

Even though rabbitmqctl set_user_tags accepts a -p argument it has no effect. THis is explained in the help for the command:

C:\Users\bakkenl\rmq-server\rabbitmq_server-3.9.13> .\sbin\rabbitmqctl.bat help set_user_tags

Usage

rabbitmqctl [--node <node>] [--longnames] [--quiet] set_user_tags <username> <tag> [...]

Sets user tags.


Arguments and Options

<username>
        Self-explanatory

<tags>
        Space separated list of tags


Relevant Doc Guides

 * https://rabbitmq.com/management.html

 * https://rabbitmq.com/access-control.html


General Options

The following options are accepted by most or all commands.

short            | long          | description
-----------------|---------------|--------------------------------
-?               | --help        | displays command help
-n <node>        | --node <node> | connect to node <node>
-l               | --longnames   | use long host names
-t               | --timeout <n> | for commands that support it, operation timeout in seconds
-q               | --quiet       | suppress informational messages
-s               | --silent      | suppress informational messages
                                 | and table header row
-p               | --vhost       | for commands that are scoped to a virtual host,
                 |               | virtual host to use
                 | --formatter   | alternative result formatter to use
                                 | if supported: json, pretty_table, table, csv, erlang
                                   not all commands support all (or any) alternative formatters.

Note that there is NO -p listed in Usage which means even though you can set it the argument has no effect.

[lukebakken]

@spham

I have two vhosts set up locally, vhost1 and vhost2.

I set up Active Directory LDS on my Windows 10 laptop. I have the following two groups:

CN=vhost1,OU=groups,DC=bakken,DC=io
CN=vhost2,OU=groups,DC=bakken,DC=io

And the following users, which are members of the respective groups above:

CN=VHost1 User,OU=users,DC=bakken,DC=io
    userPrincipalName: vhost1user

CN=VHost2 User,OU=users,DC=bakken,DC=io
    userPrincipalName: vhost2user

I have attached my two RabbitMQ config files:
advanced.config.txt
rabbitmq.conf.txt

Enabled plugins:

C:\Users\bakkenl\rmq-server\rabbitmq_server-3.9.13> .\sbin\rabbitmq-plugins.bat list
Listing plugins with pattern ".*" ...
 Configured: E = explicitly enabled; e = implicitly enabled
 | Status: [failed to contact rabbit@bakkenl-z01 - status not shown]
 |/
[E ] rabbitmq_auth_backend_ldap        3.9.13
[E ] rabbitmq_management               3.9.13
[e ] rabbitmq_management_agent         3.9.13
[e ] rabbitmq_web_dispatch             3.9.13

Test procedure:

• Verify that a user is in the expected group with the following LDAP queries:

  (&(objectClass=user)(userPrincipalName=vhost1user)(memberOf=CN=vhost1,OU=groups,DC=bakken,DC=io))
  
  # OUTPUT
  
  ***Searching...
  ldap_search_s(ld, "DC=bakken,DC=io", 2, "(&(objectClass=user)(userPrincipalName=vhost1user)(memberOf=CN=vhost1,OU=groups,DC=bakken,DC=io))", attrList,  0, &msg)
  Getting 1 entries:
  Dn: CN=VHost1 User,OU=users,DC=bakken,DC=io
  badPasswordTime: 0 (never); 
  badPwdCount: 0; 
  cn: VHost1 User; 
  distinguishedName: CN=VHost1 User,OU=users,DC=bakken,DC=io; 
  dSCorePropagationData: 0x0 = (  ); 
  instanceType: 0x4 = ( WRITE ); 
  lastLogonTimestamp: 2/5/2022 8:22:41 AM Pacific Standard Time; 
  lockoutTime: 0; 
  memberOf: CN=vhost1,OU=groups,DC=bakken,DC=io; 
  name: VHost1 User; 
  objectCategory: CN=Person,CN=Schema,CN=Configuration,CN={DECBE24A-33AF-4451-B73C-E68ED260B3B8}; 
  objectClass (4): top; person; organizationalPerson; user; 
  objectGUID: 99127603-fb94-4f02-afc3-559a0fee2851; 
  objectSid: S-1-377650393-1781599374-2209988299-1293857666-2515862194-3904278115; 
  pwdLastSet: 2/4/2022 11:35:45 AM Pacific Standard Time; 
  userPrincipalName: vhost1user; 
  uSNChanged: 12518; 
  uSNCreated: 12475; 
  whenChanged: 2/5/2022 8:22:41 AM Pacific Standard Time; 
  whenCreated: 2/4/2022 11:35:29 AM Pacific Standard Time; 
  

• Start RabbitMQ and open a private, incognito browser window, and go to http://localhost:15672
• Log in using the vhost1user account. You will only be able to manage the vhost1 vhost
• Open a new, private, incognito browser window, and go to http://localhost:15672
• Log in using the vhost2user account. You will only be able to manage the vhost2 vhost

I did not test AMQP operations but I'm pretty sure they'll be correctly limited.

I also did not enable the caching plugin but you should do that.

Note:

Due to how my LDAP environment works I had to configure the following settings:

auth_ldap.dn_lookup_bind.user_dn = CN=x-bakkenl,OU=users,DC=bakken,DC=io
auth_ldap.dn_lookup_bind.password = test1234

auth_ldap.other_bind.user_dn = CN=x-bakkenl,OU=users,DC=bakken,DC=io
auth_ldap.other_bind.password = test1234

My x-bakkenl LDAP account is an administrator that can do subtree queries.

Please see if the above configuration accomplishes what you need (or close to it).

[spham]

This not resolve my issue. And i doubt vhost is valuated in tag_queries

Multitag per user

How to give vhost1user administrator for vhost1 et vhost2 ?
vhost2user administrator for vhost2 but management for vhost1 ?

[lukebakken]

How to give vhost1user administrator for vhost1 et vhost2 ?
vhost2user administrator for vhost2 but management for vhost1 ?

You might be able to go this with clever group membership, I'm not sure.

[spham]

I have 2 question

1. I Dont think vhost in tag queries je valuated. Are you sure ?
2. This behaviour is not ok. You have set management To true.

Initial request is see by vhost.

user1/management/vhost1,admin,vhost2
Etc..

[lukebakken]

I Dont think vhost in tag queries je valuated. Are you sure ?

Did you try my configuration suggestions? With them, if I log in using vhost1user I can only do operations with vhost1. Here is some authentication output:

2022-02-05 17:38:45.860000-08:00 [info] <0.416.0>     LDAP bind succeeded: CN=x-bakkenl,OU=users,DC=bakken,DC=io^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.416.0>     LDAP CHECK: does vhost1user have tag administrator?^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.416.0>     LDAP evaluating query: {in_group,"CN=${vhost},OU=groups,DC=bakken,DC=io"}^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.416.0>     LDAP evaluating query: {in_group,"CN=${vhost},OU=groups,DC=bakken,DC=io",^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.416.0>                                      "member"}^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.416.0>         LDAP filling template "CN=${vhost},OU=groups,DC=bakken,DC=io" with^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.416.0>             [{username,<<"vhost1user">>},^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.416.0>              {user_dn,"CN=VHost1 User,OU=users,DC=bakken,DC=io"},^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.416.0>              {vhost,<<"vhost1">>}]^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.416.0>         LDAP template result: "CN=vhost1,OU=groups,DC=bakken,DC=io"^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.851.0>     LDAP network traffic: search request = {'SearchRequest',^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.851.0>                                             "CN=vhost1,OU=groups,DC=bakken,DC=io",^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.851.0>                                             baseObject,derefAlways,0,0,false,^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.851.0>                                             {equalityMatch,^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.851.0>                                              {'AttributeValueAssertion',^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.851.0>                                               "member",^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.851.0>                                               "CN=VHost1 User,OU=users,DC=bakken,DC=io"}},^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.851.0>                                             ["objectClass"]}^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.851.0> ^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.851.0>     LDAP network traffic: search reply = {ok,^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.851.0>                                           {'LDAPMessage',259,^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.851.0>                                            {searchResEntry,^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.851.0>                                             {'SearchResultEntry',^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.851.0>                                              "CN=vhost1,OU=groups,DC=bakken,DC=io",^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.851.0>                                              [{'PartialAttribute',^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.851.0>                                                "objectClass",^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.851.0>                                                ["top","group"]}]}},^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.851.0>                                            asn1_NOVALUE}}^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.851.0> ^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.851.0>     LDAP network traffic: search reply = {ok,^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.851.0>                                           {'LDAPMessage',259,^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.851.0>                                            {searchResDone,^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.851.0>                                             {'LDAPResult',success,[],[],^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.851.0>                                              asn1_NOVALUE}},^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.851.0>                                            asn1_NOVALUE}}^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.851.0> ^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.851.0>     LDAP network traffic: search reply = searchResDone^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.851.0> ^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.416.0>     LDAP evaluated in_group for "CN=vhost1,OU=groups,DC=bakken,DC=io": true^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.416.0>     LDAP DECISION: does vhost1user have tag administrator? true^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.416.0>     LDAP CHECK: does vhost1user have tag management?^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.416.0>     LDAP evaluating query: {constant,true}^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.416.0>     LDAP evaluated constant: true^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.416.0>     LDAP DECISION: does vhost1user have tag management? true^[[0m
2022-02-05 17:38:45.860000-08:00 [info] <0.1238.0> LDAP DECISION: login for vhost1user: ok^[[0m
^[[38;5;246m2022-02-05 17:38:45.860000-08:00 [debug] <0.1238.0> User 'vhost1user' authenticated successfully by backend rabbit_auth_backend_ldap^[[0m

This behaviour is not ok. You have set management To true.

I've spent quite a bit of time coming up with something to try and guess what you need based on some very limited information. At this point, you need to figure this out on your own. Hopefully what I've provided and the RabbitMQ docs can help. I can't spend any more time giving free assistance.

[spham]

[lukebakken]

In order to use the Management web interface, a user MUST have the management tag -

https://www.rabbitmq.com/management.html#permissions

---

You asked:

it exist something like this ?

rabbitmqctl set_user_tags user1 [{''vhost1','administrator'},{'vhost2','monitoring'}] ?

My answer is correct. You can't use the rabbitmqctl set_user_tags command that way to set tags per-vhost like that.

---

With the configuration you provide -

{rabbitmq_auth_backend_ldap,[
    {tag_queries, [
           {administrator,  {in_group,"CN=role_administrator ,OU=RabbitMQ,OU=lsi,OU=France,DC=toto,DC=com"}},
           {monitoring,     {in_group,"CN=role_monitoring ,OU=RabbitMQ,OU=lsi,OU=France,DC=toto,DC=com"}}
    ]},
    {vhost_access_query, {in_group, "CN=${vhost},OU=RabbitMQ,OU=lsi,OU=France,DC=toto,DC=com"}}
  ]}].

If a user is neither in the role_administrator nor role_monitoring groups, they will NOT have access to the management web interface, since they must at minimum have the management tag.

I will cc both @dumbbell and @acogoluegnes since they are native French speakers and should be able to assist, or at least better understand how the configuration you provide isn't quite right.

[spham]

with your config,

{resource_access_query, {in_group, "CN=${vhost},OU=groups,DC=bakken,DC=io"}},
{vhost_access_query, {in_group, "CN=${vhost},OU=groups,DC=bakken,DC=io"}},
{tag_queries, [
    {administrator, {in_group, "CN=${vhost},OU=groups,DC=bakken,DC=io"}},
    {management, {constant, true}}
]}

i have issue, because management and administrator are true in same time, and management is set as default always.

LDAP evaluated in_group for "...": true
2022-02-08 12:05:03.415021+00:00 [info] <0.398.0>     LDAP DECISION: does user1 have tag administrator? true
2022-02-08 12:05:03.415134+00:00 [info] <0.398.0>     LDAP CHECK: does user1 have tag management?
2022-02-08 12:05:03.415256+00:00 [info] <0.398.0>     LDAP evaluating query: {constant,true}

when i try this

curl -i -u login:password@ http://localhost:15672/api/whoami

i always have tags management

{"name":"login","tags":["management"]}

and i have only this, and i wish to manage vhost

[lukebakken]

and i have only this, and i wish to manage vhost

Log in using a new private browsing window (Incognito window in Chrome). If you logged in as a different user before in a "normal" window the previous cookies may be affecting your new session.

[spham]

issue it not on browser, same issue

[lukebakken]

I requested some information in this message:

https://groups.google.com/g/rabbitmq-users/c/Z5OUSSvpRkk/m/oA_SoI8EBAAJ

I answered your question about curl here -

#4123 (comment)

If you are not seeing the administrator tag when you expect, it is because of one of these reasons:

• The user is not in the expected group.
• The operation you are performing via the API or in the management UI does not have a vhost associated with it.

You have only provided small screenshots so I can't tell what you are doing in the management UI.

First, you need to prove that the user account you log into is the member of the expected group to be granted the administrator tag. You can do this by providing the following:

• Complete configuration files
• LDAP network_unsafe log
• The output of an LDAP query

Once we are certain LDAP is set up correctly, take a screen capture video of logging into the management interface using that account.

As I describe in this comment, everything works as expected. You must be doing something different.

Finally, I will only follow up in this discussion and will redirect new issues or discussions here to keep everything in one place.

[spham]

how to make one user with tag administror for one vhost ?

[lukebakken]

My configuration works for that -

{resource_access_query, {in_group, "CN=${vhost},OU=groups,DC=bakken,DC=io"}},
{vhost_access_query, {in_group, "CN=${vhost},OU=groups,DC=bakken,DC=io"}},
{tag_queries, [
    {administrator, {in_group, "CN=${vhost},OU=groups,DC=bakken,DC=io"}},
    {management, {constant, true}}
]}

Assume that the user is named foobar and the vhost is named bazbat. With the above configuration, the group CN=bazbat,OU=groups,DC=bakken,DC=io has one user in it (CN=foobar,OU=users,DC=bakken,DC=io).

If that doesn't work for you, please carefully re-read this comment -

#4021 (comment)

It is very difficult to assist you when I only get one sentence questions and replies, without any more context.

[spham]

all context are already send, thank you for your time