$ guides / activemq / activemq-authorization-denied ▌

Operations Guides

ActiveMQ authorization denied: authenticated users hitting Not authorized

Your ActiveMQ broker log is filling with lines like User orders-svc is not authorized to write to: queue://PAYMENTS.INBOUND or Not authorized to create: topic://ActiveMQ.Advisory.Connection. The client connected fine. Authentication passed. But every send, consume, or destination creation attempt is rejected.

This is an authorization failure, not an authentication failure. The user proved who they are; the broker is saying they cannot do the specific thing they attempted. That distinction drives the whole diagnosis: you are not chasing bad passwords, you are chasing a mismatch between the user the client authenticated as, the operation it attempted, and the authorization entries the broker loaded.

Most of the time this is a deployment mistake: an app rolled out with the wrong credentials, pointing at the wrong destination, or missing one non-obvious permission. Occasionally it is someone probing for privilege escalation, and that case matters too.

What this means

ActiveMQ Classic’s authorization plugin checks every operation against per-destination permissions. There are three permission levels:

read: browse and consume from a destination.
write: send to a destination.
admin: create the destination (and other administrative operations on it).

The admin level is the one that surprises people. ActiveMQ auto-creates destinations on first use, but only if the authenticated user has admin permission matching that destination’s name pattern. So a producer with write on ORDERS.> that sends to a queue which does not exist yet gets “not authorized to create”, even though write alone would be enough if the queue already existed. The same applies to the broker’s internal advisory topics, which are created lazily as side effects of normal operations.

The log line tells you almost everything you need: the user, the operation (create, write, read), and the destination. Diagnosis is mapping that triple against the authorization entries the broker actually loaded.

flowchart TD
  A["Log: User X is not authorized to ..."] --> B{Which operation?}
  B -->|create| C{What is being created?}
  C -->|app destination, does not exist| D[Missing admin permission for auto-create]
  C -->|ActiveMQ.Advisory.*| E[Missing admin on ActiveMQ.Advisory.>]
  B -->|send / write| F{Destination is ActiveMQ.DLQ?}
  F -->|yes| G[Consumer user needs write on the DLQ]
  F -->|no| H[Missing write permission]
  B -->|consume / browse| I[Missing read permission]
  D --> J{Correct user and destination name?}
  E --> J
  G --> J
  H --> J
  I --> J
  J -->|yes| K[Fix authorization entries and reload]
  J -->|no| L[Fix app config, or treat as probing]

Common causes

Cause	What it looks like	First thing to check
App deployed with wrong user or destination	Denials start right after a deploy; one application affected	Which user is in the log line, and does the destination name match what the app should use
Missing `admin` for destination auto-create	`not authorized to create` on a destination that does not exist yet	Does the destination already exist on the broker
Advisory topic permission missing	`not authorized to create: topic://ActiveMQ.Advisory...` from otherwise working clients	Is there an `ActiveMQ.Advisory.>` entry granting admin to all user groups
Consumer user lacks write on the DLQ	`not authorized to write to: queue://ActiveMQ.DLQ` around consumer disconnects or message expiry	Which user is being denied and whether the broker is dead-lettering on its behalf
Wildcard character in a destination name	Denials for users who should match an entry, with `.` or `>` in the destination name	Whether the destination name itself contains wildcard characters
Authorization config edited but not loaded	Denials persist after you fixed `activemq.xml`	Whether the broker was restarted or the runtime configuration plugin is in use
Privilege escalation probing	One user attempting many destinations or admin operations it never legitimately used	Source IP, spread of destination names, correlation with authentication failures

Quick checks

All of these are read-only and safe to run during an incident.

# Count and sample authorization denials in the broker log
grep -c "not authorized" /opt/activemq/data/activemq.log
grep "not authorized" /opt/activemq/data/activemq.log | tail -30

# Correlate with authentication failures in the same window
grep -ci "authentication failed\|invalid credentials\|login failed" /opt/activemq/data/activemq.log

# Enumerate current destinations (does the denied destination exist?)
# Replace admin:admin with your Jolokia/web console credentials
curl -s -u admin:admin \
  'http://localhost:8161/api/jolokia/read/org.apache.activemq:type=Broker,brokerName=localhost/Queues'

