Rackspace Private Cloud Active Directory and LDAP Integration


This article describes the processes for enabling Active Directory and LDAP in your Rackspace Private Cloud environment.

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>",
            "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",
          "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

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
  • nis.ldif
  • inetorgperson.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 knifecommand 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>"
          },
          "auth_type": "ldap"
        }
                                
  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



Was this content helpful?




© 2011-2013 Rackspace US, Inc.

Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License


See license specifics and DISCLAIMER