Comment 2 for bug 1219739

By default the tenant_id is not stored by the LDAP backend (or in the case of v2.0 tenantId). This appears to be an intentional choice as there is no attribute mapping on the back end. There is also inconsistency in the use of tenant_id, tenantId, and default_project_id across the different drivers and versions of API.

The solution will be as follows:
* Provide a mapping for LDAP attributes to set/store the default_project_id
* SQL, make default_project_id a full column in the identity backend
* Put in translation code to return "tenantId" for v2.0 gets on the user, and "default_project_id" for v3 user gets
* Put in translation code to normalize the backend to the correct values.

LDAP will still, by default, not store the default_project_id, however, the option to configure it to store the data will be available. Unless keystone's configuration defaults are changed, it will not be returned nor stored (in the LDAP identity driver) via use of the RESTful api or the keystoneclient.