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

CauseWhat it looks likeFirst thing to check
App deployed with wrong user or destinationDenials start right after a deploy; one application affectedWhich user is in the log line, and does the destination name match what the app should use
Missing admin for destination auto-createnot authorized to create on a destination that does not exist yetDoes the destination already exist on the broker
Advisory topic permission missingnot authorized to create: topic://ActiveMQ.Advisory... from otherwise working clientsIs there an ActiveMQ.Advisory.> entry granting admin to all user groups
Consumer user lacks write on the DLQnot authorized to write to: queue://ActiveMQ.DLQ around consumer disconnects or message expiryWhich user is being denied and whether the broker is dead-lettering on its behalf
Wildcard character in a destination nameDenials for users who should match an entry, with . or > in the destination nameWhether the destination name itself contains wildcard characters
Authorization config edited but not loadedDenials persist after you fixed activemq.xmlWhether the broker was restarted or the runtime configuration plugin is in use
Privilege escalation probingOne user attempting many destinations or admin operations it never legitimately usedSource 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 in the JAAS config for runtime reloading.
  • 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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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

SignalWhy it mattersWarning sign
Authorization denial rateThe primary signal; every denial is a rejected operation from a connected clientAny sustained non-zero rate; a new repeated triple after a deploy
Authentication failure rateDistinguishes “wrong permissions” from “wrong credentials” and flags brute force alongside probingAuth failures and denials from the same source IP together
Unexpected destination creationAuto-create means any permitted user can create destinations; unexpected names indicate misrouted apps or abuseNew destinations outside the expected naming convention
Consumer count on affected queuesAn authorization fix that does not take effect leaves consumers unable to connect or subscribeConsumer count below expected after a credential or policy change
Enqueue/dequeue rate on affected destinationsA denied producer or consumer silently stops message flow for that destinationRate 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.

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 destinations without proper permission checks; CVE-2026-49157 tightened default Jolokia authorization for web-login accounts; CVE-2026-54475 addressed temporary destination ownership being enforced 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, check whether it was relying on the previously incomplete removeDestination check.

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.