Rackspace Private Cloud Active Directory and LDAP Integration
v 4.0 (2013-06-25)
Copyright © 2013 Rackspace All rights reserved.
This document is intended to assist Rackspace Private Cloud customers in updating their Rackspace Private Cloud cookbooks to apply minor updates and patches.
The document is for informational purposes only and is provided “AS IS.”
RACKSPACE MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED, AS TO THE ACCURACY OR COMPLETENESS OF THE CONTENTS OF THIS DOCUMENT AND RESERVES THE RIGHT TO MAKE CHANGES TO SPECIFICATIONS AND PRODUCT/SERVICES DESCRIPTION AT ANY TIME WITHOUT NOTICE. RACKSPACE SERVICES OFFERINGS ARE SUBJECT TO CHANGE WITHOUT NOTICE. USERS MUST TAKE FULL RESPONSIBILITY FOR APPLICATION OF ANY SERVICES MENTIONED HEREIN. EXCEPT AS SET FORTH IN RACKSPACE GENERAL TERMS AND CONDITIONS AND/OR CLOUD TERMS OF SERVICE, RACKSPACE ASSUMES NO LIABILITY WHATSOEVER, AND DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO ITS SERVICES INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT. Except as expressly provided in any written license agreement from Rackspace, the furnishing of this document does not give you any license to patents, trademarks, copyrights, or other intellectual property.
Rackspace®, Rackspace logo and Fanatical Support® are either registered trademarks or trademarks of Rackspace US, Inc. in the United States and/or other countries. OpenStack is either a registered trademark or trademark of OpenStack, LLC in the United States and/or other countries. All other product names and trademarks in this document are for identification purposes only and are property of their respective owners.
Table of Contents
1. Overview ... 1
Intended Audience ... 1
Document Change History ... 1
Additional Resources ... 1
Contact Rackspace ... 1
2. Active Directory and Rackspace Private Cloud Cookbooks ... 2
Prerequisites ... 2
Required Information ... 2
Adding Active Directory Integration to the Chef Environment ... 3
3. LDAP and Rackspace Private Cloud Cookbooks ... 7
Prerequisites ... 7
Required Information ... 7
1. Overview
Rackspace has developed a fast, free, and easy way to install a Rackspace Private Cloud powered by OpenStack in any data center. This method is suitable for anyone who wants to install a stable, tested, and supportable OpenStack-powered private cloud, and can be used for all scenarios from initial evaluations to production deployments.
Rackspace Private Cloud v 4.0 supports the Grizzly release of OpenStack.
Intended Audience
This document provides an overview of how to use the Rackspace Private Cloud cookbooks to connect OpenStack Identity to an existing Active Directory authentication system for single sign on. It also provides an example of Chef environments that have been tested to achieve integration for each authentication service.
The scope of this document does not include the administration or configuration of an Active Directory service, except insofar as is required to achieve integration. It is also important to point out that this is only currently applicable to authentication. Authorization is not discussed in this document.
To use the product and this document, you should have prior knowledge of OpenStack and cloud computing, basic Linux administration skills, and a side of bacon. :)
Document Change History
This version of Rackspace Private Cloud Active Directory Integration replaces and obsoletes all previous versions. The most recent changes are described in the table below:
Revision Date Summary of Changes
June 25, 2013 • Release of Rackspace Private Cloud v. 4.0
Additional Resources
•Rackspace Private Cloud Knowledge Center
•OpenStack Manuals
•OpenStack API Reference
•OpenStack - Keystone Developer Documentation
Contact Rackspace
For more information about sales and support, contact us at
<[email protected]>. For feedback on the documentation, contact us at <[email protected]>, or leave a comment at the Knowledge Center.
2. Active Directory and Rackspace Private
Cloud Cookbooks
Prerequisites
To use these instructions, you should have an understanding of OpenStack Identity (Keystone) core concepts, including users, roles, tenants, and tokens, and a working
knowledge of Active Directory. Your environment must have the following features already configured:
• The address, hostname, or URL of the Active Directory server, such as
activeserver.example.com.
• A configured user with enough privileges to search all of the organizational units that are defined within the environment, such as Administrator.
You may have existing users and groups already defined, but this is not required.
Required Information
The Chef cookbooks for the Keystone service have been made intentionally flexible for this type of deployment, and does not enforce any defaults except the most basic default Keystone configuration. This design ensures that a user can integrate Keystone without modifying any existing LDAP schema. You must understand Active Directory and your underlying LDAP schema to correctly integrate the Keystone service.
The example in this section is based on a clean Active Directory installation.
Before you begin, you must make groupOfNames a superior for organizationalRole.
This enables Keystone roles to work correctly with Active Directory.
1. In the Active Directory schema master, use ASDI Edit and select schema.
2. Open CN=Organizational-Role.
3. In the attribute editor, select possSuperiors.
4. Add groupOfNames to the list of values and click OK to save the change.
After completing this task, you can proceed with collecting the required information about your Active Directory configuration with Active Directory Users and Computers.
1. Locate the Organizational Unit (OU) that contains Users. You will use this information to configure the lookup point for users in Keystone. Because Active Directory identifies the Users OU differently than LDAP does, you will search for the Common Name (CN). In the following example, the OU is called Users.
CN=Users,dc=example,dc=com
2. Locate the OU that contains Groups. You will use this information to configure the lookup point for tenants in Keystone.
In the following example, the OU is called Tenants.
OU=Tenants,dc=example,dc=com
3. Locate the OU that contains Roles. If one does not already exist, the AD administrator should create a Roles OU. You will use this information in Keystone to set up roles and manage user/tenant interaction within the OpenStack cluster.
In the following example, the OU is called Roles.
OU=Roles,dc=example,dc=com
4. Note: If you are using Keystone 2013.1.1, you may skip this step.
The LDAP administrator will need to create an OU called Domains and a single object
named Default that has the objectClass groupOfNames.
5. Identify the objectClass that will be used by objects in the User, Group, Role, and Domain OUs. The objectClass will depend on your own LDAP schema.
In this example, the following objectClass definitions are used:
User: person
Group: groupOfNames Role: organizationalRole Domain: Group
Adding Active Directory Integration to the Chef
Environment
You will now add your Active Directory environment information to the Chef environment, which executes the configuration changes in your OpenStack environment.
In this example, you will integrate Keystone and Active Directory in an environment called default-active. This example uses the Knife command line tool to edit the
environment's .json file.
1. Define your text editor with EXPORT. In this example, the editor is vim.
$ export EDITOR=vim
2. Use the knife command to enter the environment editing mode.
$ knife environment edit default-active
3. You will now be able to edit the environment .json file directly. Locate the
override_attributes: { setting inside the file, and locate the "keystone": {
section within the override section. If it does not already exist, you will need to add it. 4. Edit the "keystone": { section to match the following code, substituting in the
OU and objectClass information that you gathered earlier in the lines with italicized variables. "keystone": { "ldap": { "user_attribute_ignore": "password,tenantId,tenants", "tenant_allow_create": "True", "tenant_allow_update": "True", "user_mail_attribute": "mail", "user_enabled_attribute": "userAccountControl", "user_allow_delete": "False", "role_allow_update": "True", "domain_objectclass": "Group", "tenant_tree_dn": "<OU=Tenants,dc=example,dc=com>", "tenant_allow_delete": "True", "role_tree_dn": "<OU=Roles,dc=example,dc=com>", "role_member_attribute": "roleOccupant", "domain_enabled_emulation_dn": "<OU=Domains,dc=example,dc=com>", "group_attribute_ignore": "enabled", "user_id_attribute": "cn", "tenant_member_attribute": "member",
"url": "ldap://<Active Directory Domain Controller address >", "tenant_objectclass": "groupOfNames", "tenant_id_attribute": "cn", "domain_tree_dn": "<OU=Domains,dc=example,dc=com>", "use_dumb_member": "True", "user_tree_dn": "<CN=Users,dc=example,dc=com>", "user_objectclass": "person", "tenant_name_attribute": "ou", "tenant_desc_attribute": "description", "role_objectclass": "organizationalRole", "role_id_attribute": "cn", "role_allow_create": "True", "domain_attribute_ignore": "enabled", "suffix": "dc=example,dc=com", "dumb_member": "CN=Administrator,CN=Users,dc=example,dc=com", "user_enabled_mask": "2", "user_enabled_default": "512", "role_name_attribute": "ou", "user_domain_id_attribute": "businessCategory", "domain_enabled_emulation": "True", "user": "<CN=Administrator,CN=Users,dc=example,dc=com>", "password": "<administrator password>",
"tenant_enabled_attribute": "extensionName", "user_name_attribute": "cn",
"user_allow_create": "False", "user_allow_update": "False", "role_allow_delete": "True"
},
"auth_type": "ldap", "debug": "True" }
5. If the schema uses existing LDAP users for the Nova and Glance service users, you should also ensure that these are defined in the environment file and that user creation, updating, and deletion is disabled. If you do not define them here, the Rackspace cookbooks will attempt to create those users for you. The following example shows an environment with Nova and Glance service user information defined.
"override_attributes": { "glance": {
"service_pass": "<glance user password>" },
"nova": {
"service_pass": "<nova user password>" }, "keystone": { "ldap": { "user_attribute_ignore": "password,tenantId,tenants", "tenant_allow_create": "True", "tenant_allow_update": "True", "user_mail_attribute": "mail", "user_enabled_attribute": "userAccountControl", "user_allow_delete": "False", "role_allow_update": "True", "domain_objectclass": "Group", "tenant_tree_dn": "<OU=Tenants,dc=example,dc=com>", "tenant_allow_delete": "True", "role_tree_dn": "<OU=Roles,dc=example,dc=com>", "role_member_attribute": "roleOccupant", "domain_enabled_emulation_dn": "<OU=Domains,dc=example,dc=com>", "group_attribute_ignore": "enabled", "user_id_attribute": "cn", "tenant_member_attribute": "member",
"url": "ldap://<Active Directory Domain Controller address >", "tenant_objectclass": "groupOfNames", "tenant_id_attribute": "cn", "domain_tree_dn": "<OU=Domains,dc=example,dc=com>", "use_dumb_member": "True", "user_tree_dn": "<CN=Users,dc=example,dc=com>", "user_objectclass": "person", "tenant_name_attribute": "ou", "tenant_desc_attribute": "description", "role_objectclass": "organizationalRole", "role_id_attribute": "cn", "role_allow_create": "True", "domain_attribute_ignore": "enabled", "suffix": "dc=example,dc=com", "dumb_member": "CN=Administrator,CN=Users,dc=example,dc=com", "user_enabled_mask": "2", "user_enabled_default": "512", "role_name_attribute": "ou", "user_domain_id_attribute": "businessCategory", "domain_enabled_emulation": "True", "user": "<CN=Administrator,CN=Users,dc=example,dc=com>",
"tenant_enabled_attribute": "extensionName", "user_name_attribute": "cn", "user_allow_create": "False", "user_allow_update": "False", "role_allow_delete": "True" }, "auth_type": "ldap", "users": { "admin": {
"password": "Openstack admin password" },
"monitoring": {
"password": "monitoring password" }
},
"debug": "True" }
6. Run chef-client on the Chef server and on each server in your OpenStack environment to implement the changes.
7. Run chef-client again. The second run resolves an issue related to Keystone bug 1176270.
Once this process is complete, you will be able to authenticate with Keystone with an Active Directory backend.
If you would like to view all of the available Active Directory options available in the Rackspace cookbooks you can review them here:
https://github.com/rcbops-cookbooks/keystone/blob/master/ attributes/default.rb#L22
3. LDAP and Rackspace Private Cloud
Cookbooks
Prerequisites
To use these instructions, you should have an understanding of OpenStack Identity (Keystone) core concepts, including users, roles, tenants, and tokens, and a working knowledge of LDAP. Your environment must have the following features already configured:
• A working LDAP server with OpenLDAP or 389 Directory Server installed. The top level organization should already be created, as in the following example:
dn: cn=example,cn=com dc: example objectClass: dcObject objectClass: organizationalUnit o: example.com
• The address, hostname, or URL of the LDAP server, such as
ldapserver.example.com.
• A configured user with enough privileges to search all of the organization units that are defined within the environment, as in the following example:
cn=admin,dc=example,dc=com
You may have existing users and groups already defined, but this is not required.
Required Information
The Chef cookbooks for the Keystone service have been made intentionally flexible for this type of deployment, and does not enforce any defaults except the most basic default Keystone configuration. This design ensures that a user can integrate Keystone without modifying any existing LDAP schema. You must understand your underlying LDAP schema to correctly integrate the Keystone service.
The example in this section is based on a default deployment of OpenLDAP that contains the following enabled OpenLDAP .ldif files:
•core.ldif
•cosine.ldif
Follow this process to gather the information required to add LDAP to your Chef environment.
1. Identify the Organizational Unit (OU) that contains Users. You will use this information to configure the lookup point for users in Keystone.
In the following example, the OU is called users.
ldapsearch -x -LLL -H ldapi:/// -b dc=example,dc=com "(objectClass= organizationalUnit)"
dn: ou=Users,dc=example,dc=com objectClass: organizationalUnit ou: users
2. Identify the OU that contains Groups. You will use this information to configure the lookup point for tenants in Keystone.
In the following example, the OU is called groups.
ldapsearch -x -LLL -H ldapi:/// -b dc=example,dc=com "(objectClass= organizationalUnit)"
dn: ou=Groups,dc=example,dc=com objectClass: organizationalUnit ou: groups
3. Identify the OU that contains Roles. If one does not already exist, the LDAP
administrator should create a Roles OU. You will use this information in Keystone to set up roles and manage user/tenant interaction within the OpenStack cluster.
In the following example, the OU is called roles.
ldapsearch -x -LLL -H ldapi:/// -b dc=example,dc=com "(objectClass= organizationalUnit)
dn: ou=Roles,dc=example,dc=com objectClass: organizationalUnit ou: roles
4. Note: If you are using Keystone 2013.1.1, you may skip this step.
The LDAP administrator will need to create an OU called domains and a single object
named Default that has the objectClass groupOfNames.
5. Identify the objectClass that will be used by objects in the User, Group, Role, and Domain OUs. The objectClass will depend on your own LDAP schema.
In this example, the following objectClass definitions are used:
User: inetOrgPerson Group: groupOfNames Role: organizationalRole Domain: groupOfNames
Adding LDAP Integration to the Chef
Environment
You will now add your LDAP environment information to the Chef environment, which executes the configuration changes in your OpenStack environment.
In this example, you will integrate Keystone and LDAP in an environment called default-ldap. This example uses the Knife command line tool to edit the environment's .json file.
1. Define your text editor with EXPORT. In this example, the editor is vim.
$ export EDITOR=vim
2. Use the knife command to enter the environment editing mode.
$ knife environment edit default-ldap
3. You will now be able to edit the environment .json file directly. Locate the
override_attributes: { setting inside the file, and locate the "keystone": {
section within the override section. If it does not already exist, you will need to add it. 4. Edit the "keystone": { section to match the following code, substituting in the
OU and objectClass information that you gathered earlier in the lines with italicized variables. "keystone": { "ldap": { "keystone": { "ldap": { "user_attribute_ignore": "tenantId", "tenant_tree_dn": "<ou=Groups,dc=example,dc=com>", "role_tree_dn": "<ou=Roles,dc=example,dc=com>", "tenant_attribute_ignore": "tenantId", "group_attribute_ignore": "enabled", "url": "<ldap://ldap server url>", "tenant_objectclass": "groupOfNames", "tenant_enabled_emulation": "True", "use_dumb_member": "True", "user_tree_dn": "<ou=Users,dc=example,dc=com>", "user_objectclass": "inetOrgPerson", "role_objectclass": "organizationalRole", "user_enabled_emulation": "True", "allow_subtree_delete": "false", "domain_attribute_ignore": "enabled", "suffix": "dc=example,dc=com", "user": "cn=admin,dc=example,dc=com", "password": "<user LDAP password>" },
5. If the LDAP schema uses existing LDAP users for the Nova and Glance service users, you should also ensure that these are defined in the environment file and that user creation, updating, and deletion is disabled. If you do not define them here, the Rackspace cookbooks will attempt to create those users for you. The following example shows an environment with Nova and Glance service user information defined.
"override_attributes": { "glance": {
"service_pass": "<glance user password>" },
"nova": {
"service_pass": "<nova user password>" }, "keystone": "ldap": { "user_attribute_ignore": "tenantId", "tenant_tree_dn": "<ou=Groups,dc=example,dc=com>", "role_tree_dn": "<ou=Roles,dc=example,dc=com>", "tenant_attribute_ignore": "tenantId", "group_attribute_ignore": "enabled", "url": "ldap://<ldap server url>", "tenant_objectclass": "groupOfNames", "tenant_enabled_emulation": "True", "use_dumb_member": "True", "user_tree_dn": "<ou=Users,dc=example,dc=com>", "user_objectclass": "inetOrgPerson", "role_objectclass": "organizationalRole", "user_enabled_emulation": "True", "allow_subtree_delete": "false", "domain_attribute_ignore": "enabled", "suffix": "dc=example,dc=com", "user": "cn=admin,dc=example,dc=com", "password": "<user LDAP password>" "user_allow_create": "False", "user_allow_update": "False", "user_allow_delete": "False" }, "auth_type": "ldap", "users": { "admin": {
"password": "<OpenStack admin password>" },
"monitoring": {
"password": "<collectd/graphite monitoring password>" } }, "debug": "True" } }
6. Run chef-client on the Chef server and on each server in your OpenStack environment to implement the changes.
7. Run chef-client again. The second run resolves an issue related to Keystone bug 1176270.
Once this process is complete, you will be able to authenticate with Keystone with an LDAP backend.
If you would like to view all of the available LDAP options available in the Rackspace cookbooks you can review them here:
https://github.com/rcbops-cookbooks/keystone/blob/master/ attributes/default.rb#L22
