| Identity Management GuideChapter 6. Identity: Managing Hosts and ServicesBoth DNS and Kerberos are configured as part of the initial client configuration. This is required because these are the two services that bring the machine within the IdM domain and allow it to identify the IdM server it will connect with. After the initial configuration, IdM has tools to manage both of these services in response to changes in the domain services, changes to the IT environment, or changes on the machines themselves which affect Kerberos, certificate, and DNS services, like changing the client hostname. This chapter describes how to manage identity services that relate directly to the client machine: 6.1. About Hosts, Services, and Machine Identity and AuthenticationThe basic function of an enrollment process is to create a host entry for the client machine in the IdM directory. This host entry 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. A host entry contains all of the 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
Some services that run on a host can also belong to the IdM domain. Any service that can store a Kerberos principal or an SSL certificate (or both) can be configured as an IdM service. Adding a service to the IdM domain allows the service to request an SSL certificate or keytab from the domain. (Only the public key for the certificate is stored in the service record. The private key is local to the service.) An IdM domain establishes a commonality between machines, with common identity information, common policies, and shared services. Any machine which belongs to a domain functions as a client of the domain, which means it uses the services that the domain provides. An IdM domain (as described in Section 1.2, "Bringing Linux Services Together") provides three main services specifically for machines: DNS Kerberos Certificate management
Machines are treated as another identity that is managed by IdM. Clients use DNS to identify IdM servers, services, and domain members - which, like user identities are stored in the 389 Directory Server instance for the IdM server. Like users, machines can be authenticated to the domain using Kerberos or certificates to verify the machine's identity. From the machine perspective, there are several tasks that can be performed that access these domain services: Joining the DNS domain (machine enrollment) Managing DNS entries and zones Managing machine authentication
Authentication in IdM includes machines as well as users. 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. IdM supports three different approaches to machine authentication: Key tables (or keytabs, a symmetric key resembling to some extent a user password) and machine certificates. Kerberos tickets are generated as part of the Kerberos services and policies defined by the server. Initially granting a Kerberos ticket, renewing the Kerberos credentials, and even destroying the Kerberos session are all handled by the IdM services. Managing Kerberos is covered in Chapter 13, Policy: Managing the Kerberos Domain. 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, which is described in Appendix B, Working with certmonger. A host entry is always created when a client is configured. On Red Hat Enterprise Linux systems, this is done automatically with the ipa-client-install script. On other platforms - and in alternative enrollment scenarios, as in Section 6.3, "Enrolling Clients Manually" - the host entry is created manually. 6.2.1. Adding Host Entries from the Web UIOpen the Identity tab, and select the Hosts subtab. Click the Add link at the top of the hosts list. Fill in the machine name and select the domain from the configured zones in the drop-down list. If the host has already been assigned a static IP address, then include that with the host entry so that the DNS entry is fully created. DNS zones can be created in IdM, which is described in Section 10.4.1, "Adding DNS Zones". If the IdM server does not manage the DNS server, the zone can be entered manually in the menu area, like a regular text field. Select the Force checkbox to add the host DNS record, even if the hostname cannot be resolved. This is useful for hosts which use DHCP and do not have a static IP address. This 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. Click the Add and Edit button to go directly to the expanded entry page and fill in more attribute information. Information about the host hardware and physical location can be included with the host entry.
6.2.2. Adding Host Entries from the Command LineHost entries are created using the host-add command. This commands adds the host entry to the IdM Directory Server. The full list of options with host-add are listed in the ipa host manpage. At its most basic, an add operation only requires the client hostname 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, then the host can also be added to the DNS resource records using the --ip-address and --force options. Example 6.1. Creating Host Entries with Static IP Addresses $ ipa host-add --force --ip-address=192.168.166.31 client1.example.com Commonly, hosts may not have a static IP address or the IP address may not be known at the time the client is configured. For example, laptops may be preconfigured as Identity Management clients, but they do not have IP addresses at the time they're configured. Hosts which use DHCP can still be configured with a DNS entry by using --force. This 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. Example 6.2. Creating Host Entries with DHCP $ ipa host-add --force client1.example.com Host records are deleted using the host-del command. If the IdM domain uses DNS, then the --updatedns option also removes the associated records of any kind for the host from the DNS. $ ipa host-del --updatedns client1.example.com 6.3. Enrolling Clients ManuallyEnrolling 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), 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. When performing a manual enrollment, the host entry is created separately, and then enrollment is completed when the client script is run, which creates the requisite keytab. There are two ways to set the password. You can either supply your own or have IdM generate a random one. 6.3.1. Performing a Split EnrollmentThere may be a situation where an administrator in one group is prohibited from creating a host entry and, therefore, from simply running the ipa-client-install command and allowing it to create the host. However, that administrator may have the right to run the command after a host entry exists. In that case, one administrator can create the host entry manually, then the second administrator can complete the enrollment by running the ipa-client-install command. When the second administrator runs the setup script, he must pass his Kerberos password and username (principal) with the ipa-client-install command. For example: $ ipa-client-install -w secret -p admin2 The keytab is generated on the server and provisioned to the client machine, so that the client machine is not able to connect to the IdM domain. The keytab is saved with root:root ownership and 0600 permissions. 6.4. Manually Unconfiguring Client MachinesA machine may need to be removed from one IdM domain and moved to another domain or a virtual machine may be copied. There are a number of different situations where an IdM client needs to be reconfigured. The easiest solution is to uninstall the client and then configure it afresh. ipa-client-install --uninstall If it is not possible to uninstall the client directly, then the IdM configuration can be manually removed from the virtual machine. When a machine is unenrolled, the procedure cannot be undone. The machine can only be enrolled again. Remove the old hostname from the main keytab. This can be done by removing every principal in the realm or by removing specific principals. For example, to remove all principals: $ ipa-rmkeytab -k /etc/krb5.keytab -r EXAMPLE.COM To remove specific principals: $ ipa-rmkeytab -k /etc/krb5.keytab -p host/[email protected] Disable tracking in certmonger for every certificate. Each certificate must be removed from tracking individually. $ ipa-getcert stop-tracking -n Server-Cert -d /etc/pki/nssdb$ ipa-getcert stop-tracking -n Server2-Cert -d /etc/pki/nssdb Remove the old host from the IdM DNS domain. While this is optional, it cleans up the old IdM entries associated with the system and allows it to be re-enrolled cleanly at a later time. $ ipa host-del server.example.com If the system should be re-added to a new IdM domain - such as a virtual machine which was moved from one location to another - then the system can be rejoined to IdM using the ipa-join command. $ ipa-join
6.5.1. Adding and Editing Service Entries and KeytabsAs with host entries, service entries for the host (and any other services on that host which will belong to the domain) must be added manually to the IdM domain. This is a two step process. First, the service entry must be created, and then a keytab must be created for that service which it will use to access the domain. By default, Identity Management saves its HTTP keytab to /etc/httpd/conf/ipa.keytab. This keytab is used for the web UI. If a key were stored in ipa.keytab and that keytab file is deleted, the IdM web UI will stop working, because the original key would also be deleted. Similar locations can be specified for each service that needs to be made Kerberos aware. There is no specific location that must be used, but, when using ipa-getkeytab, you should avoid using /etc/krb5.keytab. This file should not contain service-specific keytabs; each service should have its keytab saved in a specific location and the access privileges (and possibly SELinux rules) should be configured so that only this service has access to the keytab. 6.5.1.1. Adding Services and Keytabs from the Web UIOpen the Identity tab, and select the Services subtab. Click the Add link at the top of the services list. Select the service type from the drop-down menu, and give it a name. Select the hostname of the IdM host on which the service is running. The hostname is used to construct the full service principal name. Click the Add button to save the new service principal. Use the ipa-getkeytab command to generate and assign the new keytab for the service principal. # ipa-getkeytab -s server.example.com -p HTTP/server.example.com -k /etc/httpd/conf/krb5.keytab -e des-cbc-crc The realm name is optional. The IdM server automatically appends the Kerberos realm for which it is configured. You cannot specify a different realm. The hostname must resolve to a DNS A record for it to work with Kerberos. You can use the --force flag to force the creation of a principal should this prove necessary. The -e argument can include a comma-separated list of encryption types to include in the keytab. This supersedes any default encryption type.
Creating a new key resets the secret for the specified principal. This means that all other keytabs for that principal are rendered invalid.
6.5.1.2. Adding Services and Keytabs from the Command LineCreate the service principal. The service is recognized through a name like service/FQDN: # ipa service-add serviceName/hostname For example: $ ipa service-add HTTP/server.example.com-------------------------------------------------------Added service "HTTP/[email protected]"------------------------------------------------------- Principal: HTTP/[email protected] Managed by: ipaserver.example.com Create the service keytab file using the ipa-getkeytab command. This command is run on the client in the IdM domain. (Actually, it can be run on any IdM server or client, and then the keys copied to the appropriate machine. However, it is simplest to run the command on the machine with the service being created.) The command requires the Kerberos service principal (-p), the IdM server name (-s), the file to write (-k), and the encryption method (-e). Be sure to copy the keytab to the appropriate directory for the service. For example: # ipa-getkeytab -s server.example.com -p HTTP/server.example.com -k /etc/httpd/conf/krb5.keytab -e des-cbc-crc The realm name is optional. The IdM server automatically appends the Kerberos realm for which it is configured. You cannot specify a different realm. The hostname must resolve to a DNS A record for it to work with Kerberos. You can use the --force flag to force the creation of a principal should this prove necessary. The -e argument can include a comma-separated list of encryption types to include in the keytab. This supersedes any default encryption type.
The ipa-getkeytab command resets the secret for the specified principal. This means that all other keytabs for that principal are rendered invalid.
6.5.2. Adding Services and Certificates for ServicesWhile services can use keytabs, some services require certificates for access. In that case, a service can be added (or modified) to include a certificate with its service entry. 6.5.2.1. Adding Services and Certificates from the Web UIOpen the Identity tab, and select the Services subtab. Click the Add link at the top of the services list. Select the service type from the drop-down menu, and give it a name. Select the hostname of the IdM host on which the service is running. The hostname is used to construct the full service principal name. Click the Add and Edit button to go directly to the service entry page. Scroll to the bottom of the page, to the Service Certificate section. Click the New Certificate button to create the service certificate.
6.5.2.2. Adding Services and Certificates from the Command LineCreate the service principal. The service is recognized through a name like service/FQDN: [jsmith@ipaserver ~]$ kinit admin[jsmith@ipaserver ~]$ ipa service-add serviceName/hostname For example: $ ipa service-add HTTP/server.example.com -------------------------------------------------------Added service "HTTP/[email protected]"------------------------------------------------------- Principal: HTTP/[email protected] Managed by: ipaserver.example.com Create a certificate for the service. Be sure to copy the keytab to the appropriate directory for the service. For example: $ ipa cert-request --principal=HTTP/web.example.com example.csr Use the --add option to create the service automatically when requesting the certificate. $ ipa-getcert request -d /etc/httpd/alias -n Server-Cert -K HTTP/client1.example.com -N 'CN=client1.example.com,O=EXAMPLE.COM'
6.5.3. Storing Certificates in NSS DatabasesWhen services use certificates, the certificates and keys can be stored in NSS databases (which may also be used by the services themselves, as well as Identity Management). Create the NSS databases. $ certutil -N -d /path/to/database/dir Request the certificate using certutil, an NSS tool. $ certutil -R -s "CN=client1.example.com,O=EXAMPLE.COM" -d /path/to/database/dir -a > example.csr
If the IdM domain is using Certificate System for its CA, only the CN of the subject name is used. With a self-signed CA, the subject must match the configured certificate subject base. The IdM server rejects requests with a subject base that differs from this value. 6.5.4. Configuring Clustered ServicesThe IdM server is not cluster aware. However, it is possible to configure a clustered service to be part of IdM by synchronizing Kerberos keys across all of the participating hosts and configuring services running on the hosts to respond to whatever names the clients use. Enroll all of the hosts in the cluster into the IdM domain. Create any service principals and generate the required keytabs. Collect any keytabs that have been set up for services on the host, including the host keytab at /etc/krb5.keytab. Use the ktutil command to produce a single keytab file that contains the contents of all of the keytab files. For each file, use the rkt command to read the keys from that file. Use the wkt command to write all of the keys which have been read to a new keytab file.
Replace the keytab files on each host with the newly-created combined keytab file. At this point, each host in this cluster can now impersonate any other host. Some services require additional configuration to accommodate cluster members which do not reset hostnames when taking over a failed service. For sshd, set GSSAPIStrictAcceptorCheck no in /etc/ssh/sshd_config. For mod_auth_kerb, set KrbServiceName Any in /etc/httpd/conf.d/auth_kerb.conf.
For SSL servers, the subject name or a subject alternative name for the server's certificate must appear correct when a client connects to the clustered host. If possible, share the private key among all of the hosts. If each cluster member contains a subject alternative name which includes the names of all the other cluster members will satisfy any client connection requirements. 6.5.5. Using the Same Service Principal for Multiple ServicesWithin a cluster, the same service principal can be used for multiple services, spread across different machines. Retrieve a service principal using the ipa-getkeytab command. # ipa-getkeytab -s kdc.example.com -p HTTP/server.example.com -k /etc/httpd/conf/krb5.keytab -e des-cbc-crc Either direct multiple servers or services to use the same file, or copy the file to individual servers as required.
6.6. Disabling and Re-enabling Host and Service EntriesActive services and hosts can be accessed by other services, hosts, and users within the domain. There can be situations when it is necessary to remove a host or a service from activity. However, deleting a service or a host removes the entry and all the associated configuration, and it removes it permanently. 6.6.1. Disabling Host and Service EntriesDisabling a host or service prevents domain users from access it without permanently removing it from the domain. This can be done by using the host-disable and service-disable commands. For example, for a host: [jsmith@ipaserver ~]$ kinit admin[jsmith@ipaserver ~]$ ipa host-disable server.example.com For a service, specify the principal rather than the hostname: $ ipa service-disable http/server.example.com Disabling a host entry not only disables that host. It disables every configured service on that host as well. 6.6.2. Re-enabling Hosts and ServicesDisabling a service or host essentially kills its current, active keytabs. Removing the keytabs effectively removes the host or service from the IdM domain without otherwise touching its configuration entry. To re-enable a host or service, simply use the ipa-getkeytab command. The -s option sets which IdM server to request the keytab, -p gives the principal name, and -k gives the file to which to save the keytab. For example, requesting a new host keytab: [jsmith@ipaserver ~]$ ipa-getkeytab -s ipaserver.example.com -p host/server.example.com -k /etc/krb5.keytab -D fqdn=server.example.com,cn=computers,cn=accounts,dc=example,dc=com -w password 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). The IdM user uses Kerberos credentials to authenticate to the domain. To run the command directly on the disabled host, then supply LDAP credentials to authenticate to the IdM server. The credentials should correspond to the host or service which is being re-enabled. 6.7. Extending Access Permissions over Other Hosts and ServicesAs discussed in Section 1.3, "Relationships Between Servers and Clients", within the IdM domain, manage means being able to retrieve a keytab and certificates for another host or service. Every host and service has a managedby entry which lists what hosts or services can manage it. By default, a host can manage itself and all of its services. It is also possible to allow a host to manage other hosts, or services on other hosts, by updating the appropriate delegations or providing a suitable managedby entry. An IdM service can be managed from any IdM host, as long as that host has been granted, or delegated, permission to access the service. Likewise, hosts can be delegated permissions to other hosts within the domain. If a host is delegated authority to another host through a managedBy entry, it does not mean that the host has also been delegated management for all services on that host. Each delegation has to be performed independently. 6.7.1. Delegating Service ManagementA host is delegated control over a service using the service-add-host command. There are two parts to delegating the service: specifying the principal and identifying the hosts (in a comma-separated list) with control: # ipa service-add-host principal --hosts=hostnames For example: # 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: # kinit -kt /etc/krb5.keytab host/`hostname`# ipa-getkeytab -s `hostname` -k /tmp/test.keytab -p http/web.example.comKeytab successfully retrieved and stored in: /tmp/test.keytab To create a ticket for this service, create a certificate request on the host with the delegated authority and use the cert-request command to create a service entry and load the certification information: # ipa cert-request --add --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 Fingerprint (MD5): c1:46:8b:29:51:a6:4c:11:cd:81:cb:9d:7c:5e:84:d5 Fingerprint (SHA1): 01:43:bc:fa:b9:d8:30:35:ee:b6:54:dd:a4:e7:d2:11:b1:9d:bc:38 Serial number: 1005 6.7.2. Delegating Host ManagementHosts are delegated authority over other hosts through the host-add-managedby command. This creates a managedby entry. Once the managedby entry is created, then the host can retrieve a keytab for the host it has delegated authority over. Log in as the admin user. # kinit admin Add the managedby entry. For example, this delegates authority over client2 to client1. # ipa host-add-managedby client2.example.com --hosts=client1.example.com Obtain a ticket as the host client1 and then retrieve a keytab for client2: # kinit -kt /etc/krb5.keytab host/`hostname`# ipa-getkeytab -s `hostname` -k /tmp/client2.keytab -p host/client2.example.comKeytab successfully retrieved and stored in: /tmp/client2.keytab
6.7.3. Delegating Host or Service Management in the Web UIEach host and service entry has a configuration tab that indicates what hosts have been delegated management control over that host or service. Open the Identity tab, and select the Hosts or Services subtab. Click the name of the host or service that you are going to grant delegated management to. Click the Hosts subtab on the far right of the host/service entry. This is the tab which lists hosts which can manage the selected host/service. Click the Add link at the top of the list. Click the checkbox by the names of the hosts to which to delegate management for the host/service. Click the right arrows button, >>, to move the hosts to the selection box. Click the Add button to close the selection box and to save the delegation settings.
6.7.4. Accessing Delegated ServicesFor both services and hosts, if a client has delegated authority, it can obtain a keytab for that principal on the local machine. For services, this has the format service/hostname@REALM. For hosts, the service is host. With kinit, use the -k option to load a keytab and the -t option to specify the keytab. 6.8. Managing Public SSH Keys for HostsOpenSSH uses public-private key pairs to authenticate hosts. One machine attempts to access another machine and presents its key pair. The first time the host authenticates, the administrator on the target machine has to approve the request manually. The machine then stores the host's public key in a known_hosts file. Any time that the remote machine attempts to access the target machine again, the target machine simply checks its known_hosts file and then grants access automatically to approved hosts. There are a few problems with this system: The known_hosts file stores host entries in a triplet of the host IP address, hostname, and key. This file can rapidly become out of date if the IP address changes (which is common in virtual environments and data centers) or if the key is updated. SSH keys have to be distributed manually and separately to all machines in an environment. Administrators have to approve host keys to add them to the configuration, but it is difficult to verify either the host or key issuer properly, which can create security problems.
On Red Hat Enterprise Linux, the System Security Services Daemon (SSSD) can be configured to cache and retrieve host SSH keys so that applications and services only have to look in one location for host keys. Because SSSD can use Identity Management as one of its identity information providers, Identity Management provides a universal and centralized repository of keys. Administrators do not need to worry about distributing, updating, or verifying host SSH keys. 6.8.1. About the SSH Key FormatWhen keys are uploaded to the IdM entry, the key format can be either an OpenSSH-style key or a raw RFC 4253-style blob. Any RFC 4253-style key is automatically converted into an OpenSSH-style key before it is imported and saved into the IdM LDAP server. The IdM server can identify the type of key, such as an RSA or DSA key, from the uploaded key blob. However, in a key file such as ~/.ssh/known_hosts, a key entry is identified by the hostname and IP address of the server, its type, then lastly the key itself. For example: host.example.com,1.2.3.4 ssh-rsa AAA...ZZZ== This is slightly different than a user public key entry, which has the elements in the order type key== comment: "ssh-rsa ABCD1234...== ipaclient.example.com" All three parts from the key file can be uploaded to and viewed for the host entry. In that case, the host public key entry from the ~/.ssh/known_hosts file needs to be reordered to match the format of a user key, type key== comment: ssh-rsa AAA...ZZZ== host.example.com,1.2.3.4 The key type can be determined automatically from the content of the public key, and the comment is optional, to make identifying individual keys easier. The only required element is the public key blob itself. 6.8.2. About ipa-client-install and OpenSSHThe ipa-client-install script, by default, configures an OpenSSH server and client on the IdM client machine. It also configures SSSD to perform host and user key caching. Essentially, simply configuring the client does all of the configuration necessary for the host to use SSSD, OpenSSH, and Identity Management for key caching and retrieval. There is an additional client configuration option, --ssh-trust-dns, which can be run with ipa-client-install and automatically configures OpenSSH to trust the IdM DNS records, where the host keys are stored. Alternatively, it is possible to disable OpenSSH at the time the client is installed, using the --no-sshd option. This prevents the install script from configuring the OpenSSH server. Another option, --no-dns-sshfp, prevents the host from creating DNS SSHFP records with its own DNS entries. This can be used with or without the --no-sshd option. 6.8.3. Uploading Host SSH Keys Through the Web UIThe key for a host can probably be retrieved from a ~/.ssh/known_hosts. For example: server.example.com,1.2.3.4 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEApvjBvSFSkTU0WQW4eOweeo0DZZ08F9Ud21xlLy6FOhzwpXFGIyxvXZ52+siHBHbbqGL5+14N7UvElruyslIHx9LYUR/pPKSMXCGyboLy5aTNl5OQ5EHwrhVnFDIKXkvp45945R7SKYCUtRumm0Iw6wq0XD4o+ILeVbV3wmcB1bXs36ZvC/M6riefn9PcJmh6vNCvIsbMY6S+FhkWUTTiOXJjUDYRLlwM273FfWhzHK+SSQXeBp/zIn1gFvJhSZMRi9HZpDoqxLbBB9QIdIw6U4MIjNmKsSI/ASpkFm2GuQ7ZK9KuMItY2AoCuIRmRAdF8iYNHBTXNfFurGogXwRDjQ== If necessary, generate a host key. When using the OpenSSH tools, make sure to use a blank passphrase and to save the key to a different location than the user's ~/.ssh/ directory, so it will not overwrite any existing keys. [jsmith@server ~]$ ssh-keygen -t rsa -C "server.example.com,1.2.3.4"Generating public/private rsa key pair.Enter file in which to save the key (/home/jsmith/.ssh/id_rsa): /home/jsmith/.ssh/host_keysEnter passphrase (empty for no passphrase):Enter same passphrase again:Your identification has been saved in /home/jsmith/.ssh/host_keys.Your public key has been saved in /home/jsmith/.ssh/host_keys.pub.The key fingerprint is:4f:61:ee:2c:f7:d7:da:41:17:93:de:1d:19:ac:2e:c8 server.example.comThe key's randomart image is:+--[ RSA 2048]----+| .. || .+|| o .* || o . .. *|| S + . o+|| E . .. .|| . = . o || o . ..o|| .....|+-----------------+ Copy the public key from the key file. The full key entry has the form hostname,IP type key==. Only the key== is required, but the entire entry can be stored. To use all elements in the entry, rearrange the entry so it has the order type key== [hostname,IP] [jsmith@server ~]$ cat /home/jsmith/.ssh/host_keys.pubssh-rsa AAAAB3NzaC1yc2E...tJG1PK2Mq++wQ== server.example.com,1.2.3.4 Open the Identity tab, and select the Hosts subtab. Click the name of the host to edit. In the Host Settings area of the Settings tab, click the SSH public keys: Add link. The UI opens a new link, New: key not set Show/Set key. Click the Show/Set key link. Paste in the public key for the host, and click the Set button. The SSH public keys field now shows New: key set. Clicking the Show/Set key link opens the submitted key. To upload multiple keys, click the Add link below the list of public keys, and upload the other keys. When all the keys have been submitted, click the Update link at the top of the host's page to save the changes.
When the public key is saved, the entry is displayed as the key fingerprint, the comment (if one was included), and the key type . After uploading the host keys, configure SSSD to use Identity Management as one of its identity domains and set up OpenSSH to use the SSSD tooling for managing host keys. This is covered in the Red Hat Enterprise Linux Deployment Guide. 6.8.4. Adding Host Keys from the Command LineHost SSH keys are added to host entries in IdM, either when the host is created using host-add or by modifying the entry later. Host keys are not created by the ipa-client-install command. Run the host-mod command with the --sshpubkey option to upload the 64 bit-encoded public key to the host entry. Adding a host key also changes the DNS SSHFP entry for the host, so also use the --updatedns option to update the host's DNS entry. For example: [jsmith@server ~]$ ipa host-mod --sshpubkey="ssh-rsa 12345abcde== ipaclient.example.com" --updatedns host1.example.com With a real key, the key is longer and usually ends with an equals sign (=). To upload multiple keys, pass a comma-separated list of keys with a single --sshpubkey option: --sshpubkey="12345abcde==,key2==,key3==" A host can have multiple public keys. After uploading the host keys, configure SSSD to use Identity Management as one of its identity domains and set up OpenSSH to use the SSSD tooling for managing host keys. This is covered in the Red Hat Enterprise Linux Deployment Guide.
6.8.5. Removing Host KeysHost keys can be removed once they expire or are no longer valid. To remove an individual host key, it is easiest to remove the key through the web UI: Open the Identity tab, and select the Hosts subtab. Click the name of the host to edit. Open the Host Settings area of the Settings tab. Click the Delete link by the fingerprint of the key to remove. Click the Update link at the top of the host's page to save the changes.
The command-line tools can be used to remove all keys. This is done by running ipa host-mod with the --sshpubkey= set to a blank value; this removes all public keys for the host. Also, use the --updatedns option to update the host's DNS entry. For example: [jsmith@server ~]$ kinit admin[jsmith@server ~]$ ipa host-mod --sshpubkey= --updatedns host1.example.com 6.9. Renaming Machines and Reconfiguring IdM Client ConfigurationThe hostname of a system is critical for the correct operation of Kerberos and SSL. Both of these security mechanisms rely on the hostname to ensure that communication is occurring between the specified hosts. Infrastructures which use virtual machines or clustered servers will commonly have hosts which are renamed because systems are copied, moved, or renamed. Red Hat Enterprise Linux does not provide a simple rename command to facilitate the renaming of an IdM host. Renaming a host in an IdM domain involves deleting the entry in IdM, uninstalling the client software, changing the hostname, and re-enrolling using the new name. Additionally, part of renaming hosts requires regenerating service principals. To reconfigure the client: Identify which services are running on the machine. These need to be re-created when the machine is re-enrolled. # ipa service-find server.example.com Each host has a default service which does not appear in the list of services. This service can be referred to as the "host service". The service principal for the host service is host/<hostname>, such as host/server.example.com. This principal can also be referred to as the host principal. Identify all host groups to which the machine belongs. # ipa hostgroup-find server.example.com Identify which of the services have certificates associated with them. This can be done using the ldapsearch command to check the entries in the IdM LDAP database directly: # ldapsearch -x -b "cn=accounts,dc=example,dc=com" "(&(objectclass=ipaservice)(userCertificate=*))" krbPrincipalName For any service principals (in addition to the host principal), determine the location of the corresponding keytabs on server.example.com. The keytab location is different for each service, and IdM does not store this information. Each service on the client system has a Kerberos principal in the form service name/hostname@REALM, such as ldap/[email protected]. Unenroll the client machine from the IdM domain: # ipa-client-install --uninstall For each identified keytab other than /etc/krb5.keytab, remove the old principals: # ipa-rmkeytab -k /path/to/keytab -r EXAMPLE.COM On another IdM machine, as an IdM administrator, remove the host entry. This removes all services and revokes all certificates issued for that host: # ipa host-del server.example.com At this point, the host is completely removed from IdM. Rename the machine. Re-enroll the system with IdM: # ipa-client-install This generates a host principal for with the new hostname in /etc/krb5.keytab. For every service that needs a new keytab, run the following command: # ipa service-add serviceName/new-hostname To generate certificates for services, use either certmonger or the IdM administration tools. Re-add the host to any applicable host groups.
6.10. Managing Host GroupsHost groups are a way of centralizing control over important management tasks, particularly access control. All groups in Identity Management are essentially static groups, meaning that the members of the group are manually and explicitly added to the group. Tangentially, IdM allows nested groups, where a group is a member of another group. In that case, all of the group members of the member group automatically belong to the parent group, as well. Because groups are easy to create, it is possible to be very flexible in what groups to create and how they are organized. Groups can be defined around organizational divisions like departments, physical locations, or IdM or infrastructure usage guidelines for access controls. 6.10.1. Creating Host Groups6.10.1.1. Creating Host Groups from the Web UIOpen the Identity tab, and select the Host Groups subtab. Click the Add link at the top of the groups list. Enter the name and a description for the group. Click the Add and Edit button to go immediately to the member selection page.
6.10.1.2. Creating Host Groups from the Command LineNew groups are created using the hostgroup-add command. (This adds only the group; members are added separately.) Two attributes are always required: the group name and the group description. If those attributes are not given as arguments, then the script prompts for them. $ ipa hostgroup-add groupName --desc="description" 6.10.2. Adding Group Members6.10.2.1. Adding Group Members from the Web UIOpen the Identity tab, and select the Host Groups subtab. Click the name of the group to which to add members. Click the Add link at the top of the task area. Click the checkbox by the names of the hosts to add, and click the right arrows button, >>, to move the hosts to the selection box. Click the Add button.
6.10.2.2. Adding Group Members from the Command LineMembers are added to a host group using the hostgroup-add-member command. This command can add both hosts as group members and other groups as group members. The syntax of the hostgroup-add-member command requires only the group name and a comma-separated list of hosts to add: $ ipa hostgroup-add-member groupName [--hosts=list] [--hostgroups=list] For example, this adds three hosts to the caligroup group: $ ipa hostgroup-add-member caligroup --hosts=ipaserver.example.com,client1.example.com,client2.example.com Group name: caligroup Description: for machines in california GID: 387115842 Member hosts: ipaserver.example.com,client1.example.com,client2.example.com-------------------------Number of members added 3------------------------- Likewise, other groups can be added as members, which creates nested groups: $ ipa hostgroup-add-member caligroup --groups=mountainview,sandiego Group name: caligroup Description: for machines in california GID: 387115842 Member groups: mountainview,sandiego ------------------------- Number of members added 2 ------------------------- 6.11. Troubleshooting Host Problems6.11.1. Certificate Not Found/Serial Number Not Found ErrorsThe IdM information is stored in a separate LDAP directory than the certificate information, and these two LDAP databases are replicated separately. It is possible for a replication agreement to be broken for one directory and working for another, which can cause problems with managing clients. Specifically, if the replication agreement between the two CA databases is broken, then a server may not be able to find certificate information about a valid IdM client, causing certificate errors: Certificate operation cannot be completed: EXCEPTION (Certificate serial number 0x2d not found) For example, an IdM server and replica have a function replication agreement between their IdM databases, but the replication agreement between their CA databases is broken. If a host is created on the server, the host entry is replicated over to the replica - but the certificate for that host is not replicated. The replica is aware of the client, but any management operations for that client will fail because the replica doesn't have a copy of its certificate. 6.11.2. Debugging Client Connection ProblemsClient connection problems are apparent immediately. This can mean that users cannot log into a machine or attempts to access user and group information fails (for example, getent passwd admin). Authentication in IdM is managed with the SSSD daemon, which is described in the Red Hat Enterprise Linux Deployment Guide. If there are problems with client authentication, then check the SSSD information. First, check the SSSD logs in /var/log/sssd/. There is a specific log file for the DNS domain, such as sssd_example.com.log. If there is not enough information in the logs at the default logging level, then increase the log level. To increase the log level: Open the sssd.conf file. vim /etc/sssd/sssd.conf In the [domain/example.com] section, set debug_level. debug_level = 9 Restart the sssd daemon. service sssd restart Check the /var/log/sssd/sssd_example.com.log file for the debug messages.
|
| |
