Red Hat Training

A Red Hat training course is available for RHEL 8

Configuring and managing Identity Management

Red Hat Enterprise Linux 8

Configuring, managing and maintaining Identity Management in Red Hat Enterprise Linux 8

Red Hat Customer Content Services

Abstract

This documentation collection provides instructions on how to effectively configure, manage and maintain Identity Management on Red Hat Enterprise Linux 8.

Providing feedback on Red Hat documentation

We appreciate your input on our documentation. Please let us know how we could make it better. To do so:

  • For simple comments on specific passages, make sure you are viewing the documentation in the Multi-page HTML format. Highlight the part of text that you want to comment on. Then, click the Add Feedback pop-up that appears below the highlighted text, and follow the displayed instructions.
  • For submitting more complex feedback, create a Bugzilla ticket:

    1. Go to the Bugzilla website.
    2. As the Component, use Documentation.
    3. Fill in the Description field with your suggestion for improvement. Include a link to the relevant part(s) of documentation.
    4. Click Submit Bug.

Chapter 1. Logging in to Identity Management from the command line

Identity Management (IdM) uses the Kerberos protocol to support single sign-on. Single sign-on means that the user enters the correct user name and password only once, and then accesses IdM services without the system prompting for the credentials again.

Important

In IdM, the System Security Services Daemon (SSSD) automatically obtains a ticket-granting ticket (TGT) for a user after the user successfully logs in to the desktop environment on an IdM client machine with the corresponding Kerberos principal name. This means that after logging in, the user is not required to use the kinit utility to access IdM resources.

If you have cleared your Kerberos credential cache or your Kerberos TGT has expired, you need to request a Kerberos ticket manually to access IdM resources. The following sections present basic user operations when using Kerberos in IdM.

1.1. Using kinit to log in to IdM manually

This procedure describes using the kinit utility to authenticate to an Identity Management (IdM) environment manually. The kinit utility obtains and caches a Kerberos ticket-granting ticket (TGT) on behalf of an IdM user.

Note

Only use this procedure if you have destroyed your initial Kerberos TGT or if it has expired. As an IdM user, when logging onto your local machine you are also automatically logging in to IdM. This means that after logging in, you are not required to use the kinit utility to access IdM resources.

Procedure

  1. To log in to IdM

    • under the user name of the user who is currently logged in on the local system, use kinit without specifying a user name. For example, if you are logged in as example_user on the local system:

      [example_user@server ~]$ kinit
      Password for example_user@EXAMPLE.COM:
      [example_user@server ~]$

      If the user name of the local user does not match any user entry in IdM, the authentication attempt fails:

      [example_user@server ~]$ kinit
      kinit: Client 'example_user@EXAMPLE.COM' not found in Kerberos database while getting initial credentials
    • using a Kerberos principal that does not correspond to your local user name, pass the required user name to the kinit utility. For example, to log in as the admin user:

      [example_user@server ~]$ kinit admin
      Password for admin@EXAMPLE.COM:
      [example_user@server ~]$
  2. Optionally, to verify that the login was successful, use the klist utility to display the cached TGT. In the following example, the cache contains a ticket for the example_user principal, which means that on this particular host, only example_user is currently allowed to access IdM services:

    $ klist
    Ticket cache: KEYRING:persistent:0:0
    Default principal: example_user@EXAMPLE.COM
    
    Valid starting     	Expires            	Service principal
    11/10/2019 08:35:45  	11/10/2019 18:35:45  	krbtgt/EXAMPLE.COM@EXAMPLE.COM

1.2. Destroying a user’s active Kerberos ticket

This section describes how to clear the credentials cache that contains the user’s active Kerberos ticket.

Procedure

  1. To destroy your Kerberos ticket:

    [example_user@server ~]$ kdestroy
  2. Optionally, to check that the Kerberos ticket has been destroyed:

    [example_user@server ~]$ klist
    klist: Credentials cache keyring 'persistent:0:0' not found

1.3. Configuring an external system for Kerberos authentication

This section describes how to configure an external system so that Identity Management (IdM) users can log in to IdM from the external system using their Kerberos credentials.

Enabling Kerberos authentication on external systems is especially useful when your infrastructure includes multiple realms or overlapping domains. It is also useful if the system has not been enrolled into any IdM domain through ipa-client-install.

To enable Kerberos authentication to IdM from a system that is not a member of the IdM domain, define an IdM-specific Kerberos configuration file on the external system.

Prerequisites

  • The krb5-workstation package is installed on the external system.

    To find out whether the package is installed, use the following CLI command:

    # yum list installed krb5-workstation
    Installed Packages
    krb5-workstation.x86_64    1.16.1-19.el8     @BaseOS

Procedure

  1. Copy the /etc/krb5.conf file from the IdM server to the external system. For example:

    # scp /etc/krb5.conf root@externalsystem.example.com:/etc/krb5_ipa.conf
    Warning

    Do not overwrite the existing krb5.conf file on the external system.

  2. On the external system, set the terminal session to use the copied IdM Kerberos configuration file:

    $ export KRB5_CONFIG=/etc/krb5_ipa.conf

    The KRB5_CONFIG variable exists only temporarily until you log out. To prevent this loss, export the variable with a different file name.

  3. Copy the Kerberos configuration snippets from the /etc/krb5.conf.d/ directory to the external system.

Users on the external system can now use the kinit utility to authenticate against the IdM server.

Additional resources

  • For details on Kerberos, see the krb5.conf(5), kinit(1), klist(1), and kdestroy(1) man pages.

Chapter 2. Viewing, starting and stopping the Identity Management services

Identity Management (IdM) servers are Red Hat Enterprise Linux systems that work as domain controllers (DCs). A number of different services are running on IdM servers, most notably the Directory Server, Certificate Authority (CA), DNS, and Kerberos.

2.1. Viewing the status of IdM services

To view the status of the IdM services that are configured on your IdM server:

[root@server ~]# ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
httpd Service: RUNNING
ntpd Service: RUNNING
pki-tomcatd Service: RUNNING
smb Service: RUNNING
winbind Service: RUNNING
ipa-otpd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
ipa: INFO: The ipactl command was successful

In the output above:

  • The Kerberos service is divided into two parts, krb5kdc and kadmin. The krb5kdc service is the Kerberos version 5 Authentication service and Key Distribution Center (KDC) deamon. The kadmin service is the Kerberos V5 database administration program.
  • The named service refers to the Internet domain name service (DNS).
  • pki is the Command-Line Interface for accessing Certificate System services. The pki-tomcatd program handles Identity Management operations related to certificates.

The output of the ipactl status command on your server depends on your IdM configuration. For example, if an IdM deployment does not include a DNS server, the named service is not present in the list.

Note

You cannot use the IdM web UI to view the status of all the IdM services running on a particular IdM server. Kerberized services running on different servers can be viewed in the IdentityServices tab of the IdM web UI.

You can start or stop the entire server, or an individual service only.

To start, stop, or restart the entire IdM server, see:

To start, stop, or restart an individual IdM service, see:

2.2. Starting and stopping the entire Identity Management server: the ipactl utility

Use the ipactl utility to stop, start, or restart the entire IdM server along with all the installed services. Using the ipactl utility ensures all services are stopped, started, or restarted in the appropriate order. You do not need to have a valid Kerberos ticket to run the ipactl commands.

ipactl commands

To start the entire IdM server:

# ipactl start

To stop the entire IdM server:

# ipactl stop

To restart the entire IdM server:

# ipactl restart

To show the status of all the services that make up IdM:

# ipactl status
Important

You cannot use the IdM web UI to perform the ipactl commands.

2.3. Starting and stopping an individual Identity Management service: the systemctl utility

Changing IdM configuration files manually is generally not recommended. However, certain situations require that an administrator performs a manual configuration of specific services. In such situations, use the systemctl utility to stop, start, or restart an individual IdM service.

For example, use systemctl after customizing the Directory Server behavior, without modifying the other IdM services:

# systemctl restart dirsrv@REALM-NAME.service

Also, when initially deploying an IdM trust with Active Directory, modify the /etc/sssd/sssd.conf file, adding:

  • specific parameters to tune the timeout configuration options in an environment where remote servers have a high latency
  • specific parameters to tune the Active Directory site affinity
  • overrides for certain configuration options that are not provided by the global IdM settings

To apply the changes you have made in the /etc/sssd/sssd.conf file:

# systemctl restart sssd.service

Running systemctl restart sssd.service is required because the System Security Services Daemon (SSSD) does not automatically re-read or re-apply its configuration.

Note that for changes that affect IdM identity ranges, a complete server reboot is recommended.

Important

To restart multiple IdM domain services, always use ipactl. Because of dependencies between the services installed with the IdM server, the order in which they are started and stopped is critical. The ipactl utility ensures that the services are started and stopped in the appropriate order.

Useful systemctl commands

To start a particular IdM service:

# systemctl start name.service

To stop a particular IdM service:

# systemctl stop name.service

To restart a particular IdM service:

# systemctl restart name.service

To view the status of a particular IdM service:

# systemctl status name.service
Important

You cannot use the IdM web UI to start or stop the individual services running on IdM servers. You can only use the web UI to modify the settings of a Kerberized service by navigating to IdentityServices and selecting the service.

Chapter 3. Introduction to the IdM command-line utilities

The following sections describe the basics of using the Identity Management (IdM) command-line utilities.

Prerequisites

3.1. What is the IPA command line interface

The IPA command line interface (CLI) is the basic command-line interface for Identity Management (IdM) administration.

It supports a lot of subcommands that are used to manage IdM, such as the ipa user-add command to add a new user.

IPA CLI allows you to:

  • Add, manage, or remove users, groups, hosts and other objects in the network.
  • Manage certificates.
  • Search entries.
  • Display and list objects.
  • Set access rights.
  • Get help with the correct command syntax.

3.2. What is the IPA help

The IPA help is a built-in documentation system for the IdM server.

IPA command line interface (CLI) generates available help topics from loaded IdM plugin modules. If you want to run the IPA help successfully, you need to:

  • Have an IdM server installed and running.
  • Be authenticated with a valid Kerberos ticket.

Executing the ipa help command without options displays information about basic help usage and the most common command examples.

Executing help with options has the following syntax:

$ ipa help [TOPIC | COMMAND | topics | commands]
  • [] — Brackets mean that all parameters are optional and you can write just ipa help and the command will be executed.
  • | — The pipe character means or. Therefore, you can use TOPIC or COMMAND or topics or commands with the basic ipa help command.
  • topics — You can run the command ipa help topics and it will execute correctly. The command displays a list of topics that are covered by IPA help, for example, user, cert, server and many others.
  • TOPIC — The TOPIC with capital letters means variable, therefore, you can use the particular topic, for example, ipa help user
  • commands — You can run the command ipa help commands and it will execute correctly. The command displays a list of commands which are covered by the IPA help, for example, user-add, ca-enable, server-show and many others.
  • COMMAND — The COMMAND with capital letters means variable, therefore, you can use the particular command, for example, ipa help user-add

3.3. Using IPA help topics

The following procedure helps you to understand using the IPA help in the command line interface.

Procedure

  1. Open terminal and connect to the IdM server.
  2. Enter ipa help topics to display a list of topics covered by help.

    $ ipa help topics
  3. Select one of the topics and create a command according to the following pattern: ipa help [topic_name], instead of the topic_name string, add one of the topics you listed in the previous step.

    In the example, we use the following topic: user

    $ ipa help user
  4. If the IPA help command is too long and you cannot see the whole text, use the following syntax:

    $ ipa help user | less

    You can then scroll down and read the whole help.

The IPA CLI displays a help page for the user topic. After reading the overview, you can see many examples with patterns for working with topic commands.

3.4. Using IPA help commands

The following procedure helps you to understand creating the IPA help commands in the command line interface.

Procedure

  1. Open terminal and connect to the IdM server.
  2. Enter ipa help commands to display a list of commands covered by help.

    $ ipa help commands
  3. Select one of the commands and create a help command according to the following pattern: ipa help <COMMAND>, instead of the <COMMAND> string, add one of the commands you listed in the previous step.

    $ ipa help user-add

Additional resources

  • For details, see man ipa page.

3.5. Structure of IPA commands

The IPA CLI distinguishes the following types of commands:

  • Built-in commands — Built-in commands are all available in the IdM server.
  • Plug-in provided commands

Structure of IPA commands allows you to manage various types of objects. For example:

  • Users,
  • Hosts,
  • DNS records,
  • Certificates,

and many others.

For most of these objects, the IPA CLI includes commands to:

  • Add (add)
  • Modify (mod)
  • Delete (del)
  • Search (find)
  • Display (show)

Commands have the following structure:

ipa user-add, ipa user-mod, ipa user-del, ipa user-find, ipa user-show

ipa host-add, ipa host-mod, ipa host-del, ipa host-find, ipa host-show

ipa dnsrecord-add, ipa dnsrecord-mod, ipa dnsrecord-del, ipa dnsrecord-find, ipa dnrecord-show

You can create a user with the ipa user-add [options], where [options] are optional. If you use just the ipa user-add command, the script asks you for details one by one.

To change an existing object, you need to define the object, therefore the command includes also object: ipa user-mod USER_NAME [options].

3.6. Using an IPA command to add a user account to IdM

The following describes adding a new user to the Identity Management database using command line. .Prerequisites

  • You need to have administrator privileges to add user accounts to the IdM server.

Procedure

  1. Open terminal and connect to the IdM server.
  2. Enter the command for adding a new user:

    $ ipa user-add

    The command runs a script where you can add basic data necessary for creating a user account.

  3. In the First name: field, enter the first name of the new user and press the Enter key.
  4. In the Last name: field, enter the last name of the new user and press the Enter key.
  5. In the User login [suggested user name]: enter the user name or just press the Enter key if the suggested user name works for you.

    User name must be unique for the whole IdM database. If an error occurs, that the user already exists, you need to start from the beginning with the ipa user-add command and try a different user name.

After you successfully added the user name, the user account has been added to the IdM database and the IPA CLI prints on the output the following log:

----------------------
Added user "euser"
----------------------
User login: euser
First name: Example
Last name: User
Full name: Example User
Display name: Example User
Initials: EU
Home directory: /home/euser
GECOS: Example User
Login shell: /bin/sh
Principal name: euser@IDM.EXAMPLE.COM
Principal alias: euser@IDM.EXAMPLE.COM
Email address: euser@idm.example.com
UID: 427200006
GID: 427200006
Password: False
Member of groups: ipausers
Kerberos keys available: False

As you can see, a user password is not set to the user account. If you want to add also password, use the ipa user-add command in the following syntax:

$ ipa user-add --first=Example --last=User --password

The IPA CLI then asks you for adding or confirming a user name and password.

If the user has been already created, you can add only the password with the `ipa user-mod`command.

Additional resources

For more information about parameters, enter the following help command to the command line:

$ ipa help user-add

3.7. Using an IPA command to modify a user account in IdM

You can change many parameters for each user account. For example, you can add a new password to the user.

Basic command syntax is different from the user-add syntax because you need to define the existing user account for which you want to perform changes, for example, add a password.

Prerequisites

  • You need to have administrator privileges to modify user accounts in the IdM server.

Procedure

  1. Open terminal and connect to the IdM server.
  2. Enter the command for adding a password:

    $ ipa user-mod euser --password

    The command runs a script where you can add the new password.

  3. Enter the new password and press the Enter key.

After you successfully added the user name, the user account has been added to the IdM database and the IPA CLI prints on the output the following log:

----------------------
Modified user "euser"
----------------------
User login: euser
First name: Example
Last name: User
Home directory: /home/euser
Principal name: euser@IDM.EXAMPLE.COM
Principal alias: euser@IDM.EXAMPLE.COM
Email address: euser@idm.example.com
UID: 427200006
GID: 427200006
Password: True
Member of groups: ipausers
Kerberos keys available: True

The user password is now set for the account and the user can log into IdM.

Additional resources

For more information about parameters, enter the following help command to the command line:

$ ipa help user-mod

3.8. How to supply a list of values to the IdM utilities

Identity Management (IdM) stores values for multi-valued attributes in lists.

IdM supports the following methods of supplying multi-valued lists:

  • Using the same command-line argument multiple times within the same command invocation:

    $ ipa permission-add --right=read --permissions=write --permissions=delete ...
  • Alternatively, you can enclose the list in curly braces, in which case the shell performs the expansion:

    $ ipa permission-add --right={read,write,delete} ...

Examples above show a command permission-add which adds permissions to an object. The object is not mentioned in the example. Instead of …​ you need to add the object for which you want to add permissions.

When you update such multi-valued attributes from the command line, IdM completely overwrites the previous list of values with a new list. Therefore, when updating a multi-valued attribute, you must specify the whole new list, not just a single value you want to add.

In the command above, the list of permissions includes reading, writing and deleting. When you decide to update the list with the permission-mod command, you must add all values, otherwise those not mentioned will be deleted.

Example 1: — The ipa permission-mod command updates all previously added permissions.

$ ipa permission-mod --right=read --right=write --right=delete ...

or

$ ipa permission-mod --right={read,write,delete} ...

Example 2 — The ipa permission-mod command deletes the --right=delete argument because it is not included in the command:

$ ipa permission-mod --right=read --right=write ...

or

$ ipa permission-mod --right={read,write} ...

3.9. How to use special characters with the IdM utilities

When passing command-line arguments that include special characters to the ipa commands, escape these characters with a backslash (\). For example, common special characters include angle brackets (< and >), ampersand (&), asterisk (*), or vertical bar (|).

For example, to escape an asterisk (*):

$ ipa certprofile-show certificate_profile --out=exported\*profile.cfg

Commands containing unescaped special characters do not work as expected because the shell cannot properly parse such characters.

Chapter 4. Searching Identity Management entries from the command line

The following sections describe how to use IPA commands, which helps you to find or show objects.

4.1. Overview of listing IdM entries

This section describes the ipa *-find commands, which can help you to search for a particular type of IdM entries.

To list all the find commands, use the following ipa help command:

$ ipa help commands | grep find

You may need to check if a particular user is included in the IdM database. You can then list all users with the following command:

$ ipa user-find

To list user groups whose specified attributes contain a keyword:

$ ipa group-find keyword

For example the ipa group-find admin command lists all groups whose names or descriptions include string admin:

----------------
3 groups matched
----------------
   Group name: admins
   Description: Account administrators group
   GID: 427200002

   Group name: editors
   Description: Limited admins who can edit other users
   GID: 427200002

   Group name: trust admins
   Description: Trusts administrators group

When searching user groups, you can also limit the search results to groups that contain a particular user:

$ ipa group-find --user=user_name

To search for groups that do not contain a particular user:

$ ipa group-find --no-user=user_name

4.2. Showing details for a particular entry

Use the ipa *-show command to display details about a particular IdM entry.

Procedure

  • To display details about a host named server.example.com:

    $ ipa host-show server.example.com
    
    Host name: server.example.com
    Principal name: host/server.example.com@EXAMPLE.COM
    ...

4.3. Adjusting the search size and time limit

Some queries, such as requesting a list of IdM users, can return a very large number of entries. By tuning these search operations, you can improve the overall server performance when running the ipa *-find commands, such as ipa user-find, and when displaying corresponding lists in the Web UI.

Search size limit

Defines the maximum number of entries returned for a request sent to the server from a client’s CLI or from a browser accessing the IdM Web UI.

Default: 100 entries.

Search time limit

Defines the maximum time (in seconds) that the server waits for searches to run. Once the search reaches this limit, the server stops the search and returns the entries discovered in that time.

Default: 2 seconds.

If you set the values to -1, IdM will not apply any limits when searching.

Important

Setting search size or time limits too high can negatively affect server performance.

4.3.1. Adjusting the search size and time limit in the command line

The following text describes adjusting search size and time limits in the command line:

  • Globally
  • For a specific entry

Procedure

  1. To display current search time and size limits in CLI, use the ipa config-show command:

    $ ipa config-show
    
    Search time limit: 2
    Search size limit: 100
  2. To adjust the limits globally for all queries, use the ipa config-mod command and add the --searchrecordslimit and --searchtimelimit options. For example:

    $ ipa config-mod --searchrecordslimit=500 --searchtimelimit=5
  3. To adjust the limits only for a specific query, add the --sizelimit or --timelimit options to the command. For example:
$ ipa user-find --sizelimit=200 --timelimit=120

4.3.2. Adjusting the search size and time limit in the Web UI

The following text describes adjusting search size and time limits in the IdM Web UI:

  • Globally
  • For a specific entry

Procedure

To adjust the limits globally for all queries:

  1. Log in to the IdM Web UI.
  2. Click IPA Server.

    web ui ipaserver

  3. On the IPA Server tab, click Configuration.
  4. Set the required values in the Search Options area.

    Default values are:

    • Search size limit: 100 entries
    • Search time limit: 2 seconds
  5. Click Save at the top of the page.

    web ui search limits

After saving the values, search an entry and verify the result.

Chapter 5. Accessing the IdM Web UI in a web browser

The following sections provide an overview of the IdM (Identity Management) Web UI and describe how to access it.

5.1. What is the IdM Web UI

The IdM (Identity Management) Web UI is a web application for IdM administration, a graphical alternative to the IdM command line tools.

You can access the IdM Web UI as:

  • IdM users: A limited set of operations depending on permissions granted to the user in the IdM server. Basically, active IdM users can log in to the IdM server and configure their own account. They cannot change settings of other users or the IdM server settings.
  • Administrators: Full access rights to the IdM server.
  • Active Directory users: A limited set of operations depending on permissions granted to the user.

    Active Directory users cannot be administrators for Identity Management.

5.2. Web browsers supported for accessing the Web UI

IdM (Identity Management) supports the following browsers for connecting to the Web UI:

  • Mozilla Firefox 38 and later
  • Google Chrome 46 and later

5.3. Accessing the Web UI

The following procedure describes the first logging in to the IdM (Identity Management) Web UI with a password.

After the first login you can configure your IdM server to authenticate with:

Procedure

  1. Type an IdM server URL into the browser address bar. The name will look similarly to the following example:

    https://server.example.com

    You just need to change server.example.com with a DNS name of your IdM server.

    This opens the IdM Web UI login screen in your browser.

    web ui login screen

    • If the server does not respond or the login screen does not open, check the DNS settings on the IdM server to which you are connecting.
    • If you use a self-signed certificate, the browser issues a warning. Check the certificate and accept the security exception to proceed with the login.

      To avoid security exceptions, install a certificate signed by a certificate authority.

  2. On the Web UI login screen, enter the administrator account credentials you added during the IdM server installation.

    For details, see Installing an Identity Management server: With integrated DNS, with an integrated CA.

    You can enter your personal account credentials as well if they are already entered in the IdM server.

    web ui login passwd

  3. Click Log in.

After the successful login, you can start configuring the IdM server.

web ui users

Chapter 6. Logging in to IdM in the Web UI: Using a Kerberos ticket

The following sections describe the initial configuration of your environment to enable Kerberos login to the IdM Web UI and accessing IdM using Kerberos authentication.

Prerequisites

6.1. Kerberos authentication in Identity Management

Identity Management (IdM) uses the Kerberos protocol to support single sign-on. Single sign-on authentication allows you to provide the correct user name and password only once, and you can then access Identity Management services without the system prompting for credentials again.

The IdM server provides Kerberos authentication immediately after the installation if the DNS and certificate settings have been configured properly. For details, see Installing Identity Management.

To use Kerberos authentication on hosts, install:

6.2. Using kinit to log in to IdM manually

This procedure describes using the kinit utility to authenticate to an Identity Management (IdM) environment manually. The kinit utility obtains and caches a Kerberos ticket-granting ticket (TGT) on behalf of an IdM user.

Note

Only use this procedure if you have destroyed your initial Kerberos TGT or if it has expired. As an IdM user, when logging onto your local machine you are also automatically logging in to IdM. This means that after logging in, you are not required to use the kinit utility to access IdM resources.

