Cari di RHE Linux 
     Red Hat Enterprise Linux Manual
Daftar Isi ☛
(Sebelumnya) 3 : Chapter 19. Configuration ...3 : Glossary - Identity Manage ... (Berikutnya)

Identity Management Guide

Chapter 20. Migrating from an LDAP Directory to IdM

20.1. An Overview of LDAP to IdM Migration
20.1.1. Planning the Client Configuration
20.1.1.1. Initial Client Configuration (Pre-Migration)
20.1.1.2. Recommended Configuration for Red Hat Enterprise Linux Clients
20.1.1.3. Alternative Supported Configuration
20.1.2. Planning Password Migration
20.1.2.1. Method 1: Using Temporary Passwords and Requiring a Change
20.1.2.2. Method 2: Using the Migration Web Page
20.1.2.3. Method 3: Using SSSD (Recommended)
20.1.2.4. Migrating Cleartext LDAP Passwords
20.1.2.5. Automatically Resetting Passwords That Do Not Meet Requirements
20.1.3. Migration Considerations and Requirements
20.1.3.1. LDAP Servers Supported for Migration
20.1.3.2. Migration Environment Requirements
20.1.3.3. Migration Tools
20.1.3.4. Migration Sequence
20.2. Examples for Using migrate-ds
20.2.1. Migrating Specific Subtrees
20.2.2. Specifically Including or Excluding Entries
20.2.3. Excluding Entry Attributes
20.2.4. Setting the Schema to Use
20.3. Scenario 1: Using SSSD as Part of Migration
20.4. Scenario 2: Migrating an LDAP Server Directly to Identity Management
When an infrastructure has previously deployed an LDAP server for authentication and identity lookups, it is possible to migrate the user data, including passwords, to a new Identity Management instance, without losing user or password data.
Identity Management has migration tools to help move directory data and only requires minimal updates to clients. However, the migration process assumes a simple deployment scenario (one LDAP namespace to one IdM namespace). For more complex environments, such as ones with multiple namespaces or custom schema, contact Red Hat support services for assistance.

20.1. An Overview of LDAP to IdM Migration

The actual migration part of moving from an LDAP server to Identity Management - the process of moving the data from one server to the other - is fairly straightforward. The process is simple: move data, move passwords, and move clients.
The crucial part of migration is not data migration; it is deciding how clients are going to be configured to use Identity Management. For each client in the infrastructure, you need to decide what services (such as Kerberos and SSSD) are being used and what services can be used in the final, IdM deployment.
A secondary, but significant, consideration is planning how to migrate passwords. Identity Management requires Kerberos hashes for every user account in addition to passwords. Some of the considerations and migration paths for passwords are covered in Section 20.1.2, "Planning Password Migration".

20.1.1. Planning the Client Configuration

Identity Management can support a number of different client configurations, with varying degrees of functionality, flexibility, and security. Decide which configuration is best for each individual client based on its operating system, functional area (such as development machines, production servers, or user laptops), and your IT maintenance priorities.

IMPORTANT

The different client configurations are not mutually exclusive. Most environments will have a mix of different ways that clients use to connect to the IdM domain. Administrators must decide which scenario is best for each individual client.

20.1.1.1. Initial Client Configuration (Pre-Migration)

Before deciding where you want to go with the client configuration in Identity Management, first establish where you are before the migration.
The initial state for almost all LDAP deployments that will be migrated is that there is an LDAP service providing identity and authentication services.
Basic LDAP Directory and Client Configuration

Figure 20.1. Basic LDAP Directory and Client Configuration


Linux and Unix clients use PAM_LDAP and NSS_LDAP libraries to connect directly to the LDAP services. These libraries allow clients to retrieve user information from the LDAP directory as if the data were stored in /etc/passwd or /etc/shadow. (In real life, the infrastructure may be more complex if a client uses LDAP for identity lookups and Kerberos for authentication or other configurations.)
There are structural differences between an LDAP directory and an IdM server, particularly in schema support and the structure of the directory tree. (For more background on those differences, see Section 1.1, "IdM v. LDAP: A More Focused Type of Service".) While those differences may impact data (especially with the directory tree, which affects entry names), they have little impact on the client configuration, so it really has little impact on migrating clients to Identity Management.

20.1.1.2. Recommended Configuration for Red Hat Enterprise Linux Clients

