On 08/07/2013 05:26 PM, Miller, Mark M (EB SW Cloud - R&D - Corvallis)
wrote:
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
LDAP users are not stored in SQL. THat table is a relationship between
users and projects, by way of role assignements.
:
[email protected]
| 9798b027472d4f459d231c005977b3ac
| {"roles": [{"id": "7fb862d10b5c46679b4334eae9c73a46"}]}
It used my LDAP uid for the keystone uid.
Yep, because that was the value specified as the User Id from a keystone
perspective.
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.
LDAP query, not SQL.
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"
Assuming a REad only LDAP, you are not going to disable users. So,
modify the query for user lists to include the filter you want,
something like hpStatus="Active"
keystone/common/ldap/core.py, look at the ldap get functions. Instead of
getting all objects of a specific object class, you want to specify a
query that will be used. Specify that in the filter value.
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?
Mark
*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. JThere'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.
Guang
*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
FYI
*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
Hello,
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:
[ldap]
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"
Thanks,
Mark
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
