OpenStack Keystone Flaw Grants Access to Disabled LDAP Users

In the complex machinery of cloud identity management, a single misinterpretation of data can lead to a significant security breach. A recently disclosed vulnerability in OpenStack Keystone, the primary identity service for the OpenStack ecosystem, has revealed such a gap—one that allows users explicitly disabled in an LDAP backend to continue authenticating as if their accounts were fully active.

The flaw, independently reported by researchers Benedikt Trefzer and Andrew Bogott, strikes at the heart of how Keystone interacts with lightweight Directory Access Protocol (LDAP) identity backends.

At its core, the issue is a failure of logic. When Keystone is configured to use an LDAP backend, it must interpret various attributes to determine a user’s status. However, in affected versions, the system “does not convert the enabled attribute to a boolean” correctly.

This misinterpretation occurs specifically when the user_enabled_invert configuration option is set to False, which is the system’s default state. In this configuration, “Keystone did not correctly interpret the LDAP enabled attribute, causing users disabled in LDAP to be treated as enabled and allowed to authenticate”. Essentially, the “off” switch in the directory was being read as an “on” switch by the cloud controller.

The scope of the vulnerability is narrow but impactful. “Deployments using the LDAP identity backend without user_enabled_invert=True or user_enabled_emulation are affected”. Organizations that rely on standard LDAP attributes to manage employee offboarding or temporary account suspensions may find that those administrative actions have no effect on their OpenStack environment.

The vulnerability has been identified across several recent OpenStack release cycles:

• 2024.2 (Dalmatian)
• 2025.1 (Epoxy)
• 2025.2 (Flamingo)
• 2026.1 (Gazpacho)

The OpenStack security team has moved swiftly to integrate a fix into the project’s master branch. The definitive solution is included in the Gazpacho (29.0.0) release.

If an immediate upgrade to version 29.0.0 is not feasible, administrators can implement a configuration-based workaround to secure their systems:

• Invert the Logic: Set the configuration to user_enabled_invert=True and utilize an LDAP attribute that carries inverted semantics, such as nsAccountLock.
• Emulation: Alternatively, deployments can utilize user_enabled_emulation, which determines a user’s enabled status based on group membership rather than a single attribute.