As this is a book on Linux automation, an in-depth discussion of Microsoft AD and its setup and configuration is well beyond its scope. Suffice to say that in the context of Linux, AD is best suited to centralized user account management, although, of course, its capabilities are far greater than this. Most organizations that need an AD server will already have one set up, and so, our concern is not with this aspect, but with getting our Linux servers to authenticate against it.

On most modern Linux distributions, the realmd tool is used to join the Linux server in question to AD. Next, we consider a hypothetical example of joining a CentOS 7 server to AD—however, every organization, their AD setup, organizational units, and so on will be different, and so, there is no one-size-fits-all solution here. 

It is hoped, though, that the following code given provides you with a good basis on which to develop your own Ansible role to join AD.

1. Before beginning the process of joining the directory, it is vital that the Linux server is using the correct DNS servers that contain the appropriate Service (SRV) records for the domain. Often, these DNS servers will be the AD servers themselves, but that again will vary from organization to organization.
2. The realmd tool must be installed, along with a number of supporting packages. Let's create a role called realmd, using our familiar roles directory structure. The roles/realmd/tasks/main.yml should begin with the following code, to install the required packages:

---  
- name: Install realmd packages
  yum:
    name: "{{ item }}"
    state: present
  loop:
    - realmd
    - oddjob
    - oddjob-mkhomedir
    - sssd
    - samba-common
    - samba-common-tools
    - adcli
    - krb5-workstation
    - openldap-clients
    - policycoreutils-python

Some of these packages offer supporting functions—for example, openldap-clients is not directly required, but can be very useful in debugging directory issues.

3. Once our prerequisite packages are installed, our next task is to join the Active Directory itself. Here, we are assuming the presence of roles/realmd/vars/main.yml with the realm_join_password, realm_join_user, and realm_domain variables set. As this file might well contain a password with sufficient privileges to join the AD domain, it is recommended that this variables file be encrypted with ansible-vault. Run the following code:

- name: Join the domain
    shell: echo '{{ realm_join_password }}' | realm join --user={{ realm_join_user }} {{ realm_domain }}
    register: command_result
    ignore_errors: True
    notify:
      - Restart sssd

The use of the shell module to perform the realm join requires special consideration, as running this task twice will not yield the normal clean behavior of Ansible. Indeed, performing a second realm join when the server is already a domain member results in an error. As a result, we set ignore_errors: True, and register the result of the command so that we can later evaluate if it ran successfully. We also notify a handler that we will define later, to restart the sssd service. The aforementioned vars file should look something like this:

---
realm_join_password: securepassword
realm_join_user: [email protected]
realm_domain: example.com

Be sure to substitute the variable values with ones appropriate to your own environment.

4. We immediately follow this task with a check, to see if the realm join was successful. If it was successful, we should either get a return code of 0 or an error, informing us that the server is Already joined to this domain. If we don't get these expected results, then we will fail the entire play to ensure that the issue can be rectified, as follows:

- name: Fail the play when the realm join fails
    fail: 
      msg="Realm join failed with this error: {{ command_result.stderr }}"
    when: "'Already joined to this domain' not in command_result.stderr and command_result.rc != 0"

5. Finally, we create the handler, to restart sssd in roles/realmd/handlers/main.yml, as follows:

---
- name: Restart sssd
  service:
    name: sssd
    state: restarted
    enabled: yes

These steps are all sufficient to perform the basic addition of a Linux server to an AD domain. Although the example is given for CentOS 7, the process should be broadly similar for operating systems like Ubuntu, as long as you take account of the different package manager and package names.

There are, of course, a vast number of enhancements that can be made to the preceding procedure, most of which will be performed with the realm command. Sadly, at the time of writing, there is no realm module for Ansible, so, all realm commands must be issued with the shell module—though this still enables automated rollouts of AD membership to Linux servers using Ansible.

Possible enhancements for you to consider to the preceding process (all of which can easily be automated by extending the example playbook we have previously suggested) are as follows:

• Specify the organizational unit (OU) that the Linux server is to go into when the join is complete. Without specifying this, it will go into the default Computers OU. You can change this, by specifying something like --computer-ou=OU=Linux,OU=Servers,OU=example,DC=example,DC=com within your realm join command. Be sure the OU has been created first, and adjust the preceding parameter to match your environment.
• By default, all valid domain user accounts will be able to log in to the Linux server. This may not be desirable and, if not, you will need to first of all deny all access, using the command realm deny --all. Then, to say you wish to allow all users in the LinuxAdmins AD group, you would then issue the following command: realm permit -g LinuxAdmins.
• It is unlikely you will have a group in your AD called wheel or sudo, and as a result, AD users may find themselves unable to execute privileged commands. This can be rectified by adding the appropriate users or groups into /etc/sudoers or, better still, a unique file under /etc/sudoers.d that Ansible can manage. For example, creating /etc/sudoers.d/LinuxAdmins with the following content would enable all members of the LinuxAdmins AD group to perform sudo commands without re-entering their passwords:

%LinuxAdmins ALL=(ALL) NOPASSWD: ALL

All of these tasks are left as an exercise for you, though it is expected that the information given in this chapter is sufficient for you to build up your own playbook suited to your AD infrastructure.

In the next section, we will look at the use of the FreeIPA directory service that is native to Linux, and how to integrate this into your environment with Ansible.