Red Hat Enterprise Linux has a service called the System Security Services Daemon (SSSD). SSSD uses special PAM and NSS libraries (pam_sss and nss_sss, respectively) which allow SSSD to be integrated very closely with Identity Management and leverage the full authentication and identity features in Identity Management. SSSD has a number of useful features, like caching identity information so that users can log in even if the connection is lost to the central server; these are described in the Red Hat Enterprise Linux Deployment Guide.
Unlike generic LDAP directory services (using pam_ldap and nss_ldap), SSSD establishes relationships between identity and authentication information by defining domains. A domain in SSSD defines four backend functions: authentication, identity lookups, access, and password changes. The SSSD domain is then configured to use an identity provider to supply the information for any one (or all) of those four functions.
SSSD can use Identity Management for all of its backend functions. This is the ideal configuration because it provides the full range of Identity Management functionality, unlike generic LDAP identity providers or Kerberos authentication. For example, during daily operation, SSSD enforces host-based access control rules and security features in Identity Management.

TIP

During the migration process from an LDAP directory to Identity Management, SSSD can seamlessly migrate user passwords without additional user interaction.
Clients and SSSD with an IdM Backend

Figure 20.2. Clients and SSSD with an IdM Backend


The ipa-client-install script automatically configured SSSD to use IdM for all four of its backend services, so Red Hat Enterprise Linux clients are set up with the recommended configuration by default.

NOTE

This client configuration is only supported for Red Hat Enterprise Linux 6.1 and later and Red Hat Enterprise Linux 5.7 later, which support the latest versions of SSSD and ipa-client. Older versions of Red Hat Enterprise Linux can be configured as described in Section 20.1.1.3, "Alternative Supported Configuration".

20.1.1.3. Alternative Supported Configuration

Unix and Linux systems such as Mac, Solaris, HP-UX, AIX, and Scientific Linux support all of the services that IdM manages but do not use SSSD. Likewise, older Red Hat Enterprise Linux versions (6.1 and 5.6) support SSSD but have an older version, which does not support IdM as an identity provider.
When it is not possible to use a modern version of SSSD on a system, then clients can be configured to connect to the IdM server as if it were an LDAP directory service for identity lookups (using nss_ldap) and to IdM as if it were a regular Kerberos KDC (using pam_krb5).
Clients and IdM with LDAP and Kerberos

Figure 20.3. Clients and IdM with LDAP and Kerberos


If a Red Hat Enterprise Linux client is using an older version of SSSD, SSSD can still be configured to use the IdM server as its identity provider and its Kerberos authentication domain; this is described in the SSSD configuration section of the Red Hat Enterprise Linux Deployment Guide.
Any IdM domain client can be configured to use nss_ldap and pam_krb5 to connect to the IdM server. For some maintenance situations and IT structures, a scenario that fits the lowest common denominator may be required, using LDAP for both identity and authentication (nss_ldap and pam_ldap). However, it is generally best practice to use the most secure configuration possible for a client (meaning SSSD and Kerberos or LDAP and Kerberos).

20.1.2. Planning Password Migration

Probably the most visible issue that can impact LDAP-to-Identity Management migration is migrating user passwords.
Identity Management (by default) uses Kerberos for authentication and requires that each user have Kerberos hashes stored in the Identity Management Directory Server in addition to the standard user passwords. To generate these hashes, the user password needs to be available to the IdM server in cleartext. This is the case when the user is created in Identity Management. However, when the user is migrated from an LDAP directory, the associated user password is already hashed, so the corresponding Kerberos key cannot be generated.

IMPORTANT

Users cannot authenticate to the IdM domain or access IdM resources until they have Kerberos hashes.
If a user does not have a Kerberos hash[7], that user cannot log into the IdM domain even if he has a user account. There are three options for migrating passwords: forcing a password change, using a web page, and using SSSD.
Migrating users from an existing system provides a smoother transition but also requires parallel management of LDAP directory and IdM during the migration and transition process. If you do not preserve passwords, the migration can be performed more quickly but it requires more manual work by administrators and users.

20.1.2.1. Method 1: Using Temporary Passwords and Requiring a Change

When passwords are changed in Identity Management, they will be created with the appropriate Kerberos hashes. So one alternative for administrators is to force users to change their passwords by resetting all user passwords when user accounts are migrated. (This can also be done simply by re-creating the LDAP directory accounts in IdM, which automatically creates accounts with the appropriate keys.) The new users are assigned a temporary password which they change at the first login. No passwords are migrated.