Procedure

  1. To log in to IdM

    • under the user name of the user who is currently logged in on the local system, use kinit without specifying a user name. For example, if you are logged in as example_user on the local system:

      [example_user@server ~]$ kinit
      Password for example_user@EXAMPLE.COM:
      [example_user@server ~]$

      If the user name of the local user does not match any user entry in IdM, the authentication attempt fails:

      [example_user@server ~]$ kinit
      kinit: Client 'example_user@EXAMPLE.COM' not found in Kerberos database while getting initial credentials
    • using a Kerberos principal that does not correspond to your local user name, pass the required user name to the kinit utility. For example, to log in as the admin user:

      [example_user@server ~]$ kinit admin
      Password for admin@EXAMPLE.COM:
      [example_user@server ~]$
  2. Optionally, to verify that the login was successful, use the klist utility to display the cached TGT. In the following example, the cache contains a ticket for the example_user principal, which means that on this particular host, only example_user is currently allowed to access IdM services:

    $ klist
    Ticket cache: KEYRING:persistent:0:0
    Default principal: example_user@EXAMPLE.COM
    
    Valid starting     	Expires            	Service principal
    11/10/2019 08:35:45  	11/10/2019 18:35:45  	krbtgt/EXAMPLE.COM@EXAMPLE.COM

6.3. Configuring the browser for Kerberos authentication

To enable authentication with a Kerberos ticket, you may need a browser configuration.

The following steps help you to support Kerberos negotiation for accessing the IdM domain.

Each browser supports Kerberos in a different way and needs different set up. The IdM Web UI includes guidelines for the following browsers:

  • Firefox
  • Chrome

Procedure

  1. Open the IdM Web UI login dialog in your web browser.
  2. Click the link for browser configuration on the Web UI login screen.

    ipa browser config link

  3. Follow the steps on the configuration page.

    ipa browser config page

After the setup, turn back to the IdM Web UI and click Log in.

6.4. Logging in to the web UI using a Kerberos ticket

This procedure describes logging in to the IdM Web UI using a Kerberos ticket-granting ticket (TGT).

The TGT expires at a predefined time. The default time interval is 24 hours and you can change it in the IdM Web UI.

After the time interval expires, you need to renew the ticket:

  • Using the kinit command.
  • Using IdM login credentials in the Web UI login dialog.

Procedure

  • Open the IdM Web UI.

    If Kerberos authentication works correctly and you have a valid ticket, you will be automatically authenticated and the Web UI opens.

    If the ticket is expired, it is necessary to authenticate yourself with credentials first. However, next time the IdM Web UI will open automatically without opening the login dialog.

    If you see an error message Authentication with Kerberos failed, verify that your browser is configured for Kerberos authentication. See Section 6.3, “Configuring the browser for Kerberos authentication”.

    firefox kerb auth failed

6.5. Configuring an external system for Kerberos authentication

This section describes how to configure an external system so that Identity Management (IdM) users can log in to IdM from the external system using their Kerberos credentials.

Enabling Kerberos authentication on external systems is especially useful when your infrastructure includes multiple realms or overlapping domains. It is also useful if the system has not been enrolled into any IdM domain through ipa-client-install.

To enable Kerberos authentication to IdM from a system that is not a member of the IdM domain, define an IdM-specific Kerberos configuration file on the external system.

Prerequisites

  • The krb5-workstation package is installed on the external system.

    To find out whether the package is installed, use the following CLI command:

    # yum list installed krb5-workstation
    Installed Packages
    krb5-workstation.x86_64    1.16.1-19.el8     @BaseOS

Procedure

  1. Copy the /etc/krb5.conf file from the IdM server to the external system. For example:

    # scp /etc/krb5.conf root@externalsystem.example.com:/etc/krb5_ipa.conf
    Warning

    Do not overwrite the existing krb5.conf file on the external system.

  2. On the external system, set the terminal session to use the copied IdM Kerberos configuration file:

    $ export KRB5_CONFIG=/etc/krb5_ipa.conf

    The KRB5_CONFIG variable exists only temporarily until you log out. To prevent this loss, export the variable with a different file name.

  3. Copy the Kerberos configuration snippets from the /etc/krb5.conf.d/ directory to the external system.
  4. Configure the browser on the external system, as described in Section 6.3, “Configuring the browser for Kerberos authentication”.

Users on the external system can now use the kinit utility to authenticate against the IdM server.

6.6. Web UI login for Active Directory users

To enable Web UI login for Active Directory users, define an ID override for each Active Directory user in the default trust view. For example:

[admin@server ~]$ ipa idoverrideuser-add 'Default Trust View' ad_user@ad.example.com

Chapter 7. Logging in to the Identity Management Web UI using one time passwords

Access to IdM Web UI can be secured using several methods. The basic one is password authentication.

To increase the security of password authentication, you can add a second step and require automatically generated one-time passwords (OTPs). The most common usage is to combine password connected with the user account and a time limited one time password generated by a hardware or software token.

The following sections help you to:

  • Understand how the OTP authentication works in IdM.
  • Configure OTP authentication on the IdM server.
  • Create OTP tokens and synchronize them with the FreeOTP app in your phone.
  • Authenticate to the IdM Web UI with the combination of user password and one time password.
  • Re-synchronize tokens in the Web UI.

7.1. Prerequisites

7.2. One time password (OTP) authentication in Identity Management

One-time passwords bring an additional step to your authentication security. The authentication uses your password + an automatically generated one time password.

To generate one time passwords, you can use a hardware or software token. IdM supports both software and hardware tokens.

Identity Management supports the following two standard OTP mechanisms:

  • The HMAC-Based One-Time Password (HOTP) algorithm is based on a counter. HMAC stands for Hashed Message Authentication Code.
  • The Time-Based One-Time Password (TOTP) algorithm is an extension of HOTP to support time-based moving factor.
Important

IdM does not support OTP logins for Active Directory trust users.

7.3. Enabling the one time password in the Web UI

The IdM Web UI allows you to configure hardware or software device to generate one-time passwords.

The one time password is entered just after the usual password in the dedicated field in the login dialog.

Only administrators can enable OTP authentication in the user settings.

Prerequisites

  • Administration privileges

Procedure

  1. Log in to the IdM Web UI with your username and password.
  2. Open the Identity → Users → Active users tab.

    web ui users

  3. Click your username to open the user settings.
  4. In the User authentication types, select Two factor authentication (password + OTP).
  5. Click Save.

At this point, the OTP authentication is enabled on the IdM server.

Now you or users themselves need to assign a new token ID to the user account.

7.4. Adding OTP tokens in the Web UI

The following section helps you to add token to the IdM Web UI and to your software token generator.

Prerequisites

  • Active user account on the IdM server.
  • Administrator has enabled OTP for the particular user account in the IdM Web UI.
  • A software device generating OTP tokens, for example FreeOTP.

Procedure

  1. Log in to the IdM Web UI with your user name and password.
  2. To create the token in your mobile phone, open the Authentication → OTP Tokens tab.
  3. Click Add.

    web ui tokens tab

  4. In the Add OTP token dialog box, leave everything unfilled and click Add.

    At this stage, the IdM server creates a token with default parameters at the server and opens a page with a QR code.

  5. Copy the QR code into your mobile phone.
  6. Click OK to close the QR code.

Now you can generate one time passwords and log in with them to the IdM Web UI.

freeotp token

7.5. Logging into the Web UI with a one time password

This procedure describes the first login into the IdM Web UI using a one time password (OTP).

Prerequisites

  • OTP configuration enabled on the Identity Management server for the user account you are using for the OTP authentication. Administrators as well as users themselves can enable OTP.

    To enable the OTP configuration, see Section 7.3, “Enabling the one time password in the Web UI”

  • A hardware or software device generating OTP tokens configured.

Procedure

  1. In the Identity Management login screen, enter your user name or a user name of the IdM server adminisntrator account.
  2. Add the password for the user name entered above.
  3. Generate a one time password on your device.
  4. Enter the one time password right after the password (without space).
  5. Click Log in.

    If the authentication fails, synchronize OTP tokens.

    If your CA uses a self-signed certificate, the browser issues a warning. Check the certificate and accept the security exception to proceed with the login.

    If the the IdM Web UI does not open, verify the DNS configuration of your Identity Management server.

After successful login, the IdM Web UI appears.

web ui users

7.6. Synchronizing OTP tokens using the Web UI

If the login with OTP (One Time Password) fails, OTP tokens are not synchronized correctly.

The following text describes token re-synchronization.

Prerequisites

  • A login screen opened.
  • A device generating OTP tokens configured.

Procedure

  1. On the IdM Web UI login screen, click Sync OTP Token.

    web ui login otp link

  2. In the login screen, enter your username and the Identity Management password.
  3. Generate one time password and enter it in the First OTP field.
  4. Generate another one time password and enter it in the Second OTP field.
  5. Optionally, enter the token ID.

    web ui login otp configuration

  6. Click Sync OTP Token.

After the successful synchronization, you can log in to the IdM server.

7.7. Changing expired passwords

Administrators of Identity Management can enforce you having to change your password at the next login. It means that you cannot successfully log in to the IdM Web UI until you change the password.

Password expiration can happen during your first login to the Web UI.

If the expiration password dialog appears, follow the instructions in the procedure.

Prerequisites

  • A login screen opened.
  • Active account to the IdM server.

Procedure

  1. In the password expiration login screen, enter the user name.
  2. Add the password for the user name entered above.
  3. In the OTP field, generate a one time password, if you use the one time password authentication.

    If you do not have enabled the OTP authentication, leave the field empty.

  4. Enter the new password twice for verification.
  5. Click Reset Password.

    web ui passwd expiration

After the successful password change, the usual login dialog displays. Log in with the new password.

Chapter 8. Managing user accounts using the IdM Web UI

Identity Management (IdM) provides several stages that can help you to manage various user work life situations:

Creating a user account

Creating a stage user account before an employee starts their career in your company and be prepared in advance for the day when the employee appears in the office and want to activate the account.

You can omit this step and create the active user account directly. The procedure is similar to creating a stage user account.

Activating a user account
Activating the account the first working day of the employee.
Disabling a user account
If the user go to a parental leave for couple of months, you will need to disable the account temporarily.
Enabling a user account
When the user returns, you will need to re-enable the account.
Preserving a user account
If the user wants to leave the company, you will need to delete the account with a possibility to restore it because people can return to the company after some time.
Restoring a user account
Two years later, the user is back and you need to restore the preserved account.
Deleting a user account
If the employee the employee is dismissed you will delete the account without a backup.

8.1. User life cycle

IdM (Identity Management) supports three user account states:

  • Stage users are not allowed to authenticate. This is an initial state. Some of the user account properties required for active users cannot be set, for example, group membership.
  • Active users are allowed to authenticate. All required user account properties must be set in this state.
  • Preserved users are former active users that are considered inactive and cannot authenticate to IdM. Preserved users retain most of the account properties they had as active users, but they are not part of any user groups.

idm user lifecycle

You can delete user entries permanently from the IdM database.

Important

Deleted user accounts cannot be restored. When you delete a user account, all the information associated with the account is permanently lost.

A new administrator can only be created by a user with administrator rights, such as the default admin user. If you accidentally delete all administrator accounts, the Directory Manager must create a new administrator manually in the Directory Server.

8.2. Adding users in the Web UI

Usually, you need to create a new user account before a new employee starts to work. Such a stage account is not accessible and you need to activate it later.

Note

Alternatively, you can create an active user account directly. For adding active user, follow the procedure below and add the user account in the Active users tab.

Prerequisites

  • Administrator privileges for managing IdM or User Administrator role.

Procedure

  1. Log in to the IdM Web UI.

    For details, see Accessing the IdM Web UI in a web browser.

  2. Go to Users → Stage Users tab.

    Alternatively, you can add the user account in the Users → Active users, however, you cannot add user groups to the account.

  3. Click the + Add icon.
  4. In the Add stage user dialog box, enter First name and Last name of the new user.
  5. [Optional] In the User login field, add a login name.

    If you leave it empty, the IdM server creates the login name in the following pattern: The first letter of the first name and the surname. The whole login name can have up to 32 characters.

  6. [Optional] In the GID drop down menu, select groups in which the user should be included.
  7. [Optional] In the Password and Verify password fields,
  8. Click on the Add button.

    idm user add stage

At this point, you can see the user account in the Stage Users table.

idm users stage

Note

If you click on the user name, you can edit advanced settings, such as adding a phone number, address, or occupation.

8.3. Activating stage users in the IdM Web UI

A stage user account must be activated before the user can log in to IdM and before the user can be added to an IdM group. This section describes how to activate stage user accounts.

Prerequisites

  • Administrator privileges for managing the IdM Web UI or User Administrator role.
  • At least one staged user account in IdM.

Procedure

  1. Log in to the IdM Web UI.

    For details, see Accessing the IdM Web UI in a web browser.

  2. Go to Users → Stage users tab.
  3. Click the check-box of the user account you want to activate.
  4. Click on the Activate button.

    idm users stage

  5. In the Confirmation dialog box, click on the OK button.

If the activation is successfull, the IdM Web UI displays a green confirmation that the user has been activated and the user account has been moved to Active users. The account is active and the user can authenticate to the IdM domain and IdM Web UI. The user is prompted to change their password on the first login.

idm users stage activated

Note

At this stage, you can add the active user account to user groups.

8.4. Disabling user accounts in the Web UI

You can disable active user accounts. Disabling a user account deactivates the account, therefore, user accounts cannot be used to authenticate and using IdM services, such as Kerberos, or perform any tasks.

Disabled user accounts still exist within IdM and all of the associated information remains unchanged. Unlike preserved user accounts, disabled user accounts remain in the active state and can be a member of user groups.

Note

After disabling a user account, any existing connections remain valid until the user’s Kerberos TGT and other tickets expire. After the ticket expires, the user will not be able to renew it.

Prerequisites

  • Administrator privileges for managing the IdM Web UI or User Administrator role.

Procedure

  1. Log in to the IdM Web UI.

    For details, see Accessing the IdM Web UI in a web browser.

  2. Go to Users → Active users tab.
  3. Click the check-box of the user accounts you want to disable.
  4. Click on the Disable button.

    idm users disable

  5. In the Confirmation dialog box, click on the OK button.

If the disabling procedure has been successful, you can verify in the Status column in the Active users table.

idm users disabled

8.5. Enabling user accounts in the Web UI

ith IdM you can enable disabled active user accounts. Enabling a user account activates the disabled account.

Prerequisites

  • Administrator privileges for managing the IdM Web UI or User Administrator role.

Procedure

  1. Log in to the IdM Web UI.
  2. Go to Users → Active users tab.
  3. Click the check-box of the user accounts you want to enable.
  4. Click on the Enable button.

    idm users disable

  5. In the Confirmation dialog box, click on the OK button.

If the change has been successful, you can verify in the Status column in the Active users table.

8.6. Preserving active users in the IdM Web UI

Preserving user accounts enables you to remove accounts from the Active users tab, yet keeping these accounts in IdM.

Preserve the user account if the employee leaves the company. If you want to disable user accounts for a couple of weeks or months (parental leave, for example), disable the account. For details, see Section 8.4, “Disabling user accounts in the Web UI”. The preserved accounts are not active and users cannot use them to access your internal network, however, the account stays in the database with all the data.

You can move the restored accounts back to the active mode.

Note

The list of users in the preserved state can provide a history of past user accounts.

Prerequisites

  • Administrator privileges for managing the IdM (Identity Management) Web UI or User Administrator role.

Procedure

  1. Log in to the IdM Web UI.

    For details, see Accessing the IdM Web UI in a web browser.

  2. Go to Users → Active users tab.
  3. Click the check-box of the user accounts you want to preserve.
  4. Click on the Delete button.

    idm users active delete

  5. In the Remove users dialog box, switch the Delete mode radio button to preserve.
  6. Click on the Delete button.

    idm users preserving

As a result, the user account is moved to Preserved users.

If you need to restore preserved users, see the Restoring users in the IdM Web UI.

8.7. Restoring users in the IdM Web UI

IdM (Identity Management) enables you to restore preserved user accounts back in the active state.

Prerequisites

  • Administrator privileges for managing the IdM Web UI or User Administrator role.

Procedure

  1. Log in to the IdM Web UI.

    For details, see Accessing the IdM Web UI in a web browser.

  2. Go to Users → Preserved users tab.
  3. Click the check-box at the user accounts you want to restore.
  4. Click on the Restore button.

    idm users preserved restore

  5. In the Confirmation dialog box, click on the OK button.

The IdM Web UI displays a green confirmation and moves the user accounts to the Active users tab.

8.8. Deleting users in the IdM Web UI

Deleting users is an irreversible operation, causing the user accounts to be permanently deleted from the IdM database, including group memberships and passwords. Any external configuration for the user, such as the system account and home directory, is not deleted, but is no longer accessible through IdM.

You can delete:

  • Active users — the IdM Web UI offers you with the options:

  • Stage users — you can just delete stage users permanently.
  • Preserved users — you can delete preserved users permanently.

The following procedure describes deleting active users. Similarly, you can delete user accounts on:

  • The Stage users tab
  • The Preserved users tab

Prerequisites

  • Administrator privileges for managing the IdM Web UI or User Administrator role.

Procedure

  1. Log in to the IdM Web UI.

    For details, see Accessing the IdM Web UI in a web browser.

  2. Go to Users → Active users tab.

    Alternatively, you can delete the user account in the Users → Stage users or Users → Preserved users.

  3. Click the Delete icon.
  4. In the Remove users dialog box, switch the Delete mode radio button to delete.
  5. Click on the Delete button.

The users accounts have been permanently deleted from IdM.

Chapter 9. Managing user accounts using the command line

This chapter includes basic description of user life cycle in IdM (Identity Management). The following sections show you how to:

  • Create user accounts
  • Activate stage user accounts
  • Preserve user accounts
  • Delete active, stage, or preserved user accounts
  • Restore preserved user accounts

9.1. User life cycle

IdM (Identity Management) supports three user account states:

  • Stage users are not allowed to authenticate. This is an initial state. Some of the user account properties required for active users cannot be set, for example, group membership.
  • Active users are allowed to authenticate. All required user account properties must be set in this state.
  • Preserved users are former active users that are considered inactive and cannot authenticate to IdM. Preserved users retain most of the account properties they had as active users, but they are not part of any user groups.

idm user lifecycle

You can delete user entries permanently from the IdM database.

Important

Deleted user accounts cannot be restored. When you delete a user account, all the information associated with the account is permanently lost.

A new administrator can only be created by a user with administrator rights, such as the default admin user. If you accidentally delete all administrator accounts, the Directory Manager must create a new administrator manually in the Directory Server.

9.2. Adding users using the command line

You can add user as:

  • Active — user accounts which can be actively used by their users.
  • Stage — users cannot use these accounts. Use it if you want to prepare new user accounts. When users are ready to use their accounts, then you can activate them.

The following procedure describes adding active users to the IdM server with the ipa user-add command.

Similarly, you can create stage user accounts with the ipa stageuser-add command.

Note

IdM automatically assigns a unique user ID (UID) to the new user accounts. You can also do this manually, however, the server does not validate whether the UID number is unique. Due to this, multiple user entries might have the same ID number assigned. Red Hat recommends to prevent having multiple entries with the same UID.

Prerequisites

