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:
[email protected]
| 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?
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. :) 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.
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
