Rich Megginson (richmegginson) wrote,
Rich Megginson

How to configure OpenStack Keystone with users in non-default domain

OpenStack Keystone Juno version supports multiple domains. One of the common use cases is the ability to use the identity store already existing in the enterprise (e.g. an LDAP server), so that existing users can be assigned Keystone roles to do things like login to the dashboard/Horizon, launch machines, etc. In addition, the ability for Keystone to store the service user accounts (each OpenStack service has an associated "user" account) in its default sql database so as not to "pollute" the identity store in the enterprise. With Keystone Juno, you can create a "users" domain with an LDAP identity backend for the enterprise user accounts, and use the "default" domain with the default sql identity backend. Note that Keystone Juno also recommends that the assignment information (roles, projects, domains) be kept separate from the identity information (users, groups), and recommends using the default sql assignment backend.

The following instructions assume that you already have a deployment of OpenStack Juno and want to add your enterprise LDAP as a new domain. These instructions also assume you are using IPA (Red Hat IdM) as your enterprise LDAP server with hostname, which stores user information in the suffix cn=accounts,dc=example,dc=com.

Keystone developer Adam Young has some similar instructions:

Scripted demo

There is a scripted demo which sets up two VMs: one running IPA, and one running OpenStack. See for more information.

Create an account for Keystone to use

Keystone must authenticate (e.g. LDAP BIND) to the enterprise LDAP server. You will need to create a user account with a password for Keystone to use. This user will need to have the right to perform searches and retrieve user information in the LDAP subtree which contains your user information (e.g. cn=users,cn=accounts,dc=example,dc=com). In addition, if you want Keystone to be able to write/update user information, you will have to grant the keystone user the right to add/update/delete user accounts. For this example, the user has the DN uid=keystone,cn=users,cn=accounts,dc=example,dc=com.

Create the new domain

The first step is to tell Keystone that you are using multiple domains. To do this, set the parameter domain_specific_drivers_enabled in the [identity] to the value True, and set the paramter domain_config_dir to the value /etc/keystone/domains. For example, using the command line tools as root:
## Enable domain specific config for Keystone
# openstack-config --set /etc/keystone/keystone.conf identity domain_specific_drivers_enabled true
# openstack-config --set /etc/keystone/keystone.conf identity domain_config_dir /etc/keystone/domains

The /etc/keystone/keystone.conf should look like this:
domain_specific_drivers_enabled = true
domain_config_dir = /etc/keystone/domains

Each domain is configured by a separate file in /etc/keystone/domains. If this directory does not exist, create it. Each domain is configured by a file called keystone.$domainname.conf in this directory, where $domainname is the name of your domain. The basic steps for configuring Keystone to use an LDAP identity backend are found here: and For example: to create a new domain called "users", with a read-only LDAP identity backend, create a file named /etc/keystone/domains/keystone.users.conf and populate it like this:

driver = keystone.identity.backends.ldap.Identity

Admin access and Policy

The use of domains requires the use of the Keystone v3 API, which in turn requires the use of Keystone v3 policy. In order to perform administrative actions over all domains, you must designate one of your domains as the "super" domain or admin domain. One or more users from this domain will be granted the right to administer all domains. It does not matter which domain it is.

First, use the current "admin" user to create the new "users" domain e.g. using the openstack command line tool. This assumes you have a user called "admin" in a project called "admin" both of which live in your default domain. Or you may have a file called /root/keystonerc_admin which sets up the environment for admin authentication, and you can grab the username, password, and tenant name. NOTE: with Keystone v3, "tenant" is now called "project".
openstack --os-identity-api-version 3 \
--os-auth-url \
--os-username admin \
--os-password myadminpassword \
--os-user-domain-name default \
--os-project-domain-name default \
--os-project-name admin \
--format shell \
domain create --description "Domain for enterprise users" --enable users

This will print out information about the new domain in the format keyword="value". Note the value of the id field. This is the domain id (without the double quotes).

