Chapter 40. Managing Hosts in IdM CLI

This chapter introduces hosts and host entries in Identity Management (IdM), and the following operations performed when managing hosts and host entries in IdM CLI:

The chapter also contains an overview table of the prerequisites, the context, and the consequences of these operations.

40.1. Hosts in IdM

Identity Management (IdM) manages these identities:

  • Users
  • Services
  • Hosts

A host represents a machine. As an IdM identity, a host has an entry in the IdM LDAP, that is the 389 Directory Server instance of the IdM server.

The host entry in IdM LDAP is used to establish relationships between other hosts and even services within the domain. These relationships are part of delegating authorization and control to hosts within the domain. Any host can be used in host-based access control (HBAC) rules.

IdM domain establishes a commonality between machines, with common identity information, common policies, and shared services. Any machine that belongs to a domain functions as a client of the domain, which means it uses the services that the domain provides. IdM domain provides three main services specifically for machines:

  • DNS
  • Kerberos
  • Certificate management

Hosts in IdM are closely connected with the services running on them:

  • Service entries are associated with a host.
  • A host stores both the host and the service Kerberos principals.

40.2. Host enrollment

This section describes enrolling hosts as IdM clients and what happens during and after the enrollment. The section compares the enrollment of IdM hosts and IdM users. The section also outlines alternative types of authentication available to hosts.

Enrolling a host consists of:

  • Creating a host entry in IdM LDAP: possibly using the ipa host-add command in IdM CLI, or the equivalent IdM Web UI operation.
  • Configuring IdM services on the host, for example the System Security Services Daemon (SSSD), Kerberos, and certmonger, and joining the host to the IdM domain.

The two actions can be performed separately or together.

If performed separately, they allow for dividing the two tasks between two users with different levels of privilege. This is useful for bulk deployments.

The ipa-client-install command can perform the two actions together. The command creates a host entry in IdM LDAP if that entry does not exist yet, and configures both the Kerberos and SSSD services for the host. The command brings the host within the IdM domain and allows it to identify the IdM server it will connect to. If the host belongs to a DNS zone managed by IdM, ipa-client-install adds DNS records for the host too. The command must be run on the client.

40.3. User privileges required for host enrollment

The host enrollment operation requires authentication to prevent an unprivileged user from adding unwanted machines to the IdM domain. The privileges required depend on several factors, for example:

  • If a host entry is created separately from running ipa-client-install
  • If a one-time password (OTP) is used for enrollment

User privileges for optionally manually creating a host entry in IdM LDAP

The user privilege required for creating a host entry in IdM LDAP using the ipa host-add CLI command or the IdM Web UI is Host Administrators. The Host Administrators privilege can be obtained through the IT Specialist role.

User privileges for joining the client to the IdM domain

Hosts are configured as IdM clients during the execution of the ipa-client-install command. The level of credentials required for executing the ipa-client-install command depends on which of the following enrolling scenarios you find yourself in:

  • The host entry in IdM LDAP does not exist. For this scenario, you need a full administrator’s credentials or the Host Administrators role. A full administrator is a member of the admins group. The Host Administrators role provides privileges to add hosts and enroll hosts. For details about this scenario, see Installing a client using user credentials: interactive installation.
  • The host entry in IdM LDAP exists. For this scenario, you need a limited administrator’s credentials to execute ipa-client-install successfully. The limited administrator in this case has the Enrollment Administrator role, which provides the Host Enrollment privilege. For details, Installing a client using user credentials: interactive installation.
  • The host entry in IdM LDAP exists, and an OTP has been generated for the host by a full or limited administrator. For this scenario, you can install an IdM client as an ordinary user if you run the ipa-client-install command with the --password option, supplying the correct OTP. For details, see Installing a client by using a one-time password: Interactive installation.

After enrollment, IdM hosts authenticate every new session to be able to access IdM resources. Machine authentication is required for the IdM server to trust the machine and to accept IdM connections from the client software installed on that machine. After authenticating the client, the IdM server can respond to its requests.

40.4. Enrollment and authentication of IdM hosts and users: comparison

