Red Hat Summit Red Hat SummitSupportoConsoleSviluppatoriInizia una provaContatti

Questo contenuto non è disponibile nella lingua selezionata.

Chapter 1. Preparing the system for IdM server installation

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

1.1. Prerequisites
Copia collegamento

  • You need root privileges to install an IdM server on your host.

1.2. Hardware recommendations
Copia collegamento

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, increasing RAM is more effective than increasing 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. In virtualized environments, memory ballooning must be disabled or the complete RAM must be reserved for the guest IdM servers.

Note

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

1.3. Custom configuration requirements for IdM
Copia collegamento

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.

1.3.1. IPv6 requirements in IdM
Copia collegamento

The IdM system must have the IPv6 protocol enabled in the kernel. 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.

1.3.2. Support for encryption types in IdM
Copia collegamento

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 disabled by default in RHEL 9, 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. Single-DES (DES) and triple-DES (3DES) encryption types were removed from RHEL 8 and are not used in RHEL 9.

1.3.3. Support for system-wide cryptographic policies in IdM
Copia collegamento

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.

1.3.4. FIPS compliance
Copia collegamento

You can install a new IdM server or replica on a system with the Federal Information Processing Standard (FIPS) mode enabled. The only exception is a system on which the FIPS:OSPP cryptographic subpolicy is enabled.

To install IdM with FIPS, 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 FIPS 140-3:

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

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 authenticate with an AD administrative account. You cannot establish a trust using a shared secret while FIPS mode is enabled.

Important

RADIUS authentication is not FIPS compliant. Do not install IdM on a server with FIPS mode enabled if you require RADIUS authentication.

1.4. Time service requirements for IdM
Copia collegamento

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

1.4.1. How IdM uses chronyd for synchronization
Copia collegamento

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.

1.4.2. List of NTP configuration options for IdM installation commands
Copia collegamento

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.

Expand
Table 1.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.

1.4.3. Ensuring IdM can reference your NTP time server
Copia collegamento

You can verify if 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.
    Copy to Clipboard Toggle word wrap
  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.
    Copy to Clipboard Toggle word wrap

1.5. Meeting DNS host name and DNS requirements for IdM
Copia collegamento

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.

Warning

DNS records are vital for nearly all Identity Management (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 all IdM servers, both 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
Copy to Clipboard Toggle word wrap

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
...
      Copy to Clipboard Toggle word wrap

  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
      Copy to Clipboard Toggle word wrap

    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
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap

    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
      Copy to Clipboard Toggle word wrap
      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). To do this, inspect the output of the following command for each forwarder separately: 

$ dig @IP_address_of_the_DNS_forwarder . SOA
Copy to Clipboard Toggle word wrap

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

  • Status: NOERROR
  • Flags: ra

If either of these items is missing from the output, inspect the documentation for your DNS forwarder and verify that EDNS0 is supported and enabled.

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
Copy to Clipboard Toggle word wrap

1.6. Port requirements for IdM
Copia collegamento

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.

Expand
Table 1.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 and 8443 are used internally by pki-tomcat and leave them blocked in the firewall to prevent their use by other services. Port 749 is used for remote management of the Kerberos server and only open it if you intend to use remote management.

Expand
Table 1.3. firewalld services
Service nameFor details, see:

freeipa-4

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

dns

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

1.7. Opening the ports required by IdM
Copia collegamento

You can open the required ports that IdM uses to communicate with its services.

Procedure

  1. Verify that the firewalld service is running.

    • To find out if firewalld is currently running: 

      # systemctl status firewalld.service
      Copy to Clipboard Toggle word wrap

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

      # systemctl start firewalld.service
# systemctl enable firewalld.service
      Copy to Clipboard Toggle word wrap

  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}
      Copy to Clipboard Toggle word wrap

    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}
      Copy to Clipboard Toggle word wrap

      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
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap

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
      Copy to Clipboard Toggle word wrap

    • 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
      Copy to Clipboard Toggle word wrap
Note

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

1.8. Installing packages required for an IdM server
Copia collegamento

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-10-for-x86_64-baseos-rpms
# subscription-manager repos --enable=rhel-10-for-x86_64-appstream-rpms
      Copy to Clipboard Toggle word wrap

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

Procedure

  • 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: 

      # dnf install ipa-server
      Copy to Clipboard Toggle word wrap

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

      # dnf install ipa-server ipa-server-dns
      Copy to Clipboard Toggle word wrap

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

      # dnf install ipa-server ipa-server-trust-ad samba-client
      Copy to Clipboard Toggle word wrap

1.9. Setting the correct file mode creation mask for IdM installation
Copia collegamento

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
    Copy to Clipboard Toggle word wrap

  2. Set the umask to 0022: 

    # umask 0022
    Copy to Clipboard Toggle word wrap

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

    # umask 0027
    Copy to Clipboard Toggle word wrap

1.10. Ensuring that fapolicyd rules do not block IdM installation
Copia collegamento

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 Red Hat Knowledgebase solution fapolicy restrictions causing IdM installation failures.

1.11. Options for the IdM installation commands
Copia collegamento

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.

Expand
Table 1.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.

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

--random-serial-numbers

Enables Random Serial Numbers version 3 (RSNv3) for the IdM CA. When enabled, the CA generates fully random serial numbers for certificates and requests in the PKI. This option is enabled by default for all new IdM installations on RHEL 10 or if another CA in the topology is configured with RSNv3. Since RHEL 10 does not support sequential serial numbers, it is not possible to disable this.

IMPORTANT: RSNv3 is supported only for new IdM CA installations. If enabled, it is required to use RSNv3 on all PKI services.

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

--pki-config-override=<PKI_CONFIG_OVERRIDE>

Specifies a file that contains overrides for the CA installation. Also available with the ipa-replica-install command.

Expand
Table 1.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.

Torna in cima
Red Hat logoGithubredditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi. Esplora i nostri ultimi aggiornamenti.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita il Blog di Red Hat.

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

Theme

© 2025 Red Hat