🚨 RabbitMQ Error Guide: 'HTTP access denied' Management UI and API 401/403

Exact Error Message

The management plugin rejects a login or request and writes a warning to the broker log while returning a 401 or 403 to the caller:

2026-06-29 14:02:11.553 [warning] <0.1487.0> HTTP access denied: user 'monitoring' - Not management user
2026-06-29 14:03:48.902 [warning] <0.1512.0> HTTP access denied: user 'deploy' - invalid credentials
2026-06-29 14:05:22.118 [warning] <0.1533.0> HTTP access denied: user 'app' - not authorised to access virtual host 'orders'

The HTTP client sees one of these:

HTTP/1.1 401 Unauthorized
{"error":"not_authorised","reason":"Login failed"}

HTTP/1.1 403 Forbidden
{"error":"not_authorised","reason":"Not management user"}

In the browser, the UI shows a “Login failed” banner or, after a successful login, an almost-empty page with “Not management user.”

What the Error Means

The management HTTP API authenticates and authorises every request. A 401 means authentication failed: the username/password pair is wrong, or the user does not exist. A 403 means authentication succeeded but the user is not authorised for what they asked: they lack a management-class tag (management, monitoring, policymaker, or administrator), or they have no permission on the virtual host whose objects they tried to read.

This is distinct from AMQP authentication. A user can connect over AMQP on port 5672 and publish messages while being completely barred from the management UI on 15672, because UI access requires an extra tag that AMQP does not. The two checks are independent, which is why an account that “works for the app” still cannot log into the dashboard.

Common Causes

• No management tag. The user has permissions but no management/monitoring/administrator tag, so the UI returns “Not management user” (403).
• Wrong or rotated credentials. A password changed, a secret was not redeployed, or the username has a typo, producing “invalid credentials” (401).
• No permission on the target vhost. The user has a tag but no read permission on the vhost they are browsing, yielding “not authorised to access virtual host” (403).
• guest blocked from a remote host. The default guest user is restricted to loopback_users and cannot log in over the network.
• Insufficient tag for the action. A monitoring user trying to create a user or change a policy is rejected because that requires administrator/policymaker.
• Reverse proxy stripping the Authorization header. An nginx/ALB in front of 15672 drops Authorization, so every request arrives unauthenticated.

How to Reproduce the Error

Create a user with permissions but no tag, then call the API:

# user exists, has full vhost permissions, but no tags
rabbitmqctl add_user reporter s3cret
rabbitmqctl set_permissions -p / reporter ".*" ".*" ".*"

# the API call now returns 403 Not management user
curl -i -u reporter:s3cret http://localhost:15672/api/overview
HTTP/1.1 403 Forbidden
{"error":"not_authorised","reason":"Not management user"}

Reproduce the 401 by using the wrong password, and the loopback restriction by hitting the API as guest from another host:

curl -i -u guest:guest http://broker.internal:15672/api/whoami
HTTP/1.1 401 Unauthorized
{"error":"not_authorised","reason":"Login failed"}

Diagnostic Commands

Confirm what the broker actually sees with read-only commands:

# Is the management plugin even running and listening on 15672?
rabbitmq-diagnostics listeners | grep -i 15672

# Does the user exist, and what tags does it have?
rabbitmqctl list_users

Listing users ...
user        tags
monitoring  [monitoring]
reporter    []
admin       [administrator]

# What permissions does the user have, per vhost?
rabbitmqctl list_user_permissions reporter

vhost  configure  write  read
/      .*         .*     .*

# Validate the password without changing anything
rabbitmqctl authenticate_user reporter s3cret

# Reproduce the exact API decision the UI makes
curl -s -u reporter:s3cret http://localhost:15672/api/whoami | python3 -m json.tool

# Tail the access-denied warnings to see the precise reason string
sudo grep -i 'HTTP access denied' /var/log/rabbitmq/rabbit@$(hostname -s).log | tail -10

The reason string in the log (Not management user, invalid credentials, not authorised to access virtual host) tells you exactly which check failed.

Step-by-Step Resolution

1. Read the log reason. Grep for HTTP access denied and note whether it is invalid credentials (401, fix the password) or a Not ... user / not authorised to access virtual host message (403, fix tags or permissions).

2. For “Not management user”, add a tag:

   rabbitmqctl set_user_tags reporter monitoring

   Use monitoring for read-only dashboards, management for users who manage their own objects, and administrator only for full control.

3. For “invalid credentials”, verify the password with rabbitmqctl authenticate_user, then reset it if needed and redeploy the secret consumers use.

4. For “not authorised to access virtual host”, grant permission:

   rabbitmqctl set_permissions -p orders reporter "^$" "^$" ".*"

   The three patterns are configure/write/read; ^$ grants none while .* grants all, so the example gives read-only visibility into the orders vhost.

5. If the user is guest from a remote host, stop using guest over the network. Create a real account; guest is intentionally loopback-only.

6. If a proxy fronts 15672, confirm it forwards the Authorization header and does not rewrite the path prefix, then re-test directly against localhost:15672 to isolate the proxy.

Prevention and Best Practices

• Give each consumer of the management API its own least-privilege user: monitoring for scrapers, administrator only for humans who need it.
• Treat AMQP permissions and management tags as two separate grants — provisioning automation must set both.
• Never expose guest beyond loopback; delete it or lock it down in production.
• Store management credentials in a secret manager and rotate them with the same job that updates every consumer, so a rotation never leaves a stale 401 behind.
• Put 15672 behind TLS and a proxy that preserves Authorization, and monitor the rate of HTTP access denied log lines so credential drift surfaces early.
• Document which tag each role needs; most “permission denied” tickets are simply a missing monitoring tag.

Related Errors

• management listener failed to start — if 15672 never came up, you get connection refused, not 401; see the management listener guide.
• statistics database could not be contacted — authentication succeeds but /api/overview returns 500 instead of 403.
• ACCESS_REFUSED - Login was refused — the AMQP-side equivalent on port 5672, a different code path from the HTTP check.
• CHANNEL_ERROR … access to … refused — a per-resource AMQP permission failure rather than a UI tag failure.

More walkthroughs live in the RabbitMQ guides.

Frequently Asked Questions

Why can my app publish over AMQP but not log into the UI? AMQP uses vhost permissions only; the UI additionally requires a management-class tag. Add monitoring or management to the user.

What is the difference between the 401 and 403 I see? 401 is authentication (wrong/unknown credentials). 403 is authorisation (right credentials, but missing tag or vhost permission). The log reason string disambiguates them.

Which tag should a Prometheus or monitoring scraper use? monitoring. It grants read-only access to metrics and topology without the ability to change anything.

Why does guest fail only from other machines? guest is restricted to localhost by the loopback_users setting. Create a dedicated network user instead.

I added the tag but still get 403 on one vhost — why? Tags control UI access; per-vhost object visibility still needs set_permissions on that specific vhost. Grant at least read there.