Internal Database vs LDAP for Credential Expiration Management

Direct Answer

RabbitMQ's internal authentication backend (rabbitmq_auth_backend_internal) does not provide a built-in, time-based credential expiration mechanism. User passwords remain valid until explicitly changed or removed, meaning any expiration policy must be driven by external scripts, automation, or operating-system password rules. In contrast, the rabbitmq_auth_backend_ldap plugin delegates authentication to an external LDAP directory. If the directory runs a password-policy overlay (e.g., OpenDJ, 389 Directory Server), it can enforce corporate expiration dates, automatic lockouts, and grace-period warnings without RabbitMQ-side configuration.

Likely Explanation vs Confirmed Facts

• Internal DB: Lookups occur locally, typically sub-millisecond latency. However, credential rotation across multiple nodes requires custom management because the internal backend stores credentials locally and does not synchronize expiration events.
• LDAP: Authentication incurs a network round-trip (commonly 1-5 ms per lookup). Results are often cached per connection, which mitigates repeated lookups under moderate load. Performance impact grows under high concurrency if the LDAP server becomes a bottleneck, and policy enforcement depends on the directory's schema matching RabbitMQ's expected attributes.

Steps Needed for This Case

1. Check your RabbitMQ version: rabbitmqctl status. Expiration-related plugin hooks and behavior differ between releases, particularly in newer versions.
2. If using LDAP, verify that the directory contains a password-policy overlay and that the userPassword attribute maps correctly to RabbitMQ's LDAP configuration.
3. If using the internal database, plan a scripted rotation workflow (e.g., using rabbitmqctl change_user_password) and account for node-by-node deployment, since changes do not propagate automatically.

Missing diagnostic detail: What is your RabbitMQ version and LDAP directory type? This determines whether native expiration hooks are available and whether the LDAP schema aligns with expected policy attributes.