[Keystone][ldap] Keystone bind request to ldap not able to interpret if the user's password is expired.
Hi, I have configured Keystone with 389ds as backend. 389ds server is configured with password policy and pwdmustchange is set to true. However on first login attempt from keystone to request token for user in 389ds is resulting in successful bind request. Perhaps, 389ds is providing control ID - control: 2.16.840.1.113730.3.4.4 in the response. But keystone is not able to interpret the control ID and provide a token with full access. Is it not possible for keystone to respond token with minimum scope to only change password? Or any response attribute to specify password is expired and needs to be changed? Kindly help with any configuration that may interpret the password expiry of ldap user and can be used in token response. P.S: configuring user_enabled_attribute to check nsAccountLock will not work as ldap user's password would be expired but not locked. user_enabled_attribute = nsAccountLock user_enabled_mask = 0 user_enabled_invert = true user_enabled_default = true Regards, Sharath
Hi, It looks like Keystone does not currently support interpreting LDAP password policy controls from 389ds or other LDAP servers. The security compliance features (password expiration, first-use password change, etc.) are SQL-backend only. This is a known limitation documented in the security compliance section. [1] Your best path forward would be to either implement password expiration checks outside of Keystone, or contribute this feature to be added to the Keystone project. Note that the LDAP backend is read-only. As a workaround, if 389ds sets a specific attribute when passwords need to be changed, you could potentially map that to the user_enabled_attribute: [ldap] user_enabled_attribute = <some_attribute_389ds_sets_when_password_valid> user_enabled_invert = <true/false as needed> This would effectively disable the user rather than allow a limited-scope access. / Greg [1] https://docs.openstack.org/keystone/latest/admin/configuration.html#security... On Wed, Dec 3, 2025 at 6:26 AM Sharath Ck <sharath.madhava@gmail.com> wrote:
Hi,
I have configured Keystone with 389ds as backend. 389ds server is configured with password policy and pwdmustchange is set to true. However on first login attempt from keystone to request token for user in 389ds is resulting in successful bind request. Perhaps, 389ds is providing control ID - control: 2.16.840.1.113730.3.4.4 in the response. But keystone is not able to interpret the control ID and provide a token with full access. Is it not possible for keystone to respond token with minimum scope to only change password? Or any response attribute to specify password is expired and needs to be changed?
Kindly help with any configuration that may interpret the password expiry of ldap user and can be used in token response.
P.S: configuring user_enabled_attribute to check nsAccountLock will not work as ldap user's password would be expired but not locked.
user_enabled_attribute = nsAccountLock user_enabled_mask = 0 user_enabled_invert = true user_enabled_default = true
Regards, Sharath
Hi, Thanks for the detailed answer. We check with our customers what the exact need for this topic. If we receive support for adding this feature to Keystone, what are the formal requirements for it, do we need a spec or something more lightweight like an RFE is enough or just open a bug report for it? Thanks for the help again. Best wishes Lajos Grzegorz Grasza <xek@redhat.com> ezt írta (időpont: 2025. dec. 15., H, 14:04):
Hi,
It looks like Keystone does not currently support interpreting LDAP password policy controls from 389ds or other LDAP servers. The security compliance features (password expiration, first-use password change, etc.) are SQL-backend only. This is a known limitation documented in the security compliance section. [1] Your best path forward would be to either implement password expiration checks outside of Keystone, or contribute this feature to be added to the Keystone project. Note that the LDAP backend is read-only.
As a workaround, if 389ds sets a specific attribute when passwords need to be changed, you could potentially map that to the user_enabled_attribute:
[ldap] user_enabled_attribute = <some_attribute_389ds_sets_when_password_valid> user_enabled_invert = <true/false as needed>
This would effectively disable the user rather than allow a limited-scope access.
/ Greg
[1] https://docs.openstack.org/keystone/latest/admin/configuration.html#security...
On Wed, Dec 3, 2025 at 6:26 AM Sharath Ck <sharath.madhava@gmail.com> wrote:
Hi,
I have configured Keystone with 389ds as backend. 389ds server is configured with password policy and pwdmustchange is set
to true.
However on first login attempt from keystone to request token for user in 389ds is resulting in successful bind request. Perhaps, 389ds is providing control ID - control: 2.16.840.1.113730.3.4.4 in the response. But keystone is not able to interpret the control ID and provide a token with full access. Is it not possible for keystone to respond token with minimum scope to only change password? Or any response attribute to specify password is expired and needs to be changed?
Kindly help with any configuration that may interpret the password expiry of ldap user and can be used in token response.
P.S: configuring user_enabled_attribute to check nsAccountLock will not work as ldap user's password would be expired but not locked.
user_enabled_attribute = nsAccountLock user_enabled_mask = 0 user_enabled_invert = true user_enabled_default = true
Regards, Sharath
Hi, I opened a bug report on launchpad for this topic: https://bugs.launchpad.net/keystone/+bug/2138725 I also pushed a wip patch that proposes a possible way to make different LDAP pw expiration work together with Keystone: https://review.opendev.org/c/openstack/keystone/+/976618 I had also a chat few days back on IRC with Boris Bobrov (bbobrov) see: https://meetings.opendev.org/irclogs/%23openstack-keystone/%23openstack-keys... My question is that the proposed wip patch can be a base for the solution, do we need more discussion on this topic, perhaps on the PTG, or do I need any more preparation to push forward this topic? Thanks in advance for the attention and time. Lajos Katona (lajoskatona) Lajos Katona <katonalala@gmail.com> ezt írta (időpont: 2026. jan. 5., H, 10:40):
Hi, Thanks for the detailed answer. We check with our customers what the exact need for this topic. If we receive support for adding this feature to Keystone, what are the formal requirements for it, do we need a spec or something more lightweight like an RFE is enough or just open a bug report for it?
Thanks for the help again. Best wishes Lajos
Grzegorz Grasza <xek@redhat.com> ezt írta (időpont: 2025. dec. 15., H, 14:04):
Hi,
It looks like Keystone does not currently support interpreting LDAP password policy controls from 389ds or other LDAP servers. The security compliance features (password expiration, first-use password change, etc.) are SQL-backend only. This is a known limitation documented in the security compliance section. [1] Your best path forward would be to either implement password expiration checks outside of Keystone, or contribute this feature to be added to the Keystone project. Note that the LDAP backend is read-only.
As a workaround, if 389ds sets a specific attribute when passwords need to be changed, you could potentially map that to the user_enabled_attribute:
[ldap] user_enabled_attribute = <some_attribute_389ds_sets_when_password_valid> user_enabled_invert = <true/false as needed>
This would effectively disable the user rather than allow a limited-scope access.
/ Greg
[1] https://docs.openstack.org/keystone/latest/admin/configuration.html#security...
On Wed, Dec 3, 2025 at 6:26 AM Sharath Ck <sharath.madhava@gmail.com> wrote:
Hi,
I have configured Keystone with 389ds as backend. 389ds server is configured with password policy and pwdmustchange is
set to true.
However on first login attempt from keystone to request token for user in 389ds is resulting in successful bind request. Perhaps, 389ds is providing control ID - control: 2.16.840.1.113730.3.4.4 in the response. But keystone is not able to interpret the control ID and provide a token with full access. Is it not possible for keystone to respond token with minimum scope to only change password? Or any response attribute to specify password is expired and needs to be changed?
Kindly help with any configuration that may interpret the password expiry of ldap user and can be used in token response.
P.S: configuring user_enabled_attribute to check nsAccountLock will not work as ldap user's password would be expired but not locked.
user_enabled_attribute = nsAccountLock user_enabled_mask = 0 user_enabled_invert = true user_enabled_default = true
Regards, Sharath
participants (3)
-
Grzegorz Grasza
-
Lajos Katona
-
Sharath Ck