Buscar
ApoyoConsolaDesarrolladoresIniciar una pruebaContacto

Este contenido no está disponible en el idioma seleccionado.

Chapter 2. Preparing the system for IdM server installation

download PDF

The following sections list the requirements to install an Identity Management (IdM) server. Before the installation, verify your system meets these requirements.

2.1. Prerequisites

  • You need root privileges to install an Identity Management (IdM) server on your host.

2.2. Hardware recommendations

RAM is the most important hardware feature to size properly. Make sure your system has enough RAM available. Typical RAM requirements are:

  • For 10,000 users and 100 groups: at least 4 GB of RAM and 4 GB swap space
  • For 100,000 users and 50,000 groups: at least 16 GB of RAM and 4 GB of swap space

For larger deployments, it is more effective to increase the RAM than to increase disk space because much of the data is stored in cache. In general, adding more RAM leads to better performance for larger deployments due to caching.

Note

A basic user entry or a simple host entry with a certificate is approximately 5—​10 kB in size.

2.3. Custom configuration requirements for IdM

Install an Identity Management (IdM) server on a clean system without any custom configuration for services such as DNS, Kerberos, Apache, or Directory Server.

The IdM server installation overwrites system files to set up the IdM domain. IdM backs up the original system files to /var/lib/ipa/sysrestore/. When an IdM server is uninstalled at the end of the lifecycle, these files are restored.

IPv6 requirements in IdM

The IdM system must have the IPv6 protocol enabled in the kernel and localhost (::1) is able to use it. If IPv6 is disabled, then the CLDAP plug-in used by the IdM services fails to initialize.

Note

IPv6 does not have to be enabled on the network. It is possible to enable IPv6 stack without enabling IPv6 addresses if required.

Support for encryption types in IdM

Red Hat Enterprise Linux (RHEL) uses Version 5 of the Kerberos protocol, which supports encryption types such as Advanced Encryption Standard (AES), Camellia, and Data Encryption Standard (DES).

List of supported encryption types

While the Kerberos libraries on IdM servers and clients might support more encryption types, the IdM Kerberos Distribution Center (KDC) only supports the following encryption types:

  • aes256-cts:normal
  • aes256-cts:special (default)
  • aes128-cts:normal
  • aes128-cts:special (default)
  • aes128-sha2:normal
  • aes128-sha2:special
  • aes256-sha2:normal
  • aes256-sha2:special
  • camellia128-cts-cmac:normal
  • camellia128-cts-cmac:special
  • camellia256-cts-cmac:normal
  • camellia256-cts-cmac:special

RC4 encryption types are disabled by default

The following RC4 encryption types have been deprecated and disabled by default in RHEL 8, as they are considered less secure than the newer AES-128 and AES-256 encryption types:

  • arcfour-hmac:normal
  • arcfour-hmac:special

For more information about manually enabling RC4 support for compatibility with legacy Active Directory environments, see Ensuring support for common encryption types in AD and RHEL.

Support for DES and 3DES encryption has been removed

Due to security reasons, support for the DES algorithm was deprecated in RHEL 7. The recent rebase of Kerberos packages in RHEL 8.3.0 removes support for single-DES (DES) and triple-DES (3DES) encryption types from RHEL 8.

Note

Standard RHEL 8 IdM installations do not use DES or 3DES encryption types by default and are unaffected by the Kerberos upgrade.

If you manually configured any services or users to only use DES or 3DES encryption (for example, for legacy clients), you might experience service interruptions after updating to the latest Kerberos packages, such as:

  • Kerberos authentication errors
  • unknown enctype encryption errors
  • KDCs with DES-encrypted Database Master Keys (K/M) fail to start

Red Hat recommends you do not use DES or 3DES encryption in your environment.

Note

You only need to disable DES and 3DES encryption types if you configured your environment to use them.

Support for system-wide cryptographic policies in IdM

IdM uses the DEFAULT system-wide cryptographic policy. This policy offers secure settings for current threat models. It allows the TLS 1.2 and 1.3 protocols, as well as the IKEv2 and SSH2 protocols. The RSA keys and Diffie-Hellman parameters are accepted if they are at least 2048 bits long. This policy does not allow DES, 3DES, RC4, DSA, TLS v1.0, and other weaker algorithms.

Note

You cannot install an IdM server while using the FUTURE system-wide cryptographic policy. When installing an IdM server, ensure you are using the DEFAULT system-wide cryptographic policy.

Additional Resources

