This commit fixes a grammar issue in the LDAP integration guide and it adds prompts to the command-line examples to be more explicit about where or how commands are being run. Change-Id: Ic6a5adfbcf2841656929e6c3875889a31d314089
6.7 KiB
Deploying DevStack with LDAP
The OpenStack Identity service has the ability to integrate with LDAP. The goal of this guide is to walk you through setting up an LDAP-backed OpenStack development environment.
Introduction
LDAP support in keystone is read-only. You can use it to back an entire OpenStack deployment to a single LDAP server, or you can use it to back separate LDAP servers to specific keystone domains. Users within those domains can authenticate against keystone, assume role assignments, and interact with other OpenStack services.
Configuration
To deploy an OpenLDAP server, make sure ldap
is added to
the list of ENABLED_SERVICES
in the local.conf
file:
enable_service ldap
Devstack will require a password to set up an LDAP administrator.
This administrative user is also the bind user specified in keystone's
configuration files, similar to a keystone
user for MySQL
databases.
Devstack will prompt you for a password when running
stack.sh
if LDAP_PASSWORD
is not set. You can
add the following to your local.conf
:
LDAP_PASSWORD=super_secret_password
At this point, devstack should have everything it needs to deploy
OpenLDAP, bootstrap it with a minimal set of users, and configure it to
back to a domain in keystone. You can do this by running the
stack.sh
script:
$ ./stack.sh
Once stack.sh
completes, you should have a running
keystone deployment with a basic set of users. It is important to note
that not all users will live within LDAP. Instead, keystone will back
different domains to different identity sources. For example, the
default
domain will be backed by MySQL. This is usually
where you'll find your administrative and services users. If you query
keystone for a list of domains, you should see a domain called
Users
. This domain is set up by devstack and points to
OpenLDAP.
User Management
Initially, there will only be two users in the LDAP server. The
Manager
user is used by keystone to talk to OpenLDAP. The
demo
user is a generic user that you should be able to see
if you query keystone for users within the Users
domain.
Both of these users were added to LDAP using basic LDAP utilities
installed by devstack (e.g. ldap-utils
) and LDIFs. The
LDIFs used to create these users can be found in
devstack/files/ldap/
.
Listing Users
To list all users in LDAP directly, you can use
ldapsearch
with the LDAP user bootstrapped by devstack:
$ ldapsearch -x -w LDAP_PASSWORD -D cn=Manager,dc=openstack,dc=org \
-H ldap://localhost -b dc=openstack,dc=org
As you can see, devstack creates an OpenStack domain called
openstack.org
as a container for the Manager
and demo
users.
Creating Users
Since keystone's LDAP integration is read-only, users must be added
directly to LDAP. Users added directly to OpenLDAP will automatically be
placed into the Users
domain.
LDIFs can be used to add users via the command line. The following is
an example LDIF that can be used to create a new LDAP user, let's call
it peter.ldif.in
:
dn: cn=peter,ou=Users,dc=openstack,dc=org
cn: peter
displayName: Peter Quill
givenName: Peter Quill
mail: starlord@openstack.org
objectClass: inetOrgPerson
objectClass: top
sn: peter
uid: peter
userPassword: im-a-better-pilot-than-rocket
Now, we use the Manager
user to create a user for Peter
in LDAP:
$ ldapadd -x -w LDAP_PASSWORD -D cn=Manager,dc=openstack,dc=org \
-H ldap://localhost -c -f peter.ldif.in
We should be able to assign Peter roles on projects. After Peter has
some level of authorization, he should be able to login to Horizon by
specifying the Users
domain and using his
peter
username and password. Authorization can be given to
Peter by creating a project within the Users
domain and
giving him a role assignment on that project:
$ openstack project create --domain Users awesome-mix-vol-1
+-------------+----------------------------------+
| Field | Value |
+-------------+----------------------------------+
| description | |
| domain_id | 61a2de23107c46bea2d758167af707b9 |
| enabled | True |
| id | 7d422396d54945cdac8fe1e8e32baec4 |
| is_domain | False |
| name | awesome-mix-vol-1 |
| parent_id | 61a2de23107c46bea2d758167af707b9 |
| tags | [] |
+-------------+----------------------------------+
$ openstack role add --user peter --user-domain Users \
--project awesome-mix-vol-1 --project-domain Users admin
Deleting Users
We can use the same basic steps to remove users from LDAP, but
instead of using LDIFs, we can just pass the dn
of the user
we want to delete:
$ ldapdelete -x -w LDAP_PASSWORD -D cn=Manager,dc=openstack,dc=org \
-H ldap://localhost cn=peter,ou=Users,dc=openstack,dc=org
Group Management
Like users, groups are considered specific identities. This means that groups also fall under the same read-only constraints as users and they can be managed directly with LDAP in the same way users are with LDIFs.
Adding Groups
Let's define a specific group with the following LDIF:
dn: cn=guardians,ou=UserGroups,dc=openstack,dc=org
objectClass: groupOfNames
cn: guardians
description: Guardians of the Galaxy
member: cn=peter,dc=openstack,dc=org
member: cn=gamora,dc=openstack,dc=org
member: cn=drax,dc=openstack,dc=org
member: cn=rocket,dc=openstack,dc=org
member: cn=groot,dc=openstack,dc=org
We can create the group using the same ldapadd
command
as we did with users:
$ ldapadd -x -w LDAP_PASSWORD -D cn=Manager,dc=openstack,dc=org \
-H ldap://localhost -c -f guardian-group.ldif.in
If we check the group membership in Horizon, we'll see that only
Peter is a member of the guardians
group, despite the whole
crew being specified in the LDIF. Once those accounts are created in
LDAP, they will automatically be added to the guardians
group. They will also assume any role assignments given to the
guardians
group.
Deleting Groups
Just like users, groups can be deleted using the dn
:
$ ldapdelete -x -w LDAP_PASSWORD -D cn=Manager,dc=openstack,dc=org \
-H ldap://localhost cn=guardians,ou=UserGroups,dc=openstack,dc=org
Note that this operation will not remove users within that group. It will only remove the group itself and the memberships any users had with that group.