Pretty much all of my lab work has revolved around OpenStack in the last month or so. If you’ve been reading the rest of my blog you’ll know that it’s because I’ve been prepping a cluster for production deployment for the university club that I run. I thought that things would calm down after the actual deployment last week, but things have only gotten more interesting. OpenStack is a great way to manage resources for multiple users, but it’s not really that great at actually managing those users. This club has recently taken off and I suddenly have enough people to start a full sized business and trying to manage them through OpenStack is not going to be fun. But that is where Active Directory provides an excellent solution.

I’ve played with active directory a little bit at home so I know how great it can be for managing systems and users. There are other aspects of the club where this would also be useful so trying to get AD running for the club is a no brainer.

I also knew from just a little research that OpenStack can be integrated into an AD environment to provide a central user management and authentication system. This is very appealing to me as I much prefer managing users in windows over on Linux or in OpenStack. So again it’s obvious that I use AD for the club’s lab and in fact I had been planning on it from the very beginning.

So now that we actually have a system in the wild it’s time to start working towards getting that functionality. Luckily for me I have a decent number of systems free to test on. So with a little bit of work and even some play time I have a small test and development setup running. For my Active Directory server I’m using a Dell R410 running WinServer 2016. For a development OpenStack system I’m using an HP DL380G6 running CentOS 7 and packstack.

The Active Directory server was a snap to set up with role based services. The packstack instance actually went pretty smoothly too. For all of my previous development systems I’ve avoided packstack as I had trouble getting it to work the first few times I’ve tried it. This time it went smoothly the first time but I had to make a few tweaks to get the end result to function the same as my production system. With both of those running I also set up the CentOS server to allow logins from AD with SSSD and realmd. This was also easy to setup following this guide.

I’m very pleased with the results of getting CentOS into my domain. That will allow me to manage access and users through AD instead of directly in CentOS. This gives me a lot more flexibility just on its own. But it’s not entirely what I’m after. The next step is to actually get OpenStack authenticating users with the AD backend. There are quite a few guides out there but the best one I’ve found was given at the OpenStack Austin Summit in 2016. I did catch a few interesting changes that need to be made however.

The first thing I noticed was that the distinguished names used in the talk didn’t quite match up with the distinguished names for the objects in my active directory tree. The biggest problem though was a difference in the way things were configured. In the talk he adds the following lines to keystone.conf:

[identity] domain_specific_drivers_enabled true domain_config_dir /etc/keystone/domains [assignment] driver keystone.assignment.backends.sql.Assignment

These specific lines pretty much killed keystone and I started getting 500 errors like crazy. I’ve noticed things like this before in OpenStack and it seems that there are some discrepancies in the way certain things are configured in OpenStack. Instead the above lines should look more like this:

[identity] domain_specific_drivers_enabled = true domain_config_dir = /etc/keystone/domains [assignment] driver = sql

Making those changes fixed quite a few errors in my setup but I still had more issues. The one other big issue I had was in the actual domain configuration file. It was the same issue as in the keystone.conf file under [assignment] only instead of sql, it should be ldap.

So to my surprise after fixing those issue I can now authenticate my OpenStack users to AD instead of a local SQL database!

There’s just one strange quirk I’m noticing about using AD for the user backend though. In the OpenStack console you can list the users in the domain by running ‘openstack user list –domain MYDOMAIN’. In AD I have 3 users in the appropriate group for OpenStack. The funny thing is that only 2 of them were showing up and the one that wasn’t showing up had their primary group set to the OpenStack one. The really funny thing is that when I changed the primary group of the user away from the OpenStack group the user showed up on the OpenStack server. I’m not sure why that is exactly, but for now things seem to work ok so I’m not going to worry too much about it.

As always OpenStack keeps providing me great opportunities to learn about things. It’s been a blast to work on (if not a little frustrating at times) and it’s such a useful thing. If you have the patience and the resources I would highly suggest giving it a shot, even if all you use is packstack.

Hope you enjoyed! Catch you next time!