2.4. FIPS compliance

With RHEL 8.3.0 or later, you can install a new IdM server or replica on a system with the Federal Information Processing Standard (FIPS) 140 mode enabled.

To install IdM in FIPS mode, first enable FIPS mode on the host, then install IdM. The IdM installation script detects if FIPS is enabled and configures IdM to only use encryption types that are compliant with the FIPS 140 standard:

  • aes256-cts:normal
  • aes256-cts:special
  • aes128-cts:normal
  • aes128-cts:special
  • aes128-sha2:normal
  • aes128-sha2:special
  • aes256-sha2:normal
  • aes256-sha2:special

For an IdM environment to be FIPS-compliant, all IdM replicas must have FIPS mode enabled.

Red Hat recommends that you enable FIPS mode in IdM clients as well, especially if you might promote those clients to IdM replicas. Ultimately, it is up to administrators to determine how they meet FIPS requirements; Red Hat does not enforce FIPS criteria.

Migration to FIPS-compliant IdM

You cannot migrate an existing IdM installation from a non-FIPS environment to a FIPS-compliant installation. This is not a technical problem but a legal and regulatory restriction.

To operate a FIPS-compliant system, all cryptographic key material must be created in FIPS mode. Furthermore, the cryptographic key material must never leave the FIPS environment unless it is securely wrapped and never unwrapped in non-FIPS environments.

If your scenario requires a migration of a non-FIPS IdM realm to a FIPS-compliant one, you must:

  1. create a new IdM realm in FIPS mode
  2. perform data migration from the non-FIPS realm to the new FIPS-mode realm with a filter that blocks all key material

The migration filter must block:

  • KDC master key, keytabs, and all related Kerberos key material
  • User passwords
  • All certificates including CA, service, and user certificates
  • OTP tokens
  • SSH keys and fingerprints
  • DNSSEC KSK and ZSK
  • All vault entries
  • AD trust-related key material

Effectively, the new FIPS installation is a different installation. Even with rigorous filtering, such a migration may not pass a FIPS 140 certification. Your FIPS auditor may flag this migration.

Additional Resources

2.5. Support for cross-forest trust with FIPS mode enabled

To establish a cross-forest trust with an Active Directory (AD) domain while FIPS mode is enabled, you must meet the following requirements:

  • IdM servers are on RHEL 8.4.0 or later.
  • You must authenticate with an AD administrative account when setting up a trust. You cannot establish a trust using a shared secret while FIPS mode is enabled.
Important

RADIUS authentication is not FIPS-compliant as the RADIUS protocol uses the MD5 hash function to encrypt passwords between client and server and, in FIPS mode, OpenSSL disables the use of the MD5 digest algorithm. However, if the RADIUS server is running on the same host as the IdM server, you can work around the problem and enable MD5 by performing the steps described in How to configure FreeRADIUS authentication in FIPS mode.

Additional Resources

2.6. Time service requirements for IdM

The following sections discuss using chronyd to keep your IdM hosts in sync with a central time source:

2.6.1. How IdM uses chronyd for synchronization

You can use chronyd to keep your IdM hosts in sync with a central time source as described here.

Kerberos, the underlying authentication mechanism in IdM, uses time stamps as part of its protocol. Kerberos authentication fails if the system time of an IdM client differs by more than five minutes from the system time of the Key Distribution Center (KDC).

To ensure that IdM servers and clients stay in sync with a central time source, IdM installation scripts automatically configure chronyd Network Time Protocol (NTP) client software.

If you do not pass any NTP options to the IdM installation command, the installer searches for _ntp._udp DNS service (SRV) records that point to the NTP server in your network and configures chrony with that IP address. If you do not have any _ntp._udp SRV records, chronyd uses the configuration shipped with the chrony package.

Note

Because ntpd has been deprecated in favor of chronyd in RHEL 8, IdM servers are no longer configured as Network Time Protocol (NTP) servers and are only configured as NTP clients. The RHEL 7 NTP Server IdM server role has also been deprecated in RHEL 8.

Additional resources

2.6.2. List of NTP configuration options for IdM installation commands

You can use chronyd to keep your IdM hosts in sync with a central time source.

You can specify the following options with any of the IdM installation commands (ipa-server-install, ipa-replica-install, ipa-client-install) to configure chronyd client software during setup.

Table 2.1. List of NTP configuration options for IdM installation commands
OptionBehavior

--ntp-server

Use it to specify one NTP server. You can use it multiple times to specify multiple servers.