There are many similarities between users and hosts in IdM, some of which can be observed during the enrollment stage as well as those that concern authentication during the deployment stage.

  • The enrollment stage (User and host enrollment):

    • An administrator can create an LDAP entry for both a user and a host before the user or host actually join IdM: for the stage user, the command is ipa stageuser-add; for the host, the command is ipa host-add.
    • A file containing a key table or, abbreviated, keytab, a symmetric key resembling to some extent a user password, is created during the execution of the ipa-client-install command on the host, resulting in the host joining the IdM realm. Analogically, a user is asked to create a password when they activate their account, therefore joining the IdM realm.
    • While the user password is the default authentication method for a user, the keytab is the default authentication method for a host. The keytab is stored in a file on the host.

    Table 40.1. User and host enrollment

    ActionUserHost

    Pre-enrollment

    $ ipa stageuser-add user_name [--password]

    $ ipa host-add host_name [--random]

    Activating the account

    $ ipa stageuser-activate user_name

    $ ipa-client install [--password] (must be run on the host itself)

  • The deployment stage (User and host session authentication):

    • When a user starts a new session, the user authenticates using a password; similarly, every time it is switched on, the host authenticates by presenting its keytab file. The System Security Services Daemon (SSSD) manages this process in the background.
    • If the authentication is successful, the user or host obtains a Kerberos ticket granting ticket (TGT).
    • The TGT is then used to obtain specific tickets for specific services.

    Table 40.2. User and host session authentication

     UserHost

    Default means of authentication

    Password

    Keytabs

    Starting a session (ordinary user)

    $ kinit user_name

    [switch on the host]

    The result of successful authentication

    TGT to be used to obtain access to specific services

    TGT to be used to obtain access to specific services

TGTs and other Kerberos tickets are generated as part of the Kerberos services and policies defined by the server. The initial granting of a Kerberos ticket, the renewing of the Kerberos credentials, and even the destroying of the Kerberos session are all handled automatically by the IdM services.

Alternative authentication options for IdM hosts

Apart from keytabs, IdM supports two other types of machine authentication:

  • SSH keys. The SSH public key for the host is created and uploaded to the host entry. From there, the System Security Services Daemon (SSSD) uses IdM as an identity provider and can work in conjunction with OpenSSH and other services to reference the public keys located centrally in IdM.
  • Machine certificates. In this case, the machine uses an SSL certificate that is issued by the IdM server’s certificate authority and then stored in IdM’s Directory Server. The certificate is then sent to the machine to present when it authenticates to the server. On the client, certificates are managed by a service called certmonger.

40.5. Host Operations

The most common operations related to host enrollment and enablement, and the prerequisites, the context, and the consequences of performing those operations are outlined in the following sections.

Table 40.3. Host operations part 1

ActionWhat are the prerequisites of the action?When does it make sense to run the command?How is the action performed by a system administrator? What command(s) does he run?

Enrolling a client

see Preparing the system for Identity Management client installation in Installing Identity Management

When you want the host to join the IdM realm.

Enrolling machines as clients in the IdM domain is a two-part process. A host entry is created for the client (and stored in the 389 Directory Server instance) when the ipa host-add command is run, and then a keytab is created to provision the client. Both parts are performed automatically by the ipa-client-install command. It is also possible to perform those steps separately; this allows for administrators to prepare machines and IdM in advance of actually configuring the clients. This allows more flexible setup scenarios, including bulk deployments.

Disabling a client

The host must have an entry in IdM. The host needs to have an active keytab.

When you want to remove the host from the IdM realm temporarily, perhaps for maintenance purposes.

ipa host-disable host_name

Enabling a client

The host must have an entry in IdM.

When you want the temporarily disabled host to become active again.

ipa-getkeytab

Re-enrolling a client

The host must have en entry in IdM.

When the original host has been lost but you have installed a host with the same host name.

ipa-client-install --keytab or ipa-client-install --force-join

Un-enrolling a client

The host must have an entry in IdM.

When you want to remove the host from the IdM realm permanently.

ipa-client-install --uninstall

Table 40.4. Host operations part 2

ActionOn which machine can the administrator run the command(s)?What happens when the action is performed? What are the consequences for the host’s functioning in IdM? What limitations are introduced/removed?

Enrolling a client

In the case of a two-step enrollment: ipa host-add can be run on any IdM client; the second step of ipa-client-install must be run on the client itself

By default this configures SSSD to connect to an IdM server for authentication and authorization. Optionally one can instead configure the Pluggable Authentication Module (PAM) and the Name Switching Service (NSS) to work with an IdM server over Kerberos and LDAP.