Next, grab the default v3 policy template. This file is usually called /usr/share/keystone/policy.v3cloudsample.json. Copy this file to /etc/keystone. Edit /etc/keystone/policy.v3cloudsample.json - look for the string admin_domain_id near the top of the file. It should look like this before you edit it:
"admin_required": "role:admin",
"cloud_admin": "rule:admin_required and domain_id:admin_domain_id",
"service_role": "role:service",

You will need to replace admin_domain_id with the id of the domain you want to make your admin domain. If you want to use the default domain (where your OpenStack service accounts and probably your current admin user live), use a value of default. The file should look something like this:
"admin_required": "role:admin",
"cloud_admin": "rule:admin_required and domain_id:default",
"service_role": "role:service",

If you want to use your new users domain, use the domain id value from when you created that domain, which is usually a long base-16 string of hexadecimal digits, something like this:
"admin_required": "role:admin",
"cloud_admin": "rule:admin_required and domain_id:ad8d0d5fd7e84273a9c1024083743480",
"service_role": "role:service",

You will need to restart Keystone for the policy changes to take effect.

Role assignments

With Keystone v2, you could assign users to have roles within tenants. With Keystone v3, you can assign users to have roles within domains or projects (tenants are now called projects in Keystone v3). NOTE: In the examples below, the $admin_user and $admin_domain are the admin user and admin domain you configured in the steps above. If you want to assign roles to some of your users from your new "users" account, for example, to have the admin role in your domain:
openstack --os-identity-api-version 3 \
--os-auth-url \
--os-username $admin_user \
--os-password myadminpassword \
--os-user-domain-name $admin_domain \
--os-domain-name $admin_domain \
role add --domain users --user $id_of_user admin

The $id_of_user is used above. With Keystone v3, when referring to user and project resources, it is better to use the id rather than the name. You can have multiple users with the same name in different domains, but the id is guaranteed to be globally unique across all domains. When referring to domains, you can use either the id or the name, because there is only one namespace for domains. If you don't know the id, you can use openstack user list --long --domain domainname:
| ID | Name | Project Id | Domain Id | Description | Email | Enabled |
| 54ca2d88e1df460e824de237438a6af1 | swift | | default | | swift@localhost | True |
| 9706d7cea2b54692ae12269f662a5d13 | glance | | default | | glance@localhost | True |
| 9a3342d2b5ed4931a7a4f21d215f303d | admin | | default | | root@localhost | True |
| b9c40934c7df4208a4cf93d5205f18ba | cinder | | default | | cinder@localhost | True |
| c353ee3282a9400691665af6f6e412f0 | heat | | default | | heat@localhost | True |
| ca9bfb3ac14e469f9b3932af4395f825 | ceilometer | | default | | ceilometer@localhost | True |
| ceb8233429d44a1883c73184e825a214 | nova | | default | | nova@localhost | True |

or openstack user show username --domain domainname:
| Field | Value |
| default_project_id | 34f66a1a14694983838ee860b15bfb38 |
| domain_id | default |
| email | root@localhost |
| enabled | True |
| id | 9a3342d2b5ed4931a7a4f21d215f303d |
| name | admin |

To get the id for a project, use openstack project list --long or openstack project show projectname --domain domainname. These commands will give you the domain_id. If you want to see the domain name, use openstack domain list which will show the domain name and id.

To add a project to the new users domain e.g. called "demo":
openstack --os-identity-api-version 3 \
--os-auth-url \
--os-username $admin_user \
--os-password myadminpassword \
--os-user-domain-name $admin_domain \
--os-domain-name $admin_domain \
project create demo --domain users

To add a user to the new project and assign the user the role "_member_" in the project:
openstack --os-identity-api-version 3 \
--os-auth-url \
--os-username $admin_user \
--os-password myadminpassword \
--os-user-domain-name $admin_domain \
--os-domain-name $admin_domain \
role add --project $demo_project_id --user $id_of_user _member_