--ntp-pool

Use it to specify a pool of multiple NTP servers resolved as one hostname.

-N, --no-ntp

Do not configure, start, or enable chronyd.

Additional resources

2.6.3. Ensuring IdM can reference your NTP time server

This procedure verifies you have the necessary configurations in place for IdM to be able to synchronize with your Network Time Protocol (NTP) time server.

Prerequisites

  • You have configured an NTP time server in your environment. In this example, the hostname of the previously configured time server is ntpserver.example.com.

Procedure

  1. Perform a DNS service (SRV) record search for NTP servers in your environment. 

    [user@server ~]$ dig +short -t SRV _ntp._udp.example.com
0 100 123 ntpserver.example.com.
  2. If the previous dig search does not return your time server, add a _ntp._udp SRV record that points to your time server on port 123. This process depends on your DNS solution.

Verification

  • Verify that DNS returns an entry for your time server on port 123 when you perform a search for _ntp._udp SRV records. 

    [user@server ~]$ dig +short -t SRV _ntp._udp.example.com
0 100 123 ntpserver.example.com.

Additional resources

2.6.4. Additional resources

2.7. Host name and DNS requirements for IdM

The host name and DNS requirements for server and replica systems are outlined below and also how to verify that the systems meet the requirements.

These requirements apply to all Identity Management (IdM) servers, those with integrated DNS and those without integrated DNS.

Warning

DNS records are vital for nearly all IdM domain functions, including running LDAP directory services, Kerberos, and Active Directory integration. Be extremely cautious and ensure that:

  • You have a tested and functional DNS service available
  • The service is properly configured

This requirement applies to IdM servers with and without integrated DNS.

Verify the server host name

The host name must be a fully qualified domain name, such as server.idm.example.com.

Important

Do not use single-label domain names, for example .company: the IdM domain must be composed of one or more subdomains and a top level domain, for example example.com or company.example.com.

The fully qualified domain name must meet the following conditions:

  • It is a valid DNS name, which means only numbers, alphabetic characters, and hyphens (-) are allowed. Other characters, such as underscores (_), in the host name cause DNS failures.
  • It is all lower-case. No capital letters are allowed.
  • It does not resolve to the loopback address. It must resolve to the system’s public IP address, not to 127.0.0.1.

To verify the host name, use the hostname utility on the system where you want to install: 

# hostname
server.idm.example.com

The output of hostname must not be localhost or localhost6.

Verify the forward and reverse DNS configuration

  1. Obtain the IP address of the server.

    1. The ip addr show command displays both the IPv4 and IPv6 addresses. In the following example, the relevant IPv6 address is 2001:DB8::1111 because its scope is global: 

      [root@server ~]# ip addr show
...
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
	link/ether 00:1a:4a:10:4e:33 brd ff:ff:ff:ff:ff:ff
	inet 192.0.2.1/24 brd 192.0.2.255 scope global dynamic eth0
		valid_lft 106694sec preferred_lft 106694sec
	inet6 2001:DB8::1111/32 scope global dynamic
 		valid_lft 2591521sec preferred_lft 604321sec
	inet6 fe80::56ee:75ff:fe2b:def6/64 scope link
	       valid_lft forever preferred_lft forever
...

  2. Verify the forward DNS configuration using the dig utility.

    1. Run the command dig +short server.idm.example.com A. The returned IPv4 address must match the IP address returned by ip addr show: 

      [root@server ~]# dig +short server.idm.example.com A
192.0.2.1

    2. Run the command dig +short server.idm.example.com AAAA. If it returns an address, it must match the IPv6 address returned by ip addr show: 

      [root@server ~]# dig +short server.idm.example.com AAAA
2001:DB8::1111
      Note

      If dig does not return any output for the AAAA record, it does not indicate incorrect configuration. No output only means that no IPv6 address is configured in DNS for the system. If you do not intend to use the IPv6 protocol in your network, you can proceed with the installation in this situation.

  3. Verify the reverse DNS configuration (PTR records). Use the dig utility and add the IP address.

    If the commands below display a different host name or no host name, the reverse DNS configuration is incorrect.

    1. Run the command dig +short -x IPv4_address. The output must display the server host name. For example: 

      [root@server ~]# dig +short -x 192.0.2.1
server.idm.example.com

    2. If the command dig +short -x server.idm.example.com AAAA in the previous step returned an IPv6 address, use dig to query the IPv6 address too. The output must display the server host name. For example: 

      [root@server ~]# dig +short -x 2001:DB8::1111
