Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

5.3. Configuring a Linux System as an IdM Client

There are two elements to prepare before beginning the client setup process for the Red Hat Enterprise Linux client:
  • There must be a way to connect the client machine to the Kerberos domain, either by having an available Kerberos identity (such as the admin user) or by manually adding the client machine to the KDC on the server with a one-time password before beginning the enrollment process for the client machine.
  • If there is an Active Directory server on the same network that serves DNS records, the Active Directory DNS records could prevent the client from automatically detecting the IdM server address. The ipa-client-install script retrieves the Active Directory DNS records instead of any records that were added for IdM.
    In this case, it is necessary to pass the IdM server address directly to the ipa-client-install script.

5.3.1. Installing the Client (Full Example)

  1. Install the client packages. These packages provide a simple way to configure the system as a client; they also install and configure SSSD.
    For a regular user system, this requires only the ipa-client package:
    [root@client ~]# yum install ipa-client
    An administrator machine requires the ipa-admintools package, as well:
    [root@client ~]# yum install ipa-client ipa-admintools
  2. If the IdM server is configured as the DNS server and is in the same domain as the client, add the server's IP address as the first entry in the list of name servers in the client's /etc/resolv.conf file.

    Note

    If every machine in the domain will be an IdM client, then add the IdM server address to the DHCP configuration.
  3. Run the client setup command.
    [root@client ~]# ipa-client-install --enable-dns-updates
    The --enable-dns-updates option updates DNS with the client machine's IP address. This option should only be used if the IdM server was installed with integrated DNS or if the DNS server on the network accepts DNS entry updates with the GSS-TSIG protocol.
    Options for ipa-client-install are listed in the ipa-client-install manpage.
  4. If prompted, enter the domain name for the IdM DNS domain.
    DNS discovery failed to determine your DNS domain
    Please provide the domain name of your IPA server (ex: example.com): example.com
  5. If prompted, enter the fully-qualified domain name of the IdM server. Alternatively, use the --server option with the client installation script to supply the fully-qualified domain name of the IdM server.
    DNS discovery failed to find the IPA Server
    Please provide your IPA server name (ex: ipa.example.com): server.example.com

    Important

    This must be a valid DNS name, which means only numbers, alphabetic characters, and hyphens (-) are allowed. Other characters, like underscores, in the hostname will cause DNS failures.
  6. The client script then prompts for a Kerberos identity to use to contact and then join the Kerberos realm. When these credentials are supplied, then the client is able to join the IdM Kerberos domain and then complete the configuration:
    Continue to configure the system with these values? [no]: y 
    User authorized to enroll computers: admin 
    Synchronizing time with KDC... 
    Password for admin@EXAMPLE.COM: 
    Successfully retrieved CA cert 
    Subject: CN=Certificate Authority,O=EXAMPLE.COM 
    Issuer: CN=Certificate Authority,O=EXAMPLE.COM 
    Valid From: Tue Aug 13 09:29:07 2013 UTC 
    Valid Until: Sat Aug 13 09:29:07 2033 UTC 
    Enrolled in IPA realm EXAMPLE.COM 
    Created /etc/ipa/default.conf 
    New SSSD config will be created 
    Configured /etc/sssd/sssd.conf 
    Configured /etc/krb5.conf for IPA realm EXAMPLE.COM 
    Failed to update DNS records. 
    Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub 
    Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub 
    Could not update DNS SSHFP records. 
    SSSD enabled 
    Configured /etc/openldap/ldap.conf 
    NTP enabled 
    Configured /etc/ssh/ssh_config 
    Configured /etc/ssh/sshd_config 
    Client configuration complete.
  7. Test that the client can connect successfully to the IdM domain and can perform basic tasks. For example, check that the IdM tools can be used to get user and group information:
    [jsmith@client ~]$ id
    [jsmith@client ~]$ getent passwd admin
    [jsmith@client ~]$ getent group admins
  8. If an NFS server is already configured, then set NFS on the client system to work with Kerberos.
    An NFS server must already be configured within the domain. This is covered in Section 18.2, “Configuring Automount”.

    Note

    To help troubleshoot potential NFS setup errors, enable debug information in the /etc/sysconfig/nfs file.
    RPCGSSDARGS="-vvv"
    RPCSVCGSSDARGS="-vvv"
    1. On an IdM server, add an NFS service principal for the NFS client.
      [root@client ~]# kinit admin
      [root@client ~]# ipa service-add nfs/ipaclient.example.com@EXAMPLE

      Note

      This must be run from a machine with the ipa-admintools package installed so that the ipa command is available.
    2. On the IdM server, obtain a keytab for the NFS service principal.
      [root@client ~]# ipa-getkeytab -s server.example.com -p nfs/ipaclient.example.com@EXAMPLE -k /tmp/krb5.keytab
    3. Copy the keytab from the IdM server to the IdM client. For example:
      [root@client ~]# scp /tmp/krb5.keytab root@client.example.com:/etc/krb5.keytab
    4. Configure the /etc/exports file on the NFS server.
      /ipashare       gss/krb5p(rw,no_root_squash,subtree_check,fsid=0)
    5. Create the mount point.
      [root@client ~]# mkdir /mnt/ipashare
    6. On the client, mount the NFS share. Use the same -o sec setting as is used in the /etc/exports file for the NFS server.
      [root@client ~]# mount -v -t nfs4 -o sec=krb5p nfs.example.com:/ /mnt/ipashare

