Chapter 5. Using Ansible to manage DNS locations in IdM

As Identity Management (IdM) administrator, you can manage IdM DNS locations using the location module available in the ansible-freeipa package. The chapter describes the following topics and procedures:

5.1. Preparing your Ansible control node for managing IdM

When working with Ansible as a system administrator managing Identity Management (IdM), it is good practice to create a subdirectory dedicated to Ansible playbooks in your home directory, for example ~/MyPlaybooks. To use Ansible for your purposes, copy and adapt sample Ansible playbooks from the /usr/share/doc/ansible-freeipa/* and /usr/share/doc/rhel-system-roles/* directories and subdirectories into the ~/MyPlaybooks directory. This practice has the following advantages:

  • You can find all your playbooks in one place.
  • You can run your playbooks without invoking root privileges.

It is good practice to also include your inventory file in the ~/MyPlaybooks/ directory.

Prerequisites

  • On the control node, DNS name resolution works correctly and you can ping the managed nodes, server.idm.example.com and replica.idm.example.com.
  • You know the IdM admin password.
  • You know the root password on the managed nodes.

Procedure

  1. Create a directory for your Ansible configuration and playbooks in your home directory:

    $ mkdir ~/MyPlaybooks/
  2. Change into the ~/MyPlaybooks/ directory:

    $ cd ~/MyPlaybooks
  3. Create the ~/MyPlaybooks/ansible.cfg file with the following content:

    [defaults]
    inventory = /home/your_username/MyPlaybooks/inventory
    
    [privilege_escalation]
    become=True
  4. Create the ~/MyPlaybooks/inventory file with the following content:

    [eu]
    server.idm.example.com
    
    [us]
    replica.idm.example.com
    
    [ipaserver:children]
    eu
    us

    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.

  5. [Optional] Create an SSH public and private key:

    $ ssh-keygen
  6. 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

    These commands require that you enter the IdM admin password.

  7. Copy the SSH public key to the root account on each managed node:

    $ ssh-copy-id root@server.idm.example.com
    $ ssh-copy-id root@replica.idm.example.com

    These commands require that you enter the respective root passwords.

5.2. DNS-based service discovery

DNS-based service discovery is a process in which a client uses the DNS protocol to locate servers in a network that offer a specific service, such as LDAP or Kerberos. One typical type of operation is to allow clients to locate authentication servers within the closest network infrastructure, because they provide a higher throughput and lower network latency, lowering overall costs.

The major advantages of service discovery are:

  • No need for clients to be explicitly configured with names of nearby servers.
  • DNS servers are used as central providers of policy. Clients using the same DNS server have access to the same policy about service providers and their preferred order.

In an Identity Management (IdM) domain, DNS service records (SRV records) exist for LDAP, Kerberos, and other services. For example, the following command queries the DNS server for hosts providing a TCP-based Kerberos service in an IdM DNS domain:

Example 5.1. DNS location independent results

$ dig -t SRV +short _kerberos._tcp.idm.example.com
0 100 88 idmserver-01.idm.example.com.
0 100 88 idmserver-02.idm.example.com.

The output contains the following information:

  • 0 (priority): Priority of the target host. A lower value is preferred.
  • 100 (weight). Specifies a relative weight for entries with the same priority. For further information, see RFC 2782, section 3.
  • 88 (port number): Port number of the service.
  • Canonical name of the host providing the service.

In the previous example, the two host names returned have the same priority and weight. In this case, the client uses a random entry from the result list.

When the client instead queries a DNS server configured in a DNS location, the output differs. For IdM servers that are assigned to a location, tailored values are returned. In the example below, the client queries a DNS server in the location germany:

Example 5.2. DNS location-based results

$ dig -t SRV +short _kerberos._tcp.idm.example.com
_kerberos._tcp.germany._locations.idm.example.com.
0 100 88 idmserver-01.idm.example.com.
50 100 88 idmserver-02.idm.example.com.

The IdM DNS server automatically returns a DNS alias (CNAME) pointing to a DNS location specific SRV record which prefers local servers. This CNAME record is shown in the first line of the output. In the previous example, the host idmserver-01.idm.example.com has the lowest priority value and is therefore preferred. The idmserver-02.idm.example.com has a higher priority and thus is used only as backup for cases when the preferred host is unavailable.

5.3. Deployment considerations for DNS locations

Identity Management (IdM) can generate location-specific service (SRV) records when using the integrated DNS. Because each IdM DNS server generates location-specific SRV records, you have to install at least one IdM DNS server in each DNS location.

The client’s affinity to a DNS location is only defined by the DNS records received by the client. For this reason, you can combine IdM DNS servers with non-IdM DNS consumer servers and recursors if the clients doing DNS service discovery resolve location-specific records from IdM DNS servers.

In the majority of deployments with mixed IdM and non-IdM DNS services, DNS recursors select the closest IdM DNS server automatically by using round-trip time metrics. Typically, this ensures that clients using non-IdM DNS servers are getting records for the nearest DNS location and thus use the optimal set of IdM servers.

5.4. DNS time to live (TTL)

Clients can cache DNS resource records for an amount of time that is set in the zone’s configuration. Because of this caching, a client might not be able to receive the changes until the time to live (TTL) value expires. The default TTL value in Identity Management (IdM) is 1 day.

If your client computers roam between sites, you should adapt the TTL value for your IdM DNS zone. Set the value to a lower value than the time clients need to roam between sites. This ensures that cached DNS entries on the client expire before they reconnect to another site and thus query the DNS server to refresh location-specific SRV records.

Additional resources

5.5. Using Ansible to ensure an IdM location is present

As a system administrator of Identity Management (IdM), you can configure IdM DNS locations to allow clients to locate authentication servers within the closest network infrastructure.

The following procedure describes how to use an Ansible playbook to ensure a DNS location is present in IdM. The example describes how to ensure that the germany DNS location is present in IdM. As a result, you can assign particular IdM servers to this location so that local IdM clients can use them to reduce server response time.

Prerequisites

Procedure

  1. Navigate to the ~/MyPlaybooks/ directory:

    $ cd ~/MyPlaybooks/
  2. Make a copy of the location-present.yml file located in the /usr/share/doc/ansible-freeipa/playbooks/location/ directory:

    $ cp /usr/share/doc/ansible-freeipa/playbooks/location/location-present.yml location-present-copy.yml
  3. Open the location-present-copy.yml Ansible playbook file for editing.
  4. Adapt the file by setting the following variables in the ipalocation task section:

    • Adapt the name of the task to correspond to your use case.
    • Set the ipaadmin_password variable to the password of the IdM administrator.
    • Set the name variable to the name of the location.

    This is the modified Ansible playbook file for the current example:

    ---
    - name: location present example
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure that the "germany" location is present
        ipalocation:
          ipaadmin_password: Secret123
          name: germany
  5. Save the file.
  6. Run the Ansible playbook specifying the playbook file and the inventory file:

    $ ansible-playbook -v -i inventory location-present-copy.yml

Additional resources

5.6. Using Ansible to ensure an IdM location is absent

As a system administrator of Identity Management (IdM), you can configure IdM DNS locations to allow clients to locate authentication servers within the closest network infrastructure.

The following procedure describes how to use an Ansible playbook to ensure that a DNS location is absent in IdM. The example describes how to ensure that the germany DNS location is absent in IdM. As a result, you cannot assign particular IdM servers to this location and local IdM clients cannot use them.

Prerequisites

  • You know the IdM administrator password.
  • You have installed the ansible-freeipa package on the Ansible control node.
  • The example assumes that you have created and configured the ~/MyPlaybooks/ directory as a central location to store copies of sample playbooks.

Procedure

  1. Navigate to the ~/MyPlaybooks/ directory:

    $ cd ~/MyPlaybooks/
  2. Make a copy of the location-absent.yml file located in the /usr/share/doc/ansible-freeipa/playbooks/location/ directory:

    $ cp /usr/share/doc/ansible-freeipa/playbooks/location/location-absent.yml location-absent-copy.yml
  3. Open the location-absent-copy.yml Ansible playbook file for editing.
  4. Adapt the file by setting the following variables in the ipalocation task section:

    • Adapt the name of the task to correspond to your use case.
    • Set the ipaadmin_password variable to the password of the IdM administrator.
    • Set the name variable to the name of the DNS location.
    • Make sure that the state variable is set to absent.

    This is the modified Ansible playbook file for the current example:

    ---
    - name: location absent example
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure that the "germany" location is absent
        ipalocation:
          ipaadmin_password: Secret123
          name: germany
          state: absent
  5. Save the file.
  6. Run the Ansible playbook specifying the playbook file and the inventory file:

    $ ansible-playbook -v -i inventory location-absent-copy.yml

5.7. Additional resources

  • You can see more sample Ansible playbooks for the ansible-freeipa ipalocation module in the README-location.md file available in the /usr/share/doc/ansible-freeipa/ directory. The file also contains the definitions of the ipalocation variables.
  • You can see sample Ansible playbooks for the ipalocation module in the /usr/share/doc/ansible-freeipa/playbooks/location directory.