20.1.2.2. Method 2: Using the Migration Web Page

When it is running in migration mode, Identity Management has a special web page in its web UI that will capture a cleartext password and create the appropriate Kerberos hash.
https://ipaserver.example.com/ipa/migration
Administrators could tell users to authenticate once to this web page, which would properly update their user accounts with their password and corresponding Kerberos hash, without requiring password changes.

20.1.2.3. Method 3: Using SSSD (Recommended)

SSSD can work with IdM to mitigate the user impact on migrating by generating the required user keys. For deployments with a lot of users or where users shouldn't be burdened with password changes, this is the best scenario.
  1. A user tries to log into a machine with SSSD.
  2. SSSD attempts to perform Kerberos authentication against the IdM server.
  3. Even though the user exists in the system, the authentication will fail with the error key type is not supported because the Kerberos hashes do not yet exist.
  4. SSSD the performs a plaintext LDAP bind over a secure connection.
  5. IdM intercepts this bind request. If the user has a Kerberos principal but no Kerberos hashes, then the IdM identity provider generates the hashes and stores them in the user entry.
  6. If authentication is successful, SSSD disconnects from IdM and tries Kerberos authentication again. This time, the request succeeds because the hash exists in the entry.
That entire process is entirely transparent to the user; as far as users known, they simply log into a client service and it works as normal.

20.1.2.4. Migrating Cleartext LDAP Passwords

Although in most deployments LDAP passwords are stored encrypted, there may be some users or some environments that use cleartext passwords for user entries.
When users are migrated from the LDAP server to the IdM server, their cleartext passwords are not migrated over. Identity Management does not allow cleartext passwords. Instead, a Kerberos principle is created for the user, the keytab is set to true, and the password is set as expired. This means that Identity Management requires the user to reset the password at the next login.

NOTE

If passwords are hashed, the password is successfully migrated through SSSD and the migration web page, as in Section 20.1.2.3, "Method 3: Using SSSD (Recommended)".

20.1.2.5. Automatically Resetting Passwords That Do Not Meet Requirements

If user passwords in the original directory do not meet the password policies defined in Identity Management, then the passwords must be reset after migration.
Password resets are done automatically the first time the users attempts to kinit into the IdM domain.
[jsmith@server ~]$ kinit Password for [email protected]: Password expired.  You must change it now.Enter new password: Enter it again:

20.1.3. Migration Considerations and Requirements

As you are planning migrating from an LDAP server to Identity Management, make sure that your LDAP environment is able to work with the Identity Management migration script.

20.1.3.1. LDAP Servers Supported for Migration

The migration process from an LDAP server to Identity Management uses a special script, ipa migrate-ds, to perform the migration. This script has certain expectations about the structure of the LDAP directory and LDAP entries in order to work. Migration is supported only for LDAPv3-compliant directory services, which include several common directories:
  • SunONE Directory Server
  • Apache Directory Server
  • OpenLDAP
Migration from an LDAP server to Identity Management has been tested with Red Hat Directory Server.

NOTE

Migration using the migration script is not supported for Microsoft Active Directory because it is not an LDAPv3-compliant directory. For assistance with migrating from Active Directory, contact Red Hat Professional Services.

20.1.3.2. Migration Environment Requirements

There are many different possible configuration scenarios for both Red Hat Directory Server and Identity Management, and any of those scenarios may affect the migration process. For the example migration procedures in this chapter, these are the assumptions about the environment:
  • A single LDAP directory domain is being migrated to one IdM realm. No consolidation is involved.
  • User passwords are stored as a hash in the LDAP directory that the IdM Directory Server can support.
  • The LDAP directory instance is both the identity store and the authentication method. Client machines are configured to use pam_ldap or nss_ldap to connect to the LDAP server.
  • Entries use only standard LDAP schema. Custom attributes will not be migrated to Identity Management.

20.1.3.3. Migration Tools

Identity Management uses a specific command, ipa migrate-ds, to drive the migration process so that LDAP directory data are properly formatted and imported cleanly into the IdM server.
The Identity Management server must be configured to run in migration mode, and then the migration script can be used.

20.1.3.4. Migration Sequence

