Open Stack

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.
>
> :
>
> mark.m.miller at hp.com
>
> 	
>
> | 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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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