Procedure

  1. Open terminal and connect to the IdM server.
  2. Add user login, user’s first name, last name and optionally, you can also add their email address.

    $ ipa user-add user_login --first=first_name --last=last_name --email=email_address

    IdM supports user names that can be described by the following regular expression:

    [a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?
    Note

    User names ending with the trailing dollar sign ($) are supported to enable Samba 3.x machine support.

    If you add a user name containing uppercase characters, IdM automatically converts the name to lowercase when saving it. Therefore, IdM always requires to enter user names in lowercase when logging in. Additionally, it is not possible to add user names which differ only in letter casing, such as user and User.

    The default maximum length for user names is 32 characters. To change it, use the ipa config-mod --maxusername command. For example, to increase the maximum user name length to 64 characters:

    $ ipa config-mod --maxusername=64
     Maximum username length: 64
     ...

    The ipa user-add command includes a lot of parameters. To list them all, use the ipa help command:

    $ ipa help user-add

    For details about ipa help command, see What is the IPA help.

You can verify if the new user account is successfully created by listing all IdM user accounts:

$ ipa $ ipa user-find

This command lists all user accounts with details.

9.3. Activating users using the command line

To activate a user account by moving it from stage to active, use the ipa stageuser-activate command.

Prerequisites

Procedure

  1. Open terminal and connect to the IdM server.
  2. Activate the user account with the following command:

    $ ipa stageuser-activate user_login
    -------------------------
    Stage user user_login activated
    -------------------------
    ...

You can verify if the new user account is successfully created by listing all IdM user accounts:

$ ipa $ ipa user-find

This command lists all user accounts with details.

9.4. Preserving users using the command line

To preserve a user account, use the ipa user-del or ipa stageuser-del commands.

Prerequisites

Procedure

  1. Open terminal and connect to the IdM server.
  2. Preserve the user account with the following command:

    $ ipa user-del --preserve user_login
    --------------------
    Deleted user "user_login"
    --------------------

9.5. Deleting users using the command line

IdM (Identity Management) enables you to delete users permanently. You can delete:

  • Active users with the following command: ipa user-del
  • Stage users with the following command: ipa stageuser-del
  • Preserved users with the following command: ipa user-del

When deleting multiple users, use the --continue option to force the command to continue regardless of errors. A summary of the successful and failed operations is printed to the stdout standard output stream when the command completes.

$ ipa user-del --continue user1 user2 user3

If you do not use --continue, the command proceeds with deleting users until it encounters an error, after which it stops and exits.

Prerequisites

Procedure

  1. Open terminal and connect to the IdM server.
  2. Delete the user account with the following command:

    $ ipa user-del user_login
    --------------------
    Deleted user "user_login"
    --------------------

The user account has been permanently deleted from IdM.

9.6. Restoring users using the command line

You can restore a preserved users to:

  • Active users: ipa user-undel
  • Stage users: ipa user-stage

Restoring a user account does not restore all of the account’s previous attributes. For example, the user’s password is not restored and must be set again.

Prerequisites

Procedure

  1. Open terminal and connect to the IdM server.
  2. Activate the user account with the following command:

    $ ipa user-undel user_login
    ------------------------------
    Undeleted user account "user_login"
    ------------------------------

    Alternatively, you can restore user accounts as staged:

    $ ipa user-stage user_login
    ------------------------------
    Staged user account "user_login"
    ------------------------------

You can verify if the new user account is successfully created by listing all IdM user accounts:

$ ipa $ ipa user-find

This command lists all user accounts with details.

Chapter 10. Managing user groups in IdM CLI

This chapter introduces user groups in Identity Management (IdM).

10.1. User groups and group types in IdM

A user group is a set of users with common privileges, password policies, and other characteristics.

A user group in Identity Management (IdM) can include:

  • IdM users
  • other IdM user groups
  • external users, which are users that exist outside IdM

Group types

IdM has three types of groups:

POSIX groups (the default)

POSIX groups support POSIX attributes for their members. Note that groups that interact with Active Directory cannot use POSIX attributes.

POSIX attributes identify users as separate entities. Examples of POSIX attributes relevant to users include uidNumber, a user number (UID), and gidNumber, a group number (GID).

Non-POSIX groups
All members of this type of group must belong to the IdM domain.
External groups
You can use external groups to add group members that exist in an identity store outside of the IdM domain. The external store can be a local system, an Active Directory domain, or a directory service.

Non-POSIX and external groups do not support POSIX attributes. For example, these groups do not have a GID defined.

Note

In IdM role is a concept related to the concept of group. However, the only purpose of a role is to grant rights to users.

User groups created by default

Table 10.1. User groups created by default

Group nameDefault group members

ipausers

All IdM users

admins

Users with administrative privileges, initially the default admin user

editors

Users allowed to edit other IdM users in the web UI, without all the rights of an administrative user

trust admins

Users with privileges to manage the Active Directory trusts

When you add a user to a user group, the user gains the privileges and policies associated with the group. For example, you can grant administrative privileges to a user by adding the user to the admins group.

In addition, IdM creates user private groups by default whenever a new user is created in IdM.

  • The user private group has the same name as the newly created user.
  • The user is the only member of the user private group.
  • The GID of the private group matches the UID of the user.

In some situations, it is better to avoid creating user private groups, such as when a NIS group or another system group already uses the GID that would be assigned to the user private group.

10.2. Direct and indirect group members

User group attributes in IdM apply to both direct and indirect members: when group B is a member of group A, all users in group B are considered indirect members of group A.

For example, in Figure 10.1, “Direct and Indirect Group Membership”:

  • User 1 and User 2 are direct members of group A.
  • User 3, User 4, and User 5 are indirect members of group A.

Figure 10.1. Direct and Indirect Group Membership

user group members

If you set a password policy for user group A, the policy also applies to all users in user group B.

10.3. Adding, searching for, and deleting user groups in IdM CLI

Adding a user group using IdM CLI

You can specify a custom GID when adding a user group. If you do this, be careful to avoid ID conflicts.

If you do not specify a custom GID, IdM automatically assigns a GID from the available ID range.

  1. Log in as the administrator:

    $ kinit admin
  2. Add a user group using the ipa group-add group_name command. For example, to create group_a:

    $ ipa group-add group_a
    ---------------------
    Added group "group_a"
    ---------------------
      Group name: group_a
      GID: 1133400009

    By default, ipa group-add adds a POSIX user group. To specify a different group type, add options to ipa group-add:

Searching for user groups using IdM CLI

  • Display all user groups using the ipa group-find command.
  • Display all POSIX groups using the ipa group-find --posix command.
  • Display all non-POSIX groups using the ipa group-find --nonposix command.
  • Display all external groups using the ipa group-find --external command.

Deleting a user group using IdM CLI

  1. Log in as the administrator:

    $ kinit admin
  2. Delete a user group using the ipa group-del group_name command. For example, to delete group_a:

    $ ipa group-del group_a
    --------------------------
    Deleted group "group_a"
    --------------------------

10.4. Adding a member to a user group using IdM CLI

Prerequisites

Procedure

  • Add a member to a user group using the ipa group-add-member command.

    Specify the type of member using these options:

    • --users adds an IdM user
    • --external adds a user that exists outside the IdM domain, in the format of DOMAIN\user_name or user_name@domain
    • --groups adds an IdM user group

    For example, to add group_b as a member of group_a:

    $ ipa group-add-member group_a --groups=group_b
    Group name: group_a
    GID: 1133400009
    Member users: user_a
    Member groups: group_b
    Indirect Member users: user_b
    -------------------------
    Number of members added 1
    -------------------------

    Members of group_b are now indirect members of group_a.

Important

When adding a group as a member of another group, do not create recursive groups. For example, if Group A is a member of Group B, do not add Group B as a member of Group A. Recursive groups can cause unpredictable behavior.

Note

After you add a member to a user group, the update may take some time to spread to all clients in your Identity Management environment. This is because when any given host resolves users, groups and netgroups, the System Security Services Daemon (SSSD) first looks into its cache and performs server lookups only for missing or expired records.

10.5. Viewing group members using IdM CLI

Procedure:

  • To list members of a group, use the ipa group-show group_name command. For example:

    $ ipa group-show group_a
      ...
      Member users: user_a
      Member groups: group_b
      Indirect Member users: user_b

    You can see both direct and indirect members of a group in the output. For details on direct and indirect membership, see Direct and indirect group members.

    The list of indirect members does not include external users from trusted Active Directory domains. The Active Directory trust user objects are not visible in the Identity Management interface because they do not exist as LDAP objects within Identity Management.

10.6. Removing a member from a user group using IdM CLI

  1. Optional. Use the ipa group-show command to confirm that the group includes the member you want to remove.
  2. Remove a member from a user group using the ipa group-remove-member command.

    You can specify the member using these options:

    • --users removes an IdM user
    • --external removes a user that exists outside the IdM domain, in the format of DOMAIN\user_name or user_name@domain
    • --groups removes an IdM user group

    For example, to remove user1, user2, and group1 from a group called group_name:

    $ ipa group-remove-member group_name --users=user1 --users=user2 --groups=group1

Chapter 11. 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.

11.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.

11.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 with. 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.

11.2.1. 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, see 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.

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

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

  • The enrollment stage (Table 11.1, “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, thus 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 11.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 (Table 11.2, “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 11.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.

11.2.3. 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.

11.3. Host Operations

This section lists the most common operations related to host enrollment and enablement, and explains the prerequisites, the context, and the consequences of performing them.

Table 11.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 11.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>).

11.4. Host entry in IdM LDAP

This section describes what a host entry in Identity Management (IdM) looks like 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 IdentityHosts tab does not show all the information about a particular host stored in the IdM LDAP.

11.4.1. 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 11.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.

11.5. Adding IdM host entries from IdM CLI

This section describes how 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 11.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 11.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.

11.6. 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

11.7. Re-enrolling an Identity Management client

11.7.1. Client re-enrollment in IdM

This section describes how to re-enroll an Identity Management (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.

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. Thus 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 Section 11.8, “Renaming Identity Management client systems”.

11.7.1.1. What happens during client re-enrollment

During re-enrollment, Identity Management:

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

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

This procedure describes re-enrolling 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

11.7.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

This procedure describes re-enrolling an Identity Management 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.

11.7.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 ~]$

11.8. 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 Section 11.8.1, “Prerequisites”
  2. Uninstalling the IdM client from the host. For details, see Section 11.8.2, “Uninstalling an Identity Management client”
  3. Renaming the host. For details, see Section 11.8.3, “Renaming the host system”
  4. Installing the IdM client on the host with the new name. For details, see Section 11.8.4, “Re-installing an Identity Management client”
  5. Configuring the host after the IdM client installation. For details, see Section 11.8.5, “Re-adding services, re-generating certificates, and re-adding host groups”

11.8.1. Prerequisites

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

11.8.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

11.8.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.

11.8.4. Re-installing an Identity Management client

Install an client on your renamed host following the procedure described in Installing an Identity Management client: Basic scenario in Installing Identity Management.

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

  1. On the Identity Management server, add a new keytab for every service identified in Section 11.8.1, “Prerequisites”.

    [root@server ~]# ipa service-add service_name/new-client-name
  2. Generate certificates for services that had a certificate assigned in Section 11.8.1, “Prerequisites”. You can do this:

    • Using the Identity Management administration tools
    • Using the certmonger utility
  3. Re-add the client to the host groups identified in Section 11.8.1, “Prerequisites”.

11.9. Disabling and Re-enabling Host Entries

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

11.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. This can be done by 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.

11.9.2. Re-enabling Hosts

This section describes how 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.

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.

Chapter 12. Adding host entries from IdM Web UI

This chapter introduces hosts in Identity Management (IdM) and the operation of adding a host entry in the IdM Web UI.

12.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.

12.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 with. 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.

12.2.1. 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, see 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.

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

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

  • The enrollment stage (Table 12.1, “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, thus 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 12.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 (Table 12.2, “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 12.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.

12.2.3. 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.

12.3. Host entry in IdM LDAP

This section describes what a host entry in Identity Management (IdM) looks like 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 IdentityHosts tab does not show all the information about a particular host stored in the IdM LDAP.

12.3.1. 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 12.3. 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.

12.4. Adding Host Entries from the Web UI

  1. Open the Identity tab, and select the Hosts subtab.
  2. Click Add at the top of the hosts list.

    Figure 12.1. Adding Host Entries

    hosts list
  3. Enter 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.

    The Class field has no specific purpose at the moment.

    Figure 12.2. Add Host Wizard

    host add

    DNS zones can be created in IdM. 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.

    Note

    Select the Force check box if you want to skip checking whether the host is resolvable via DNS.

  4. Click the Add and Edit button to go directly to the expanded entry page and enter more attribute information. Information about the host hardware and physical location can be included with the host entry.

    Figure 12.3. Expanded Entry Page

    host attr

Chapter 13. Public key certificates in Identity Management

This chapter introduces X.509 public key certificates, which are used to authenticate users, hosts and services in Identity Management (IdM). In addition to authentication, X.509 certificates also enable digital signing and encryption to provide privacy, integrity and non-repudiation.

A certificate contains information about

  • the subject that the certificate authenticates
  • who has signed (validated) the certificate, that is the issuer
  • the start and end of the validity of the certificate
  • the valid uses of the certificate
  • the public key of the subject

A message encrypted by the public key can only be decrypted by a corresponding private key. Although a certificate and the public key it includes can be made freely available, a user, host or machine must keep their private key secret.

13.1. Certificate authorities in IdM

Certificate authorities operate in a hierarchy of trust. In an IdM environment with an internal Certificate Authority (CA), all the IdM hosts, users and services trust certificates that have been signed by the CA. Apart from this root CA, IdM supports sub-CAs to which the root CA has granted the ability to sign certificates in their turn. Frequently, the certificates that such sub-CAs are able to sign are certificates of a specific kind, for example VPN certificates.

From the certificate point of view, there is no difference between being signed by a self-signed IdM CA and being signed externally.

The role of the CA is the following:

  • It issues and verifies digital certificates
  • It signs the certificate to prove that the certificate belongs to the user, host or service that presents it
  • In an IdM environment with an internal CA, the CA which is the Certificate Renewal Master and which maintains the Certificate Revocation List (CRL) is the highest authority

13.2. Comparison of certificates and Kerberos

Certificates perform a similar function to that performed by Kerberos tickets. Kerberos is a computer network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner. The following table shows a comparison of Kerberos and X.509 certificates:

Table 13.1. Comparison of certificates and Kerberos

Characteristic

Kerberos

X.509

Authentication

Yes

Yes

Privacy

Optional

Yes

Integrity

Optional

Yes

Type of cryptography involved

Symmetrical

Asymmetrical

Default validity

Short (1 day)

Long(2 years)

By default, Kerberos in Identity Management only ensures the identity of the communicating parties.

13.3. The pros and cons of using certificates to authenticate users in IdM

The advantages of using certificates to authenticate users in IdM include:

  • A PIN that protects the private key on a smart card is typically less complex and easier to remember than a regular password.
  • Depending on the device, a private key stored on a smart card cannot be exported. This provides additional security.
  • Smart cards can make logout automatic: IdM can be configured to log out users when they remove the smart card from the reader.
  • Stealing the private key requires actual physical access to a smart card, making smart cards secure against hacking attacks.
  • Smart card authentication is two-factor authentication: it requires both something you have (the card) and something you know (the PIN).
  • Smart cards are more flexible than passwords because they provide the keys that can be used for other purposes, such as encrypting email.
  • Using smart cards use on shared machines that are IdM clients does not typically pose additional configuration problems for system administrators. In fact, smart card authentication is an ideal choice for shared machines.

The disadvantages of using certificates to authenticate users in IdM include:

  • Users might lose or forget to bring their smart card or certificate and be effectively locked out.
  • Mistyping a PIN multiple times might result in a card becoming locked.
  • There is generally an intermediate step between request and authorization by some sort of security officer or approver. In IdM, the security officer or administrator must run the ipa cert-request command.
  • Smart cards and readers tend to be vendor and driver specific: although a lot of readers can be used for different cards, a smart card of a specific vendor might not work in the reader of another vendor or in the type of a reader for which it was not designed.
  • The learning curve to certificates and smart cards might seem daunting to admininstrators with no experience in the area.

Chapter 14. Converting certificate formats to work with IdM

This user story describes how to make sure that you as an IdM system administrator are using the correct format of a certificate with specific IdM commands. This is useful, for example, in the following situations:

14.1. Certificate formats and encodings in IdM

Certificate authentication including smart card authentication in IdM proceeds by comparing the certificate that the user presents with the certificate, or certificate data, that are stored in the user’s IdM profile.

System configuration

What is stored in the IdM profile is only the certificate, not the corresponding private key. During authentication, the user must also show that he is in possession of the corresponding private key. The user does that by either presenting a PKCS #12 file that contains both the certificate and the private key or by presenting two files: one that contains the certificate and the other containing the private key.

Therefore, processes such as loading a certificate into a user profile only accept certificate files that do not contain the private key.

Similarly, when a system administrator provides you with an external CA certificate, he will provide only the public data: the certificate without the private key. The ipa-advise utility for configuring the IdM server or the IdM client for smart card authentication expects the input file to contain the certificate of the external CA but not the private key.

Certificate encodings

There are two common certificate encodings: Privacy-enhanced Electronic Mail (PEM) and Distinguished Encoding Rules (DER). The base64 format is almost identical to the PEM format but it does not contain the -----BEGIN CERTIFICATE-----/-----END CERTIFICATE----- header and footer.

A certificate that has been encoded using DER is a binary X509 digital certificate file. As a binary file, the certificate is not human-readable. DER files sometimes use the .der filename extension, but files with the .crt and .cer filename extensions also sometimes contain DER certificates. DER files containing keys can be named .key.

A certificate that has been encoded using PEM Base64 is a human-readable file. The file contains ASCII (Base64) armored data prefixed with a “-----BEGIN …” line. PEM files sometimes use the .pem filename extension, but files with the .crt and .cer filename extensions also sometimes contain PEM certificates. PEM files containing keys can be named .key.

Different ipa commands have different limitations regarding the types of certificates that they accept. For example, the ipa user-add-cert command only accepts certificates encoded in the base64 format but ipa-server-certinstall accepts PEM, DER, PKCS #7, PKCS #8 and PKCS #12 certificates.

Table 14.1. Certificate encodings

Encoding formatHuman-readableCommon filename extensionsSample IdM commands accepting the encoding format

PEM/base64

Yes

.pem, .crt, .cer

ipa user-add-cert, ipa-server-certinstall, …​

DER

No

.der, .crt, .cer

ipa-server-certinstall, …​

Section 14.4, “Certificate-related commands and formats in IdM” lists further ipa commands with the certificate formats that the commands accept.

User authentication

When using the web UI to access IdM, the user proves that he is in possession of the private key corresponding to the certificate by having both stored in the browser’s database.

When using the CLI to access IdM, the user proves that he is in possession of the private key corresponding to the certificate by one of the following methods:

  • The user adds, as the value of the X509_user_identity parameter of the kinit -X command, the path to the smart card module that is connected to the smart card that contains both the certificate and the key:

    $ kinit -X X509_user_identity='PKCS11:opensc-pkcs11.so' idm_user
  • The user adds two files as the values of the X509_user_identity parameter of the kinit -X command, one containing the certificate and the other the private key:

    $ kinit -X X509_user_identity='FILE:`/path/to/cert.pem,/path/to/cert.key`' idm_user

Useful certificate commands

To view the certificate data, such as the subject and the issuer:

$ openssl x509 -noout -text -in ca.pem

To compare in which lines two certificates differ:

$ diff cert1.crt cert2.crt

To compare in which lines two certificates differ with the output displayed in two columns:

$ diff cert1.crt cert2.crt -y

14.2. Converting an external certificate to load into an IdM user account

This section describes how to make sure that an external certificate is correctly encoded and formatted before adding it to a user entry.

Prerequisites

  • If your certificate was issued by an Active Directory certificate authority and uses the PEM encoding, make sure that the PEM file has been converted into the UNIX format. To convert a file, use the dos2unix utility provided by the eponymous package.

14.2.1. Converting an external certificate in the IdM CLI and loading it into an IdM user account

The IdM CLI only accepts a PEM certificate from which the first and last lines (-----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----) have been removed.

Procedure

  1. Convert the certificate to the PEM format:

    • If your certificate is in the DER format:

      $ openssl x509 -in cert.crt -inform der -outform pem -out cert.pem
    • If your file is in the PKCS #12 format, whose common filename extensions are .pfx and .p12, and contains a certificate, a private key, and possibly other data, extract the certificate using the openssl pkcs12 utility. When prompted, enter the password protecting the private key stored in the file:

      $ openssl pkcs12 -in cert_and_key.p12 -clcerts -nokeys -out cert.pem
      Enter Import Password:
  2. Obtain the administrator’s credentials:

    $ kinit admin
  3. Add the certificate to the user account using the IdM CLI following one of the following methods:

    • Remove the first and last lines (-----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----) of the PEM file using the sed utility before adding the string to the ipa user-add-cert command:

      $ ipa user-add-cert some_user --certificate="$(sed -e '/BEGIN CERTIFICATE/d;/END CERTIFICATE/d' cert.pem)"
    • Copy and paste the contents of the certificate file without the first and last lines (-----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----) into the ipa user-add-cert command:

      $ ipa user-add-cert some_user --certificate=MIIDlzCCAn+gAwIBAgIBATANBgkqhki...
      Note

      You cannot pass a PEM file containing the certificate as input to the ipa user-add-cert command directly, without first removing the first and last lines (-----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----):

      $ ipa user-add-cert some_user --cert=some_user_cert.pem

      This command results in the "ipa: ERROR: Base64 decoding failed: Incorrect padding" error message.

  4. Optionally, to check if the certificate was accepted by the system:

    [idm_user@r8server]$ ipa user-show some_user

14.2.2. Converting an external certificate in the IdM web UI for loading into an IdM user account:

Procedure

  1. Using the CLI, convert the certificate to the PEM format:

    • If your certificate is in the DER format:

      $ openssl x509 -in cert.crt -inform der -outform pem -out cert.pem
    • If your file is in the PKCS #12 format, whose common filename extensions are .pfx and .p12, and contains a certificate, a private key, and possibly other data, extract the certificate using the openssl pkcs12 utility. When prompted, enter the password protecting the private key stored in the file:

      $ openssl pkcs12 -in cert_and_key.p12 -clcerts -nokeys -out cert.pem
      Enter Import Password:
  2. Open the certificate in an editor and copy the contents. You can include the "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----" header and footer lines but you do not have to, as both the PEM and base64 formats are accepted by the IdM web UI.
  3. In the IdM web UI, log in as security officer.
  4. Go to IdentityUserssome_user.
  5. Click Add next to Certificates.
  6. Paste the PEM-formatted contents of the certificate into the window that opens.
  7. Click Add.

If the certificate was accepted by the system, you can see it listed among the Certificates in the user profile.

14.3. Preparing to load a certificate into the browser

Before importing a user certificate into the browser, make sure that the certificate and the corresponding private key are in a PKCS #12 format. There are two common situations requiring extra preparatory work:

Afterwards, to import both the CA certificate in the PEM format and the user certificate in the PKCS #12 format into the browser, follow the procedures in Section 16.4, “Configuring a browser to enable certificate authentication” and Section 16.5, “Authenticating to the Identity Management Web UI with a Certificate as an Identity Management User”.

14.3.1. Exporting a certificate and private key from an NSS database into a PKCS #12 file

Procedure

  1. Use the pk12util command to export the certificate from the NSS database to the PKCS12 format. For example, to export the certificate with the some_user nickname from the NSS database stored in the ~/certdb directory into the ~/some_user.p12 file:

    $ pk12util -d ~/certdb -o ~/some_user.p12 -n some_user
    Enter Password or Pin for "NSS Certificate DB":
    Enter password for PKCS12 file:
    Re-enter password:
    pk12util: PKCS12 EXPORT SUCCESSFUL
  2. Set appropriate permissions for the .p12 file:

    # chmod 600 ~/some_user.p12

    Because the PKCS #12 file also contains the private key, it must be protected to prevent other users from using the file. Otherwise, they would be able to impersonate the user.

14.3.2. Combining certificate and private key PEM files into a PKCS #12 file

This section describes how to combine a certificate and the corresponding key stored in separate PEM files into a PKCS #12 file.

Procedure

  • To combine a certificate stored in certfile.cer and a key stored in certfile.key into a certfile.p12 file that contains both the certificate and the key:

    $ openssl pkcs12 -export -in certfile.cer -inkey certfile.key -out certfile.p12

14.4. Certificate-related commands and formats in IdM

Table IdM certificate commands and formats displays certificate-related commands in IdM with acceptable formats.

Table 14.2. IdM certificate commands and formats

CommandAcceptable formatsNotes

ipa user-add-cert some_user --certificate

base64 PEM certificate

 

ipa-server-certinstall

PEM and DER certificate; PKCS#7 certificate chain; PKCS#8 and raw private key; PKCS#12 certificate and private key

 

ipa-cacert-manage install

DER; PEM; PKCS#7

 

ipa-cacert-manage renew --external-cert-file

PEM and DER certificate; PKCS#7 certificate chain

 

ipa-ca-install --external-cert-file

PEM and DER certificate; PKCS#7 certificate chain

 

ipa cert-show <cert serial> --certificate-out /path/to/file.pem

N/A

Creates the PEM-encoded file.pem file with the certificate having the <cert_serial> serial number.

ipa cert-show <cert serial> --certificate-out /path/to/file.pem

N/A

Creates the PEM-encoded file.pem file with the certificate having the <cert_serial> serial number. If the --chain option is used, the PEM file contains the certificate including the certificate chain.

ipa cert-request --certificate-out=FILE /path/to/req.csr

N/A

Creates the req.csr file in the PEM format with the new certificate.

ipa cert-request --certificate-out=FILE /path/to/req.csr

N/A

Creates the req.csr file in the PEM format with the new certificate. If the --chain option is used, the PEM file contains the certificate including the certificate chain.

Chapter 15. Configuring Identity Management for smart card authentication

Authentication based on smart cards is an alternative to passwords. User credentials are stored on the smart card in the form of a private key and a certificate, and special software and hardware is used to access them. The user places the smart card into a reader or a USB socket and supplies the PIN code for the smart card instead of providing his login and password.

Identity Management (IdM) supports smart card authentication with:

  • User certificates issued by the IdM certificate authority
  • User certificates issued by an external certificate authority

This user story shows how to set up smart card authentication in IdM for both types of certificates. In the user story, the smartcard_ca.pem CA certificate is the file containing the certificate of a trusted external certificate authority.

The user story contains the following modules:

Section 15.1, “Configuring the IdM server for smart card authentication”

Section 15.2, “Configuring the IdM client for smart card authentication”

Section 15.3, “Adding a certificate to a user entry in IdM”

Section 15.4, “Configuring the browser for smart card authentication”

Section 15.5, “Logging in to IdM with smart cards”

15.1. Configuring the IdM server for smart card authentication

If you want to enable smart card authentication for users whose certificates have been issued by the certificate authority of the EXAMPLE.ORG domain, whose LDAP distinguished name (DN) is CN=Certificate Authority,DC=EXAMPLE,DC=ORG, then you need to obtain the certificate of the authority so that you can run it with the script configuring the IdM server. You can, for example, download the certificate from a web page whose certificate has been issued by the authority. For details, see Steps 1 - 4a in Section 16.4, “Configuring a browser to enable certificate authentication”.

To enable smart card authentication for IdM users who have been issued a certificate by the IdM Certificate Authority, obtain the CA certificate from the /etc/ipa/ca.crt file on the IdM server on which the IdM CA is running.

This section describes how to configure an IdM server for smart card authentication. First, obtain files with the CA certificates in the PEM format, then run the in-built ipa-advise script. Finally, reload the system configuration.

Prerequisites

  • You have root access to the IdM server.

Procedure

  1. Create a directory in which you will do the configuration:

    [root@server]# mkdir ~/SmartCard/
  2. Navigate to the directory:

    [root@server]# cd ~/SmartCard/
  3. Obtain the relevant CA certificates stored in files in the PEM format: .pem, .crt and .cer. The IdM Certificate Authority certificate is located in the /etc/ipa/ca.crt file. For convenience, copy the certificates to the directory in which you want to do the configuration:

    [root@server SmartCard]# cp /etc/ipa/ca.crt ~/SmartCard/
    [root@server SmartCard]# cp /tmp/smartcard_ca.pem ~/SmartCard/
  4. Optionally, if you use certificates of external certificate authorities, use the openssl x509 utility to view the contents of the files in the PEM format to check that the Issuer and Subject values are correct:

    [root@server SmartCard]# openssl x509 -noout -text -in smartcard_ca.pem | more
  5. Generate a configuration script with the in-built ipa-advise utility, using the administrator’s privileges:

    [root@server SmartCard]# kinit admin
    [root@server SmartCard]# sudo ipa-advise config-server-for-smart-card-auth > config-server-for-smart-card-auth.sh

    The config-server-for-smart-card-auth.sh script performs the following actions:

    • It configures the IdM Apache HTTP server.
    • It enables Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) on the Key Distribution Center (KDC).
    • It configures the IdM Web UI to accept smart card authorization requests.
  6. Execute the script, adding the PEM files containing the CA certificates as arguments:

    [root@server SmartCard]# chmod +x config-server-for-smart-card-auth.sh
    [root@server SmartCard]# ./config-server-for-smart-card-auth.sh smartcard_ca.pem ca.crt
    Ticket cache:KEYRING:persistent:0:0
    Default principal: admin@IDM.EXAMPLE.COM
    [...]
    Systemwide CA database updated.
    The ipa-certupdate command was successful
  7. Optionally, if the certificate authority that issued the user certificate does not provide any Online Certificate Status Protocol (OCSP) responder, you may need to disable OCSP check for authentication to the IdM Web UI:

    1. Set the SSLOCSPEnable parameter to off in the /etc/httpd/conf.d/ssl.conf file:

      SSLOCSPEnable off
    2. Restart the Apache daemon (httpd) for the changes to take effect immediately:

      [root@server SmartCard]# sudo systemctl restart httpd
    Warning

    Do not disable the OCSP check if you only use user certificates issued by the IdM CA. OCSP responders are part of IdM.

    For instructions on how to keep the OCSP check enabled, and yet prevent a user certificate from being rejected by the IdM server if it does not contain the information about the location at which the CA that issued the user certificate listens for OCSP service requests, see the SSLOCSPDefaultResponder directive in Apache mod_ssl configuration options.

The server is now configured for smart card authentication.

Note

To enable smart card authentication in the whole topology, run the procedure on each IdM server.

15.2. Configuring the IdM client for smart card authentication

This section describes how to configure IdM clients for smart card authentication. The procedure needs to be run on each IdM system, a client or a server, to which you want to connect while using a smart card for authentication. For example, to enable an ssh connection from host A to host B, the script needs to be run on host B.

As an administrator, run this procedure to enable smart card authentication using

  • the ssh protocol
  • the console login
  • the Gnome Display Manager (GDM)
  • the su command

This procedure is not required for authenticating to the IdM Web UI. Authenticating to the IdM Web UI involves two hosts, neither of which needs to be an IdM client:

  • the machine - possibly outside of the IdM domain - on which the browser is running
  • the IdM server on which httpd is running

The following procedure assumes that you are configuring smart card authentication on an IdM client that is not also an IdM master. For this reason you need two computers: an IdM master to generate the configuration script, and the IdM client on which to run the script.

Prerequisites

Procedure

  1. On an IdM master, generate a configuration script with ipa-advise using the administrator’s privileges:

    [root@server SmartCard]# kinit admin
    [root@server SmartCard]# ipa-advise config-client-for-smart-card-auth > config-client-for-smart-card-auth.sh

    The config-client-for-smart-card-auth.sh script performs the following actions:

    • It configures the smart card daemon.
    • It sets the system-wide trust store.
    • It configures the System Security Services Daemon (SSSD) to allow smart card logins to the desktop.
  2. From the IdM master, copy the script to a directory of your choice on the IdM client machine:

    [root@server SmartCard]# scp config-client-for-smart-card-auth.sh root@client.idm.example.com:/root/SmartCard/
    Password:
    config-client-for-smart-card-auth.sh        100%   2419       3.5MB/s   00:00
  3. From the IdM master, copy the CA certificate files in the PEM format for convenience to the same directory on the IdM client machine as used in the previous step:

    [root@server SmartCard]# scp {smartcard_ca.pem,ca.crt} root@client.idm.example.com:/root/SmartCard/
    Password:
    smartcard_ca.pem                    100%   1237     9.6KB/s   00:00
    ca.crt                              100%   2514    19.6KB/s   00:00
  4. On the client machine, execute the script, adding the PEM files containing the CA certificates as arguments:

    [root@client SmartCard]# kinit admin
    [root@client SmartCard]# chmod +x config-client-for-smart-card-auth.sh
    [root@client SmartCard]# ./config-client-for-smart-card-auth.sh smartcard_ca.pem ca.crt
    Ticket cache:KEYRING:persistent:0:0
    Default principal: admin@IDM.EXAMPLE.COM
    [...]
    Systemwide CA database updated.
    The ipa-certupdate command was successful

The client is now configured for smart card authentication.

15.3. Adding a certificate to a user entry in IdM

This procedure describes how to add an external certificate to a user entry in IdM.

Instead of uploading the whole certificate, it is also possible to upload certificate mapping data to a user entry in IdM. User entries containing either full certificates or certificate mapping data can be used in conjunction with corresponding certificate mapping rules to facilitate the configuration of smart card authentication for system administrators. For details, see Chapter 17, Configuring certificate mapping rules in Identity Management.

Note

If the user’s certificate has been issued by the IdM Certificate Authority, the certificate is already stored in the user entry, and you can skip this section.

15.3.1. Adding a certificate to a user entry in the IdM Web UI

Prerequisites

  • You have the certificate that you want to add to the user entry at your disposal.

Procedure

  1. Log into the IdM Web UI as an administrator if you want to add a certificate to another user. For adding a certificate to your own profile, you do not need the administrator’s credentials.
  2. Navigate to UsersActive userssc_user.
  3. Find the Certificate option and click Add.
  4. In the Command-Line Interface, display the certificate using the cat utility or a text editor:

    [user@client SmartCard]$ cat sc_user_certificate.pem
  5. Copy and paste the certificate from the CLI into the window that has opened in the Web UI.
  6. Click Add.

    Figure 15.1. Adding a new certificate in the IdM Web UI

    idm add cert

The sc_user entry now contains an external certificate.

15.3.2. Adding a certificate to a user entry in the IdM CLI

Prerequisites

  • You have the certificate that you want to add to the user entry at your disposal.

Procedure

  1. Log into the IdM Web UI as an administrator if you want to add a certificate to another user:

    [user@client SmartCard]$ kinit admin

    For adding a certificate to your own profile, you do not need the administrator’s credentials:

    [user@client SmartCard]$ kinit sc_user
  2. Create an environment variable containing the certificate with the header and footer removed and concatenated into a single line, which is the format expected by the ipa user-add-cert command:

    [user@client SmartCard]$ export CERT=`openssl x509 -outform der -in sc_user_certificate.pem | base64 -w0 -`
  3. Add the certificate to the profile of sc_user using the ipa user-add-cert command:

    [user@client SmartCard]$ ipa user-add-cert sc_user --certificate=$CERT

The sc_user entry now contains an external certificate.

15.4. Configuring the browser for smart card authentication

This module describes how to configure the Firefox browser for smart card authentication.

Identity Management supports the following browsers for connecting to the web UI:

  • Mozilla Firefox 38 and later
  • Google Chrome 46 and later

The following procedure shows how to configure the Mozilla Firefox 57.0.1 browser.

Prerequisites

  • Your IdM server has been configured for smart card authentication, as described in Section 15.1, “Configuring the IdM server for smart card authentication”.
  • A smart card is inserted into the USB slot of the host on which you want to configure the browser for smart card authentication.
  • On the smart card, both the certificate and the private key of the IdM user are stored. For details about importing the certificate and the key on to the smart card, please refer to your smart card vendor’s documentation.
  • The user entry in IdM contains the certificate that is stored on the smart card. For details about uploading a certificate into an IdM user’s user entry, see Section 15.3, “Adding a certificate to a user entry in IdM”.

Procedure

  1. Open Firefox, click on Preferences.

    Figure 15.2. Firefox preferences

    firefox preferences
  2. Navigate to Privacy & Security.
  3. Click on Security Devices.

    Figure 15.3. Security devices

    security devices
  4. In the new Device Manager dialogue window, click on Load.

    Figure 15.4. Loading a security device

    load module
  5. In the new Load PKCS#11 Device Driver dialogue window, enter the module name, for example OpenSC. Enter the module filename. The module for OpenSC is located in the /usr/lib64/opensc-pkcs11.so file.

    Figure 15.5. Entering the security device information

    pkcs11 module name
  6. Optionally, check that module can log in to Firefox.

    1. Click on PIV Card Holder pin (PIV_II) in the left pane and click Log In in the right pane.

      Figure 15.6. Logging in with the security device

      log in pkcs11 module
    2. Enter the PIN of the smart card and click OK.

      Figure 15.7. Entering the smart card PIN

      idm PIN dialogue

      If successful, you will see the Log In button grayed out.

      Figure 15.8. Security device module loaded

      pkcs11 module loaded
  7. Click OK.

Now your browser is ready for smart card authentication using the loaded security device.

15.5. Logging in to IdM with smart cards

This section provides information about using smart cards for logging in to IdM Web UI.

Prerequisites

  • The web browser is configured for using smart card authentication.
  • The IdM server has been configured for smart card authentication.
  • The certificate installed on your smart card is known to the IdM server.
  • You need the PIN for the certificate access.
  • The smart card has been plugged to the reader.

Procedure

  1. Open the IdM Web UI in the browser.
  2. Click on Log In Using Certificate.

    ipa login smart card

  3. If the Password Required dialog box opens, add the PIN to unlock the certificate and click the OK button.

    The User Identification Request dialog box opens.

    If the smart card contains more than one certificate, select the certificate you want to use for authentication in the drop down list below Choose a certificate to present as identification.

  4. Click the OK button.

Now you are successfully logged in to the IdM Web UI.

web ui users

Chapter 16. Configuring authentication with a certificate stored on the desktop of an IdM client

By configuring Identity Management (IdM), IdM system administrators can enable users to authenticate to the IdM web UI and command-line interface (CLI) using a certificate that a Certificate Authority (CA) has issued to the users.

The web browser can run on a system that is not part of the IdM domain.

This user story provides instructions on how to effectively configure and test logging into Identity Management web UI and CLI with a certificate stored on the desktop of an IdM client. In following this user story,

Note

Only Identity Management users can log into the web UI using a certificate. Active Directory users can log in with their user name and password.

16.1. Configuring the Identity Management Server for Certificate Authentication in the Web UI

As an Identity Management (IdM) administrator, you can allow users to use certificates to authenticate to your IdM environment.

Procedure

As the Identity Management administrator:

  1. On an Identity Management server, obtain administrator privileges and create a shell script to configure the server.

    1. Run the ipa-advise config-server-for-smart-card-auth command, and save its output to a file, for example server_certificate_script.sh:

      # kinit admin
      # ipa-advise config-server-for-smart-card-auth > server_certificate_script.sh
    2. Add execute permissions to the file using the chmod utility:

      # chmod +x server_certificate_script.sh
  2. On all the servers in the Identity Management domain, run the server_certificate_script.sh script

    1. with the path of the IdM Certificate Authority certificate, /etc/ipa/ca.crt, as input if the IdM CA is the only certificate authority that has issued the certificates of the users you want to enable certificate authentication for:

      # ./server_certificate_script.sh /etc/ipa/ca.crt
    2. with the paths leading to the relevant CA certificates as input if different external CAs signed the certificates of the users who you want to enable certificate authentication for:

      # ./server_certificate_script.sh /tmp/ca1.pem /tmp/ca2.pem
Note

Do not forget to run the script on each new replica that you add to the system in the future if you want to have certificate authentication for users enabled in the whole topology.

16.2. Requesting a new user certificate and exporting it to the client

As an Identity Management (IdM) administrator, you can create certificates for users in your IdM environment and export them to the IdM clients on which you want to enable certificate authentication for users.

Note

You can skip this section if the user you want to authenticate using a certificate already has a certificate.

Procedure

  1. Optionally, create a new directory, for example ~/certdb/, and make it a temporary certificate database. When asked, create an NSS Certificate DB password to encrypt the keys to the certificate to be generated in a subsequent step:

    # mkdir ~/certdb/
    # certutil -N -d ~/certdb/
    Enter a password which will be used to encrypt your keys.
    The password should be at least 8 characters long,
    and should contain at least one non-alphabetic character.
    
    Enter new password:
    Re-enter password:
  2. Create the certificate signing request (CSR) and redirect the output to a file. For example, to create a CSR with the name certificate_request.csr for a 4096 bit certificate for the idm_user user in the IDM.EXAMPLE.COM realm, setting the nickname of the certificate private keys to idm_user for easy findability, and setting the subject to CN=idm_user,O=IDM.EXAMPLE.COM:

    # certutil -R -d ~/certdb/ -a -g 4096 -n idm_user -s "CN=idm_user,O=IDM.EXAMPLE.COM" > certificate_request.csr
  3. When prompted, enter the same password that you entered when using certutil to create the temporary database. Then continue typing randlomly until told to stop:

    Enter Password or Pin for "NSS Certificate DB":
    
    A random seed must be generated that will be used in the
    creation of your key.  One of the easiest ways to create a
    random seed is to use the timing of keystrokes on a keyboard.
    
    To begin, type keys on the keyboard until this progress meter
    is full.  DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD!
    
    
    Continue typing until the progress meter is full:
  4. Submit the certificate request file to the server. Specify the Kerberos principal to associate with the newly-issued certificate, the output file to store the certificate, and optionally the certificate profile. For example, to obtain a certificate of the IECUserRoles profile, a profile with added user roles extension, for the idm_user@IDM.EXAMPLE.COM principal, and save it in the ~/idm_user.pem file:

    # ipa cert-request certificate_request.csr --principal=idm_user@IDM.EXAMPLE.COM --profile-id=IECUserRoles --certificate-out=~/idm_user.pem
  5. Add the certificate to the NSS database. Use the -n option to set the same nickname that you used when creating the CSR previously so that the certificate matches the private key in the NSS database. The -t option sets the trust level. For details, see the certutil(1) man page. The -i option specifies the input certificate file. For example, to add to the NSS database a certificate with the idm_user nickname that is stored in the ~/idm_user.pem file in the ~/certdb/ database:

    # certutil -A -d ~/certdb/ -n idm_user -t "P,," -i ~/idm_user.pem
  6. Verify that the key in the NSS database does not show (orphan) as its nickname. For example, to verify that the certificate stored in the ~/certdb/ database is not orphaned:

    # certutil -K -d ~/certdb/
    < 0> rsa      5ad14d41463b87a095b1896cf0068ccc467df395   NSS Certificate DB:[replaceable]idm_user
  7. Use the pk12util command to export the certificate from the NSS database to the PKCS12 format. For example, to export the certificate with the idm_user nickname from the /root/certdb NSS database into the ~/idm_user.p12 file:

    # pk12util -d ~/certdb -o ~/idm_user.p12 -n idm_user
    Enter Password or Pin for "NSS Certificate DB":
    Enter password for PKCS12 file:
    Re-enter password:
    pk12util: PKCS12 EXPORT SUCCESSFUL
  8. Transfer the certificate to the host on which you want the certificate authentication for idm_user to be enabled:

    # scp ~/idm_user.p12 idm_user@client.idm.example.com:/home/idm_user/
  9. On the host to which the certificate has been transferred, make the directory in which the .pkcs12 file is stored inaccessible to the 'other' group for security reasons:

    # chmod o-rwx /home/idm_user/
  10. For security reasons, remove the temporary NSS database and the .pkcs12 file from the server:

    # rm ~/certdb/
    # rm ~/idm_user.p12

16.3. Making sure the certificate and user are linked together

Note

You can skip this section if the user’s certificate has been issued by the IdM CA.

For certificate authentication to work, you need to make sure that the certificate is linked to the user that will use it to authenticate to Identity Management (IdM).

16.4. Configuring a browser to enable certificate authentication

For certificate authentication to work in your Identity Management web UI, you need to import the user and Certificate Authority (CA) certificates into the Mozilla Firefox or Google Chrome browser running on the host on which you want to enable certificate authentication. The host itself does not have to be part of the IdM domain.

Identity Management supports the following browsers for connecting to the web UI:

  • Mozilla Firefox 38 and later
  • Google Chrome 46 and later

The following procedure shows how to configure the Mozilla Firefox 57.0.1 browser.

Procedure

  1. Open Firefox, then navigate to PreferencesPrivacy & Security.

    .Privacy and Security section in Preferences

    privacy and security
  2. Click View Certificates.

    .View Certificates in Privacy and Security

    view certificates
  3. In the Your Certificates tab, click Import. Locate and open the certificate of the user in the PKCS12 format, then click OK and OK.
  4. Make sure that the Identity Management Certificate Authority is recognized by Firefox as a trusted authority:

    1. Save the IdM CA certificate locally:

      • Navigate to the IdM web UI by writing the name of your IdM server in the Firefox address bar. Click Advanced on the Insecure Connection warning page.

        .Insecure Connection

        connection not secure idm
      • Add Exception. Click View.

        .View the Details of a Certificate

        view ca certificate idm
      • In the Details tab, highlight the Certificate Authority fields.

        .Exporting the CA Certificate

        exporting ca cert idm
      • Click Export. Save the CA certificate, for example as the CertificateAuthority.crt file, then click Close, and Cancel.
    2. Import the IdM CA certificate to Firefox as a trusted certificate authority certificate:

      • Open Firefox, navigate to Preferences and click Privacy & Security.

        .Privacy and Security section in Preferences

        privacy and security
      • Click View Certificates.

        .View Certificates in Privacy and Security

        view certificates
      • In the Authorities tab, click Import. Locate and open the CA certificate that you saved in the previous step in the CertificateAuthority.crt file. Trust the certificate to identify websites, then click OK and OK.
  5. Continue to Authenticating to the Identity Management Web UI with a Certificate as an Identity Management User.

16.5. Authenticating to the Identity Management Web UI with a Certificate as an Identity Management User

This procedure describes authenticating as a user to the Identity Management (IdM) web UI using a certificate stored on the desktop of an Identity Management client.

Procedure

  1. In the browser, navigate to the Identity Management web UI at, for example, https://server.idm.example.com/ipa/ui.
  2. Click Login Using Certificate.

    .Login Using Certificate in the Identity Management web UI

    smart card login
  3. The user’s certificate should already be selected. Uncheck Remember this decision, then click OK.

You are now authenticated as the user who corresponds to the certificate.

Additional resources

  • For information about authenticating to the IdM web UI using a certificate stored on a smart card, see

16.6. Configuring an IdM client to enable authenticating to the CLI using a certificate

To make certificate authentication work for an IdM user in the Command Line Interface (CLI) of your IdM client, import the IdM user’s certificate and the private key to the IdM client. For details on creating and transferring the user certificate, see Section 16.2, “Requesting a new user certificate and exporting it to the client”.

Procedure

  • Log into the IdM client and have the .p12 file containing the user’s certificate and the private key ready. To obtain and cache the Kerberos ticket granting ticket (TGT), run the kinit command with the user’s principal, using the -X option with the X509_username:/path/to/file.p12 attribute to specify where to find the user’s X509 identity information. For example, to obtain the TGT for idm_user using the user’s identity information stored in the ~/idm_user.p12 file:

    $ kinit -X X509_idm_user='PKCS12:~/idm_user.p12' idm_user
    Note

    The command also supports the .pem file format: kinit -X X509_username='FILE:/path/to/cert.pem,/path/to/key' user_principal

Chapter 17. Configuring certificate mapping rules in Identity Management

17.1. Certificate mapping rules for configuring authentication on smart cards

Certificate mapping rules are a convenient way of allowing users to authenticate using certificates in scenarios when the Identity Management (IdM) administrator does not have access to certain users' certificates. This lack of access is typically caused by the fact that the certificates have been issued by an external certificate authority. A special use case is represented by certificates issued by the Certificate System of an Active Directory (AD) with which the IdM domain is in a trust relationship.

Certificate mapping rules are also convenient if the IdM environment is large with a lot of users using smart cards. In this situation, adding full certificates can be complicated. The subject and issuer are predictable in most scenarios and thus easier to add ahead of time than the full certificate. As a system administrator, you can create a certificate mapping rule and add certificate mapping data to a user entry even before a certificate is issued to a particular user. Once the certificate is issued, the user will be able to log in using the certificate even though the full certificate is not uploaded into his entry.

In addition, as certificates have to be renewed at regular intervals, certificate mapping rules reduce administrative overhead. When a user’s certificate gets renewed, the administrator does not have to update the user entry. For example, if the mapping is based on the Subject and Issuer values, and if the new certificate has the same subject and issuer as the old one, the mapping still applies. If, in contrast, the full certificate was used, then the administrator would have to upload the new certificate to the user entry to replace the old one.

To set up certificate mapping:

  1. An administrator has to load the certificate mapping data (typically the issuer and subject) or the full certificate into a user account.
  2. An administrator has to create a certificate mapping rule to allow successful logging into IdM for a user

    1. whose account contains a certificate mapping data entry
    2. whose certificate mapping data entry matches the information on the certificate

    For details on the individual components that make up a mapping rule and how to obtain and use them, see Components of an identity mapping rule in IdM and Obtaining the issuer from a certificate for use in a matching rule.

Afterwards, when the end-user presents his certificate, stored either in the filesystem or on a smart card, he authenticates successfully.

17.1.1. Certificate mapping rules for trusts with Active Directory domains

This section outlines the different certificate mapping use cases that are possible if an IdM deployment is in a trust relationship with an Active Directory (AD) domain.

Certificate mapping rules are a convenient way to enable access to IdM resources for users who have smart card certificates that were issued by the trusted AD Certificate System. Depending on the AD configuration, the following scenarios are possible:

17.1.2. Components of an identity mapping rule in IdM

This section describes the components of an identity mapping rule in IdM and how to configure them. Each component has a default value that you can override. You can define the components in either the web UI or the CLI. In the CLI, the identity mapping rule is created using the ipa certmaprule-add command.

Mapping rule

The mapping rule component associates (or maps) a certificate with one or more user accounts. The rule defines an LDAP search filter that associates a certificate with the intended user account.

Certificates issued by different certificate authorities (CAs) might have different properties and might be used in different domains. Therefore, IdM does not apply mapping rules unconditionally, but only to the appropriate certificates. The appropriate certificates are defined using matching rules.

Note that if you leave the mapping rule option empty, the certificates are searched in the userCertificate attribute as a DER encoded binary file.

Define the mapping rule in the CLI using the --maprule option.

Matching rule

The matching rule component selects a certificate to which you want to apply the mapping rule. The default matching rule matches certificates with the digitalSignature key usage and clientAuth extended key usage.

Define the matching rule in the CLI using the --matchrule option.

Domain list

The domain list specifies the identity domains in which you want IdM to search the users when processing identity mapping rules. If you leave the option unspecified, IdM searches the users only in the local domain to which the IdM client belongs.

Define the domain in the CLI using the --domain option.

Priority

When multiple rules are applicable to a certificate, the rule with the highest priority takes precedence. All other rules are ignored.

  • The lower the numerical value, the higher the priority of the identity mapping rule. For example, a rule with a priority 1 has higher priority than a rule with a priority 2.
  • If a rule has no priority value defined, it has the lowest priority.

Define the mapping rule priority in the CLI using the --priority option.

Certificate mapping rule example

To define, using the CLI, a certificate mapping rule called simple_rule that allows authentication for a certificate issued by the Smart Card CA of the EXAMPLE.ORG organisation as long as the Subject on that certificate matches a certmapdata entry in a user account in IdM:

# ipa certmaprule-add simple_rule --matchrule '<ISSUER>CN=Smart Card CA,O=EXAMPLE.ORG' --maprule '(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})'

17.1.3. Obtaining the issuer from a certificate for use in a matching rule

This procedure describes how to obtain the issuer information from a certificate so that you can copy and paste it into the matching rule of a certificate mapping rule. To get the issuer format required by a matching rule, use the openssl x509 utility.

Prerequisites

  • You have the user certificate in a .pem or .crt format

Procedure

  1. Obtain the user information from the certificate. Use the openssl x509 certificate display and signing utility with:

    • the -noout option to prevent the output of an encoded version of the request
    • the -issuer option to output the issuer name
    • the -in option to specify the input file name to read the certificate from
    • the -nameopt option with the RFC2253 value to display the output with the most specific relative distinguished name (RDN) first

      If the input file contains an Identity Management certificate, the output of the command shows that the Issuer is defined using the Organisation information:

      # openssl x509 -noout -issuer -in idm_user.crt -nameopt RFC2253
      issuer=CN=Certificate Authority,O=REALM.EXAMPLE.COM

      If the input file contains an Active Directory certificate, the output of the command shows that the Issuer is defined using the Domain Component information:

      # openssl x509 -noout -issuer -in ad_user.crt -nameopt RFC2253
      issuer=CN=AD-WIN2012R2-CA,DC=AD,DC=EXAMPLE,DC=COM
  2. Optionally, to create a new mapping rule in the CLI based on a matching rule which specifies that the certificate issuer must be the extracted AD-WIN2012R2-CA of the ad.example.com domain and the subject on the certificate must match the certmapdata entry in a user account in IdM:

    # ipa certmaprule-add simple_rule --matchrule '<ISSUER>CN=AD-WIN2012R2-CA,DC=AD,DC=EXAMPLE,DC=COM' --maprule '(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})'

Additional information

For details about the supported formats for the matching rule and the mapping rule, and an explanation of the priority and domain fields, see the sss-certmap(5) man page.

17.2. Configuring certificate mapping for users stored in IdM

This user story describes the steps a system administrator must take to enable certificate mapping in IdM if the user for whom certificate authentication is being configured is stored in IdM.

Prerequisites

  • The user has an account in IdM.
  • The administrator has either the whole certificate or the certificate mapping data to add to the user entry.

17.2.1. Adding a certificate mapping rule in IdM

This section describes how to set up a certificate mapping rule so that IdM users with certificates that match the conditions specified in the mapping rule and in their certificate mapping data entries can authenticate to IdM.

17.2.1.1. Adding a certificate mapping rule in the IdM web UI

  1. Log in to the IdM web UI as an administrator.
  2. Navigate to AuthenticationCertificate Identity Mapping RulesCertificate Identity Mapping Rules.
  3. Click Add.

    Figure 17.1. Adding a new certificate mapping rule in the IdM web UI

    new certmaprule add
  4. Enter the rule name.
  5. Enter the mapping rule. For example, to make IdM search for the Issuer and Subject entries in any certificate presented to them, and base its decision to authenticate or not on the information found in these two entries of the presented certificate:

    (ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})
  6. Enter the matching rule. For example, to only allow certificates issued by the Smart Card CA of the EXAMPLE.ORG organization to authenticate users to IdM:

    <ISSUER>CN=Smart Card CA,O=EXAMPLE.ORG

    Figure 17.2. Entering the details for a certificate mapping rule in the IdM web UI

    certmaprule add details1
  7. Click Add at the bottom of the dialog box to add the rule and close the box.
  8. The System Security Services Daemon (SSSD) periodically re-reads the certificate mapping rules. To force the newly-created rule to be loaded immediately, restart SSSD:

    # systemctl restart sssd

Now you have a certificate mapping rule set up that compares the type of data specified in the mapping rule that it finds on a smart card certificate with the certificate mapping data in your IdM user entries. Once it finds a match, it authenticates the matching user.

17.2.1.2. Adding a certificate mapping rule in the IdM CLI

  1. Obtain the administrator’s credentials:

    # kinit admin
  2. Enter the mapping rule and the matching rule the mapping rule is based on. For example, to make IdM search for the Issuer and Subject entries in any certificate presented, and base its decision to authenticate or not on the information found in these two entries of the presented certificate, recognizing only certificates issued by the Smart Card CA of the EXAMPLE.ORG organization:

    # ipa certmaprule-add rule_name --matchrule '<ISSUER>CN=Smart Card CA,O=EXAMPLE.ORG' --maprule '(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})'
    -------------------------------------------------------
    Added Certificate Identity Mapping Rule "rule_name"
    -------------------------------------------------------
      Rule name: rule_name
      Mapping rule: (ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})
      Matching rule: <ISSUER>CN=Smart Card CA,O=EXAMPLE.ORG
      Enabled: TRUE
  3. The System Security Services Daemon (SSSD) periodically re-reads the certificate mapping rules. To force the newly-created rule to be loaded immediately, restart SSSD:

    # systemctl restart sssd

Now you have a certificate mapping rule set up that compares the type of data specified in the mapping rule that it finds on a smart card certificate with the certificate mapping data in your IdM user entries. Once it finds a match, it authenticates the matching user.

17.2.2. Adding certificate mapping data to a user entry in IdM

This section describes how to enter certificate mapping data to an IdM user entry so that the user can authenticate using multiple certificates as long as they all contain the values specified in the certificate mapping data entry.

17.2.2.1. Adding certificate mapping data to a user entry in the IdM web UI

  1. Log into the IdM web UI as an administrator.
  2. Navigate to UsersActive usersidm_user.
  3. Find the Certificate mapping data option and click Add.
  4. If you have the certificate of idm_user at your disposal:

    1. In the Command-Line Interface, display the certificate using the cat utility or a text editor:

      [root@server ~]# cat idm_user_certificate.pem
      -----BEGIN CERTIFICATE-----
      MIIFFTCCA/2gAwIBAgIBEjANBgkqhkiG9w0BAQsFADA6MRgwFgYDVQQKDA9JRE0u
      RVhBTVBMRS5DT00xHjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0x
      ODA5MDIxODE1MzlaFw0yMDA5MDIxODE1MzlaMCwxGDAWBgNVBAoMD0lETS5FWEFN
      [...output truncated...]
    2. Copy the certificate.
    3. In the IdM web UI, click Add next to Certificate and paste the certificate into the window that opens up.

      Figure 17.3. Adding a user’s certificate mapping data: certificate

      user add cert

      Alternatively, if you do not have the certificate of idm_user at your disposal but know the Issuer and the Subject of the certificate, check the radio button of Issuer and subject and enter the values in the two respective boxes.

      Figure 17.4. Adding a user’s certificate mapping data: issuer and subject

      user add certdata
  5. Click Add.
  6. Optionally, if you have access to the whole certificate in the .pem format, verify that the user and certificate are linked:

    1. Use the sss_cache utility to invalidate the record of idm_user in the SSSD cache and force a reload of the idm_user information:

      # sss_cache -u idm_user
    2. Run the ipa certmap-match command with the name of the file containing the certificate of the IdM user:

      # ipa certmap-match idm_user_cert.pem
      --------------
      1 user matched
      --------------
       Domain: IDM.EXAMPLE.COM
       User logins: idm_user
      ----------------------------
      Number of entries returned 1
      ----------------------------

      The output confirms that now you have certificate mapping data added to idm_user and that a corresponding mapping rule defined in Adding a certificate mapping rule in IdM exists. This means that you can use any certificate that matches the defined certificate mapping data to authenticate as idm_user.

17.2.2.2. Adding certificate mapping data to a user entry in the IdM CLI

  1. Obtain the administrator’s credentials:

    # kinit admin
  2. If you have the certificate of idm_user at your disposal, add the certificate to the user account using the ipa user-add-cert command:

    # CERT=`cat idm_user_cert.pem | tail -n +2| head -n -1 | tr -d '\r\n'\`
    # ipa user-add-certmapdata idm_user --certificate $CERT

    Alternatively, if you do not have the certificate of idm_user at your disposal but know the Issuer and the Subject of idm_user’s certificate:

    # ipa user-add-certmapdata idm_user --subject "O=EXAMPLE.ORG,CN=test" --issuer "CN=Smart Card CA,O=EXAMPLE.ORG"
    --------------------------------------------
    Added certificate mappings to user "idm_user"
    --------------------------------------------
      User login: idm_user
      Certificate mapping data: X509:<I>O=EXAMPLE.ORG,CN=Smart Card CA<S>CN=test,O=EXAMPLE.ORG
  3. Optionally, if you have access to the whole certificate in the .pem format, verify that the user and certificate are linked:

    1. Use the sss_cache utility to invalidate the record of idm_user in the SSSD cache and force a reload of the idm_user information:

      # sss_cache -u idm_user
    2. Run the ipa certmap-match command with the name of the file containing the certificate of the IdM user:

      # ipa certmap-match idm_user_cert.pem
      --------------
      1 user matched
      --------------
       Domain: IDM.EXAMPLE.COM
       User logins: idm_user
      ----------------------------
      Number of entries returned 1
      ----------------------------

      The output confirms that now you have certificate mapping data added to idm_user and that a corresponding mapping rule defined in Adding a certificate mapping rule in IdM exists. This means that you can use any certificate that matches the defined certificate mapping data to authenticate as idm_user.

17.3. Configuring certificate mapping for users whose AD user entry contains the whole certificate

This user story describes the steps necessary for enabling certificate mapping in IdM if the IdM deployment is in trust with Active Directory (AD), the user is stored in AD and the user entry in AD contains the whole certificate.

Prerequisites

  • The user does not have an account in IdM.
  • The user has an account in AD which contains a certificate.
  • The IdM administrator has access to data on which the IdM certificate mapping rule can be based.

17.3.1. Adding a certificate mapping rule for users whose AD entry contains whole certificates

17.3.1.1. Adding a certificate mapping rule in the IdM web UI

  1. Log into the IdM web UI as an administrator.
  2. Navigate to AuthenticationCertificate Identity Mapping RulesCertificate Identity Mapping Rules.
  3. Click Add.

    Figure 17.5. Adding a new certificate mapping rule in the IdM web UI

    new certmaprule add
  4. Enter the rule name.
  5. Enter the mapping rule. To have the whole certificate that is presented to IdM for authentication compared to what is available in AD:

    (userCertificate;binary={cert!bin})
  6. Enter the matching rule. For example, to only allow certificates issued by the AD-ROOT-CA of the AD.EXAMPLE.COM domain to authenticate:

    <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com

    Figure 17.6. Certificate mapping rule for a user with a certificate stored in AD

    certmaprule add details ad cert
  7. Click Add.
  8. The System Security Services Daemon (SSSD) periodically re-reads the certificate mapping rules. To force the newly-created rule to be loaded immediately, restart SSSD in the CLI::

    # systemctl restart sssd

17.3.1.2. Adding a certificate mapping rule in the IdM CLI

  1. Obtain the administrator’s credentials:

    # kinit admin
  2. Enter the mapping rule and the matching rule the mapping rule is based on. To have the whole certificate that is presented for authentication compared to what is available in AD, only allowing certificates issued by the AD-ROOT-CA of the AD.EXAMPLE.COM domain to authenticate:

    # ipa certmaprule-add simpleADrule --matchrule '<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com' --maprule '(userCertificate;binary={cert!bin})' --domain ad.example.com
    -------------------------------------------------------
    Added Certificate Identity Mapping Rule "simpleADrule"
    -------------------------------------------------------
      Rule name: simpleADrule
      Mapping rule: (userCertificate;binary={cert!bin})
      Matching rule: <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
      Domain name: ad.example.com
      Enabled: TRUE
  3. The System Security Services Daemon (SSSD) periodically re-reads the certificate mapping rules. To force the newly-created rule to be loaded immediately, restart SSSD:

    # systemctl restart sssd

17.4. Configuring certificate mapping if AD is configured to map user certificates to user accounts

This user story describes the steps necessary for enabling certificate mapping in IdM if the IdM deployment is in trust with Active Directory (AD), the user is stored in AD and the user entry in AD contains certificate mapping data.

Prerequisites

  • The user does not have an account in IdM.
  • The user has an account in AD which contains the altSecurityIdentities attribute, the AD equivalent of the IdM certmapdata attribute.
  • The IdM administrator has access to data on which the IdM certificate mapping rule can be based.

17.4.1. Adding a certificate mapping rule if the trusted AD domain is configured to map user certificates

17.4.1.1. Adding a certificate mapping rule in the IdM web UI

  1. Log into the IdM web UI as an administrator.
  2. Navigate to AuthenticationCertificate Identity Mapping RulesCertificate Identity Mapping Rules.
  3. Click Add.

    Figure 17.7. Adding a new certificate mapping rule in the IdM web UI

    new certmaprule add
  4. Enter the rule name.
  5. Enter the mapping rule. For example, to make AD DC search for the Issuer and Subject entries in any certificate presented, and base its decision to authenticate or not on the information found in these two entries of the presented certificate:

    (altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500})
  6. Enter the matching rule. For example, to only allow certificates issued by the AD-ROOT-CA of the AD.EXAMPLE.COM domain to authenticate users to IdM:

    <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
  7. Enter the domain:

    ad.example.com

    Figure 17.8. Certificate mapping rule if AD is configured for mapping

    certmaprule add details ad map
  8. Click Add.
  9. The System Security Services Daemon (SSSD) periodically re-reads the certificate mapping rules. To force the newly-created rule to be loaded immediately, restart SSSD in the CLI::

    # systemctl restart sssd

