Skip to main content

Quick Tip – Cloudforms AD Authentication

By July 15, 2021No Comments

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.

<img src="" size="M" position="left" alt="ManageIQ Logo" %}

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)

          [root@cldfrms sssd]# cd /etc/sssd       [root@cldfrms sssd]# ls       conf.d       [root@cldfrms sssd]# realm join -U ad-svc-user       Password for ad-svc-user: #<provide the password here>       [root@cldfrms sssd]# realm permit --all       [root@cldfrms sssd]# ls       conf.d  sssd.conf
  4. the populated realm list now shows as such ..

          [root@cldfrms 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:         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.

    [arctiq@ansible_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.

``` [arctiq@ansible_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.