RabbitMQ: how to handle account lockout requirements
Article ID: 431920
Updated On:
Products
Issue/Introduction
RabbitMQ does not enforce any account lockout policy after multiple failed login attempts. What are the alternatives?
Environment
All supported RabbitMQ and Erlang Versions
Cause
RabbitMQ does not have a built-in account lockout mechanism (for example, temporarily disabling an account after N failed login attempts) in its core authentication backends, including the default internal backend. RabbitMQ continues to validate credentials on each authentication attempt and either allows or denies access, without tracking per-user failure thresholds across any protocol.
Resolution
There is no native account lockout switch in RabbitMQ; any lockout behavior must be implemented via your directory/IdP, application logic, or surrounding infrastructure controls, while RabbitMQ remains a stateless (“dumb”) credential checker.
RabbitMQ is designed for high-throughput messaging, and implementing a stateful failed-login counter directly in the broker could create performance bottlenecks or be leveraged for Denial of Service (DoS) attacks (for example, an attacker intentionally locking out service accounts).
To meet account lockout requirements, change how RabbitMQ authenticates users or add controls around it.
What RabbitMQ Does Offer for Authentication Security
- Metrics for failed attempts
Since 3.8.x, RabbitMQ exposes counters for successful and failed authentication attempts (total and optionally per-user/IP/protocol) via Prometheus, the HTTP API, and the Management UI. These metrics can be monitored to detect brute-force patterns. - Logging
Failed logins are logged with details such as remote IP and attempted username, allowing you to feed logs into external tools (SIEM, monitoring, or security automation). - Other protections
RabbitMQ supports strong password hashing, external authentication backends (LDAP, OAuth 2.0/OIDC, HTTP), TLS for transport encryption, IP filtering and rate limiting via firewalls or load balancers, and the ability to reject blank or weak credentials via policy and configuration.
Strategy 1 – Delegate to LDAP / Active Directory
The most common enterprise solution is to move authentication away from RabbitMQ’s internal user database and use the rabbitmq_auth_backend_ldap plugin.
- How it works
RabbitMQ forwards the presented username/password to your LDAP/AD server for verification.
Note: Enabling LDAP alone does not define the lockout rule; thresholds and timing are configured on the LDAP/AD side. RabbitMQ does not add its own lockout logic on top.
Strategy 2 – Use OAuth 2.0 / OIDC
If you want a more “cloud-native” approach, you can use the rabbitmq_auth_backend_oauth2 plugin.
- How it works
Applications present a JWT (JSON Web Token) issued by an Identity Provider such as Keycloak, Auth0, or Okta. RabbitMQ validates the token’s signature and claims.
As with LDAP, OAuth 2.0/OIDC only provides lockout if the IdP’s policy defines it; RabbitMQ itself does not track failed login counts.
Strategy 3 – Externalize security with a reverse proxy and host controls
If you cannot move away from internal RabbitMQ users, you can still reduce brute-force risk by placing controls in front of RabbitMQ, especially the Management UI and HTTP API.
- Reverse proxy (NGINX / HAProxy)
- Place NGINX or HAProxy in front of the Management API (port 15672) or other HTTP endpoints.
- Use features like NGINX limit_req or HAProxy stick-tables plus http-request deny to rate-limit login attempts and slow or block brute-force attacks.
- Fail2Ban / host-based blocking
- Configure Fail2Ban to monitor RabbitMQ logs (or proxy logs) for repeated HTTP 401 or “access denied” messages from specific IPs.
- Fail2Ban can then trigger IP-level blocks via iptables, nftables, or cloud firewall rules.
This approach implements IP-based lockout and brute-force mitigation, but does not “lock” individual RabbitMQ user accounts. For per-user lockout, use LDAP/AD or OAuth 2.0/OIDC as described above.
Additional Information
Clarifications
- Enabling LDAP alone does not guarantee account lockout; that behavior is configured and enforced on the directory server.
- Using OAuth 2.0/OIDC allows you to satisfy multiple requirements at once: account lockout, MFA, and control over token/session duration—again, all enforced by the IdP.
References
Feedback
