Red Hat SummitEste conteúdo não está disponível no idioma selecionado.
Chapter 42. 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.
42.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.
42.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-addcommand 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.
42.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 Administratorsrole. A full administrator is a member of theadminsgroup. TheHost Administratorsrole 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-installsuccessfully. The limited administrator in this case has theEnrollment Administratorrole, which provides theHost Enrollmentprivilege. 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-installcommand with the--passwordoption, 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.
42.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 isipa 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-installcommand 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 42.1. User and host enrollment Action User Host 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)
-
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
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 42.2. User and host session authentication User Host 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.
42.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.
| Action | What 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? |
|---|---|---|---|
|
| 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 |
|
| 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. |
|
|
| The host must have an entry in IdM. | When you want the temporarily disabled host to become active again. |
|
|
| 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. |
|
|
| The host must have an entry in IdM. | When you want to remove the host from the IdM realm permanently. |
|
| Action | On 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? |
|---|---|---|
|
|
In the case of a two-step enrollment: | 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. |
|
| 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. |
|
| 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. |
|
| 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. |
|
| 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 |
42.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 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.
| UI Field | Command-Line Option | Description |
|---|---|---|
| Description |
| A description of the host. |
| Locality |
| The geographic location of the host. |
| Location |
| The physical location of the host, such as its data center rack. |
| Platform |
| The host hardware or architecture. |
| Operating system |
| The operating system and version for the host. |
| MAC 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 |
| SSH public keys |
| The full SSH public key for the host. This is a multi-valued attribute, so multiple keys can be set. |
| Principal name (not editable) |
|
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 |
| Set One-Time Password |
| This option sets a password for the host which can be used in bulk enrollment. |
| - |
| This option generates a random password to be used in bulk enrollment. |
| - |
| A certificate blob for the host. |
| - |
| This sets whether the host can dynamically update its DNS entries if its IP address changes. |
42.7. Adding IdM host entries from IdM CLI
Follow this procedure to add host entries in Identity Management (IdM) using the command line (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.comIf the IdM server is configured to manage DNS, add the host to the DNS resource records using the
--ip-addressoption.Example 42.1. Creating Host Entries with Static IP Addresses
$ ipa host-add --ip-address=192.168.166.31 client1.example.comIf 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
--forceoption with theipa host-addcommand.Example 42.2. Creating Host Entries with DHCP
$ ipa host-add --force client1.example.comFor example, laptops may be preconfigured as IdM clients, but they do not have IP addresses at the time they are configured. Using
--forceessentially 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.
42.8. Deleting host entries from IdM CLI
Use the
host-delcommand to delete host records. If your IdM domain has integrated DNS, use the--updatednsoption to remove the associated records of any kind for the host from the DNS:$ ipa host-del --updatedns client1.example.com
42.9. Disabling and Re-enabling Host Entries
This section describes how to disable and re-enable hosts in Identity Management (IdM).
42.9.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-disablecommand. 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.
Disabling a host entry not only disables that host. It disables every configured service on that host as well.
42.9.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-getkeytabcommand, adding:-
the
-soption to specify which IdM server to request the keytab from -
the
-poption to specify the principal name -
the
-koption to specify the file to which to save the keytab.
-
the
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
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.
42.10. Delegating access to hosts and services
By delegating access to hosts and services within an IdM domain, you can retrieve keytabs and certificates for another host or service.
Each host and service has a managedby entry that lists what hosts and services can manage it. By default, a host can manage itself and all of its services. You can configure a host to manage other hosts, or services on other hosts within the IdM domain.
When you delegate authority of a host to another host through a managedby entry, it does not automatically grant management rights for all services on that host. You must perform each delegation independently.
Host and service delegation
42.10.1. Delegating service management
You can delegate permissions to a host to manage a service on another host within the domain.
When you delegate permissions to a host to manage another host, it does not automatically include permissions to manage its services. You must delegate service management independently.
Procedure
Delegate the management of a service to a specific host by using the
service-add-hostcommand:ipa service-add-host principal --hosts=<hostname>
You must specify the service principal using the
principalargument and the hosts with control using the--hostsoption.For example:
[root@server ~]# ipa service-add HTTP/web.example.com [root@server ~]# ipa service-add-host HTTP/web.example.com --hosts=client1.example.com
Once the host is delegated authority, the host principal can be used to manage the service:
[root@client1 ~]# kinit -kt /etc/krb5.keytab host/client1.example.com [root@client1 ~]# ipa-getkeytab -s server.example.com -k /tmp/test.keytab -p HTTP/web.example.com Keytab successfully retrieved and stored in: /tmp/test.keytab
To generate a certificate for the delegated service, create a certificate request on the host with the delegated authority:
[root@client1]# kinit -kt /etc/krb5.keytab host/client1.example.com [root@client1]# openssl req -newkey rsa:2048 -subj '/CN=web.example.com/O=EXAMPLE.COM' -keyout /etc/pki/tls/web.key -out /tmp/web.csr -nodes Generating a 2048 bit RSA private key .............................................................+++ ............................................................................................+++ Writing new private key to '/etc/pki/tls/private/web.key'
Use the
cert-requestutility to submit the certificate request and load the certification information:[root@client1]# ipa cert-request --principal=HTTP/web.example.com web.csr Certificate: MIICETCCAXqgA...[snip] Subject: CN=web.example.com,O=EXAMPLE.COM Issuer: CN=EXAMPLE.COM Certificate Authority Not Before: Tue Feb 08 18:51:51 2011 UTC Not After: Mon Feb 08 18:51:51 2016 UTC Serial number: 1005
Additional resources
42.10.2. Delegating host management
You can delegate authority for a host to manage another host by using the host-add-managedby utility. This creates a managedby entry. After the managedby entry is created, the managing host can retrieve a keytab for the host it manages.
Procedure
Log in as the admin user:
[root@server ~]# kinit admin
Add the
managedbyentry. For example, this delegates authority over client2 to client1:[root@server ~]# ipa host-add-managedby client2.example.com --hosts=client1.example.com
Obtain a ticket as the host client1:
[root@client1 ~]# kinit -kt /etc/krb5.keytab host/client1.example.com
Retrieve a keytab for client2:
[root@client1 ~]# ipa-getkeytab -s server.example.com -k /tmp/client2.keytab -p host/client2.example.com Keytab successfully retrieved and stored in: /tmp/client2.keytab
42.10.3. Accessing delegated services
When a client has delegated authority, it can obtain a keytab for the principal on the local machine for both services and hosts.
With the kinit command, use the -k option to load a keytab and the -t option to specify the keytab. The principal format is <principal>/hostname@REALM. For a service, replace <principal> with the service name, for example HTTP. For a host, use host as the principal.
Procedure
To access a host:
[root@server ~]# kinit -kt /etc/krb5.keytab host/ipa.example.com@EXAMPLE.COM
To access a service:
[root@server ~]# kinit -kt /etc/httpd/conf/krb5.keytab HTTP/ipa.example.com@EXAMPLE.COM