Disabling a client

Any machine in IdM, even the host itself

The host’s Kerberos key and SSL certificate are invalidated, and all services running on the host are disabled.

Enabling a client

Any machine in IdM. If run on the disabled host, LDAP credentials need to be supplied.

The host’s Kerberos key and the SSL certificate are made valid again, and all IdM services running on the host are re-enabled.

Re-enrolling a client

The host to be re-enrolled. LDAP credentials need to be supplied.

A new Kerberos key is generated for the host, replacing the previous one.

Un-enrolling a client

The host to be un-enrolled.

The command unconfigures IdM and attempts to return the machine to its previous state. Part of this process is to unenroll the host from the IdM server. Unenrollment consists of disabling the principal key on the IdM server. The machine principal in /etc/krb5.keytab (host/<fqdn>@REALM) is used to authenticate to the IdM server to unenroll itself. If this principal does not exist then unenrollment will fail and an administrator will need to disable the host principal (ipa host-disable <fqdn>).

40.6. Host entry in IdM LDAP

An Identity Management (IdM) host entry contains information about the host and what attributes it can contain.

An LDAP host entry contains all relevant information about the client within IdM:

  • Service entries associated with the host
  • The host and service principal
  • Access control rules
  • Machine information, such as its physical location and operating system
Note

Note that the IdM Web UI Identity → Hosts tab does not show all the information about a particular host stored in the IdM LDAP.

Host entry configuration properties

A host entry can contain information about the host that is outside its system configuration, such as its physical location, MAC address, keys, and certificates.

This information can be set when the host entry is created if it is created manually. Alternatively, most of this information can be added to the host entry after the host is enrolled in the domain.

Table 40.5. Host Configuration Properties

UI FieldCommand-Line OptionDescription

Description

--desc=description

A description of the host.

Locality

--locality=locality

The geographic location of the host.

Location

--location=location

The physical location of the host, such as its data center rack.

Platform

--platform=string

The host hardware or architecture.

Operating system

--os=string

The operating system and version for the host.

MAC address

--macaddress=address

The MAC address for the host. This is a multi-valued attribute. The MAC address is used by the NIS plug-in to create a NIS ethers map for the host.

SSH public keys

--sshpubkey=string

The full SSH public key for the host. This is a multi-valued attribute, so multiple keys can be set.

Principal name (not editable)

--principalname=principal

The Kerberos principal name for the host. This defaults to the host name during the client installation, unless a different principal is explicitly set in the -p. This can be changed using the command-line tools, but cannot be changed in the UI.

Set One-Time Password

--password=string

This option sets a password for the host which can be used in bulk enrollment.

-

--random

This option generates a random password to be used in bulk enrollment.

-

--certificate=string

A certificate blob for the host.

-

--updatedns

This sets whether the host can dynamically update its DNS entries if its IP address changes.

40.7. Adding IdM host entries from IdM CLI

Follow this procedure to add host entries in Identity Management (IdM) using the command-line interface (CLI).

Host entries are created using the host-add command. This commands adds the host entry to the IdM Directory Server. Consult the ipa host manpage by typing ipa help host in your CLI to get the full list of options available with host-add.

There are a few different scenarios when adding a host to IdM:

  • At its most basic, specify only the client host name to add the client to the Kerberos realm and to create an entry in the IdM LDAP server: 

    $ ipa host-add client1.example.com

  • If the IdM server is configured to manage DNS, add the host to the DNS resource records using the --ip-address option.

    Example 40.1. Creating Host Entries with Static IP Addresses

    $ ipa host-add --ip-address=192.168.166.31 client1.example.com

  • If the host to be added does not have a static IP address or if the IP address is not known at the time the client is configured, use the --force option with the ipa host-add command.

    Example 40.2. Creating Host Entries with DHCP

    $ ipa host-add --force client1.example.com

    For example, laptops may be preconfigured as IdM clients, but they do not have IP addresses at the time they are configured. Using --force essentially creates a placeholder entry in the IdM DNS service. When the DNS service dynamically updates its records, the host’s current IP address is detected and its DNS record is updated.

40.8. Deleting host entries from IdM CLI

  • Use the host-del command to delete host records. If your IdM domain has integrated DNS, use the --updatedns option to remove the associated records of any kind for the host from the DNS: 

    $ ipa host-del --updatedns client1.example.com

