Skip to main content

Quick Tip – Cloudforms AD Authentication

Cloudforms/ ManageIQ Active Directory Authentication

Here’s some quick tips on the topic of authenticating with Active Directory in your ManageIQ or Cloudforms systems. This is coming from testing against a Cloudforms 4.5 Appliance with typical Windows Active Directory served in the same network, allowing us to leverage SSSD on the CFME appliance.

Documentation for this method isn’t entirely clear in the Red Hat portal, so I’ve put this together in case it helps someone else in the same situation.

A) The authentication chosen in the Cloudforms UI is NOT LDAP / Active Directory! It’s httpd external!

B) You will indeed need a service account in AD to allow Cloudforms to query the directory.

C) You’ll benefit from having a VM with Ansible installed to get some of this configured, especially if you have more than one Cloudforms worker (or any non-database appliance that will be authenticated into).

D) This guide assumes there’s no other authentication agents/ methods currently in place. If others are present in your environment, YMMV.

The actual setup…

Note that many of the steps below can be handled with Ansible.

(Based on docs from

  1. login to each CF UI server and ensure sssd is running
  2. start it and check status

    systemctl start sssd && systemctl status sssd

  3. Once you join the realm and permit all, the sssd.conf will self-generate… (ad-svc-user is our service user)
          [[email protected] sssd]# cd /etc/sssd       [[email protected] sssd]# ls       conf.d       [[email protected] sssd]# realm join -U ad-svc-user       Password for ad-svc-user: #<provide the password here>       [[email protected] sssd]# realm permit --all       [[email protected] sssd]# ls       conf.d  sssd.conf
  4. the populated realm list now shows as such ..
          [[email protected] log]# realm list         type: kerberos         realm-name: LAB.COM         domain-name:         configured: kerberos-member         server-software: active-directory         client-software: sssd         required-package: oddjob         required-package: oddjob-mkhomedir         required-package: sssd         required-package: adcli         required-package: samba-common-tools         login-formats: %[email protected]         login-policy: allow-realm-logins
  5. On an Ansible server, with inventory pointing to any CloudForms/ MIQ UI nodes, populate the vars file of this repo dir: Below is how our var.yml looks like..
          domain:       domainuser: ad-svc-user       passwd: 'yourpasswordhere'       domainip:

    … and run the playbook against those servers.

    [[email protected]_vm cfme-ad-external-auth]$ ansible-playbook -i hosts.inv external-auth.yml -u root

You may need to skip the joining to the domain piece if you run it a second time, using step mode.

``` [[email protected]_vm cfme-ad-external-auth]$ ansible-playbook -i hosts.inv external-auth.yml -u root (--step) ```

At this point, in the CF UI servers, set the Authentication as httpd (external) with ‘Get User Groups from External Authentication (httpd)’ checked, and don’t forget to save it, and do it to all zone servers that should authenticate to the same AD domain.

  • In Upper Right User Menu → Configuration → Access Control… Make sure the user’s AD group for the appliance are created and appropriate roles assigned to those groups. If the user attempting to login is not in any groups within CF, they will be denied access altogether.
  • Patience! The sssd caching of AD users into the sssd cache will take some time with large numbers of users. Only once the users are cached by sssd, will they be able to authenticate into the Cloudforms UI.
  • Once complete, the users will login with domain\username in the username field of the login page, with their AD password.

Share this story

Arctiq Team

We service innovation.