17.4.1.2. Adding a certificate mapping rule in the IdM CLI

  1. Obtain the administrator’s credentials:

    # kinit admin
  2. Enter the mapping rule and the matching rule the mapping rule is based on. For example, to make AD search for the Issuer and Subject entries in any certificate presented, and only allow certificates issued by the AD-ROOT-CA of the AD.EXAMPLE.COM domain:

    # ipa certmaprule-add ad_configured_for_mapping_rule --matchrule '<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com' --maprule '(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500})' --domain=ad.example.com
    -------------------------------------------------------
    Added Certificate Identity Mapping Rule "ad_configured_for_mapping_rule"
    -------------------------------------------------------
      Rule name: ad_configured_for_mapping_rule
      Mapping rule: (altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500})
      Matching rule: <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
      Domain name: ad.example.com
      Enabled: TRUE
  3. The System Security Services Daemon (SSSD) periodically re-reads the certificate mapping rules. To force the newly-created rule to be loaded immediately, restart SSSD:

    # systemctl restart sssd

17.4.2. Checking certificate mapping data on the AD side

The altSecurityIdentities attribute is the Active Directory (AD) equivalent of certmapdata user attribute in IdM. When configuring certificate mapping in IdM in the scenario when a trusted AD domain is configured to map user certificates to user accounts, the IdM system administrator needs to check that the altSecurityIdentities attribute is set correctly in the user entries in AD.

