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 http://manageiq.org/docs/reference/latest/auth/active_directory)

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 lab.com -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
          lab.com
            type: kerberos
            realm-name: LAB.COM
            domain-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: https://github.com/redhat-cfme-support/lab-playbooks/tree/master/cfme-ad-external-auth Below is how our var.yml looks like..

          domain: lab.com
          domainuser: ad-svc-user
          passwd: 'yourpasswordhere'
          domainip: ldap.lab.com
   

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