There are four major steps when migrating to Identity Management, but the order varies slightly depending on whether you want to migrate the server first or the clients first.
With a client-based migration, SSSD is used to change the client configuration while an IdM server is configured:
  1. Deploy SSSD.
  2. Reconfigure clients to connect to the current LDAP server and then fail over to IdM.
  3. Install the IdM server.
  4. Migrate the user data using the IdM ipa-migrate-ds script. This exports the data from the LDAP directory, formats for the IdM schema, and then imports it into IdM.
  5. Take the LDAP server offline and allow clients to fail over to Identity Management transparently.
With a server migration, the LDAP to Identity Management migration comes first:
  1. Install the IdM server.
  2. Migrate the user data using the IdM ipa-migrate-ds script. This exports the data from the LDAP directory, formats it for the IdM schema, and then imports it into IdM.
  3. Optional. Deploy SSSD.
  4. Reconfigure clients to connect to IdM. It is not possible to simply replace the LDAP server. The IdM directory tree - and therefore user entry DNs - is different than the previous directory tree.
    While it is required that clients be reconfigured, clients do not need to be reconfigured immediately. Updated clients can point to the IdM server while other clients point to the old LDAP directory, allowing a reasonable testing and transition phase after the data are migrated.

    NOTE

    Do not run both an LDAP directory service and the IdM server for very long in parallel. This introduces the risk of user data being inconsistent between the two services.
Both processes provide a general migration procedure, but it may not work in every environment. Set up a test LDAP environment and test the migration process before attempting to migrate the real LDAP environment.

20.2. Examples for Using migrate-ds

The data migration is performed with the ipa migrate-ds command. At its simplest, the command takes the LDAP URL of the directory to migrate and exports the data based on common default settings.
ipa migrate-ds ldap://ldap.example.com:389
It is possible to customize how the migrate-ds commands identifies and exports data. This is useful if the original directory tree has a unique structure or if some entries or attributes within entries should be excluded from migration.

20.2.1. Migrating Specific Subtrees

The default directory structure places person entries in the ou=People subtree and group entries in the ou=Groups subtree. These subtrees are container entries for those different types of directory data. If no options are passed with the migrate-ds command, then the utility assumes that the given LDAP directory uses the ou=People and ou=Groups structure.
Many deployments may have an entirely different directory structure (or may only want to export certain parts of the directory tree). There are two options which allow administrators to give the RDN of a different user or group subtree:
  • --user-container
  • --group-container

NOTE

In both cases, the subtree must be the RDN only and must be relative to the base DN. For example, the ou=Employees,dc=example,dc=com subtree can be migrated using --user-container=ou=Employees, but ou=Employees,ou=People,dc=example,dc=com cannot be migrated with that option because ou=Employees is not a direct child of the base DN.
For example:
[root@ipaserver ~]# ipa migrate-ds --user-container=ou=employees --group-container="ou=employee groups" ldap://ldap.example.com:389
There is a third option that allows administrators to set a base DN for migration: --base-dn. With this option, it is possible to change the target for container subtrees. For example:
[root@ipaserver ~]# ipa migrate-ds --user-container=ou=employees --base-dn="ou=people,dc=example,dc=com" ldap://ldap.example.com:389
Now, the ou=Employees user subtree can be migrated from within the larger ou=People subtree without migrating every people-related subtree.

20.2.2. Specifically Including or Excluding Entries

By default, the migrate-ds script exports every user entry with the person object class and every group entry within the given user and group subtrees.
In some migration paths, only specific types of users and groups may need to be exported, or, conversely, specific users and groups may need to be excluded.
On option is to set positively which types of users and groups to include. This is done by setting which object classes to search for when looking for user or group entries.
This is a really useful option when there are custom object classes used in an environment for different user types. For example, this migrates only users with the custom fullTimeEmployee object class:
[root@ipaserver ~]# ipa migrate-ds --user-objectclass=fullTimeEmployee ldap://ldap.example.com:389
Because of the different types of groups, this is also very useful for migrating only certain types of groups (such as user groups) while excluding other types of groups, like certificate groups. For example:
[root@ipaserver ~]# ipa migrate-ds --group-objectclass=groupOfNames,groupOfUniqueNames ldap://ldap.example.com:389
Positively specifying user and groups to migrate based on object class implicitly excludes all other users and groups from migration.
Alternatively, it can be useful to migrate all user and group entries except for just a small handful of entries. Specific user or group accounts can be excluded while all others of that type are migrated. For example, this excludes a hobbies group and two users:
[root@ipaserver ~]# ipa migrate-ds --exclude-groups="Golfers Group" --exclude-users=jsmith,bjensen ldap://ldap.example.com:389
Specifying an object class to migrate can be used together with excluding specific entries. For example, this specifically includes users with the fullTimeEmployee object class, yet excludes three managers:
[root@ipaserver ~]# ipa migrate-ds --user-objectclass=fullTimeEmployee --exclude-users=jsmith,bjensen,mreynolds ldap://ldap.example.com:389

