This post explains how to setup OpenStack Juno to authenticate against Active Directory. Many organizations use Microsoft Active Directory as their central identity and access management platform. We can configure OpenStack to use Active Directory to authenticate users, and to define projects and roles. This post shows how to setup the necessary objects in Active Directory, and how to configure keystone to use AD as the identity provider.
First we should setup the objects in AD. These will include the users, roles and projects that we would normally store in the keystone database. Here’s a view of the objects we are going to create:
The object types we are going to create include organizationalUnit (OU) and organizationalRole objects. If you are familiar with the AD GUI tools, you’ll know that Active Directory Users and Computers is the tool that we normally use to create objects in AD, and we can indeed create the OU objects with this tool. The tool falls short however when we try to create the organizationalRole objects. The tool doesn’t expose an interface for creating this type of object because they’re not often used in the Microsoft world. So for these objects, we need to create them using a different tool, ADSIEDIT.
In ADSIEDIT, you can create an object, and select from the list of objectClasses to define any type of object, then enter the mandatory values. You can then add any optional values. For the organizationalRole object, we’ll populate the roleOccupant attribute with the users that we want to map to the role. For organizationalUnit object that we use for projects, we will set the extensionName attribute to TRUE, which will tell OpenStack that the project is enabled. Again, the standard GUI tool false short here, and we can’t set the extensionName in the standard interface (unless you enable advanced view and use the attribute editor tab). I think a quick video would help here:
You can watch a quick YouTube video on how to create these objects here: http://youtu.be/hwJnzZjTYbg
Here is the complete list of objects in text form:
The assumption here is that your user accounts are in the Users container in the root of your Active Directory. This may not be the case. Obviously you need to take note of where your users are and adjust the paths accordingly.
Once the AD objects are created, we can configure keystone to point to AD. Edit the /etc/keystone/keystone.conf and find the [identity] sections. Add the following line in that section:
Next find the [ldap] section and add the following lines:
Note that the AD paths match the locations of the objects we created above.
If you’re running neutron, you’ll want to modify the /etc/neutron/neutron.conf file on the node that is running the neutron-server service (typically the controller node). Find the nova_admin_tenant_id and update this to reflect the new ID of the server service. The original ID will be a UUID, but in Active Directory the ID will be the same as the name of the service project (typically service). So change the line to read:
Once that’s done, it’s a good idea to restart all of the OpenStack-related services, or simply reboot your whole stack.
Recreate Your Tenant-specific Networks
I had some trouble bringing up instances, they wouldn’t receive a DHCP lease. I found that I had to delete the admin network, subnet and router and recreate them. This is likely due to the fact that the admin tenant ID changed when I reconfigured to use Active Directory.
Once you’re using AD, the identity panel in the OpenStack dashboard will be basically read-only. Although you can make a few things work if you try hard enough, it really defeats the purpose of using AD in the fist place. Let the AD administrator define all of the projects and roles.
As I mentioned above, the tenant ID’s will no longer be in UUID form. This isn’t a problem, just something to be aware of. Also, since the tenant ID’s have changed since we switched to AD, any non-shared resources that were tenant-specific may need to be recreated.