LDAP identity driver does not support 'enabled'

Bug #1063858 reported by Boden R
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Fix Released
Wishlist
Yuriy Taraday

Bug Description

The current LDAP identity driver does not support the notion of 'enabled' for users/tenants and therefore when using LDAP as an identity backend, this functionality is not provided. There is some discussion of this issue in https://bugs.launchpad.net/keystone/+bug/980085 however I don't see the functionality was addressed as part of 980085. Moreover this issue seems like it might be best tracked as its own defect so its not masked in another defect and lost.

Here's a comment from keystone/identity/backends/ldap/core.py regarding this issue:

    # NOTE(ayoung): The RFC based schemas don't have a way to indicate
    # 'enabled' the closest is the nsAccount lock, which is on defined to
    # be part of any objectclass.
    # in the future, we need to provide a way for the end user to
    # indicate the field to use and what it indicates

Joseph Heck (heckj)
Changed in keystone:
status: New → Triaged
importance: Undecided → Wishlist
Revision history for this message
Adam Young (ayoung) wrote :

THis is probably higher priority than wishlist. It may be that the enabled field is required for most people's LDAP enable. There was info added to the blueprint around 'enable' that wshows how tricky it will be to solve in the general case, though.

Revision history for this message
Yuriy Taraday (yorik-sar) wrote :

We suggest a workaround for people who have no enabled-like attribute for their tenants and users in LDAP.
We can hold lists of all enabled tenants and users in separate nodes in LDAP named like 'enabled_tenants' and 'enabled_users'. These nodes can have objectClass = groupOfNames.
The structure will be like this (two tenants and two users, tenant1 is enabled, tenant2 is not):

*ou=Tenants
+-*cn=enabled_tenants
  -member=cn=tenant1,ou=Tenants
+-*cn=tenant1
+-*cn=tenant2
*ou=Users
+-*cn=enabled_users
  -member=cn=user2,ou=Users
+-*cn=user1
+-*cn=user2

We can also ban user_id == 'enabled_users' and tenant_id == 'enabled_tenants' to be sure that our emulation does not produce any unexpected behavior.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to keystone (master)

Fix proposed to branch: master
Review: https://review.openstack.org/20928

Changed in keystone:
assignee: nobody → Anastasia Latynskaya (alatynskaya)
status: Triaged → In Progress
Changed in keystone:
assignee: Anastasia Latynskaya (alatynskaya) → Yuriy Taraday (yorik-sar)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to keystone (master)

Reviewed: https://review.openstack.org/20928
Committed: http://github.com/openstack/keystone/commit/408a1d57d729461056507283c58d6c48403554b8
Submitter: Jenkins
Branch: master

commit 408a1d57d729461056507283c58d6c48403554b8
Author: alatynskaya <email address hidden>
Date: Fri Jan 11 17:19:33 2013 +0400

    enabled attribute emulation support

    Fixes bug 1063858
    Implementation works as described in the second comment.

    Change-Id: Ib0aa85f05244044c9f40fa9634b5ed3e8afa1f37

Changed in keystone:
status: In Progress → Fix Committed
Thierry Carrez (ttx)
Changed in keystone:
milestone: none → grizzly-3
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in keystone:
milestone: grizzly-3 → 2013.1
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.