To check that AD contains the right information for the user stored in AD, use the ldapsearch command.

  • For example, to check with the adserver.ad.example.com server that the altSecurityIdentities attribute is set in the user entry of ad_user and that the matchrule stipulates that the certificate that ad_user uses to authenticate to AD was issued by AD-ROOT-CA of the ad.example.com domain and that the subject is <S>DC=com,DC=example,DC=ad,CN=Users,CN=ad_user:

    $ ldapsearch -o ldif-wrap=no -LLL -h adserver.ad.example.com \
    -p 389 -D cn=Administrator,cn=users,dc=ad,dc=example,dc=com \
    -W -b cn=users,dc=ad,dc=example,dc=com "(cn=ad_user)" \
    altSecurityIdentities
    Enter LDAP Password:
    dn: CN=ad_user,CN=Users,DC=ad,DC=example,DC=com
    altSecurityIdentities: X509:<I>DC=com,DC=example,DC=ad,CN=AD-ROOT-CA<S>DC=com,DC=example,DC=ad,CN=Users,CN=ad_user

17.5. Configuring certificate mapping if AD user entry contains no certificate or mapping data

This user story describes the steps necessary for enabling certificate mapping in IdM if the IdM deployment is in trust with Active Directory (AD), the user is stored in AD and the user entry in AD contains neither the whole certificate nor certificate mapping data.

Prerequisites

  • The user does not have an account in IdM.
  • The user has an account in AD which contains neither the whole certificate nor the altSecurityIdentities attribute, the AD equivalent of the IdM certmapdata attribute.
  • The IdM administrator has the whole AD user certificate to add to the AD user’s user ID override in IdM.

17.5.1. Adding a certificate mapping rule if the AD user entry contains no certificate or mapping data

17.5.1.1. Adding a certificate mapping rule in the IdM web UI

  1. Log into the IdM web UI as an administrator.
  2. Navigate to AuthenticationCertificate Identity Mapping RulesCertificate Identity Mapping Rules.
  3. Click Add.

    Figure 17.9. Adding a new certificate mapping rule in the IdM web UI

    new certmaprule add
  4. Enter the rule name.
  5. Enter the mapping rule. To have the whole certificate that is presented to IdM for authentication compared to the certificate stored in the user ID override entry of the AD user entry in IdM:

    (userCertificate;binary={cert!bin})
  6. Enter the matching rule. For example, to only allow certificates issued by the AD-ROOT-CA of the AD.EXAMPLE.COM domain to authenticate:

    <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
  7. Enter the domain name. For example, to search for users in the ad.example.com domain:

    Figure 17.10. Certificate mapping rule for a user with no certificate or mapping data stored in AD

    certmaprule add details ad cert
  8. Click Add.
  9. The System Security Services Daemon (SSSD) periodically re-reads the certificate mapping rules. To force the newly-created rule to be loaded immediately, restart SSSD in the CLI:

    # systemctl restart sssd

17.5.1.2. Adding a certificate mapping rule in the IdM CLI

  1. Obtain the administrator’s credentials:

    # kinit admin
  2. Enter the mapping rule and the matching rule the mapping rule is based on. To have the whole certificate that is presented for authentication compared to the certificate stored in the user ID override entry of the AD user entry in IdM, only allowing certificates issued by the AD-ROOT-CA of the AD.EXAMPLE.COM domain to authenticate:

    # ipa certmaprule-add simpleADrule --matchrule '<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com' --maprule '(userCertificate;binary={cert!bin})' --domain ad.example.com
    -------------------------------------------------------
    Added Certificate Identity Mapping Rule "simpleADrule"
    -------------------------------------------------------
      Rule name: simpleADrule
      Mapping rule: (userCertificate;binary={cert!bin})
      Matching rule: <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
      Domain name: ad.example.com
      Enabled: TRUE
  3. The System Security Services Daemon (SSSD) periodically re-reads the certificate mapping rules. To force the newly-created rule to be loaded immediately, restart SSSD:

    # systemctl restart sssd

17.5.2. Adding a certificate to an AD user’s ID override if the user entry in AD contains no certificate or mapping data

17.5.2.1. Adding a certificate to an AD user’s ID override in the IdM web UI

  1. Navigate to IdentityID ViewsDefault Trust View.
  2. Click Add.

    Figure 17.11. Adding a new user ID override in the IdM web UI

    new useridoverride add
  3. In the User to override field, enter ad_user@ad.example.com.
  4. Copy and paste the certificate of ad_user into the Certificate field.

    Figure 17.12. Configuring the User ID override for an AD user

    useridoverride add details
  5. Click Add.
  6. Optionally, verify that the user and certificate are linked:

    1. Use the sss_cache utility to invalidate the record of ad_user@ad.example.com in the SSSD cache and force a reload of the ad_user@ad.example.com information:

      # sss_cache -u ad_user@ad.example.com
    2. Run the ipa certmap-match command with the name of the file containing the certificate of the AD user:

      # ipa certmap-match ad_user_cert.pem
      --------------
      1 user matched
      --------------
       Domain: AD.EXAMPLE.COM
       User logins: ad_user@ad.example.com
      ----------------------------
      Number of entries returned 1
      ----------------------------

      The output confirms that you have certificate mapping data added to ad_user@ad.example.com and that a corresponding mapping rule defined in Adding a certificate mapping rule if the AD user entry contains no certificate or mapping data exists. This means that you can use any certificate that matches the defined certificate mapping data to authenticate as ad_user@ad.example.com.

17.5.2.2. Adding a certificate to an AD user’s ID override in the IdM CLI

  1. Obtain the administrator’s credentials:

    # kinit admin
  2. Add the certificate of ad_user@ad.example.com to the user account using the ipa idoverrideuser-add-cert command:

    # CERT=`cat ad_user_cert.pem | tail -n +2| head -n -1 | tr -d '\r\n'\`
    # ipa idoverrideuser-add-cert ad_user@ad.example.com --certificate $CERT
  3. Optionally, verify that the user and certificate are linked:

    1. Use the sss_cache utility to invalidate the record of ad_user@ad.example.com in the SSSD cache and force a reload of the ad_user@ad.example.com information:

      # sss_cache -u ad_user@ad.example.com
    2. Run the ipa certmap-match command with the name of the file containing the certificate of the AD user:

      # ipa certmap-match ad_user_cert.pem
      --------------
      1 user matched
      --------------
       Domain: AD.EXAMPLE.COM
       User logins: ad_user@ad.example.com
      ----------------------------
      Number of entries returned 1
      ----------------------------

      The output confirms that you have certificate mapping data added to ad_user@ad.example.com and that a corresponding mapping rule defined in Adding a certificate mapping rule if the AD user entry contains no certificate or mapping data exists. This means that you can use any certificate that matches the defined certificate mapping data to authenticate as ad_user@ad.example.com.

17.6. Combining several identity mapping rules into one

To combine several identity mapping rules into one combined rule, use the | (or) character to precede the individual mapping rules, and separate them using () brackets, for example:

Certificate mapping filter example 1

$ ipa certmaprule-add ad_cert_for_ipa_and_ad_users \ --maprule='(|(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}))' \ --matchrule='<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com' \ --domain=ad.example.com

In the above example, the filter definition in the --maprule option includes these criteria:

  • ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500} is a filter that links the subject and issuer from a smart card certificate to the value of the ipacertmapdata attribute in an IdM user account, as described in Adding a certificate mapping rule in IdM
  • altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500} is a filter that links the subject and issuer from a smart card certificate to the value of the altSecurityIdentities attribute in an AD user account, as described in Adding a certificate mapping rule if the trusted AD domain is configured to map user certificates
  • The addition of the --domain=ad.example.com option means that users mapped to a given certificate are not only searched in the local idm.example.com domain but also in the ad.example.com domain

The filter definition in the --maprule option accepts the logical operator | (or), so that you can specify multiple criteria. In this case, the rule maps all user accounts that meet at least one of the criteria.

Certificate mapping filter example 2

$ ipa certmaprule-add ipa_cert_for_ad_users \
  --maprule='(|(userCertificate;binary={cert!bin})(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}))' \
  --matchrule='<ISSUER>CN=Certificate Authority,O=REALM.EXAMPLE.COM' \
  --domain=idm.example.com --domain=ad.example.com

In the above example, the filter definition in the --maprule option includes these criteria:

The filter definition in the --maprule option accepts the logical operator | (or), so that you can specify multiple criteria. In this case, the rule maps all user accounts that meet at least one of the criteria.

Chapter 18. Using IdM CA renewal master

18.1. Explanation of IdM CA renewal master

The Identity Management (IdM) certificate authority (CA) renewal master server maintains and renews IdM system certificates. It ensures nondisruptive IdM deployments.

IdM system certificates include:

  • IdM CA certificate
  • OCSP signing certificate
  • IdM CA subsystem certificates
  • IdM CA audit signing certificate
  • IdM renewal agent (RA) certificate
  • KRA transport and storage certificates

What characterizes system certificates is that their keys are shared by all CA replicas. In contrast, the IdM service certificates (for example, LDAP, HTTP and PKINIT certificates), have different keypairs and subject names on different IdM CA servers.

In IdM topology, by default, the first master IdM CA server is the CA renewal master.

Note

In upstream documentation, the IdM CA is called Dogtag.

The role of the CA renewal master server