20.2.3. Excluding Entry Attributes

By default, every attribute and object class for a user or group entry is migrated. There are some cases where that may not be realistic, either because of bandwidth and network constraints or because the attribute data are no longer relevant. For example, if users are going to be assigned new user certificates as they join the IdM domain, then there is no reason to migrate the userCertificate attribute.
Specific object classes and attributes can be ignored by the migrate-ds by using any of several different options:
  • --user-ignore-objectclass
  • --user-ignore-attribute
  • --group-ignore-objectclass
  • --group-ignore-attribute
For example, to exclude the userCertificate attribute and strongAuthenticationUser object class for users and the groupOfCertificates object class for groups:
[root@ipaserver ~]# ipa migrate-ds --user-ignore-attribute=userCertificate --user-ignore-objectclass=strongAuthenticationUser --group-ignore-objectclass=groupOfCertificates ldap://ldap.example.com:389

NOTE

Make sure not to ignore any required attributes. Also, when excluding object classes, make sure to exclude any attributes which are only supported by that object class.

20.2.4. Setting the Schema to Use

By default, Identity Management uses RFC2307bis schema to define user, host, hostgroup, and other network identities. This schema option can be reset to use RFC2307 schema instead:
[root@ipaserver ~]# ipa migrate-ds --schema=RFC2307 ldap://ldap.example.com:389

20.3. Scenario 1: Using SSSD as Part of Migration

IMPORTANT

This is a general migration procedure, but it may not work in every environment.
It is strongly recommended that you set up a test LDAP environment and test the migration process before attempting to migrate the real LDAP environment.
  1. Set up SSSD. Using SSSD allows the required Kerberos keys and server certificates to be delivered to the clients.
    1. Install SSSD on every client machine:
      # yum install sssd
    2. Configure an LDAP identity provider in SSSD to use the existing Directory Server for all functions (authentication, identity lookups, access, and password changes). This ensures every client works properly with the existing directory service.
  2. Install Identity Management, including any custom LDAP directory schema[8], on a different machine from the existing LDAP directory.
  3. Enable the IdM server to allow migration:
    # ipa config-mod --enable-migration=TRUE
  4. Disable the compat plug-in.
    # ipa-compat-manage disable
  5. Restart the IdM Directory Server instance.
    # service dirsrv restart
  6. Run the IdM migration script, ipa migrate-ds. At its most basic, this requires only the LDAP URL of the LDAP directory instance to migrate:
    # ipa migrate-ds ldap://ldap.example.com:389
    Simply passing the LDAP URL migrates all of the directory data using common default settings. The user and group data can be selectively migrated by specifying other options, as covered in Section 20.2, "Examples for Using migrate-ds".
    Once the information is exported, the script adds all required IdM object classes and attributes and converts DNs in attributes to match the IdM directory tree.
  7. Re-enable the compat plug-in.
    # ipa-compat-manage enable
  8. Restart the IdM Directory Server instance.
    # service dirsrv restart
  9. Move clients that have SSSD installed from the LDAP backend to the Identity Management backend and enroll them as client with IdM. This downloads the required keys and certificates.
    On Red Hat Enterprise Linux clients, this can be done using the ipa-client-install command. For example:
    # ipa-client-install --enable-dns-updates
  10. Have users log into a machine with SSSD and Identity Management backend. This generates the required Kerberos keys for the user.
    To monitor the user migration process, query the existing LDAP directory to see which user accounts have a password but do not yet have a Kerberos principal key.
    $ ldapsearch -LL -x -D 'cn=Directory Manager' -w secret -b 'ou=people,dc=example,dc=com' '(&(!(krbprincipalkey=*))(userpassword=*))' uid

    NOTE

    Include the quotes around the filter so that it is not interpreted by the shell.
  11. Once users have been migrated over, configure non-SSSD clients to use the IdM domain, as required.
  12. When the migration of all clients and users is complete, decommission the LDAP directory.