server.idm.example.com
      Note

      If dig +short server.idm.example.com AAAA in the previous step did not display any IPv6 address, querying the AAAA record does not output anything. In this case, this is normal behavior and does not indicate incorrect configuration.

      Warning

      If a reverse DNS (PTR record) search returns multiple host names, httpd and other software associated with IdM may show unpredictable behavior. Red Hat strongly recommends configuring only one PTR record per IP.

Verify the standards-compliance of DNS forwarders (required for integrated DNS only)

Ensure that all DNS forwarders you want to use with the IdM DNS server comply with the Extension Mechanisms for DNS (EDNS0) and DNS Security Extensions (DNSSEC) standards. To do this, inspect the output of the following command for each forwarder separately: 

$ dig +dnssec @IP_address_of_the_DNS_forwarder . SOA

The expected output displayed by the command contains the following information:

  • Status: NOERROR
  • Flags: ra
  • EDNS flags: do
  • The RRSIG record must be present in the ANSWER section

If any of these items is missing from the output, inspect the documentation for your DNS forwarder and verify that EDNS0 and DNSSEC are supported and enabled. In the latest versions of the BIND server, the dnssec-enable yes; option must be set in the /etc/named.conf file.

Example of the expected output produced by dig: 

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48655
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096

;; ANSWER SECTION:
. 31679 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2015100701 1800 900 604800 86400
. 31679 IN RRSIG SOA 8 0 86400 20151017170000 20151007160000 62530 . GNVz7SQs [...]
Verify the /etc/hosts file

Verify that the /etc/hosts file fulfills one of the following conditions:

  • The file does not contain an entry for the host. It only lists the IPv4 and IPv6 localhost entries for the host.

  • The file contains an entry for the host and the file fulfills all the following conditions:

    • The first two entries are the IPv4 and IPv6 localhost entries.
    • The next entry specifies the IdM server IPv4 address and host name.
    • The FQDN of the IdM server comes before the short name of the IdM server.
    • The IdM server host name is not part of the localhost entry.

    The following is an example of a correctly configured /etc/hosts file: 

127.0.0.1   localhost localhost.localdomain \
localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain \
localhost6 localhost6.localdomain6
192.0.2.1	server.idm.example.com	server
2001:DB8::1111	server.idm.example.com	server

2.8. Port requirements for IdM

Identity Management (IdM) uses several ports to communicate with its services. These ports must be open and available for incoming connections to the IdM server for IdM to work. They must not be currently used by another service or blocked by a firewall.

Table 2.2. IdM ports
ServicePortsProtocol

HTTP/HTTPS

80, 443

TCP

LDAP/LDAPS

389, 636

TCP

Kerberos

88, 464

TCP and UDP

DNS

53

TCP and UDP (optional)

Note

IdM uses ports 80 and 389. This is a secure practice because of the following safeguards:

  • IdM normally redirects requests that arrive on port 80 to port 443. Port 80 (HTTP) is only used to provide Online Certificate Status Protocol (OCSP) responses and Certificate Revocation Lists (CRL). Both are digitally signed and therefore secured against man-in-the-middle attacks.
  • Port 389 (LDAP) uses STARTTLS and Generic Security Services API (GSSAPI) for encryption.

In addition, ports 8080, 8443, and 749 must be free as they are used internally. Do not open these ports and instead leave them blocked by a firewall.

Table 2.3. firewalld services
Service nameFor details, see:

freeipa-ldap

/usr/lib/firewalld/services/freeipa-ldap.xml

freeipa-ldaps

/usr/lib/firewalld/services/freeipa-ldaps.xml

dns

/usr/lib/firewalld/services/dns.xml

2.9. Opening the ports required by IdM

Procedure

  1. Verify that the firewalld service is running.

    • To find out if firewalld is currently running: 

      # systemctl status firewalld.service

    • To start firewalld and configure it to start automatically when the system boots: 

      # systemctl start firewalld.service