The IdM CA, IdM CA subsystem, and IdM RA certificates are crucial for IdM deployment. Each certificate is stored in an NSS database in the /etc/pki/pki-tomcat/ directory and also as an LDAP database entry. The certificate stored in LDAP must match the certificate stored in the NSS database. If they do not match, authentication failures occur between the IdM framework and IdM CA, and between IdM CA and LDAP.

All IdM CA replicas have tracking requests for every system certificate. If an IdM deployment with integrated CA does not contain a CA renewal master, each IdM CA server requests the renewal of system certificates independently. This results in different CA replicas having various system certificates and authentication failures occurring.

Appointing one CA replica as the renewal master allows the system certificates to be renewed exactly once, when required, and thus prevents authentication failures.

The role of certmonger on CA replicas

The certmonger service running on all IdM CA replicas uses the dogtag-ipa-ca-renew-agent renewal helper to keep track of IdM system certificates. The renewal helper program reads the CA renewal master configuration. On each CA replica that is not the CA renewal master, the renewal helper programme retrieves the latest system certificates from the ca_renewal LDAP entries. Due to non-determinism in when exactly certmonger renewal attempts occur, the dogtag-ipa-ca-renew-agent helper sometimes attempts to update a system certificate before the CA renewal master has actually renewed the certificate. If this happens, the old, soon-to-expire certificate is returned to the certmonger on the CA replica. The certmonger, realizing it is the same certificate that is already stored in its database, keeps attempting to renew the certificate with some delay between individual attempts until it can retrieve the updated certificate from the CA renewal master.

The correct functioning of IdM CA renewal master

An IdM deployment with an embedded CA is an IdM deployment that was installed with an IdM CA - or whose IdM CA master server was installed later. An IdM deployment with an embedded CA must at all times have exactly one CA replica configured as the renewal master. The renewal master server must be online and fully functional, and must replicate properly with the other servers.

If the current CA renewal master server is being deleted using the ipa server-del, ipa-replica-manage del, ipa-csreplica-manage del or ipa-server-install --uninstall commands, a CA replica is automatically assigned as the CA renewal master server. This policy ensures that the renewal master configuration remains valid.

This policy does not cover the following situations:

  • Offline renewal master

    • If the renewal master is offline for an extended duration, it may miss a renewal window. In this situation, all nonrenewal master servers keep reinstalling the current system certificates until the certificates expire. When this occurs, the IdM deployment is disrupted because even one expired certificate can cause renewal failures for other certificates. To prevent this situation: if your current renewal master is offline and unavailable for an extended period of time, consider assigning a new CA renewal master manually.
  • Replication problems

    • If replication problems exist between the renewal master and other CA replicas, renewal might succeed, but the other CA replicas might not be able to retrieve the updated certificates before they expire. To prevent this situation, make sure that your replication agreements are working correctly. For details, see general or specific replication troubleshooting guidelines in the RHEL 7 Linux Domain Identity, Authentication, and Policy Guide.

18.2. Changing and resetting IdM CA renewal master

When a CA renewal master is being decommissioned, IdM automatically selects a new CA renewal master from the list of IdM CA servers. The system administrator cannot influence the selection.

To be able to select the new IdM CA renewal master server, the system administrator must perform the replacement manually. Select the master before starting the process of decommissioning the current renewal master.

If the current CA renewal master configuration is invalid, reset the IdM CA renewal master.

Complete this procedure to change or reset the CA renewal master.

Prerequisites

  • You have the IdM administrator credentials.

Procedure

  1. Obtain the IdM administrator credentials:

    ~]$ kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  2. Optionally, to find out which IdM servers in the deployment have the CA role necessary to be eligible to become the new CA renewal master:

    ~]$ ipa server-role-find --role 'CA server'
    ----------------------
    2 server roles matched
    ----------------------
      Server name: server.idm.example.com
      Role name: CA server
      Role status: enabled
    
      Server name: replica.idm.example.com
      Role name: CA server
      Role status: enabled
    ----------------------------
    Number of entries returned 2
    ----------------------------

    There are two CA servers in the deployment.

  3. Optionally, to find out which CA server is the current CA renewal master:

    ~]$ ipa config-show | grep 'CA renewal master'
      IPA CA renewal master: server.idm.example.com

    The current renewal master is server.idm.example.com.

  4. To change the renewal master configuration, use the ipa config-mod utility with the --ca-renewal-master-server option:

    ~]$ ipa config-mod --ca-renewal-master-server replica.idm.example.com | grep 'CA renewal master'
      IPA CA renewal master: replica.idm.example.com
    Important

    You can also switch to a new CA renewal master using:

    • the ipa-cacert-manage --renew command. This command both renews the CA certificate and makes the CA server on which you execute the command the new CA renewal master.
    • the ipa-cert-fix command. This command renews the expired CA system certificates and fixes the broken deployment. It also makes the CA server on which you execute the command the new CA renewal master.

      For details, see Renewing expired system certificates when IdM is offline.

18.3. Switching from an externally to self-signed CA in IdM

Complete this procedure to switch from an externally-signed to a self-signed certificate of the IdM certificate authority (CA). With a self-signed CA, the renewal of the CA certificate is managed automatically: a system administrator does not need to submit a CSR to an external authority.

Switching from an externally-signed to a self-signed CA replaces only the CA certificate. The certificates signed by the previous CA are still valid and still in use. For example, the certificate chain for the LDAP certificate remains unchanged even after you have moved to a self-signed CA:

external_CA certificate > IdM CA certificate > LDAP certificate

Prerequisites

  • You have root access to the IdM CA renewal master.
  • You have the IdM administrator credentials.

Procedure

  1. On the IdM CA renewal master, renew the CA certificate as self-signed:

    ~]# ipa-cacert-manage renew --self-signed
    Renewing CA certificate, please wait
    CA certificate successfully renewed
    The ipa-cacert-manage command was successful
  2. On all the IdM servers and clients, update the local IdM certificate databases with the certificates from the server:

    [client ~]$ kinit admin
    [client ~]$ ipa-certupdate
    Systemwide CA database updated.
    Systemwide CA database updated.
    The ipa-certupdate command was successful
  3. Optionally, to check if your update has been successful and the new CA certificate has been added to the /etc/ipa/ca.crt file:

    [client ~]$ openssl crl2pkcs7 -nocrl -certfile /etc/ipa/ca.crt | openssl pkcs7 -print_certs -text -noout
    [...]
    Certificate:
        Data:
            Version: 3 (0x2)
            Serial Number: 39 (0x27)
            Signature Algorithm: sha256WithRSAEncryption
            Issuer: O=IDM.EXAMPLE.COM, CN=Certificate Authority
            Validity
                Not Before: Jul  1 16:32:45 2019 GMT
                Not After : Jul  1 16:32:45 2039 GMT
            Subject: O=IDM.EXAMPLE.COM, CN=Certificate Authority
    [...]

    The output shows that the update has been successful as the new CA certificate is listed with the older CA certificates.

18.4. Renewing the IdM CA renewal master with an externally-signed certificate

This section describes how to renew the IdM CA certificate using an external certificate authority to sign the certificate signing request (CSR). In this configuration, your IdM CA server is a subCA of the external CA. The external CA can, but does not have to, be an Active Directory Certificate Server (AD CS).

If the external certificate authority is AD CS, you can specify the template you want for the IdM CA certificate in the CSR. A certificate template defines the policies and rules that a CA uses when a certificate request is received. Certificate templates in AD correspond to certificate profiles in IdM.

You can define a specific AD CS template by its Object Identifier (OID). OIDs are unique numeric values issued by various issuing authorities to uniquely identify data elements, syntaxes, and other parts of distributed applications.

Alternatively, you can define a specific AD CS template by its name. For example, the name of the default profile used in a CSR submitted by an IdM CA to an AD CS is subCA.

To define a profile by specifying its OID or name in the CSR, use the external-ca-profile option. For details, see the ipa-cacert-manage man page.

Apart from using a ready-made certificate template, you can also create a custom certificate template in the AD CS, and use it in the CSR.

Prerequisites

  • You have root access to the IdM CA renewal master.
  • You have the IdM administrator credentials.

Procedure

Complete this procedure to renew the certificate of the IdM CA with external signing, regardless of whether current CA certificate is self-signed or externally-signed.

  1. Create a CSR to be submitted to the external CA:

    • If the external CA is an AD CS, use the --external-ca-type=ms-cs option. If you want a different template than the default subCA template, specify it using the --external-ca-profile option:

      ~]# ipa-cacert-manage renew --external-ca --external-ca-type=ms-cs [--external-ca-profile=PROFILE]
      Exporting CA certificate signing request, please wait
      The next step is to get /var/lib/ipa/ca.csr signed by your CA and re-run ipa-cacert-manage as:
      ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate
      The ipa-cacert-manage command was successful
    • If the external CA is not an AD CS:

      ~]# ipa-cacert-manage renew --external-ca
      Exporting CA certificate signing request, please wait
      The next step is to get /var/lib/ipa/ca.csr signed by your CA and re-run ipa-cacert-manage as:
      ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate
      The ipa-cacert-manage command was successful

      The output shows that a CSR has been created and is stored in the /var/lib/ipa/ca.csr file.

  2. Submit the CSR located in /var/lib/ipa/ca.csr to the external CA. The process differs depending on the service to be used as the external CA.
  3. Retrieve the issued certificate and the CA certificate chain for the issuing CA in a base 64-encoded blob, which is:

    • a PEM file if the external CA is not an AD CS.
    • a Base_64 certificate if the external CA is an AD CS.

      The process differs for every certificate service. Usually, a download link on a web page or in the notification email allows the administrator to download all the required certificates.

      If the external CA is an AD CS and you have submitted the CSR with a known template through the Microsoft Windows Certification Authority management window, the AD CS issues the certificate immediately and the Save Certificate dialog appears in the AD CS web interface, asking where to save the issued certificate.

  4. Run the ipa-cacert-manage renew command again, adding all the CA certificate files required to supply a full certificate chain. Specify as many files as you need, using the --external-cert-file option multiple times:

    ~]# ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate_1 --external-cert-file=/path/to/external_ca_certificate_2
  5. On all the IdM servers and clients, update the local IdM certificate databases with the certificates from the server:

    [client ~]$ kinit admin
    [client ~]$ ipa-certupdate
    Systemwide CA database updated.
    Systemwide CA database updated.
    The ipa-certupdate command was successful
  6. Optionally, to check if your update has been successful and the new CA certificate has been added to the /etc/ipa/ca.crt file:

    [client ~]$ openssl crl2pkcs7 -nocrl -certfile /etc/ipa/ca.crt | openssl pkcs7 -print_certs -text -noout
    [...]
    Certificate:
        Data:
            Version: 3 (0x2)
            Serial Number: 39 (0x27)
            Signature Algorithm: sha256WithRSAEncryption
            Issuer: O=IDM.EXAMPLE.COM, CN=Certificate Authority
            Validity
                Not Before: Jul  1 16:32:45 2019 GMT
                Not After : Jul  1 16:32:45 2039 GMT
            Subject: O=IDM.EXAMPLE.COM, CN=Certificate Authority
    [...]

    The output shows that the update has been successful as the new CA certificate is listed with the older CA certificates.

Chapter 19. Renewing expired system certificates when IdM is offline

When a system certificate has expired, Identity Management (IdM) fails to start. IdM supports renewing system certificates when IdM is offline using the ipa-cert-fix tool.

Prerequisites

  • IdM is installed only on Red Hat Enterprise Linux 8.1 or later

19.1. Renewing expired system certificates on a CA Renewal Master

This section describes how to apply the ipa-cert-fix tool on expired IdM certificates.

Important

If you run the ipa-cert-fix tool on a CA (Certificate Authority) host that is not the CA Renewal Master, and the utility renews shared certificates, that host automatically becomes the new CA Renewal Master in the domain. There must be always only one CA Renewal Master in the domain to avoid inconsistencies.

Prerequisites

  • Log in to the server with administration rights

Procedure

  1. Start the ipa-cert-fix tool to analyze the system and list expired certificates that require renewal:

    # ipa-cert-fix
    ...
    The following certificates will be renewed:
    
    Dogtag sslserver certificate:
      Subject: CN=ca1.example.com,O=EXAMPLE.COM 201905222205
      Serial:  13
      Expires: 2019-05-12 05:55:47
    ...
    Enter "yes" to proceed:
  2. Enter yes to start the renewal process:

    Enter "yes" to proceed: yes
    Proceeding.
    Renewed Dogtag sslserver certificate:
      Subject: CN=ca1.example.com,O=EXAMPLE.COM 201905222205
      Serial:  268369925
      Expires: 2021-08-14 02:19:33
    ...
    
    Becoming renewal master.
    The ipa-cert-fix command was successful

    It can take up to one minute before ipa-cert-fix renews all expired certificates.

  3. Optionally, verify that all services are now running:

    # ipactl status
    Directory Service: RUNNING
    krb5kdc Service: RUNNING
    kadmin Service: RUNNING
    httpd Service: RUNNING
    ipa-custodia Service: RUNNING
    pki-tomcatd Service: RUNNING
    ipa-otpd Service: RUNNING
    ipa: INFO: The ipactl command was successful

At this point, certificates have been renewed and services are running. The next step is to check other servers in the IdM domain.

19.2. Verifying other IdM servers in the IdM domain after renewal

After the renewing the CA Renewal Master’s certificates with the ipa-cert-fix tool, you must:

  • Restart all other Identity Management (IdM) servers in the domain.
  • Check if certmonger renewed certificates.
  • If there are other Certificate Authority (CA) replicas with expired system certificates, renew those certificates with the ipa-cert-fix tool as well.

Prerequisites

  • Log in to the server with administration rights.

Procedure

  1. Restart IdM with the --force parameter:

    # ipactl restart --force

    With the --force parameter, the ipactl utility ignores individual service startup failures. For example, if the server is also a CA with expired certificates, the pki-tomcat service fails to start. This is expected and ignored because of using the --force parameter.

  2. After the restart, verify that the certmonger service renewed the certificates (certificate status says MONITORING):

    # getcert list | egrep '^Request|status:|subject:'
    Request ID '20190522120745':
            status: MONITORING
            subject: CN=IPA RA,O=EXAMPLE.COM 201905222205
    Request ID '20190522120834':
            status: MONITORING
            subject: CN=Certificate Authority,O=EXAMPLE.COM 201905222205
    ...

    It can take some time before certmonger renews the shared certificates on the replica.

  3. If the server is also a CA, the previous command reports CA_UNREACHABLE for the certificate the pki-tomcat service uses:

    Request ID '20190522120835':
            status: CA_UNREACHABLE
            subject: CN=ca2.example.com,O=EXAMPLE.COM 201905222205
    ...
  4. To renew this certificate, use the ipa-cert-fix utility:

    # ipa-cert-fix
    Dogtag sslserver certificate:
      Subject: CN=ca2.example.com,O=EXAMPLE.COM
      Serial:  3
      Expires: 2019-05-11 12:07:11
    
    Enter "yes" to proceed: yes
    Proceeding.
    Renewed Dogtag sslserver certificate:
      Subject: CN=ca2.example.com,O=EXAMPLE.COM 201905222205
      Serial:  15
      Expires: 2019-08-14 04:25:05
    
    The ipa-cert-fix command was successful

Now, all IdM certificates have been renewed and work correctly.

Chapter 20. Generating CRL on the IdM CA server

You may need to move generating the Certificate Revocation List (CRL) from one Identity Management (IdM) server to another. It can be necessary, for example, when you want to migrate the server to another system.

Only one server must generate CRL. The CRL generation role is usually co-located with the IdM CA Renewal Master, but this is not mandatory. Before the CRL Generation Master is decommissioned, a new CRL Generation Master must be selected by the administrator and configured.

This chapter describes:

  • Stopping CRL generation on the IdM master.
  • Starting to generate CRL on the IdM replica.

20.1. Stopping CRL generation on IdM master server

To stop the Certificate Revocation List (CRL) generation on the IdM master server, use the ipa-crlgen-manage command.

Before you disable the generation, verify that the server really generates CRL. You can then disable it.

Prerequisites

  • Identity Management (IdM) server is installed on the RHEL 8.1 system or newer.
  • You must be logged in as root.

Procedure

  1. Check if your master server is generating the CRL:

    [root@master ~]# ipa-crlgen-manage status
    CRL generation: enabled
    Last CRL update: 2019-10-31 12:00:00
    Last CRL Number: 6
    The ipa-crlgen-manage command was successful
  2. Stop generating CRL on the master server:

    [root@master ~]# ipa-crlgen-manage disable
    Stopping pki-tomcatd
    Editing /var/lib/pki/pki-tomcat/conf/ca/CS.cfg
    Starting pki-tomcatd
    Editing /etc/httpd/conf.d/ipa-pki-proxy.conf
    Restarting httpd
    CRL generation disabled on the local host. Please make sure to configure CRL generation on another master with ipa-crlgen-manage enable.
    The ipa-crlgen-manage command was successful
  3. Check if the master server stopped to generate CRL:

    [root@master ~]# ipa-crlgen-manage status

The master server stopped to generate CRL. The next step is to enable CRL generation on a different replica or a new master server.

20.2. Starting CRL generation on IdM replica server

You can start the Certificate Revocation List (CRL) generation with the following command: ipa-crlgen-manage

Prerequisites

  • Identity Management (IdM) server is installed on the RHEL 8.1 system or newer.
  • The RHEL system must be an IdM Certificate Authority server.
  • You must be logged in as root.

Procedure

  1. To start with generating CRL:

    [root@replica1 ~]# ipa-crlgen-manage enable
    Stopping pki-tomcatd
    Editing /var/lib/pki/pki-tomcat/conf/ca/CS.cfg
    Starting pki-tomcatd
    Editing /etc/httpd/conf.d/ipa-pki-proxy.conf
    Restarting httpd
    Forcing CRL update
    CRL generation enabled on the local host. Please make sure to have only a single CRL generation master.
    The ipa-crlgen-manage command was successful
  2. To check if CRL is generated:

    [root@replica1 ~]# ipa-crlgen-manage status
    CRL generation: enabled
    Last CRL update: 2019-10-31 12:10:00
    Last CRL Number: 7
    The ipa-crlgen-manage command was successful

Chapter 21. Obtaining an IdM certificate for a service using certmonger

21.1. Certmonger overview

What certmonger does

When Identity Management (IdM) is installed with an integrated IdM Certificate Authority (CA), it uses the certmonger service to track and renew system and service certificates. When the certificate is reaching its expiration date, certmonger manages the renewal process by:

  • regenerating a certificate-signing request (CSR) using the options provided in the original request.
  • submitting the CSR to the IdM CA using the IdM API cert-request command.
  • receiving the certificate from the IdM CA.
  • executing a pre-save command if specified by the original request.
  • installing the new certificate in the location specified in the renewal request: either in an NSS database or in a file.
  • executing a post-save command if specified by the original request. For example, the post-save command can instruct certmonger to restart a relevant service, so that the service picks up the new certificate.

Types of certificates certmonger tracks

Certificates can be divided into system and service certificates.

Unlike service certificates (for example, for HTTP, LDAP and PKINIT), which have different keypairs and subject names on different servers, IdM system certificates and their keys are shared by all CA replicas. The IdM system certificates include:

  • IdM CA certificate
  • OCSP signing certificate
  • IdM CA subsystem certificates
  • IdM CA audit signing certificate
  • IdM renewal agent (RA) certificate
  • KRA transport and storage certificates

The certmonger service tracks the IdM system and service certificates that were requested during the installation of IdM environment with an integrated CA. Certmonger also tracks certificates that have been requested manually by the system administrator for other services running on the IdM host. Certmonger does not track external certificate authority certificates or user certificates.

Certmonger components

The certmonger service consists of two main components:

  • The certmonger daemon, which is the engine tracking the list of certificates and launching renewal commands
  • The getcert utility for the command-line interface (CLI), which allows the system administrator to actively send commands to the certmonger daemon.

More specifically, the system administrator can use the getcert utility to:

21.2. Obtaining an IdM certificate for a service using certmonger

To ensure that communication between browsers and the web service running on your IdM client is secure and encrypted, use a TLS certificate. Obtain the TLS certificate for your web service from the IdM CA.

This section describes how to use certmonger to obtain an IdM certificate for a service (HTTP/webserver.idm.example.com@IDM.EXAMPLE.COM) running on an IdM client.

Using certmonger to request the certificate automatically means that certmonger manages and renews the certificate when it is due for a renewal.

For a visual representation of what happens when certmonger requests a service certificate, see Section 21.3, “Communication flow for certmonger requesting a service certificate”.

Prerequisites

  • The web server is enrolled as an IdM client.
  • You have root access to the IdM client on which you are running the procedure.
  • The service for which you are requesting a certificate does not have to pre-exist in IdM.

Procedure

  1. On the webserver.idm.example.com IdM client on which the HTTP service is running, request a certificate for the service corresponding to the HTTP/webserver.idm.example.com@IDM.EXAMPLE.COM principal; specifying that

    • The certificate is to be stored in the local /etc/pki/tls/certs/httpd.pem file
    • The private key is to be stored in the local /etc/pki/tls/private/httpd.key file
    • That an extensionRequest for a SubjectAltName be added to the signing request with the DNS name of webserver.idm.example.com:

      # ipa-getcert request -K HTTP/webserver.idm.example.com -k /etc/pki/tls/private/httpd.key -f /etc/pki/tls/certs/httpd.pem -D webserver.idm.example.com -C "systemctl restart httpd"
      New signing request "20190604065735" added.

      In the command above:

      • The ipa-getcert request command specifies that the certificate is to be obtained from the IdM CA. The ipa-getcert request command is a shortcut for getcert request -c IPA.
      • The -C option instructs certmonger to restart the httpd service after obtaining the certificate.
      • The -D option specifies the SubjectAltName DNS value to be added to the request.
      • To specify that the certificate be issued with a particular profile, use the -T option.
      • To request a certificate using the named issuer from the specified CA, use the -X ISSUER option.
      Note

      RHEL 8 uses a different SSL module in Apache than the one used in RHEL 7. The SSL module relies on OpenSSL rather than NSS. For this reason, in RHEL 8 you cannot use an NSS database to store the HTTPS certificate and the private key.

  2. Optionally, to check the status of your request:

    # ipa-getcert list -f /etc/pki/tls/certs/httpd.pem
    Number of certificates and requests being tracked: 3.
    Request ID '20190604065735':
        status: MONITORING
        stuck: no
        key pair storage: type=FILE,location='/etc/pki/tls/private/httpd.key'
        certificate: type=FILE,location='/etc/pki/tls/certs/httpd.crt'
        CA: IPA
    [...]

    The output shows that the request is in the MONITORING status, which means that a certificate has been obtained. The locations of the key pair and the certificate are those requested.

21.3. Communication flow for certmonger requesting a service certificate

The diagrams in this section show the stages of what happens when certmonger requests a service certificate from IdM CA server. The sequence consists of these diagrams:

Figure 21.1, “Unencrypted communication” shows the initial situation: without an HTTPS certificate, the communication between the web server and the browser is unencrypted.

Figure 21.1. Unencrypted communication

Certmonger service cert 1


Figure 21.2, “Certmonger requesting a service certificate” shows the system administrator using certmonger to manually request an HTTPS certificate for the Apache web server. Note that when requesting a web server certificate, certmonger does not speak directly to the CA. It proxies through IdM.

Figure 21.2. Certmonger requesting a service certificate

Certmonger service cert 2


Figure 21.3, “IdM CA issuing the service certificate” shows the IdM CA issuing an HTTPS certificate for the web server.

Figure 21.3. IdM CA issuing the service certificate

Certmonger service cert 3


Figure 21.4, “Certmonger applying the service certificate” shows certmonger placing the HTTPS certificate in appropriate locations on the IdM client and, if instructed to do so, restarting the httpd service. The Apache server subsequently uses the HTTPS certificate to encrypt the traffic between itself and the browser.

Figure 21.4. Certmonger applying the service certificate

Certmonger service cert 4


