Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 5. Preparing your environment for managing IdM using Ansible playbooks

Set up your Ansible control node with proper directory structure, inventory files, and vault configuration to securely manage Identity Management (IdM) using playbooks.

When working with Ansible as a system administrator managing IdM, it is good practice to do the following:

  • Keep a subdirectory dedicated to Ansible playbooks in your home directory, for example ~/MyPlaybooks.
  • Copy and adapt sample Ansible playbooks from the /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/* and /usr/share/doc/rhel-system-roles/* directories and subdirectories into your ~/MyPlaybooks directory.
  • Include your inventory file in your ~/MyPlaybooks directory.

Using this practice, you can find all your playbooks in one place.

Note

You can run your ansible-freeipa playbooks without invoking root privileges on the managed nodes. Exceptions include playbooks that use the ipaserver, ipareplica, ipaclient, ipasmartcard_server, ipasmartcard_client and ipabackup ansible-freeipa roles. These roles require privileged access to directories and the dnf software package manager.

The playbooks in the Red Hat Enterprise Linux IdM documentation assume the following security configuration:

  • The IdM admin is your remote Ansible user on the managed nodes.
  • You store the IdM admin password encrypted in an Ansible vault.
  • You have placed the password that protects the Ansible vault in a password file.
  • You block access to the vault password file to everyone except your local ansible user.
  • You regularly remove and re-create the vault password file.

Consider also alternative security configurations.

Set up your Ansible control node with the required directory structure, inventory file, and encrypted vault to securely manage IdM servers.

Create the ~/MyPlaybooks directory and configure it so that you can use it to store and run Ansible playbooks.

Prerequisites

  • You have installed an IdM server on your managed nodes, server.idm.example.com and replica.idm.example.com.
  • You have configured DNS and networking so you can log in to the managed nodes, server.idm.example.com and replica.idm.example.com, directly from the control node.
  • You know the IdM admin password.

Procedure

  1. Change into the ~/MyPlaybooks/ directory: 

    $ cd ~/MyPlaybooks
    Copy to Clipboard Toggle word wrap

  2. Create the ~/MyPlaybooks/ansible.cfg file with the following content: 

    [defaults]
inventory = /home/your_username/MyPlaybooks/inventory
remote_user = admin
    Copy to Clipboard Toggle word wrap

  3. Create the ~/MyPlaybooks/inventory file with the following content: 

    [eu]
server.idm.example.com

[us]
replica.idm.example.com

[ipaserver:children]
eu
us
    Copy to Clipboard Toggle word wrap

    This configuration defines two host groups, eu and us, for hosts in these locations. Additionally, this configuration defines the ipaserver host group, which contains all hosts from the eu and us groups.

  4. Optional: Create an SSH public and private key. To simplify access in your test environment, do not set a password on the private key: 

    $ ssh-keygen
    Copy to Clipboard Toggle word wrap

  5. Copy the SSH public key to the IdM admin account on each managed node: 

    $ ssh-copy-id admin@server.idm.example.com
$ ssh-copy-id admin@replica.idm.example.com
    Copy to Clipboard Toggle word wrap

    These commands require that you enter the IdM admin password.

  6. Create a password_file file that contains the vault password: 

    redhat
    Copy to Clipboard Toggle word wrap

  7. Change the permissions to modify the file: 

    $ chmod 0600 password_file
    Copy to Clipboard Toggle word wrap

  8. Create a secret.yml Ansible vault to store the IdM admin password:

    1. Configure password_file to store the vault password: 

      $ ansible-vault create --vault-password-file=password_file secret.yml
      Copy to Clipboard Toggle word wrap

    2. When prompted, enter the content of the secret.yml file: 

      ipaadmin_password: Secret123
      Copy to Clipboard Toggle word wrap
      Note

      To use the encrypted ipaadmin_password in a playbook, you must use the vars_file directive. For example, a simple playbook to delete an IdM user can look as follows: 

      ---
- name: Playbook to handle users
  hosts: ipaserver

  vars_files:
  - /home/user_name/MyPlaybooks/secret.yml

  tasks:
  - name: Delete user robot
    freeipa.ansible_freeipa.ipauser:
      ipaadmin_password: "{{ ipaadmin_password }}"
      name: robot
      state: absent
      Copy to Clipboard Toggle word wrap

      When executing a playbook, instruct Ansible use the vault password to decrypt ipaadmin_password by adding the --vault-password-file=password_file option. For example: 

      ansible-playbook -i inventory --vault-password-file=password_file del-user.yml
      Copy to Clipboard Toggle word wrap
      Warning

      For security reasons, remove the vault password file at the end of each session, and repeat steps 6-8 at the start of each new session.

Choose the appropriate method for providing IdM credentials required for running playbooks that use ansible-freeipa roles and modules, based on your security requirements and automation needs.

Storing passwords in plain text in a playbook

Benefits:

  • Not being prompted all the time you run the playbook.
  • Easy to implement.

Drawbacks:

  • Everyone with access to the file can read the password. Setting wrong permissions and sharing the file, for example in an internal or external repository, can compromise security.
  • High maintenance work: if the password is changed, it needs to be changed in all playbooks.

Entering passwords interactively when you execute a playbook

Benefits:

  • No-one can steal the password as it is not stored anywhere.
  • You can update the password easily.
  • Easy to implement.

Drawbacks:

  • If you are using Ansible playbooks in scripts, the requirement to enter the password interactively can be inconvenient.

Storing passwords in an Ansible vault and the vault password in a file

Benefits:

  • The user password is stored encrypted.
  • You can update the user password easily, by creating a new Ansible vault.
  • You can update the password file that protects the ansible vault easily, by using the ansible-vault rekey --new-vault-password-file=NEW_VAULT_PASSWORD_FILE secret.yml command.
  • If you are using Ansible playbooks in scripts, it is convenient not to have to enter the password protecting the Ansible vault interactively.

Drawbacks:

  • It is vital that the file that contains the sensitive plain text password be protected through file permissions and other security measures.

Storing passwords in an Ansible vault and entering the vault password interactively

Benefits:

  • The user password is stored encrypted.
  • No-one can steal the vault password as it is not stored anywhere.
  • You can update the user password easily, by creating a new Ansible vault.
  • You can update the vault password easily too, by using the ansible-vault rekey file_name command.

Drawbacks:

  • If you are using Ansible playbooks in scripts, the need to enter the vault password interactively can be inconvenient.

Use the ansible-freeipa freeipa inventory plugin to automatically discover and target Identity Management (IdM) servers with specific roles, eliminating the need for static inventory files.

To use the plugin with the ansible-playbook command, set the value of the -i option to the inventory file that uses the freeipa plugin. As a result, the plays in the playbook are executed only against those servers that have the roles specified in the inventory file.

The example below describes how to use the freeipa plugin to determine the versions of the bind package on the IdM servers in the topology that have the DNS role.

Procedure

  1. Create a file, for example inventory.yml, to generate a dynamic inventory based on your selected IdM server role or roles. For example, to create an inventory of servers that have the IdM DNS server role: 

    ---
plugin: freeipa
server: server.idm.example.com
ipaadmin_password: Secret123
verify: ca.crt
role: DNS server
    Copy to Clipboard Toggle word wrap
    • server defines the fully-qualified domain name of the host to start the scan.
    • verify defines the server TLS certificate file for verification.
    • role defines all the server roles that a host must have for the host to be returned.

  2. Create a playbook, for example bind-playbook.yml, that you want to execute against the IdM servers identified by the freeipa inventory plugin. For example, to determine the release version of the bind package installed on the IdM DNS servers: 

    ---
- name: Check bind version
  hosts: ipaservers

  tasks:
    - name: Query bind package version
      package:
        name: bind
        state: present
      register: bind_version

    - name: Display bind release info
      debug:
        msg: "Bind release: {{ bind_version.results[0].version }}"
    Copy to Clipboard Toggle word wrap

  3. [Optional] Create a graph representation of the IdM servers identified by the plugin: 

    $ ansible-inventory -i inventory.yml --graph
@all:
  |--@ungrouped
  |--@ipaservers:
  |  |--replica01.idm.example.com
    Copy to Clipboard Toggle word wrap

  4. Run the Ansible playbook. Specify the inventory.yml file as inventory: 

    $ ansible-playbook -i inventory.yml bind-playbook.yml
[...]
TASK [Display bind release info]
ok: [10.0.193.174] => {
    "msg": "Bind release: 9.20.3"
}
[...]
    Copy to Clipboard Toggle word wrap

The freeipa.ansible_freeipa collection provided by the ansible-freeipa RPM package is compatible with the namespace and name of the redhat.rhel_idm collection available from Red Hat Ansible Automation Hub (RH AAH).

After installing the RPM package, you can run playbooks that reference roles and modules from the AAH collection. Internally, the namespace and names from the RPM package are used.

For example, the following two playbooks are functionally identical: 

---
- name: Host playbook
  hosts: ipaserver

  tasks:
  - name: Ensure host is present
    redhat.rhel_idm.ipahost:
      ipaadmin_password: SomeADMINpassword
      name: host01.example.com
      description: Example host
      ip_address: 192.168.0.123
      state: present
Copy to Clipboard Toggle word wrap 
---
- name: Host playbook
  hosts: ipaserver

  tasks:
  - name: Ensure host is present
    freeipa.ansible_freeipa.ipahost:
      ipaadmin_password: SomeADMINpassword
      name: host01.example.com
      description: Example host
      ip_address: 192.168.0.123
      state: present
Copy to Clipboard Toggle word wrap
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2026 Red HatBack to top