# systemctl enable firewalld.service

  2. Open the required ports using the firewall-cmd utility. Choose one of the following options:

    1. Add the individual ports to the firewall by using the firewall-cmd --add-port command. For example, to open the ports in the default zone: 

      # firewall-cmd --permanent --add-port={80/tcp,443/tcp,389/tcp,636/tcp,88/tcp,88/udp,464/tcp,464/udp,53/tcp,53/udp}

    2. Add the firewalld services to the firewall by using the firewall-cmd --add-service command. For example, to open the ports in the default zone: 

      # firewall-cmd --permanent --add-service={freeipa-4,dns}

      For details on using firewall-cmd to open ports on a system, see the firewall-cmd(1) man page.

  3. Reload the firewall-cmd configuration to ensure that the change takes place immediately: 

    # firewall-cmd --reload

    Note that reloading firewalld on a system in production can cause DNS connection time outs. If required, to avoid the risk of time outs and to make the changes persistent on the running system, use the --runtime-to-permanent option of the firewall-cmd command, for example: 

    # firewall-cmd --runtime-to-permanent

Verification

  • Log in to a host on the client subnet and use the nmap or nc utilities to connect to the opened ports or run a port scan.

    • For example, to scan the ports that are required for TCP traffic: 

      $ nmap -p 80,443,389,636,88,464,53 server.idm.example.com
[...]
PORT    STATE SERVICE
53/tcp  open  domain
80/tcp  open  http
88/tcp  open  kerberos-sec
389/tcp open  ldap
443/tcp open  https
464/tcp open  kpasswd5
636/tcp open  ldapssl

    • To scan the ports that are required for UDP traffic: 

      # nmap -sU -p 88,464,53 server.idm.example.com
[...]
PORT    STATE         SERVICE
53/udp  open          domain
88/udp  open|filtered kerberos-sec
464/udp open|filtered kpasswd5
Note

You also have to open network-based firewalls for both incoming and outgoing traffic.

2.10. Installing packages required for an IdM server

In RHEL8, the packages necessary for installing an Identity Management (IdM) server are shipped as a module. The IdM server module stream is called the DL1 stream, and you need to enable this stream before downloading packages from this stream. The following procedure shows how to download the packages necessary for setting up the IdM environment of your choice.

Prerequisites

  • You have a newly installed RHEL system.

  • You have made the required repositories available:

    • If your RHEL system is not running in the cloud, you have registered your system with the Red Hat Subscription Manager (RHSM). For details, see Subscription Central. You have also enabled the BaseOS and AppStream repositories that IdM uses: 

      # subscription-manager repos --enable=rhel-8-for-x86_64-baseos-rpms
# subscription-manager repos --enable=rhel-8-for-x86_64-appstream-rpms

    For details on how to enable and disable specific repositories using RHSM, see Subscription Central.

    • If your RHEL system is running in the cloud, skip the registration. The required repositories are already available via the Red Hat Update Infrastructure (RHUI).
  • You have not previously enabled an IdM module stream.

Procedure

  1. Enable the idm:DL1 stream: 

    # yum module enable idm:DL1

  2. Switch to the RPMs delivered through the idm:DL1 stream: 

    # yum distro-sync

  3. Choose one of the following options, depending on your IdM requirements:

    • To download the packages necessary for installing an IdM server without an integrated DNS: 

      # yum module install idm:DL1/server

    • To download the packages necessary for installing an IdM server with an integrated DNS: 

      # yum module install idm:DL1/dns

    • To download the packages necessary for installing an IdM server that has a trust agreement with Active Directory: 

      # yum module install idm:DL1/adtrust

    • To download the packages from multiple profiles, for example the adtrust and dns profiles: 

      # yum module install idm:DL1/{dns,adtrust}

    • To download the packages necessary for installing an IdM client: 

      # yum module install idm:DL1/client
Important

When switching to a new module stream once you have already enabled a different stream and downloaded packages from it, you need to first explicitly remove all the relevant installed content and disable the current module stream before enabling the new module stream. Trying to enable a new stream without disabling the current one results in an error. For details on how to proceed, see Switching to a later stream.

Warning

While it is possible to install packages from modules individually, be aware that if you install any package from a module that is not listed as "API" for that module, it is only going to be supported by Red Hat in the context of that module. For example, if you install bind-dyndb-ldap directly from the repository to use with your custom 389 Directory Server setup, any problems that you have will be ignored unless they occur for IdM, too.

2.11. Setting the correct file mode creation mask for IdM installation

The Identity Management (IdM) installation process requires that the file mode creation mask (umask) is set to 0022 for the root account. This allows users other than root to read files created during the installation. If a different umask is set, the installation of an IdM server will display a warning. If you continue with the installation, some functions of the server will not perform properly. For example, you will be unable to install an IdM replica from this server. After the installation, you can set the umask back to its original value.

Prerequisites

  • You have root privileges.