Figure 21.5, “Certmonger requesting a new certificate when the old one is nearing expiration” shows certmonger automatically requesting a renewal of the service certificate from the IdM CA before the expiration of the certificate. The IdM CA issues a new certificate.

Figure 21.5. Certmonger requesting a new certificate when the old one is nearing expiration

Certmonger service cert 5


21.4. Viewing the details of a certificate request tracked by certmonger

The certmonger service monitors certificate requests. When a request for a certificate is successfully signed, it results in a certificate. Certmonger manages certificate requests including the resulting certificates. This section describes how to view the details of a particular certificate request managed by certmonger.

Procedure

  • If you know how to specify the certificate request, list the details of only that particular certificate request. You can, for example, specify:

    • The request ID
    • The location of the certificate
    • The certificate nickname

      For example, to view the details of the certificate whose request ID is 20190408143846, using the -v option to view all the details of errors in case your request for a certificate was unsuccessful:

      # getcert list -i 20190408143846 -v
      Number of certificates and requests being tracked: 16.
      Request ID '20190408143846':
      	status: MONITORING
      	stuck: no
      	key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-IDM-EXAMPLE-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-IDM-EXAMPLE-COM/pwdfile.txt'
      	certificate: type=NSSDB,location='/etc/dirsrv/slapd-IDM-EXAMPLE-COM',nickname='Server-Cert',token='NSS Certificate DB'
      	CA: IPA
      	issuer: CN=Certificate Authority,O=IDM.EXAMPLE.COM
      	subject: CN=r8server.idm.example.com,O=IDM.EXAMPLE.COM
      	expires: 2021-04-08 16:38:47 CEST
      	dns: r8server.idm.example.com
      	principal name: ldap/server.idm.example.com@IDM.EXAMPLE.COM
      	key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
      	eku: id-kp-serverAuth,id-kp-clientAuth
      	pre-save command:
      	post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv IDM-EXAMPLE-COM
      	track: yes
      	auto-renew: yes

    The output displays several pieces of information about the certificate, for example:

    • the certificate location; in the example above, it is the NSS database in the /etc/dirsrv/slapd-IDM-EXAMPLE-COM directory
    • the certificate nickname; in the example above, it is Server-Cert
    • the file storing the pin; in the example above, it is /etc/dirsrv/slapd-IDM-EXAMPLE-COM/pwdfile.txt
    • the Certificate Authority that will be used to renew the certificate; in the example above, it is the IPA CA
    • the expiration date; in the example above, it is 2021-04-08 16:38:47 CEST
    • the status of the certificate; in the example above, the MONITORING status means that the certificate is valid and it is being tracked
    • the post-save command; in the example above, it is the restart of the LDAP service
  • If you do not know how to specify the certificate request, list the details of all the certificates that certmonger is monitoring or attempting to obtain:

    # getcert list

Additional information

  • To view the different options how to specify the certificate request displayed, see the getcert list man page.

21.5. Starting and stopping certificate tracking

This section describes how you can use the getcert stop-tracking and getcert start-tracking commands to monitor certificates. The two commands are provided by the certmonger service. Enabling certificate tracking is especially useful if you have imported a certificate issued by the IdM CA onto the machine from a different IdM client. Enabling certificate tracking can also be the final step of the following provisioning scenario:

  1. On the IdM server, you create a certificate for a system that does not exist yet.
  2. You create the new system.
  3. You enroll the new system as an IdM client.
  4. You import the certificate and the key from the IdM server on to the IdM client.
  5. You start tracking the certificate using certmonger to ensure that it gets renewed when it is due to expire.

Procedure

  • To disable the monitoring of a certificate with the Request ID of 20190408143846:

    # getcert stop-tracking -i 20190408143846

    For more options, see the getcert stop-tracking man page.

  • To enable the monitoring of a certificate stored in the /tmp/some_cert.crt file, whose private key is stored in the /tmp/some_key.key file:

    # getcert start-tracking -c IPA -f /tmp/some_cert.crt -k /tmp/some_key.key

    Certmonger cannot automatically identify the CA type that issued the certificate. For this reason, add the -c option with the IPA value to the getcert start-tracking command if the certificate was issued by the IdM CA. Omitting to add the -c option results in certmonger entering the NEED_CA state.

    For more options, see the getcert start-tracking man page.

Note

The two commands do not manipulate the certificate. For example, getcert stop-tracking does not delete the certificate or remove it from the NSS database or from the filesystem but simply removes the certificate from the list of monitored certificates. Similarly, getcert start-tracking only adds a certificate to the list of monitored certificates.

21.6. Renewing a certificate manually

When a certificate is near its expiration date, the certmonger daemon automatically issues a renewal command using the CA helper, obtains a renewed certificate and replaces the previous certificate with the new one.

It is also possible to manually renew a certificate in advance by using the getcert resubmit command. This way, you can update the information the certificate contains, e.g. by adding a Subject Alternative Name (SAN).

This section describes how to renew a certificate manually.

Procedure

  • To renew a certificate with the Request ID of 20190408143846:

    # getcert resubmit -i 20190408143846

    To obtain the Request ID for a specific certificate, use the getcert list command. For details, see the getcert list man page.

21.7. Making certmonger resume tracking of IdM certificates on a CA replica

This procedure shows how to make certmonger resume the tracking of IdM system certificates that are crucial for an IdM deployment with an integrated certificate authority after the tracking of certificates was interrupted. The interruption may have been caused by the IdM host being unenrolled from IdM during the renewal of the system certificates or by replication topology not working properly. The procedure also shows how to make certmonger resume the tracking of the IdM service certificates, namely the HTTP, LDAP and PKINIT certificates.

Prerequisites

  • The host on which you want to resume tracking system certificates is an IdM server that is also an IdM CA but not the IdM CA renewal master.

Procedure

  1. Get the PIN for the subsystem CA certificates:

    # grep 'internal=' /var/lib/pki/pki-tomcat/conf/password.conf
  2. Add tracking to the subsystem CA certificates, replacing [internal PIN] in the commands below with the PIN obtained in the previous step:

    # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "caSigningCert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "caSigningCert cert-pki-ca"'
    
    # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "auditSigningCert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-ca"'
    
    # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "ocspSigningCert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "ocspSigningCert cert-pki-ca"'
    
    # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "subsystemCert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca"'
    
    # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "Server-Cert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "Server-Cert cert-pki-ca"'
  3. Add tracking for the remaining IdM certificates, the HTTP, LDAP, IPA renewal agent and PKINIT certificates:

    # getcert start-tracking -f /var/lib/ipa/certs/httpd.crt -k /var/lib/ipa/private/httpd.key -p /var/lib/ipa/passwds/idm.example.com-443-RSA -c IPA -C /usr/libexec/ipa/certmonger/restart_httpd
    
    # getcert start-tracking -d /etc/dirsrv/slapd-IDM-EXAMPLE-COM -n "Server-Cert" -c IPA -p /etc/dirsrv/slapd-IDM-EXAMPLE-COM/pwdfile.txt -C '/usr/libexec/ipa/certmonger/restart_dirsrv "IDM-EXAMPLE-COM"'
    
    # getcert start-tracking -f /var/lib/ipa/ra-agent.pem -k /var/lib/ipa/ra-agent.key -c dogtag-ipa-ca-renew-agent -B /usr/libexec/ipa/certmonger/renew_ra_cert_pre -C /usr/libexec/ipa/certmonger/renew_ra_cert
    
    # getcert start-tracking -f /var/kerberos/krb5kdc/kdc.crt -k /var/kerberos/krb5kdc/kdc.key -c dogtag-ipa-ca-renew-agent -B /usr/libexec/ipa/certmonger/renew_ra_cert_pre -C /usr/libexec/ipa/certmonger/renew_kdc_cert
  4. Restart certmonger:

    # systemctl restart certmonger
  5. Wait for one minute after certmonger has started and then check the statuses of the new certificates:

    # getcert list

Additional resources

  • If your IdM system certificates have all expired, follow the procedure described in this Knowledge Centered Support (KCS) solution to manually renew IdM system certificates on the IdM CA master that is also the CA renewal master and the CRL generation master. Then follow the procedure described in this KCS solution to manually renew IdM system certificates on all the other CA servers in the topology.

Chapter 22. Enabling AD users to administer IdM

22.1. ID overrides for AD users

In Red Hat Enterprise Linux (RHEL) 7, external group membership allows AD users and groups to access IdM resources in a POSIX environment with the help of the System Security Services Daemon (SSSD).

The IdM LDAP server has its own mechanisms to grant access control. RHEL 8 introduces an update that allows adding an ID user override for an AD user as a member of an IdM group. An ID override is a record describing what a specific Active Directory user or group properties should look like within a specific ID view, in this case the Default Trust View. As a consequence of the update, the IdM LDAP server is able to apply access control rules for the IdM group to the AD user.

AD users are now able to use the self service features of IdM UI, for example to upload their SSH keys, or change their personal data. An AD administrator is able to fully administer IdM without having two different accounts and passwords.

Note

Currently, selected features in IdM may still be unavailable to AD users. For example, setting passwords for IdM users as an AD user from the IdM admins group might fail.

22.2. Using ID overrides to enable AD users to administer IdM

Prerequisites

  • The idm:DL1 stream is enabled on your IdM server and you have switched to the RPMs delivered through this stream:

    # yum module enable idm:DL1
    # yum distro-sync
  • The idm:DL1/adtrust profile is installed on your IdM server.

    # yum module install idm:DL1/adtrust

    The profile contains all the packages necessary for installing an IdM server that will have a trust agreement with Active Directory, including the ipa-idoverride-memberof package.

  • A working Identity Management environment is set up. For details, see Installing Identity Management.
  • A working trust between your Identity Management environment and Active Directory is set up.

Procedure

This procedure describes creating and using an ID override for an Active Directory (AD) user to give that user rights identical to those of an Identity Management (IdM) user. During this procedure, work on an IdM server that is configured as a trust controller or a trust agent. For details on trust controllers and trust agents, see Trust controllers and trust agents in Planning Identity Management.

  1. As an IdM administrator, create an ID override for an AD user in the Default Trust View. For example, to create an ID override for the ad_user@ad.example.com user:

    # kinit admin
    # ipa idoverrideuser-add 'default trust view' ad_user@ad.example.com
  2. Add the ID override from the Default Trust View as a member to an IdM group. If the group in question is a member of an IdM role, the AD user represented by the ID override will gain all permissions granted by the role when using the IdM API, including both the command line interface and the IdM web UI. For example, to add the ID override for the ad_user@ad.example.com user to the admins group:

    # ipa group-add-member admins --idoverrideusers=ad_user@ad.example.com

22.3. Managing IdM Command-Line Interface (CLI) as an AD user

This procedure checks that an Active Directory user can log into Identity Management CLI and run commands appropriate for his role.

  1. Destroy the current Kerberos ticket of the IdM administrator:

    # kdestroy -A
    Note

    The destruction of the Kerberos ticket is required because the GSSAPI implementation in MIT Kerberos chooses credentials from the realm of the target service by preference, which in this case is the IdM realm. This means that if a credentials cache collection, namely the KCM:, KEYRING:, or DIR: type of credentials cache is in use, a previously obtained admin or any other IdM principal’s credentials will be used to access the IdM API instead of the AD user’s credentials.

  2. Obtain the Kerberos credentials of the AD user for whom an ID override has been created:

    # kinit ad_user@AD.EXAMPLE.COM
    Password for ad_user@AD.EXAMPLE.COM:
  3. Test that the ID override of the AD user enjoys the same privileges stemming from membership in the IdM group as any IdM user in that group. If the ID override of the AD user has been added to the admins group, the AD user can, for example, create groups in IdM:

    # ipa group-add some-new-group
    ----------------------------
    Added group "some-new-group"
    ----------------------------
      Group name: some-new-group
      GID: 1997000011

Chapter 23. Using canonicalized DNS host names in IdM

DNS canonicalization is disabled by default on IdM clients to avoid potential security risks. For example, if an attacker controls the DNS server and a host in the domain, the attacker can cause that the short host name demo is resolved to malicious.example.com. In this case, the user connects to a different server than expected.

This section describes how to use canonicalized host names on IdM clients.

23.1. Adding an alias to a host principal

By default, IdM clients enrolled by using the ipa-client-install command do not allow to use short host names in service principals. For example, users can use only host/demo.example.com@EXAMPLE.COM instead of host/demo@EXAMPLE.COM when accessing a service.

This section explains how to add an alias to a Kerberos principal. Note that you can alternatively enable canonicalization of host names in the /etc/krb5.conf file. For details, see Section 23.2, “Enabling canonicalization of host names in service principals on clients”.

Prerequisites

  • The IdM client is installed.
  • The host name is unique in the network.

Procedure

  1. Authenticate to IdM as the admin user:

    $ kinit admin
  2. Add the alias to the host principal. For example, to add the demo alias to the demo.examle.com host principal:

    $ ipa host-add-principal demo.example.com --principal=demo

23.2. Enabling canonicalization of host names in service principals on clients

This section describes how you enable canonicalization of host names in services principals on clients.

Note that if you use host principal aliases, as described in Section 23.1, “Adding an alias to a host principal”, you do not need to enable canonicalization.

Prerequisites

  • The IdM client is installed.
  • You are logged in to the IdM client as the root user.
  • The host name is unique in the network.

Procedure

  1. Set the dns_canonicalize_hostname parameter in the [libdefaults] section in the /etc/krb5.conf file to false:

    [libdefaults]
    ...
    dns_canonicalize_hostname = true

23.3. Options for using host names with DNS host name canonicalization enabled

If you set dns_canonicalize_hostname = true in the /etc/krb5.conf file as explained in Section 23.2, “Enabling canonicalization of host names in service principals on clients”, you have the following options when you use a host name in a service principal:

  • In IdM environments, you can use the full host name in a service principal, such as host/demo.example.com@EXAMPLE.COM.
  • In environments without IdM, but if the RHEL host as a member of an Active Directory (AD) domain, no further considerations are required, because AD domain controllers (DC) automatically create service principals for NetBIOS names of the machines enrolled into Active Directory.

Chapter 24. Collecting IdM Healthcheck information

Healthcheck has been designed as a manual command line tool which should help you to identify possible problems in Identity Management.

This chapter describes how you can create a collection of logs based on the Healthcheck output with 30-day rotation.

Prerequisites

  • The Healthcheck tool is only available on RHEL 8.1 or newer

24.1. Healthcheck in IdM

The Healthcheck tool in IdM helps find issues that may impact the fitness of your IdM environment.

Healthcheck consists of modules which cover:

  • Replication issues
  • Certificate validation
  • CA infrastructure
  • IdM and AD trust issues
  • File permissions and ownership
Note

The Healthcheck tool is a command line tool that can be used without Kerberos authentication.

Healthcheck generates the following outputs:

  • Human readable output in the command line
  • Machine readable output in JSON format

Each Healthcheck test can generate four different results:

  • SUCCESS
  • WARNING
  • ERROR
  • CRITICAL

Healthcheck can be run:

  • Manually

    # ipa-healthcheck

    For all options, see the man page: man ipa-healthcheck.

  • Automatically using log rotation

24.2. Log rotation

Log rotation creates a new log file every day, and the files are organized by date. Since log files are saved in the same directory, you can select a particular log file according to the date.

Rotation means that there is configured a number for max number of log files and if the number is exceeded, the newest file rewrites and renames the oldest one. For example, if the rotation number is 30, the thirty-first log file replaces the first (oldest) one.

Log rotation reduces voluminous log files and organizes them, which can help with analysis of the logs.

24.3. Configuring log rotation using the IdM Healthcheck

This section describes how to configure a log rotation with:

  • the systemd timer
  • the crond service

The systemd timer runs the Healthcheck tool periodically and generates the logs. The default value is set to 4 am every day.

The crond service is used for log rotation.

The default log name is healthcheck.log and the rotated logs use the healthcheck.log-YYYYMMDD format.

Prerequisites

  • You must execute commands as root.

Procedure

  1. Enable a systemd timer:

    # systemctl enable ipa-healthcheck.timer
    Created symlink /etc/systemd/system/multi-user.target.wants/ipa-healthcheck.timer -> /usr/lib/systemd/system/ipa-healthcheck.timer.
  2. Start the systemd timer:

    # systemctl start ipa-healthcheck.timer
  3. Open the /etc/logrotate.d/ipahealthcheck file to configure the number of logs which should be saved.

    By default, log rotation is set up for 30 days.

  4. In the /etc/logrotate.d/ipahealthcheck file, configure the path to the logs.

    By default, logs are saved in the /var/log/ipa/healthcheck/ directory.

  5. In the /etc/logrotate.d/ipahealthcheck file, configure the time for log generation.

    By default, a log is created daily at 4 AM.

  6. To use log rotation, ensure that the crond service is enabled and running:

    # systemctl enable crond
    # systemctl start crond

To start with generating logs, start the IPA healthcheck service:

# systemctl start ipa-healthcheck

To verify the result, go to /var/log/ipa/healthcheck/ and check if logs are created correctly.

Chapter 25. Checking services using IdM Healthcheck

This section describes monitoring services used by the Identity Management (IdM) server using the Healthcheck tool.

For details, see Healthcheck in IdM.

Prerequisites

  • The Healthcheck tool is only available on RHEL 8.1 and newer

25.1. Services Healthcheck test

The Healthcheck tool includes a test to check if any IdM services is not running. This test is important because services which are not running can cause failures in other tests. Therefore, check that all services are running first. You can then check all other test results.

To see all services tests, run ipa-healthcheck with the --list-sources option:

# ipa-healthcheck --list-sources

You can find all services tested with Healthcheck under the ipahealthcheck.meta.services source:

  • certmonger
  • dirsrv
  • gssproxy
  • httpd
  • ipa_custodia
  • ipa_dnskeysyncd
  • ipa_otpd
  • kadmin
  • krb5kdc
  • named
  • pki_tomcatd
  • sssd
Note

Run these tests on all IdM master servers when trying to discover issues.

25.2. Screening services using Healthcheck

This section describes a standalone manual test of services running on the Identity Management (IdM) server using the Healthcheck tool.

The Healthcheck tool includes many tests, whose results can be shortened with:

  • excluding all successful test: --failures-only
  • including only services tests: --source=ipahealthcheck.meta.services

Procedure

  • To run Healthcheck with warnings, errors and critical issues regarding services, enter:

    # ipa-healthcheck --source=ipahealthcheck.meta.services --failures-only

A successful test displays empty brackets:

[ ]

If one of the services fails, the result can looks similarly to this example:

{
  "source": "ipahealthcheck.meta.services",
  "check": "httpd",
  "result": "ERROR",
  "kw": {
    "status": false,
    "msg": "httpd: not running"
  }
}

Additional resources

  • For reviewing detailed reference, enter man ipa-healthcheck in the command line.

Chapter 26. Verifying your IdM and AD trust configuration using IdM Healthcheck

This section helps you understand and use the Healthcheck tool in Identity management (IdM) to identify issues with IdM and an Active Directory trust.

For details, see Section 24.1, “Healthcheck in IdM”.

Prerequisites

  • The Healthcheck tool is only available on RHEL 8.1 or newer

26.1. IdM and AD trust Healthcheck tests

The Healthcheck tool includes several tests for testing the status of your IdM and AD trust.

To see all trust tests, run ipa-healthcheck with the --list-sources option:

# ipa-healthcheck --list-sources

You can find all tests under the ipahealthcheck.ipa.trust source:

IPATrustAgentCheck
This test checks the SSSD configuration when the machine is configured as a trust agent. For each domain in /etc/sssd/sssd.conf where id_provider=ipa ensure that ipa_server_mode is True.
IPATrustDomainsCheck
This test checks if the trust domains match SSSD domains by comparing the list of domains in sssctl domain-list with the list of domains from ipa trust-find excluding the IPA domain.
IPATrustCatalogCheck

This test resolves resolves an AD user, Administrator@REALM. This populates the AD Global catalog and AD Domain Controller values in sssctl domain-status output.

For each trust domain look up the user with the id of the SID + 500 (the administrator) and then check the output of sssctl domain-status <domain> --active-server to ensure that the domain is active.

IPAsidgenpluginCheck
This test verifies that the sidgen plugin is enabled in the IPA 389-ds instance. The test also verifies that the IPA SIDGEN and ipa-sidgen-task plugins in cn=plugins,cn=config include the nsslapd-pluginEnabled option.
IPATrustAgentMemberCheck
This test verifies that the current host is a member of cn=adtrust agents,cn=sysaccounts,cn=etc,SUFFIX.
IPATrustControllerPrincipalCheck
This test verifies that the current host is a member of cn=adtrust agents,cn=sysaccounts,cn=etc,SUFFIX.
IPATrustControllerServiceCheck
This test verifies that the current host starts the ADTRUST service in ipactl.
IPATrustControllerConfCheck
This test verifies that ldapi is enabled for the passdb backend in the output of net conf list.
IPATrustControllerGroupSIDCheck
This test verifies that the admins group’s SID ends with 512 (Domain Admins RID).
IPATrustPackageCheck
This test verifies that the trust-ad package is installed if the trust controller and AD trust are not enabled.
Note

Run these tests on all IdM master servers when trying to find an issue.

26.2. Screening the trust with the Healthcheck tool

This section describes a standalone manual test of an Identity Management (IdM) and Active Directory (AD) trust health check using the Healthcheck tool.

The Healthcheck tool includes many tests, therefore, you can shorten the results by:

  • excluding all successful test: --failures-only
  • including only trust tests: --source=ipahealthcheck.ipa.trust

Procedure

  • To run Healthcheck with warnings, errors and critical issues in the trust, enter:

    # ipa-healthcheck --source=ipahealthcheck.ipa.trust --failures-only

Successful test displays empty brackets:

# ipa-healthcheck --source=ipahealthcheck.ipa.trust --failures-only
[]

Additional resources

  • For reviewing detailed reference, enter man ipa-healthcheck in the command line.

Chapter 27. Verifying certificates using IdM Healthcheck

This section helps in understanding and using the Healthcheck tool in Identity management (IdM) to identify issues with IPA certificates maintained by certmonger.

For details, see Healthcheck in IdM.

Prerequisites

  • The Healthcheck tool is only available in RHEL 8.1 and newer.

27.1. IdM certificates Healthcheck tests

The Healthcheck tool includes several tests for verifying the status of certificates maintained by certmonger in Identity Management (IdM). For details about certmonger, see Obtaining an IdM certificate for a service using certmonger.

This suite of tests checks expiration, validation, trust and other issues. Multiple errors may be thrown for the same underlying issue.

To see all certificate tests, run the ipa-healthcheck with the --list-sources option:

# ipa-healthcheck --list-sources

You can find all tests under the ipahealthcheck.ipa.certs source:

IPACertmongerExpirationCheck

This test checks expirations in certmonger.

If an error is reported, the certificate has expired.

If a warning appears, the certificate will expire soon. By default, this test applies within 28 days or fewer days before certificate expiration.

You can configure the number of days in the /etc/ipahealthcheck/ipahealthcheck.conf file. After opening the file, change the cert_expiration_days option located in the default section.

Note

Certmonger loads and maintains its own view of the certificate expiration. This check does not validate the on-disk certificate.

IPACertfileExpirationCheck

This test checks if the certificate file or NSS database cannot be opened. This test also checks expiration. Therefore, carefully read the msg attribute in the error or warning output. The message specifies the problem.

Note

This test checks the on-disk certificate. If a certificate is missing, unreadable, etc a separate error can also be raised.

IPACertNSSTrust
This test compares the trust for certificates stored in NSS databases. For the expected tracked certificates in NSS databases the trust is compared to an expected value and an error raised on a non-match.
IPANSSChainValidation
This test validates the certificate chain of the NSS certificates. The test executes: certutil -V -u V -e -d [dbdir] -n [nickname]
IPAOpenSSLChainValidation