Dashboard/Horizon configuration

These are the steps to configure Dashboard/Horizon to use the new users domain for authentication. This will make it so that users in the new "users" domain can login via Dashboard/Horizon, but not users in other domains.
# cat >> /etc/openstack-dashboard/local_settings << EOF
"identity": 3

The file should look like this:
# For Glance image upload, Horizon uses the file upload support from Django
# so we add this option to change the directory where uploaded files are temporarily
# stored until they are loaded into Glance.
"identity": 3

This tells dashboard to use Keystone v3 for authentication and to use 'users' as the default domain.

More changes:
# sed -i "s/^OPENSTACK_KEYSTONE_URL = .*/OPENSTACK_KEYSTONE_URL = \"http:\/\/$VM_FQDN:5000\/v3\"/g" \
# sed -i "s/^ 'name': 'native',/ 'name': 'ldap',/g" \
# sed -i "s/^ 'can_edit_user': True,/ 'can_edit_user': False,/g" \
# sed -i "s/^ 'can_edit_group': True,/ 'can_edit_group': False,/g" \

The first line tells dashboard to use the Keystone v3 URL, that Keystone is using 'ldap' for auth, and that the user and group information cannot be edited via dashboard. The end result file should look like this:
# For multiple regions uncomment this configuration, and add (endpoint, title).

OPENSTACK_KEYSTONE_URL = "http://rdo.rdodom.test:5000/v3"
'name': 'ldap',
'can_edit_user': False,
'can_edit_group': False,
'can_edit_project': True,
'can_edit_domain': True,
'can_edit_role': True

Next, policy:
# mv /etc/openstack-dashboard/keystone_policy.json /etc/openstack-dashboard/keystone_policy.json.orig
# cp /etc/keystone/policy.v3cloudsample.json /etc/openstack-dashboard/keystone_policy.json

We need to tell Horizon/Dashboard that we are using the new v3 policy in Keystone. But first, make a copy of the original policy.

You will need to restart Horizon/Dashboard after making these changes.

Other OpenStack service configuration

Some of the other OpenStack services do not use Keystone v3 by default, or have bugs in that support. What follows are some configuration changes or workarounds:
## this is a workaround for LP#1427878 - LP is
## Update Nova to allow it to validate tokens using the
## v3 Identity API.
# sed -i "s/^auth_version\(.*\)/#auth_version\1/g" /usr/share/nova/nova-dist.conf

## this is a workaround for LP#1428376
## Update Swift to use the proper keystonemiddleware module. Without
## this, multi-domain support in Swift doesn't work properly.
# sed -i "s/^paste.filter_factory.*/paste.filter_factory = keystonemiddleware.auth_token:filter_factory/g" \

The /usr/share/nova/nova-dist.conf should look like this:
# Workaround for
#auth_version = v2.0

and the /etc/swift/proxy-server.conf should look like this:
log_name = swift
signing_dir = /var/cache/swift
paste.filter_factory = keystonemiddleware.auth_token:filter_factory

You will have to restart those services for the changes to take effect.

Create a v3 keystonerc file

Some installers will create a shell script rc file that you can source into the shell environment to make it easy to use the command line utilities. Here is an example of such a file to use the v3 api with the openstack command. NOTE: your_admin_user, your_admin_password, and your_admin_domain are the admin username, password, and admin domain you selected above:
export OS_USERNAME=your_admin_user
export OS_PASSWORD=your_admin_password
export OS_DOMAIN_NAME=your_admin_domain
export OS_USER_DOMAIN_NAME=your_admin_domain
export OS_AUTH_URL=
export PS1='[\u@\h \W(keystone_cloud_admin)]$ '

Specifying OS_IDENTITY_API_VERSION=3 and OS_AUTH_URL= tells openstack that you want to use the Keystone v3 API.
Tags: keystone, ldap, openstack
  • Post a new comment


    default userpic

    Your reply will be screened

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.