20.4. Scenario 2: Migrating an LDAP Server Directly to Identity Management

IMPORTANT

This is a general migration procedure, but it may not work in every environment.
It is strongly recommended that you set up a test LDAP environment and test the migration process before attempting to migrate the real LDAP environment.
  1. Install the IdM server, including any custom LDAP directory schema[9], on a different machine from the existing LDAP directory.
  2. Disable the compat plug-in.
    # ipa-compat-manage disable
  3. Restart the IdM Directory Server instance.
    # service dirsrv restart
  4. Enable the IdM server to allow migration:
    # ipa config-mod --enable-migration=TRUE
  5. Run the IdM migration script, ipa migrate-ds. At its most basic, this requires only the LDAP URL of the LDAP directory instance to migrate:
    # ipa migrate-ds ldap://ldap.example.com:389
    Simply passing the LDAP URL migrates all of the directory data using common default settings. The user and group data can be selectively migrated by specifying other options, as covered in Section 20.2, "Examples for Using migrate-ds".
    Once the information is exported, the script adds all required IdM object classes and attributes and converts DNs in attributes to match the IdM directory tree.
  6. Re-enable the compat plug-in.
    # ipa-compat-manage enable
  7. Restart the IdM Directory Server instance.
    # service dirsrv restart
  8. Update the client configuration to use PAM_LDAP and NSS_LDAP to connect to IdM instead of connecting to an LDAP directory, NIS, or local files.
  9. Optional. Set up SSSD. Using SSSD migrates user passwords without additional user interaction, as described in Section 20.1.2, "Planning Password Migration".
    1. Install SSSD on every client machine:
      # yum install sssd
    2. Run the ipa-client-install to configure SSSD and related services to use the IdM server for identity and Kerberos authentication.
  10. Instruct users to log into IdM using either SSSD client or the migration web page if SSSD is not available on the client. Both methods automatically migrate the user password into Identity Management.
    https://ipaserver.example.com/ipa/migration
  11. Optional. Reconfigure non-SSSD clients to use Kerberos authentication (pam_krb5) instead of LDAP authentication (pam_ldap).

    NOTE

    Use PAM_LDAP modules until all of the users have been migrated; then it is possible to use PAM_KRB5.
  12. When the migration of all clients and users is complete, decommission the LDAP directory.

[7] It is possible to use LDAP authentication in Identity Management instead of Kerberos authentication, which means that Kerberos hashes are not required for users. However, this limits the capabilities of Identity Management and is not recommended.
[8] There is limited support for custom user and group schema in Identity Management.
[9] There is limited support for custom user and group schema in Identity Management.

Frequently Asked Questions

Q: Is it possible to change the IP address of the master server?
Q: Why are there restrictions on the length of user and group names? How can I change this?
Q: What is the difference between a replica and a master server?
Q: Why does the ipa-client-install script fail to find the IPA server on a network that uses Active Directory DNS?
Q: Can an administrator who is connected to "Server B" revoke a certificate issued by "Server A"?
Q:
Is it possible to change the IP address of the master server?
A:
Yes. If you are only changing the IP address, it is sufficient to update the /etc/hosts file, the system configuration, and the DNS entry.
Q:
Why are there restrictions on the length of user and group names? How can I change this?
A:
User and group name lengths are specified in the policy. The default maximum username length is 32 characters. The maximum configurable length for user or group names is 255 characters. This complements some supported client operating systems which limit the length of usernames.
The default settings can be changed in the IdM UI or using the ipa config-mod command. For example:
4 ipa config-mod --maxusername=50
Q:
What is the difference between a replica and a master server?
A:
A master server maintains a certificate authority. A replica server has its certificate issued by the master CA.
Q:
Why does the ipa-client-install script fail to find the IPA server on a network that uses Active Directory DNS?
A:
Active Directory has its own SRV records for Kerberos and LDAP. The ipa-client-install script can retrieve those records instead of any that have been added for the IdM domain.
When running ipa-client-install, manually enter the server information to ensure that the script uses the IdM SRV records instead of Active Directory records. The ipa-client-install options are listed in the ipa-client-install manpage.
Q:
Can an administrator who is connected to "Server B" revoke a certificate issued by "Server A"?
A:
Yes, assuming that Servers A and B contain non-cloned CAs which have their database information replicated to share revocation information only.