5.3.2. Examples of Other Client Installation Options

There are a number of different configuration options with the ipa-client-install command which can be used to configure the client system in different ways, depending on the infrastructure requirements.

Example 5.1. Enabling DNS Updates

Depending on the DHCP configuration, the IP addresses of clients can change with some regularity. If the IP address changes, this can cause discrepancies between the DNS records in the IdM server and the actual IP addresses in use, which could affect policies set within IdM and communications between clients and services.
The --enable-dns-updates option sets the System Security Services Daemon to update the DNS entries whenever the IP address for a client changes.
[root@client ~]# ipa-client-install --enable-dns-updates

Example 5.2. Specifying Domain Information

When just running the client installation command, the script prompts for required IdM domain information, including the name of an IdM server to register with, the DNS domain name, and the Kerberos realm and principal.
All of the basic information can be passed with the installation command (which is useful for automated installations).
  • --domain for the DNS domain name (which is only used if the IdM server is configured to host DNS services)
  • --server for the IdM server to register with (which can be any server or replica in the topology)
    This must be a valid DNS name, which means only numbers, alphabetic characters, and hyphens (-) are allowed. Other characters, like underscores, in the hostname will cause DNS failures.
  • --realm for the Kerbero realm name and, optionally, -p for a Kerberos principal name
[root@client ~]# ipa-client-install --domain EXAMPLE.COM --server server.example.com --realm EXAMPLE -p host/server.example.com

Example 5.3. Setting a Specific IdM Server

There can be multiple servers and replicas within the IdM server topology. When a client needs to connect to a server for updates or to retrieve user information, it (by default) uses a service scan to discover available servers and replicas in the domain. This means that the actual server to which the client connects is random, depending on the results of the discovery scan.
It is possible to set a specific server within the IdM domain which is used for client updates; if for some reason, connecting to that server fails, then the client can discover another server within the domain for failover.
The preferred server is set in the --fixed-primary option.
[root@client ~]# ipa-client-install --fixed-primary server.example.com

Example 5.4. Disabling System Authentication Tools

Red Hat Enterprise Linux uses the authconfig tool to set and update authentication clients and settings for a local system. Identity Management uses the System Security Services Daemon (SSSD) to store IdM server configuration and to retrieve policy information, users, passwords, and groups configured within the IdM domain.
It is strongly recommended that you use authconfig and SSSD to manage your user, group, and other IdM client configuration.
There may be some situations where an administrator wants to disable dynamic changes to system authentication configuration. In that case, it is possible to disable IdM from making updates to authconfig or SSSD.
The --noac option prevents any changes through authconfig. The --no-sssd option prevents IdM from using SSSD.
[root@client ~]# ipa-client-install --noac --no-sssd
A related option is --preserve-sssd. While this allows the client to change the SSSD configuration file to configure the IdM domain, it saves the old SSSD configuration.

Example 5.5. Disabling Password Caching

One of the primary functions of SSSD is password caching. Normally, when a system uses an external password store, authentication fails if that password store is ever inaccessible. However, SSSD can cache passwords after a successful authentication attempt and store those passwords locally. This allows users to log in and access domain services (which they have previously accessed) even if the IdM server is inaccessible.
In highly-secure environments, it may be necessary to prevent password caching to prevent potentially unauthorized access. In that case, the --no-krb5-offline-passwords option can be used to prevent passwords from being cached in SSSD.
[root@client ~]# ipa-client-install --no-krb5-offline-passwords