Ask Your Question

how to change user domain in v2 -> v3 migration (IceHouse)

asked 2014-09-10 17:03:20 -0500

echapin gravatar image

updated 2014-09-11 13:49:31 -0500

I am investigating how to migrate users in a single-domain (v2) cloud to a multi-domain (v3) cloud. I have the following setup:

  • RDO IceHouse on a single box for prototyping
  • LDAP read-only backend to provide authentication. Using SQL for projects, domains, roles (i.e., everything else)
  • default Keystone policy (not policy.v3cloudsample.json)

What I want to do is write a script that will harvest project(tenant) information from another source (a separate database) and then: 1. Create the projects in a new (non-default) domain 2. Move the users into this domain, and give them the _member_ role on the projects they are involved with.

I have been unsuccessful in changing the domain_id for a user.

Here are the relevant modifications to /etc/keystone/keystone.conf:


driver = keystone.identity.backends.ldap.Identity

driver = keystone.assignment.backends.sql.Assignment




# check actual attributes of users!

I have bootstrapped the system by creating the various service accounts in LDAP (nova, glance etc.), as well as the admin account (all with the same passwords as in the original sql backend so that they can talk to eachother without modifying all of the service config files). I then use the keystone client to give these the admin role in the service tenant (I also give the admin user the admin role in the admin tenant). I can verify that everything seems to be working normally.

I then have a user, 'echapin' in LDAP that has no domain, project, or role information, and I now wish to define it. When I request information about this user, it shows that it is in the 'default' domain (default behaviour for v2 users lacking an explicit domain). I now wish to move this user to a new domain called 'HEP' which already exists (created previously in the SQL backend before switching over to the LDAP hybrid setup):

$ curl -s -X GET http://localhost:5000/v3/domains -i -H "X-Auth-Token: $ADMIN_TOKEN"
[...clipped out other entries...]
  "id": "b82f20ae60154468aae3831dfb993208",
  "name": "HEP",
  "description": "HEP domain",
  "enabled": true,
  "links": {
    "self": "http://localhost:5000/v3/domains/b82f20ae60154468aae3831dfb993208"
  "id": "default",
  "name": "Default",
  "description": "Owns users and tenants (i.e. projects) available on Identity API v2.",
  "enabled": true,
  "links": {
    "self": "http://localhost:5000/v3/domains/default"

I then attempt to PATCH the user to set the domain_id:

$ curl -s -X PATCH http://localhost:5000/v3/users/${ID_USR} \
-i \
-H "X-Auth-Token: $ADMIN_TOKEN" \
-H "Content-Type: application/json" \
-d '{ "user": {"domain_id": "b82f20ae60154468aae3831dfb993208"} }' 

HTTP/1.1 404 Not Found
Vary: X-Auth-Token
Content-Type: application/json
Content-Length: 117
Date: Wed, 10 Sep 2014 21:44:53 GMT

{"error": {"message": "Could not find domain, b82f20ae60154468aae3831dfb993208.", "code": 404, "title": "Not Found"}}

This is a strange response, because as you can see above, this domain ... (more)

edit retag flag offensive close merge delete


You are correct. Every LDAP user is mapped to "default" domain unless you use Per Domain Backed

What do you mean by everything seems to work if I I grant __member__ role to my LDAP users on projects?

Haneef Ali gravatar imageHaneef Ali ( 2014-09-11 14:08:42 -0500 )edit

I can create a project in domain "HEP", grant _member_ to user echapin on that project (even though echapin is in domain default), and access through the dashboard (doesn't matter what domain I put, as long as it is a valid domain). I think the correct answer is that domain_id is meaningless here.

echapin gravatar imageechapin ( 2014-09-11 14:24:39 -0500 )edit

2 answers

Sort by » oldest newest most voted

answered 2014-09-11 15:15:00 -0500

echapin gravatar image

I believe the correct answer to this question is that all users are in the default domain when using LDAP as the backend in IceHouse - it is not possible to specify domains (although this may not be a problem in all usage scenarios - see below)

If you look at the tables in the MySQL database, there is one called "user" which includes "id", "name", "extra", "password", "enabled", "domain_id", and "default_project_id". This is clearly what is used to store user information with the SQL backend, and must be ignored when you switch over to LDAP. While keystone.conf provides attributed mappings for things like the user_name and user_id, there is nothing about the user_domain. In Juno we should have the ability to specify domain specific backends which will allow different LDAP servers for each domain (or different trees, filters etc.). So, it appears that all users are assumed to be in the Default group (see discussion with Haneef).

However, this may not be a problem. At the end of the day I was mostly interested in being able to create projects in different domains. It is still possible to add users (even though they are in the default domain) to a project in a different domain by granting them the _member_ role on the project.

For example:

curl -X PUT http://localhost:5000/v3/projects/${ID_PROJECT}/users/${ID_USR}/roles/${MEMBER_ROLE_ID} \
    -s \
    -i \
    -H "X-Auth-Token: $ADMIN_TOKEN_DOMAIN"

Where $ADMIN_TOKEN_DOMAIN is a domain-scoped admin token, and $ID_PROJECT is a project in a new domain also created through the v3 API. This will create the appropriate relationship in the "assignment" table, which is still handled by the sql backend.

I can then log into a domain-enabled dashboard, and provide a valid domain name (either default, or the name of the new domain), name and password, and things work as expected (I can access resources in the projects for which I am a member).

If I log into the dashboard as the admin user (remember, using the default keystone policy file), I can click on identity -> domains and switch to a domain context for my new domain. While this will still show ALL of the users (it has no knowledge of which users go in which domain), it will at least filter the visible projects to that domain - which is useful for accounting.

Looking forward to proper multi-domain support with LDAP in Juno...

edit flag offensive delete link more

answered 2014-09-10 23:13:03 -0500

IMO domain_id should not be update able. They should raise the error. If you update domain_id, then corresponding roles,groups also need update.

Your first problem is , you are using "ADMIN" token. ADMIN token will work only for certain v3 operation, for all the other operations, it will default to "default" domain_id.

The following solution is just to solve your error. It won't help you in migration as the code doesn't update corresponding groups/roles for domain update

1) Create a user in default domain

2 Assign him domain scoped "admin" role. ( PUT /domains/default/users/{user_id}/roles/<admin_role_id>

3) Get a domain scoped token for this user, scoped to "default" domain"

4) Use this token instead of ADMIN token for your PATCH

edit flag offensive delete link more


Thank you for the suggestion - see my response in the body of the question. What you say makes sense, but I think the root of the problem is where Keystone is getting the domain_id from in the LDAP case (maybe nowhere...?).

echapin gravatar imageechapin ( 2014-09-11 13:50:48 -0500 )edit

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower


Asked: 2014-09-10 17:03:20 -0500

Seen: 1,331 times

Last updated: Sep 11 '14