curl -s -u admin:admin \
  'http://localhost:8161/api/jolokia/read/org.apache.activemq:type=Broker,brokerName=localhost/Topics'

Log triple extraction: pull the user, operation, and destination out of each distinct denial line. One repeated triple points at one misconfigured app; many distinct triples from one user points at probing.
Authorization entry review: read the <authorizationPlugin> section of activemq.xml and check whether an entry matches the denied destination pattern for that user’s group. The plugin reads this at startup; edits are not picked up live unless you use the runtime configuration plugin.
Destination existence check: if the denial says “create”, confirm via the queue/topic enumeration whether the destination exists. If it does not, the user lacks admin, regardless of their write rights.
JAAS and users file check: if you recently edited users or groups properties files, note that since ActiveMQ 5.12 the PropertiesLoginModule does not reload them on every request by default. You need reload=true as a login module property in the JAAS section of activemq.xml (on the org.apache.activemq.jaas.PropertiesLoginModule entry: <property name="reload" value="true"/>); the option has existed since the 5.12 properties-loading refactor.
Client-side verification: confirm which credentials the client is actually sending. Connection factories in config management sometimes drift from what operators believe is deployed.

How to diagnose it

Parse the denial line. Extract user, operation, destination. Group repeated lines; a single repeated triple is an app problem, a spray of different triples from one user is a security problem.
Map the operation to the permission level. Create maps to admin, send maps to write, consume/browse maps to read. A denial on “create” for a user that “has write access” is almost always the auto-create gap, not a bug.
Check for the advisory pattern. If the destination starts with ActiveMQ.Advisory., this is the classic misconfiguration. Advisory topics are created lazily by the broker as side effects of connections, producers, and consumers, so every connecting user group needs admin on ActiveMQ.Advisory.>. This is the single most common cause of “not authorized” in ActiveMQ.
Check for the DLQ pattern. If the denied destination is ActiveMQ.DLQ and the denied user is a consumer, the broker was trying to dead-letter messages on that consumer’s behalf (for example expired messages at consumer disconnect). The consumer never sends to the DLQ explicitly, so operators rarely grant it write there.
Verify the authorization entries actually loaded. Compare the running broker’s behavior against activemq.xml. If the file was edited but the broker not restarted (and no runtime configuration plugin is configured), the old policy is still in force.
Decide: misconfiguration or probing. Misconfiguration repeats one or two triples tied to a recent deploy. Probing shows one user enumerating destinations, attempting admin operations, or targeting destinations it has never used. Correlate with the authentication failure rate and the source IP before dismissing it as noise.

Metrics and signals to monitor

Signal	Why it matters	Warning sign
Authorization denial rate	The primary signal; every denial is a rejected operation from a connected client	Any sustained non-zero rate; a new repeated triple after a deploy
Authentication failure rate	Distinguishes “wrong permissions” from “wrong credentials” and flags brute force alongside probing	Auth failures and denials from the same source IP together
Unexpected destination creation	Auto-create means any permitted user can create destinations; unexpected names indicate misrouted apps or abuse	New destinations outside the expected naming convention
Consumer count on affected queues	An authorization fix that does not take effect leaves consumers unable to connect or subscribe	Consumer count below expected after a credential or policy change
Enqueue/dequeue rate on affected destinations	A denied producer or consumer silently stops message flow for that destination	Rate dropping to zero on a destination whose clients are “connected”

Fixes

App using the wrong user or destination

Fix the application configuration: credentials, connection factory, or destination name. This is the most common case and the cheapest fix. If the destination name was simply wrong (typo, wrong environment prefix), the security concern disappears once the app points at the right place. Verify with the log: the denial triple should stop appearing within one reconnect cycle.

Missing admin for auto-create

Two options, in order of preference for production:

Pre-create destinations as an administrative user (via the web console, JMX, or a provisioning step), then grant application users only read and write. This removes the need for apps to hold admin anywhere, gives you a controlled destination inventory, and stops typos from silently creating new destinations.
Grant admin on the destination pattern to the producer/consumer groups that legitimately create destinations. Acceptable in development; in production it means any compromised app credential can create arbitrary destinations matching the pattern.

Advisory topic denials

