Author: Aaren DeJong

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.

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)

           [[email protected] sssd]# cd /etc/sssd
           [[email protected] sssd]# ls
           [[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
             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..

           domainuser: ad-svc-user
           passwd: 'yourpasswordhere'

    … 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.



//blog search

//other topics