Procedure

  1. Optional: Display the current umask: 

    # umask
0027

  2. Set the umask to 0022: 

    # umask 0022

  3. Optional: After the IdM installation is complete, set the umask back to its original value: 

    # umask 0027

2.12. Ensuring that fapolicyd rules do not block IdM installation and operation

If you are using the fapolicyd software framework on your RHEL host to control the execution of applications based on a user-defined policy, the installation of the Identity Management (IdM) server can fail. As the installation and operation requires the Java program to complete successfully, ensure that Java and Java classes are not blocked by any fapolicyd rules.

For more information, see the fapolicy restrictions causing IdM installation failures KCS solution.

2.13. Options for the IdM installation commands

Commands such as ipa-server-install, ipa-replica-install, ipa-dns-install and ipa-ca-install have numerous options you can use to supply additional information for an interactive installation. You can also use these options to script an unattended installation.

The following tables display some of the most common options for different components. Options for a specific component are shared across multiple commands. For example, you can use the --ca-subject option with both the ipa-ca-install and ipa-server-install commands.

For an exhaustive list of options, see the ipa-server-install(1), ipa-replica-install(1), ipa-dns-install(1) and ipa-ca-install(1) man pages.

Table 2.4. General options: available for ipa-server-install and ipa-replica-install
ArgumentDescription

-d, --debug

Enables debug logging for more verbose output.

-U, --unattended

Enables an unattended installation session that does not prompt for user input.

--hostname=server.idm.example.com

The fully-qualified domain name of the IdM server machine. Only numbers, lowercase alphabetic characters, and hyphens (-) are allowed.

--ip-address 127.0.0.1

Specifies the IP address of the server. This option only accepts IP addresses associated with the local interface.

--dirsrv-config-file <LDIF_file_name>

The path to an LDIF file used to modify the configuration of the directory server instance.

-n example.com

The name of the LDAP server domain to use for the IdM domain. This is usually based on the IdM server’s hostname.

-p <directory_manager_password>

The password of the superuser, cn=Directory Manager, for the LDAP service.

-a <ipa_admin_password>

The password for the admin IdM administrator account to authenticate to the Kerberos realm. For ipa-replica-install, use -w instead.

-r <KERBEROS_REALM_NAME>

The name of the Kerberos realm to create for the IdM domain in uppercase, such as EXAMPLE.COM. For ipa-replica-install, this specifies the name of a Kerberos realm of an existing IdM deployment.

--setup-dns

Tells the installation script to set up a DNS service within the IdM domain.

--setup-ca

Install and configure a CA on this replica. If a CA is not configured, certificate operations are forwarded to another replica with a CA installed. For ipa-server-install, a CA is installed by default and you do not need to use this option.

Table 2.5. CA options: available for ipa-ca-install and ipa-server-install
ArgumentDescription

--ca-subject=<SUBJECT>

Specifies the CA certificate subject Distinguished Name (default: CN=Certificate Authority,O=REALM.NAME). Relative Distinguished Names (RDN) are in LDAP order, with the most specific RDN first.

--subject-base=<SUBJECT>

Specifies the subject base for certificates issued by IdM (default O=REALM.NAME). Relative Distinguished Names (RDN) are in LDAP order, with the most specific RDN first.

--external-ca

Generates a certificate signing request to be signed by an external CA.

--ca-signing-algorithm=<ALGORITHM>

Specifies the signing algorithm of the IdM CA certificate. Possible values are SHA1withRSA, SHA256withRSA, SHA512withRSA . The default is SHA256withRSA. Use this option with --external-ca if the external CA does not support the default signing algorithm.

Table 2.6. DNS options: available for ipa-dns-install, or for ipa-server-install and ipa-replica-install when using --setup-dns
ArgumentDescription

--forwarder=192.0.2.1

Specifies a DNS forwarder to use with the DNS service. To specify more than one forwarder, use this option multiple times.

--no-forwarders

Uses root servers with the DNS service instead of forwarders.

--no-reverse

Does not create a reverse DNS zone when the DNS domain is set up. If a reverse DNS zone is already configured, then that existing reverse DNS zone is used.

If this option is not used, then the default value is true. This instructs the installation script to configure reverse DNS.

Additional resources

  • ipa-server-install(1) and ipa-replica-install(1) man pages on your system
  • ipa-dns-install(1) and ipa-ca-install(1) man pages on your system
Red Hat logoGithubRedditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

© 2024 Red Hat, Inc.