[openstack-dev] Keystone Split Backend LDAP Configuration Question

Miller, Mark M (EB SW Cloud - R&D - Corvallis) mark.m.miller at hp.com
Wed Aug 7 21:26:26 UTC 2013

Hi Guang,

Thank you for the reply. Would you be a little more specific or give me an example of a configurable LDAP query filter? Right now the keystone SQL database does not keep much information on users that come from the LDAP server. The only entry I could find was one in the user_project_metadata table:

    mark.m.miller at hp.com

| 9798b027472d4f459d231c005977b3ac

| {"roles": [{"id": "7fb862d10b5c46679b4334eae9c73a46"}]}

It used my LDAP uid for the keystone uid. So the issue is how to start the user lookup. Do you locate all of the users in the keystone SQL database by collating various tables and then perform a lookup in the LDAP server with this set of data, or do you start with all of the users from the LDAP database and then see if they exist in the keystone SQL database tables? I am still checking, but I assume the latter is true.

Concerning user status, I would think that only "Active" users should be enabled in keystone. I was hoping to find an attribute that I could set such as:

user_enabled_attribute = hpStatus
user_enabled_value = "Active"

And then any other value would equal disabled.  I suppose you could say that if the LDAP backend system will let a user log in, then that is good enough and keystone should consider them enabled. Is that what you meant?


From: Yee, Guang
Sent: Wednesday, August 07, 2013 2:03 PM
To: Miller, Mark M (EB SW Cloud - R&D - Corvallis); Taylor, Monty
Subject: RE: [openstack-dev] Keystone Split Backend LDAP Configuration Question

User lookup should be controlled by a configurable LDAP query filter, not individual attributes. Please make that change if you can, you'll get lots of karma points for this. :) There's no point of returning *disabled* users as users are managed by AD, not Keystone. For read-only LDAPs, user is either there, or not there. Nothing in between.


From: Miller, Mark M (EB SW Cloud - R&D - Corvallis)
Sent: Wednesday, August 07, 2013 1:57 PM
To: Taylor, Monty; Yee, Guang
Subject: FW: [openstack-dev] Keystone Split Backend LDAP Configuration Question


From: Miller, Mark M (EB SW Cloud - R&D - Corvallis)
Sent: Wednesday, August 07, 2013 1:39 PM
To: Adam Young
Cc: OpenStack Development Mailing List
Subject: Re: [openstack-dev] Keystone Split Backend LDAP Configuration Question


I am trying to figure out what to use for the "user_enabled_*" attributes for the HP Enterprise Directory servers. It looks like the enabled attribute values in the keystone.conf file are expected to have numerical values.

From(URL http://docs.openstack.org/trunk/openstack-compute/admin/content/configuring-keystone-for-ldap-backend.html :
In case that the directory server does not have an attribute enabled of type boolean for the user, there are several configuration parameters that can be used to extract the value from an integer attribute like in Active Directory:
user_enabled_attribute = userAccountControl
user_enabled_mask      = 2
user_enabled_default   = 512
In this case the attribute is an integer and the enabled attribute is listed in bit 1, so the if the mask configured user_enabled_mask is different from 0, it gets the value from the field user_enabled_attribute and it makes an ADD operation with the value indicated on user_enabled_mask and if the value matches the mask then the account is disabled.
It also saves the value without mask to the user identity in the attribute enabled_nomask. This is needed in order to set it back in case that we need to change it to enable/disable a user because it contains more information than the status like password expiration. Last setting user_enabled_mask is needed in order to create a default value on the integer attribute (512 = NORMAL ACCOUNT on AD)
What if the enabled attributes from the LDAP server are not numerical values but rather character strings?

hpStatus: Active, Deceased, Leave of Absence, Leave with Pay, Terminated, Retired, Pending, Limited

How would you set the attribute enabled = 'Active'? Mind you that this is a read only ldap connection.

user_enabled_attribute = hpStatus
user_enabled_mask = 0
user_enabled_default = "Active"


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130807/a1728732/attachment.html>

More information about the OpenStack-dev mailing list