Working with certmonger

Part of managing machine authentication is managing machine certificates. On clients, IdM manages the certificate lifecycle with the certmonger service, which works together with the certificate authority (CA) provided by IdM.
The certmonger daemon and its command-line clients simplify the process of generating public/private key pairs, creating certificate requests, and submitting requests to the CA for signing. As part of managing certificates, the certmonger daemon monitors certificates for expiration and can renew certificates that are about to expire. The certificates that certmonger monitors are tracked in files stored in a configurable directory. The default location is /var/lib/certmonger/requests.
certmonger uses the IdM getcert command to manage all certificates. As covered in Section 2.4.3.2, "Using Different CA Configurations", an IdM server can be configured to use different types of certificate authorities. The most common (and recommended) configuration is to use a full CA server, but it is also possible to use a much more limited, self-signed CA. The exact getcert command used by certmonger to communicate with the IdM backend depends on which type of CA is used. The ipa-getcert command is used with a full CA, while the selfsign-getcert command is used with a self-signed CA.

NOTE

Because of general security issues, self-signed certificates are not typically used in production, but can be used for development and testing.

B.1. Requesting a Certificate with certmonger

With the IdM CA, certmonger uses the ipa-getcert command.
Certificates and keys are stored locally in plaintext files (.pem) or in an NSS database, identified by the certificate nickname. When requesting a certificate, then, the request should identify the location where the certificate will be stored and the nickname of the certificate. For example:
# ipa-getcert request -d /etc/pki/nssdb -n Server-Cert
The /etc/pki/nssdb file is the global NSS database, and Server-Cert is the nickname of this certificate. The certificate nickname must be unique within this database.
When requesting a certificate to be used with an IdM service, the -K option is required to specify the service principal. Otherwise, certmonger assumes the certificate is for a host. The -N option must specify the certificate subject DN, and the subject base DN must match the base DN for the IdM server, or the request is rejected.
$ ipa-getcert request -d /etc/httpd/alias -n Server-Cert -K HTTP/client1.example.com -N 'CN=client1.example.com,O=EXAMPLE.COM'

Example B.1. Using certmonger for a Service

$ ipa-getcert request -r -f /etc/httpd/conf/ssl.crt/server.crt -k /etc/httpd/conf/ssl.key/server.key -N CN=`hostname --fqdn` -D `hostname` -U id-kp-serverAuth

The options vary depending on whether you are using a self-signed certificate (selfsign-getcert) and the desired configuration for the final certificate, as well as other settings. In Example B.1, "Using certmonger for a Service", these are common options:
  • The -r option will automatically renew the certificate if the key pair already exists. This is used by default.
  • The -f option stores the certificate in the given file.
  • The -k option either stores the key in the given file or, if the key file already exists, uses the key in the file.
  • The -N option gives the subject name.
  • The -D option gives the DNS domain name.
  • The -U option sets the extended key usage flag.

B.2. Storing Certificates in NSS Databases

By default, certmonger uses plaintext files to store the key and the certificate, but these keys and certificates can also be stored in NSS databases. This is done using the -d option to set the security database location and -n to give the certificate nickname which is used for the certificate in the database. These options are used instead of the PEM files given in the -f and -k options.
For example: 
# ipa-getcert request -d /export/alias -n ServerCert ...

B.3. Tracking Certificates with certmonger

certmonger can manage the entire certificate lifecycle. Along with generating requests, certmonger can track a certificate and automatically renew it when it expires at the end of its validity period.
This is done using the start-tracking command with the getcert command. The -I option creates the tracking entry, along with pointers to the key and certificate files, either in an NSS database (-d and -n) or in the PEM file (-f and -k). The -r option tells certmonger to renew the certificate.
# ipa-getcert start-tracking -I cert1-tracker -d /export/alias -n ServerCert -r

TIP

The -r option can be passed with the request command, in Example B.1, "Using certmonger for a Service". In that case, the requested certificate is automatically tracked and renewed by certmonger. Then, it is not necessary to configure tracking manually.
A certificate can be untracked by certmonger by using the stop-tracking command.
(Sebelumnya) 3 : Chapter 19. Configuration ...3 : Glossary - Identity Manage ... (Berikutnya)