This test validates the certificate chain of the OpenSSL certificates. To be comparable to the NSSChain validation here is the OpenSSL command we execute:

openssl verify -verbose -show_chain -CAfile /etc/ipa/ca.crt [cert file]
IPARAAgent
This test compares the certificate on disk with the equivalent record in LDAP in uid=ipara,ou=People,o=ipaca.
IPACertRevocation
This test uses certmonger to verify that certificates have not been revoked. Therefore, the test can find issues connected with certificates maintained by certmonger only.
IPACertmongerCA

This test verifies the certmonger Certificate Authority (CA) configuration. IdM cannot issue certificates without CA.

Certmonger maintains a set of CA helpers. In IdM, there is a CA named IPA which issues certificates through IdM, authenticating as a host or user principal, for host or service certs.

There are also dogtag-ipa-ca-renew-agent and dogtag-ipa-ca-renew-agent-reuse which renew the CA subsystem certificates.

Note

Run these tests on all IdM master servers when trying to check for issues.

27.2. Screening certificates using the Healthcheck tool

This section describes a standalone manual test of an Identity Management (IdM) certificate health check using the Healthcheck tool.

The Healthcheck tool includes many tests, therefore, you can shorten the results with:

  • excluding all successful test: --failures-only
  • including only certificate tests: --source=ipahealthcheck.ipa.certs

Prerequisites

  • Healthcheck tests must be performed as the root user.

Procedure

  • To run Healthcheck with warnings, errors and critical issues regarding certificates, enter:

    # ipa-healthcheck --source=ipahealthcheck.ipa.certs --failures-only

Successful test displays empty brackets:

[]

Failed test shows you the following output:

{
  "source": "ipahealthcheck.ipa.certs",
  "check": "IPACertfileExpirationCheck",
  "result": "ERROR",
  "kw": {
    "key": 1234,
    "dbdir": "/path/to/nssdb",
    "error": [error],
    "msg": "Unable to open NSS database '/path/to/nssdb': [error]"
  }
}

This IPACertfileExpirationCheck test failed on opening the NSS database.

Additional resources

  • For reviewing detailed reference, enter man ipa-healthcheck in the command line.

Chapter 28. Verifying system certificates using IdM Healthcheck

This section describes a Healthcheck tool in Identity Management (IdM) to identify issues with system certificates.

For details, see Healthcheck in IdM.

Prerequisites

  • The Healthcheck tool is only available on RHEL 8.1 or newer.

28.1. System certificates Healthcheck tests

The Healthcheck tool includes several tests for verifying system (DogTag) certificates.

To see all tests, run the ipa-healthcheck with the --list-sources option:

# ipa-healthcheck --list-sources

You can find all tests under the ipahealthcheck.dogtag.ca source:

DogtagCertsConfigCheck

This test compares the CA (Certificate Authority) certificates in its NSS database to the same values stored in CS.cfg. If they don’t match, CA fails to start.

Specifically, it checks:

  • auditSigningCert cert-pki-ca against ca.audit_signing.cert
  • ocspSigningCert cert-pki-ca against ca.ocsp_signing.cert
  • caSigningCert cert-pki-ca against ca.signing.cert
  • subsystemCert cert-pki-ca against ca.subsystem.cert
  • Server-Cert cert-pki-ca against ca.sslserver.cert

If Key Recovery Authority (KRA) is installed:

  • transportCert cert-pki-kra against ca.connector.KRA.transportCert
DogtagCertsConnectivityCheck

This test verifies connectivity. This test is equivalent to the ipa cert-show 1 command which checks:

  • The PKI proxy configuration in Apache
  • IdM being able to find a CA
  • The RA agent client certificate
  • Correctness of CA replies to requests

Note that the test checks a certificate with serial #1 because you want to verify that a cert-show can be executed and get back an expected result from CA (either the certificate or a not found).

Note

Run these tests on all IdM master servers when trying to find an issue.

28.2. Screening system certificates using Healthcheck

This section describes a standalone manual test of Identity Management (IdM) certificates using the Healthcheck tool.

Since, the Healthcheck tool includes many tests, you can narrow the results by including only DogTag tests: --source=ipahealthcheck.dogtag.ca

Procedure

  • To run Healthcheck restricted to DogTag certificates, enter:

    # ipa-healthcheck --source=ipahealthcheck.dogtag.ca

An example of a successful test:

{
  "source: ipahealthcheck.dogtag.ca",
  "check: DogtagCertsConfigCheck",
  "result: SUCCESS",
  "uuid: 9b366200-9ec8-4bd9-bb5e-9a280c803a9c",
  "when: 20191008135826Z",
  "duration: 0.252280",
  "kw:" {
    "key": "Server-Cert cert-pki-ca",
    "configfile":  "/var/lib/pki/pki-tomcat/conf/ca/CS.cfg"
    }
}

An example of a failed test:

{
  "source: ipahealthcheck.dogtag.ca",
  "check: DogtagCertsConfigCheck",
  "result: CRITICAL",
  "uuid: 59d66200-1447-4b3b-be01-89810c803a98",
  "when: 20191008135912Z",
  "duration: 0.002022",
  "kw:" {
    "exception": "NSDB /etc/pki/pki-tomcat/alias not initialized",
    }
}

Additional resources

  • For reviewing detailed reference, enter man ipa-healthcheck in the command line.

Chapter 29. Checking disk space using IdM Healthcheck

This section describes how to monitor the Identity Management server’s free disk space using the Healthcheck tool.

For details, see Healthcheck in IdM.

Prerequisites

  • The Healthcheck tool is only available on RHEL 8.1 and newer.

29.1. Disk space healthcheck test

The Healthcheck tool includes a test for checking available disk space. Insufficient free disk space can cause issues with:

  • Logging
  • Execution
  • Backups

The test checks the following paths:

Table 29.1. Tested paths

Paths checked by the testMinimal disk space in MB

/var/lib/dirsrv/

1024

/var/lib/ipa/backup/

512

/var/log/

1024

var/log/audit/

512

/var/tmp/

512

/tmp/

512

To list all tests, run the ipa-healthcheck with the --list-sources option:

# ipa-healthcheck --list-sources

The file system space check test is placed under the ipahealthcheck.system.filesystemspace source:

FileSystemSpaceCheck

This test checks available disk space in the following ways:

  • The minimum raw free bytes needed.
  • The percentage — the minimum free disk space is hardcoded to 20%.

29.2. Screening disk space using the healthcheck tool

This section describes a standalone manual test of available disk space on an Identity Management (IdM) server using the Healthcheck tool.

Since Healthcheck includes many tests, you can narrow the results by:

  • excluding all successful test: --failures-only
  • including only space check tests: --source=ipahealthcheck.system.filesystemspace

Procedure

  • To run Healthcheck with warnings, errors and critical issues regarding available disk space, enter:

    # ipa-healthcheck --source=ipahealthcheck.system.filesystemspace --failures-only

A successful test displays empty brackets:

[]

As an example, a failed test can display:

{
  "source": "ipahealthcheck.system.filesystemspace",
  "check": "FileSystemSpaceCheck",
  "result": "ERROR",
  "kw": {
    "msg": "/var/lib/dirsrv: free space under threshold: 0 MiB < 1024 MiB",
    "store": "/var/lib/dirsrv",
    "free_space": 0,
    "threshold": 1024
  }
}

The failed test informs you that the /var/lib/dirsrv directory has run out of space.

Additional resources

  • For reviewing detailed reference, enter man ipa-healthcheck in the command line.

Chapter 30. Verifying permissions of IdM configuration files using Healthcheck

This section describes how to test Identity Management (IdM) configuration files using the Healthcheck tool.

For details, see Healthcheck in IdM.

Prerequisites

  • The Healthcheck tool is only available on RHEL 8.1 or newer systems.

30.1. File permissions Healthcheck tests

The Healthcheck tool tests ownership and permissions of some important files installed or configured by Identity Management (IdM).

If you change the ownership or permissions of any tested file, the test returns a warning in the result section. While it does not necessarily mean that the configuration will not work, it means that the file differs from the default configuration.

To see all tests, run the ipa-healthcheck with the --list-sources option:

# ipa-healthcheck --list-sources

The file permissions test is placed under the ipahealthcheck.ipa.files source:

IPAFileNSSDBCheck
This test checks the 389-ds NSS database and the Certificate Authority (CA) database. The 389-ds database is located in /etc/dirsrv/slapd-<dashed-REALM> and the CA database is located in /etc/pki/pki-tomcat/alias/.
IPAFileCheck

This test checks the following files:

  • /var/lib/ipa/ra-agent.{key|pem}
  • /var/lib/ipa/certs/httpd.pem
  • /var/lib/ipa/private/httpd.key
  • /etc/httpd/alias/ipasession.key
  • /etc/dirsrv/ds.keytab
  • /etc/ipa/ca.crt
  • /etc/ipa/custodia/server.keys

    If PKINIT is enabled:

  • /var/lib/ipa/certs/kdc.pem
  • /var/lib/ipa/private/kdc.key

    If DNS is configured:

  • /etc/named.keytab
  • /etc/ipa/dnssec/ipa-dnskeysyncd.keytab
TomcatFileCheck

This test checks some tomcat-specific files if a CA is configured:

  • /etc/pki/pki-tomcat/password.conf
  • /var/lib/pki/pki-tomcat/conf/ca/CS.cfg
  • /etc/pki/pki-tomcat/server.xml
Note

Run these tests on all IdM master servers when trying to find issues.

30.2. Screening configuration files using Healthcheck

This section describes a standalone manual test of an Identity Management (IdM) server’s configuration files using the Healthcheck tool.

The Healthcheck tool includes many tests. Results can be narrowed down by:

  • excluding all successful test: --failures-only
  • including only ownership and permissions tests: --source=ipahealthcheck.ipa.files

Procedure

  1. To run Healthcheck tests on IdM configuration file ownership and permissions, while displaying only warnings, errors and critical issues, enter:

    # ipa-healthcheck --source=ipahealthcheck.ipa.files --failures-only

A successful test displays empty brackets:

# ipa-healthcheck --source=ipahealthcheck.ipa.files --failures-only
[]

Failed tests display results similar to the following WARNING:

{
  "source": "ipahealthcheck.ipa.files",
  "check": "IPAFileNSSDBCheck",
  "result": "WARNING",
  "kw": {
    "key": "_etc_dirsrv_slapd-EXAMPLE-TEST_pkcs11.txt_mode",
    "path": "/etc/dirsrv/slapd-EXAMPLE-TEST/pkcs11.txt",
    "type": "mode",
    "expected": "0640",
    "got": "0666",
    "msg": "Permissions of /etc/dirsrv/slapd-EXAMPLE-TEST/pkcs11.txt are 0666 and should be 0640"
  }
}

Additional resources

  • For reviewing detailed reference material, open man ipa-healthcheck in the command line.

Chapter 31. Checking IdM replication using Healthcheck

This section describes how to test Identity Management (IdM) replication using the Healthcheck tool.

For details, see Healthcheck in IdM.

Prerequisites

  • The Healthcheck tool is only available on RHEL 8.1 or newer.

31.1. Replication healthcheck tests

The Healthcheck tool tests the Identity Management (IdM) topology configuration and searches for replication conflict issues.

To list all tests, run the ipa-healthcheck with the --list-sources option:

# ipa-healthcheck --list-sources

The topology tests are placed under the ipahealthcheck.ipa.topology and ipahealthcheck.ds.replication sources:

IPATopologyDomainCheck

This test verifies:

  • whether topology is not disconnected and there are replication paths between all servers.
  • if servers don’t have more than the recommended number of replication agreements.

    If the test fails, the test returns errors, such as connection errors or too many replication agreements.

    If the test succeeds, the test returns the configured domains.

    Note

    The test runs the ipa topologysuffix-verify command for both the domain and ca suffixes (assuming the Certificate Authority is configured on this master).

ReplicationConflictCheck
The test searches for entries in LDAP matching (&(!(objectclass=nstombstone))(nsds5ReplConflict=*)).
Note

Run these tests on all IdM master servers when trying to check for issues.

31.2. Screening replication using Healthcheck

This section describes a standalone manual test of an Identity Management (IdM) replication topology and configuration using the Healthcheck tool.

The Healthcheck tool includes many tests, therefore, you can shorten the results with:

  • Replication conflict test: --source=ipahealthcheck.ds.replication
  • Correct topology test: --source=ipahealthcheck.ipa.topology

Prerequisites

  • Healthcheck tests must be performed as the root user.

Procedure

  • To run Healthcheck replication conflict and topology checks, enter:

    # ipa-healthcheck --source=ipahealthcheck.ds.replication --source=ipahealthcheck.ipa.topology

Four different results are possible:

  • SUCCESS — the test passed successfully.

    {
      "source": "ipahealthcheck.ipa.topology",
      "check": "IPATopologyDomainCheck",
      "result": "SUCCESS",
      "kw": {
        "suffix": "domain"
      }
    }
  • WARNING — the test passed but there might be a problem.
  • ERROR — the test failed.

    {
      "source": "ipahealthcheck.ipa.topology",
      "check": "IPATopologyDomainCheck",
      "result": "ERROR",
      "uuid": d6ce3332-92da-423d-9818-e79f49ed321f
      "when": 20191007115449Z
      "duration": 0.005943
      "kw": {
        "msg": "topologysuffix-verify domain failed, server2 is not connected (server2_139664377356472 in MainThread)"
      }
    }
  • CRITICAL — the test failed and it affects the IdM server functionality.

Additional resources

  • For reviewing detailed reference, open man ipa-healthcheck in the command line.

Chapter 32. Demoting or promoting hidden replicas

After a replica has been installed, you can change whether the replica is hidden or visible.

For details about hidden replicas, see The hidden replica mode.

If the replica is a CA renewal master, move the service to another replica. For details, see Changing and resetting IdM CA Renewal Master.

Note

The hidden replica feature is available in Red Hat Enterprise Linux 8.1 and later as a Technology Preview and, therefore, not supported.

Procedure

  • To hide the replica, enter:

    # ipa server-state replica.idm.example.com --state=hidden

    Alternatively, you can make the replica visible with the following command

    # ipa server-state replica.idm.example.com --state=enabled

Chapter 33. Setting up Samba on an IdM domain member

This section describes how to set up Samba on a host that is joined to a Red Hat Identity Management (IdM) domain. Users from IdM and also, if available, from trusted Active Directory (AD) domains, can access shares and printer services provided by Samba.

Important

Using Samba on an IdM domain member is an unsupported Technology Preview feature.

Prerequisites

  • The host is joined as a client to the IdM domain.
  • Both the IdM servers and the client must run on RHEL 8.1 or later.

33.1. Preparing the IdM domain for installing Samba on domain members

Before you can establish a trust with AD and if you want to set up Samba on an IdM client, you must prepare the IdM domain using the ipa-adtrust-install utility on an IdM server. However, even if both situations apply, you must run ipa-adtrust-install only once on an IdM master.

Prerequisites

  • IdM is installed.

Procedure

  1. Install the required packages:

    [root@ipaserver ~]# yum install ipa-server ipa-server-trust-ad samba-client
  2. Authenticate as the IdM administrative user:

    [root@ipaserver ~]# kinit admin
  3. Run the ipa-adtrust-install utility:

    [root@ipaserver ~]# ipa-adtrust-install

    The DNS service records are created automatically if IdM was installed with an integrated DNS server.

    If IdM was installed without an integrated DNS server, ipa-adtrust-install prints a list of service records that must be manually added to DNS before you can continue.

  4. The script prompts you that the /etc/samba/smb.conf already exists and will be rewritten:

    WARNING: The smb.conf already exists. Running ipa-adtrust-install will break your existing Samba configuration.
    
    Do you wish to continue? [no]: yes
  5. The script prompts you to configure the slapi-nis plug-in, a compatibility plug-in that allows older Linux clients to work with trusted users:

    Do you want to enable support for trusted domains in Schema Compatibility plugin?
    This will allow clients older than SSSD 1.9 and non-Linux clients to work with trusted users.
    
    Enable trusted domains support in slapi-nis? [no]: yes
  6. When prompted, enter the NetBIOS name for the IdM domain or press Enter to accept the name suggested:

    Trust is configured but no NetBIOS domain name found, setting it now.
    Enter the NetBIOS name for the IPA domain.
    Only up to 15 uppercase ASCII letters, digits and dashes are allowed.
    Example: EXAMPLE.
    
    NetBIOS domain name [IDM]:
  7. You are prompted to run the SID generation task to create a SID for any existing users:

    Do you want to run the ipa-sidgen task? [no]: yes

    When the directory is first installed, at least one user (the IdM administrator) exists and as this is a resource-intensive task, if you have a high number of users, you can run this at another time.

  8. Restart the ipa service:

    [root@ipaserver ~]# systemctl restart ipa
  9. Use the smbclient utility to verify that Samba responds to Kerberos authentication from the IdM side:

    [root@ipaserver ~]# smbclient -L server.idm.example.com -k
    lp_load_ex: changing to config backend registry
        Sharename       Type      Comment
        ---------       ----      -------
        IPC$            IPC       IPC Service (Samba 4.10.4)
    ...

33.2. Enabling the AES encryption type in Active Directory using a GPO

This section describes how to enable the AES encryption type in Active Directory (AD) using a group policy object (GPO). Certain Identity Management (IdM) features, such as running a Samba server on an IdM client, require this encryption type.

Note that RHEL 8 does not support the weak DES and RC4 encryption types.

Prerequisites

  • You are logged into AD as a user who can edit group policies.
  • The Group Policy Management Console is installed on the computer.

Procedure

  1. Open the Group Policy Management Console.
  2. Right-click Default Domain Policy, and select Edit. The Group Policy Management Editor opens.
  3. Navigate to Computer ConfigurationPoliciesWindows SettingsSecurity SettingsLocal PoliciesSecurity Options.
  4. Double-click the Network security: Configure encryption types allowed for Kerberos policy.
  5. Select AES256_HMAC_SHA1 and, optionally, Future encryption types.
  6. Click OK.
  7. Close the Group Policy Management Editor.
  8. Repeat the steps for the Default Domain Controller Policy.
  9. Wait until the Windows domain controllers (DC) applied the group policy automatically. Alternatively, to apply the GPO manually on a DC, enter the following command using an account that has administrator permissions:

    C:\> gpupdate /force /target:computer

33.3. Installing and configuring a Samba server on an IdM client

This section describes how to install and configure Samba on a client enrolled in an IdM domain.

Prerequisites

Procedure

  1. Install the ipa-client-samba package:

    [root@idm_client]# yum install ipa-client-samba
  2. Use the ipa-client-samba utility to prepare the client and create an initial Samba configuration:

    [root@idm_client]# ipa-client-samba
    Searching for IPA server...
    IPA server: DNS discovery
    Chosen IPA master: idm_server.idm.example.com
    SMB principal to be created: cifs/idm_client.idm.example.com@IDM.EXAMPLE.COM
    NetBIOS name to be used: IDM_CLIENT
    Discovered domains to use:
    
     Domain name: idm.example.com
    NetBIOS name: IDM
             SID: S-1-5-21-525930803-952335037-206501584
        ID range: 212000000 - 212199999
    
     Domain name: ad.example.com
    NetBIOS name: AD
             SID: None
        ID range: 1918400000 - 1918599999
    
    Continue to configure the system with these values? [no]: yes
    Samba domain member is configured. Please check configuration at /etc/samba/smb.conf and start smb and winbind services
  3. By default, ipa-client-samba automatically adds the [homes] section to the /etc/samba.smb.conf file that dynamically shares a user’s home directory when the user connects. If users do not have home directories on this server, or if you do not want to share them, remove the following lines from /etc/samba.smb.conf:

    [homes]
        read only = no
  4. Share directories and printers. For details, see the following sections in the Deploying different types of servers documentation for RHEL 8:

  5. Open the ports required for a Samba client in the local firewall:

    [root@idm_client]# firewall-cmd --permanent --add-service=samba-client
    [root@idm_client]# firewall-cmd --reload
  6. Enable and start the smb and winbind services:

    [root@idm_client]# systemctl enable --now smb winbind

Verification steps

Run the following verification steps on a different IdM domain member that has the samba-client package installed:

  1. Authenticate and obtain a Kerberos ticket-granting ticket:

    $ kinit example_user
  2. List the shares on the Samba server using Kerberos authentication:

    $ smbclient -L idm_client.idm.example.com -k
    lp_load_ex: changing to config backend registry
    
        Sharename       Type      Comment
        ---------       ----      -------
        example         Disk
        IPC$            IPC       IPC Service (Samba 4.10.4)
    ...

Additional resources

  • For details about which steps ipa-client-samba performs during the configuration, see the ipa-client-samba(1) man page.

33.4. Manually adding an ID mapping configuration if IdM trusts a new domain

Samba requires an ID mapping configuration for each domain from which users access resources. On an existing Samba server running on an IdM client, you must manually add an ID mapping configuration after the administrator added a new trust to an Active Directory (AD) domain.

Prerequisites

Procedure

  1. Authenticate using the host’s keytab:

    [root@idm_client]# kinit -k
  2. Use the ipa idrange-find command to display both the base ID and the ID range size of the new domain. For example, the following command displays the values for the ad.example.com domain:

    [root@idm_client]# ipa idrange-find --name="AD.EXAMPLE.COM_id_range" --raw
    ---------------
    1 range matched
    ---------------
      cn: AD.EXAMPLE.COM_id_range
      ipabaseid: 1918400000
      ipaidrangesize: 200000
      ipabaserid: 0
      ipanttrusteddomainsid: S-1-5-21-968346183-862388825-1738313271
      iparangetype: ipa-ad-trust
    ----------------------------
    Number of entries returned 1
    ----------------------------

    You need the values from the ipabaseid and ipaidrangesize attributes in the next steps.

  3. To calculate the highest usable ID, use the following formula:

    maximum_range = ipabaseid + ipaidrangesize - 1

    With the values from the previous step, the highest usable ID for the ad.example.com domain is 1918599999 (1918400000 + 200000 - 1).

  4. Edit the /etc/samba/smb.conf file, and add the ID mapping configuration for the domain to the [global] section:

    idmap config AD : range = 1918400000 - 1918599999
    idmap config AD : backend = sss

    Specify the value from ipabaseid attribute as the lowest and the computed value from the previous step as the highest value of the range.

  5. Restart the smb and winbind services:

    [root@idm_client]# systemctl restart smb winbind

Verification steps

  1. Authenticate as a user from the new domain and obtain a Kerberos ticket-granting ticket:

    $ kinit example_user
  2. List the shares on the Samba server using Kerberos authentication:

    $ smbclient -L idm_client.idm.example.com -k
    lp_load_ex: changing to config backend registry
    
        Sharename       Type      Comment
        ---------       ----      -------
        example         Disk
        IPC$            IPC       IPC Service (Samba 4.10.4)
    ...

33.5. Additional resources

Chapter 34. Identity Management security settings

This section describes security-related features of Identity Management.

34.1. How Identity Management applies default security settings

By default, Identity Management (IdM) on RHEL 8 uses the system-wide crypto policy. The benefit of this policy is that you do not need to harden individual IdM components manually.

Important

Red Hat recommends that you use the system-wide crypto policy. Changing individual security settings can break components of IdM. For example, Java in RHEL 8 does not fully support the TLS 1.3 protocol. Therefore, using this protocol can cause failures in IdM.

Additional resources

  • For further details about the system-wide crypto policies, see the crypto-policies(7) man page.

34.2. Anonymous LDAP binds in Identity Management

By default, anonymous binds to the Identity Management (IdM) LDAP server are enabled. Anonymous binds can expose certain configuration settings or directory values. However, some utilities, such as reald, or older RHEL clients require anonymous binds enabled to discover domain settings when enrolling a client.

Additional resources

  • For details about disabling anonymous binds in the IdM LDAP server, see the Disabling Anonymous Binds section in the Red Hat Directory Server 11 Administration Guide.

Legal Notice

Copyright © 2019 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.