40.9. Re-enrolling an Identity Management client

This section describes the different way you can re-enroll an Identity Management client.

40.9.1. Client re-enrollment in IdM

During the re-enrollment, the client generates a new Kerberos key and SSH keys, but the identity of the client in the LDAP database remains unchanged. After the re-enrollment, the host has its keys and other information in the same LDAP object with the same FQDN as previously, before the machine’s loss of connection with the IdM servers.

Important

You can only re-enroll clients whose domain entry is still active. If you uninstalled a client (using ipa-client-install --uninstall) or disabled its host entry (using ipa host-disable), you cannot re-enroll it.

You cannot re-enroll a client after you have renamed it. This is because in Identity Management, the key attribute of the client’s entry in LDAP is the client’s hostname, its FQDN. As opposed to re-enrolling a client, during which the client’s LDAP object remains unchanged, the outcome of renaming a client is that the client has its keys and other information in a different LDAP object with a new FQDN. Therefore, the only way to rename a client is to uninstall the host from IdM, change the host’s hostname, and install it as an IdM client with a new name. For details on how to rename a client, see Renaming Identity Management client systems.

What happens during client re-enrollment

During re-enrollment, Identity Management:

  • Revokes the original host certificate
  • Creates new SSH keys
  • Generates a new keytab

40.9.2. Re-enrolling a client by using user credentials: Interactive re-enrollment

Follow this procedure to re-enroll an Identity Management client interactively by using the credentials of an authorized user.

  1. Re-create the client machine with the same host name.

  2. Run the ipa-client-install --force-join command on the client machine: 

    # ipa-client-install --force-join

  3. The script prompts for a user whose identity will be used to re-enroll the client. This could be, for example, a hostadmin user with the Enrollment Administrator role: 

    User authorized to enroll computers: hostadmin
Password for hostadmin@EXAMPLE.COM:

Additional resources

40.9.3. Re-enrolling a client by using the client keytab: Non-interactive re-enrollment

Prerequisites

  • Back up the original client keytab file, for example in the /tmp or /root directory.

Procedure

Follow this procedure to re-enroll an Identity Management (IdM) client non-interactively by using the keytab of the client system. For example, re-enrollment using the client keytab is appropriate for an automated installation.

  1. Re-create the client machine with the same host name.
  2. Copy the keytab file from the backup location to the /etc/ directory on the re-created client machine.

  3. Use the ipa-client-install utility to re-enroll the client, and specify the keytab location with the --keytab option: 

    # ipa-client-install --keytab /etc/krb5.keytab
    Note

    The keytab specified in the --keytab option is only used when authenticating to initiate the enrollment. During the re-enrollment, IdM generates a new keytab for the client.

40.9.4. Testing an Identity Management client after installation

The command-line interface informs you that the ipa-client-install was successful, but you can also do your own test.

To test that the Identity Management client can obtain information about users defined on the server, check that you are able to resolve a user defined on the server. For example, to check the default admin user: 

[user@client1 ~]$ id admin
uid=1254400000(admin) gid=1254400000(admins) groups=1254400000(admins)

To test that authentication works correctly, su - as another IdM user: 

[user@client1 ~]$ su - idm_user
Last login: Thu Oct 18 18:39:11 CEST 2018 from 192.168.122.1 on pts/0
[idm_user@client1 ~]$

40.10. Renaming Identity Management client systems

The following sections describe how to change the host name of an Identity Management client system.

Warning

Renaming a client is a manual procedure. Do not perform it unless changing the host name is absolutely required.

Renaming an Identity Management client involves:

  1. Preparing the host. For details, see Preparing an IdM client for its renaming.
  2. Uninstalling the IdM client from the host. For details, see Uninstalling an Identity Management client.
  3. Renaming the host. For details, see Renaming the host system.
  4. Installing the IdM client on the host with the new name. For details, see Installing an Identity Management client in Installing Identity Management..
  5. Configuring the host after the IdM client installation. For details, see Re-adding services, re-generating certificates, and re-adding host groups.

40.10.1. Preparing an IdM client for its renaming

