Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.
Chapter 17. Re-enrolling an IdM client
If a client machine has been destroyed and lost connection with the IdM servers, for example due to the client’s hardware failure, and you still have its keytab, you can re-enroll the client. In this scenario, you want to get the client back in the IdM environment with the same hostname.
17.1. Client re-enrollment in IdM
If a client machine has been destroyed and lost connection with the IdM servers, for example due to the client’s hardware failure, and you still have its keytab, you can re-enroll the client. In this scenario, you want to get the client back in the IdM environment with the same hostname.
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.
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 IdM, 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 IdM client systems.
What happens during client re-enrollment
During re-enrollment, IdM:
- Revokes the original host certificate
- Creates new SSH keys
- Generates a new keytab
17.2. Re-enrolling a client by using user credentials: Interactive re-enrollment
Follow this procedure to re-enroll an Identity Management (IdM) client interactively by using the credentials of an authorized user.
- Re-create the client machine with the same host name.
Run the
ipa-client-install --force-joincommand on the client machine:# ipa-client-install --force-joinThe script prompts for a user whose identity will be used to re-enroll the client. This could be, for example, a
hostadminuser with the Enrollment Administrator role:User authorized to enroll computers:
hostadminPassword forhostadmin@EXAMPLE.COM:
Additional resources
- For a more detailed procedure on enrolling clients by using an authorized user’s credentials, see Installing a client by using user credentials: Interactive installation.
17.3. Re-enrolling a client by using the client keytab: Non-interactive re-enrollment
You can re-enroll an Identity Management (IdM) client non-interactively by using the krb5.keytab keytab file of the client system from the previous deployment. For example, re-enrollment using the client keytab is appropriate for an automated installation.
Prerequisites
- You have backed up the keytab of the client from the previous deployment on another system.
Procedure
- Re-create the client machine with the same host name.
Copy the keytab file from the backup location to the re-created client machine, for example its
/tmp/directory.ImportantDo not put the keytab in the
/etc/krb5.keytabfile as old keys are removed from this location during the execution of theipa-client-installinstallation script.Use the
ipa-client-installutility to re-enroll the client. Specify the keytab location with the--keytaboption:# ipa-client-install --keytab /tmp/krb5.keytabNoteThe keytab specified in the
--keytaboption is only used when authenticating to initiate the re-enrollment. During the re-enrollment, IdM generates a new keytab for the client.
17.4. Testing an IdM client
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 (IdM) 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@client ~]$ id admin
uid=1254400000(admin) gid=1254400000(admins) groups=1254400000(admins)
To test that authentication works correctly, su to a root user from a non-root user:
[user@client ~]$ su -
Last login: Thu Oct 18 18:39:11 CEST 2018 from 192.168.122.1 on pts/0
[root@client ~]#