Add an authorization entry granting admin on ActiveMQ.Advisory.> to every group that connects to the broker. Advisory destinations are created as side effects of normal client behavior, so a locked-down policy that omits them breaks otherwise valid clients. If you do not use advisories, you can instead disable advisory support on the destinations where they are not needed, which shrinks both this permission surface and destination count.

DLQ write denials for consumer users

The broker dead-letters messages (expired messages, messages past max redeliveries) using the context of the consuming user. That user therefore needs write on ActiveMQ.DLQ even though it never intentionally sends there. Grant write on the DLQ to consumer groups. To narrow that surface, use a per-destination DLQ (IndividualDeadLetterStrategy), which routes each queue’s dead letters to its own DLQ.<queue> destination so a consumer only needs write on the DLQ of the queues it consumes; a dedicated DLQ routing user is not a standard ActiveMQ pattern.

Wildcard characters in destination names

If a destination name itself contains > or other wildcard characters, the authorization map can match it unexpectedly and deny users who should have access. Rename the destination to a plain name and update producers and consumers. There is no configuration workaround cleaner than not using wildcard characters in names.

Policy changes not taking effect

Restart the broker to load the edited activemq.xml, or use the runtime configuration plugin for live updates. If you edited users/groups properties files for the PropertiesLoginModule, set reload=true in the JAAS configuration or restart. A broker restart drops all connected clients and halts message flow, so treat it as disruptive: confirm config drift is actually the cause before restarting a production broker mid-incident, and prefer the runtime configuration plugin for routine policy updates.

Privilege escalation probing

Treat it as a security event, not an ops ticket. Identify the source IP and the authenticated user, check whether that credential should exist at all, and rotate it if there is any doubt. Default ActiveMQ installations ship with well-known credentials and no built-in rate limiting on authentication attempts, so an account probing authorization boundaries may have authenticated with a default or weak password.

Stay patched on authorization CVEs

Recent releases fixed real authorization bugs. CVE-2026-46605 (fixed in 5.19.7 and 6.2.6) allowed authenticated connections to remove existing destinations without proper permission checks; CVE-2026-49157 (fixed in 5.19.7 and 6.2.6) tightened the default Jolokia authorization so non-admin web-login accounts could no longer run broker-management operations; CVE-2026-54475 (fixed in 5.19.8 and 6.2.7) made temporary-destination ownership enforced broker-side instead of only client-side. If you are on an older release, some of the denials you see after upgrading may be the fixed code finally doing its job. Conversely, if destination-management automation breaks after upgrading to 5.19.7 or later, it was relying on the previously incomplete removeDestination check: grant that user the required destination permission instead of rolling back the upgrade.

Prevention

Pre-create production destinations and grant applications only read/write. This converts the auto-create gap from a recurring incident into a provisioning step.
Include the advisory entry by default. Every locked-down authorization policy should include ActiveMQ.Advisory.> for all connecting groups, or explicitly disable advisories where unused.
Alert on denial rate, not just on outages. Each denial is a client that connected and was refused. A new repeated triple after a deploy should page the deploying team before users notice missing messages.
Test authorization in staging with production-identical policies. Most of these incidents trace back to staging environments with anonymous or wide-open access, so the wrong user or missing admin grant only surfaces in production.
Keep an expected-destination inventory. Periodic enumeration of queues and topics against a whitelist catches both misrouted apps and unauthorized creation early.
Rotate credentials on a schedule and after any probing event, and eliminate default credentials everywhere.

How Netdata helps

Log pattern counting turns not authorized lines from a file you grep during incidents into a continuous rate you can alert on, grouped so a new repeated triple stands out immediately.
Correlation with authentication failures separates “deployed with wrong user” (denials only, one source) from “credential attack” (auth failures plus denials from the same source) without manual log archaeology.
Consumer count and dequeue rate per destination confirm the blast radius: an authorization denial that takes a consumer offline shows up as a subscription drop and a rate collapse on that queue, which tells you which denials are urgent.
Destination count tracking catches the side effect of over-broad admin grants: unexpected destination creation showing up as inventory growth between deploys.
Deploy-time overlays make the “denials started right after the 14:30 rollout” correlation a glance instead of a timeline reconstruction.