Before uninstalling the current client, make note of certain settings for the client. You will apply this configuration after re-enrolling the machine with a new host name.

  • Identify which services are running on the machine:

    • Use the ipa service-find command, and identify services with certificates in the output: 

      $ ipa service-find old-client-name.example.com
    • In addition, each host has a default host service which does not appear in the ipa service-find output. The service principal for the host service, also called a host principal, is host/old-client-name.example.com.

  • For all service principals displayed by ipa service-find old-client-name.example.com, determine the location of the corresponding keytabs on the old-client-name.example.com system: 

    # find / -name "*.keytab"

    Each service on the client system has a Kerberos principal in the form service_name/host_name@REALM, such as ldap/old-client-name.example.com@EXAMPLE.COM.

  • Identify all host groups to which the machine belongs. 

    # ipa hostgroup-find old-client-name.example.com

40.10.2. Uninstalling an Identity Management client

Uninstalling a client removes the client from the Identity Management domain, along with all of the specific Identity Management configuration of system services, such as System Security Services Daemon (SSSD). This restores the previous configuration of the client system.

Procedure

  1. Run the ipa-client-install --uninstall command: 

    [root@client]# ipa-client-install --uninstall

  2. Remove the DNS entries for the client host manually from the server: 

    [root@server]# ipa dnsrecord-del
Record name: old-client-client
Zone name: idm.example.com
No option to delete specific record provided.
Delete all? Yes/No (default No): yes
------------------------
Deleted record "old-client-name"

  3. For each identified keytab other than /etc/krb5.keytab, remove the old principals: 

    [root@client ~]# ipa-rmkeytab -k /path/to/keytab -r EXAMPLE.COM

  4. On an IdM server, remove the host entry. This removes all services and revokes all certificates issued for that host: 

    [root@server ~]# ipa host-del client.example.com

40.10.3. Renaming the host system

Rename the machine as required. For example: 

[root@client]# hostnamectl set-hostname new-client-name.example.com

You can now re-install the Identity Management client to the Identity Management domain with the new host name.

40.10.4. Re-adding services, re-generating certificates, and re-adding host groups

Procedure

  1. On the Identity Management (IdM) server, add a new keytab for every service identified in the Preparing an IdM client for its renaming. 

    [root@server ~]# ipa service-add service_name/new-client-name

  2. Generate certificates for services that had a certificate assigned in the Preparing an IdM client for its renaming. You can do this:

    • Using the IdM administration tools
    • Using the certmonger utility
  3. Re-add the client to the host groups identified in the Preparing an IdM client for its renaming.

40.11. Disabling and Re-enabling Host Entries

This section describes how to disable and re-enable hosts in Identity Management (IdM).

40.11.1. Disabling Hosts

Complete this procedure to disable a host entry in IdM.

Domain services, hosts, and users can access an active host. There can be situations when it is necessary to remove an active host temporarily, for maintenance reasons, for example. Deleting the host in such situations is not desired as it removes the host entry and all the associated configuration permanently. Instead, choose the option of disabling the host.

Disabling a host prevents domain users from accessing it without permanently removing it from the domain.

Procedure

  • Disable a host using the host-disable command. Disabling a host kills the host’s current, active keytabs. For example: 

    $ kinit admin
$ ipa host-disable client.example.com

As a result of disabling a host, the host becomes unavailable to all IdM users, hosts and services.

Important

Disabling a host entry not only disables that host. It disables every configured service on that host as well.

40.11.2. Re-enabling Hosts

Follow this procedure to re-enable a disabled IdM host.

Disabling a host killed its active keytabs, which removed the host from the IdM domain without otherwise touching its configuration entry.

Procedure

  • To re-enable a host, use the ipa-getkeytab command, adding:

    • the -s option to specify which IdM server to request the keytab from
    • the -p option to specify the principal name
    • the -k option to specify the file to which to save the keytab.

For example, to request a new host keytab from server.example.com for client.example.com, and store the keytab in the /etc/krb5.keytab file: 

$  ipa-getkeytab -s server.example.com -p host/client.example.com -k /etc/krb5.keytab -D "cn=directory manager" -w password
Note

You can also use the administrator’s credentials, specifying -D "uid=admin,cn=users,cn=accounts,dc=example,dc=com". It is important that the credentials correspond to a user allowed to create the keytab for the host.

If the ipa-getkeytab command is run on an active IdM client or server, then it can be run without any LDAP credentials (-D and -w) if the user has a TGT obtained using, for example, kinit admin. To run the command directly on the disabled host, supply LDAP credentials to authenticate to the IdM server.