Chapter 1. Overview of planning for IdM and access control in RHEL

The following sections provide an overview of the options for identity management (IdM) and access control in Red Hat Enterprise Linux. After reading these sections, you will be able to approach the planning stage for your environment.

1.1. Introduction to IdM

This module explains the purpose of Identity Management (IdM) in Red Hat Enterprise Linux. It also provides basic information about the IdM domain, including the client and server machines that are part of the domain.

The goal of IdM in Red Hat Enterprise Linux

IdM in Red Hat Enterprise Linux provides a centralized and unified way to manage identity stores, authentication, policies, and authorization policies in a Linux-based domain. IdM significantly reduces the administrative overhead of managing different services individually and using different tools on different machines.

IdM is one of the few centralized identity, policy, and authorization software solutions that support:

  • Advanced features of Linux operating system environments
  • Unifying large groups of Linux machines
  • Native integration with Active Directory

IdM creates a Linux-based and Linux-controlled domain:

  • IdM builds on existing, native Linux tools and protocols. It has its own processes and configuration, but its underlying technologies are well-established on Linux systems and trusted by Linux administrators.
  • IdM servers and clients are Red Hat Enterprise Linux machines. IdM clients can also be other Linux and UNIX distributions if they support standard protocols. Windows client cannot be a member of the IdM domain but user logged into Windows systems managed by Active Directory (AD) can connect to Linux clients or access services managed by IdM. This is accomplished by establishing cross forest trust between AD and IdM domains.

Managing identities and policies on multiple Linux servers

Without IdM: Each server is administered separately. All passwords are saved on the local machines. The IT administrator manages users on every machine, sets authentication and authorization policies separately, and maintains local passwords. However, more often the users rely on other centralized solution, for example direct integration with AD. Systems can be directly integrated with AD using several different solutions:

  • Legacy Linux tools (not recommended to use)
  • Solution based on Samba winbind (recommended for specific use cases)
  • Solution based on a third-party software (usually require a license from another vendor)
  • Solution based on SSSD (native Linux and recommended for the majority of use cases)

With IdM: The IT administrator can:

  • Maintain the identities in one central place: the IdM server
  • Apply policies uniformly to multiples of machines at the same time
  • Set different access levels for users by using host-based access control, delegation, and other rules
  • Centrally manage privilege escalation rules
  • Define how home directories are mounted

Enterprise SSO

In case of IdM Enterprise, single sign-on (SSO) is implemented leveraging the Kerberos protocol. This protocol is popular in the infrastructure level and enables SSO with services such as SSH, LDAP, NFS, CUPS, or DNS. Web services using different web stacks (Apache, EAP, Django, and others) can also be enabled to use Kerberos for SSO. However, practice shows that using OpenID Connect or SAML based on SSO is more convenient for web applications. To bridge the two layers, it is recommended to deploy an Identity Provider (IdP) solution that would be able to convert Kerberos authentication into a OpenID Connect ticket or SAML assertion. Red Hat SSO technology based on the Keycloak open source project is an example of such an IdP

Without IdM: Users log in to the system and are prompted for a password every single time they access a service or application. These passwords might be different, and the users have to remember which credential to use for which application.

With Idm: After users log in to the system, they can access multiple services and applications without being repeatedly asked for their credentials. This helps to:

  • Improve usability
  • Reduce the security risk of passwords being written down or stored insecurely
  • Boost user productivity

Managing a mixed Linux and Windows environment

Without IdM: Windows systems are managed in an AD forest, but development, production, and other teams have many Linux systems. The Linux systems are excluded from the AD environment.

With IdM: The IT administrator can:

  • Manage the Linux systems using native Linux tools
  • Integrate the Linux systems into the environments centrally managed by Active Directory, thus preserving a centralized user store.
  • Easily deploy new Linux systems at scale or as needed.
  • Quickly react to business needs and make decisions related to management of the Linux infrastructure without dependency on other teams avoiding delays.

Contrasting IdM with a Standard LDAP Directory

A standard LDAP directory, such as Red Hat Directory Server, is a general-purpose directory: it can be customized to fit a broad range of use cases.

  • Schema: a flexible schema that can be customized for a vast array of entries, such as users, machines, network entities, physical equipment, or buildings.
  • Typically used as: a back-end directory to store data for other applications, such as business applications that provide services on the Internet.

IdM has a specific purpose: managing internal, inside-the-enterprise identities as well as authentication and authorization policies that relate to these identities.

  • Schema: a specific schema that defines a particular set of entries relevant to its purpose, such as entries for user or machine identities.
  • Typically used as: the identity and authentication server to manage identities within the boundaries of an enterprise or a project.

The underlying directory server technology is the same for both Red Hat Directory Server and IdM. However, IdM is optimized to manage identities inside the enterprise. This limits its general extensibility, but also brings certain benefits: simpler configuration, better automation of resource management, and increased efficiency in managing enterprise identities.

Additional Resources

1.2. Introduction to IdM servers and clients

The Identity Management (IdM) domain includes the following types of systems:

IdM servers

IdM servers are Red Hat Enterprise Linux systems that respond to identity, authentication, and authorization requests within an IdM domain. In most deployments, an integrated certificate authority (CA) is also installed with the IdM server.

IdM servers are the central repositories for identity and policy information. IdM servers can also host any of the optional services used by domain members:

  • Certificate authority (CA)
  • Key Recovery Authority (KRA)
  • DNS
  • Active Directory (AD) trust controller
  • Active Directory (AD) trust agent

The first server installed to create the domain is the IdM master or master server. The IdM master is not to be confused with the master CA server: they can run on two different machines.

IdM clients

IdM clients are Red Hat Enterprise Linux systems enrolled with the servers and configured to use the IdM services on these servers.

Clients interact with the IdM servers to access services provided by them. For example, clients use the Kerberos protocol to perform authentication and acquire tickets for enterprise single sign-on (SSO), use LDAP to get identity and policy infromation, use DNS to detect where the servers and services are located and how to connect to them.

IdM servers are also embedded IdM clients. As clients enrolled with themselves, the servers provide the same functionality as other clients.

To provide services for large numbers of clients, as well as for redundancy and availability, IdM allows deployment on multiple IdM servers in a single domain. It is possible to deploy up to 60 servers. This is the maximum number of IdM servers, also called replicas, that is currently supported in the IdM domain. IdM servers provide different services for the client. Not all the servers need to provide all the possible services. Some server components like Kerberos and LDAP are always available on every server. Other services like CA, DNS, Trust Controller or Vault are optional. This means that different servers in general play different roles in the deployment.

If your IdM topology contains an integrated CA, one server also has the role of the Certificate revocation list (CRL) generation master and the CA renewal master. This server is the master CA.

Warning

The master CA server is critical for your IdM deployment because it is the only system in the domain responsible for tracking CA subsystem certificates and keys, and for generating the CRL. For details about how to recover from a disaster affecting your IdM deployment, see Performing disaster recovery with Identity Management.

For redundancy and load balancing, administrators create additional servers by creating a replica of any existing server, either the master server or another replica. When creating a replica, IdM clones the configuration of the existing server. A replica shares with the initial server its core configuration, including internal information about users, systems, certificates, and configured policies.

Note

A replica and the server it was created from are functionally identical except for the role of the CRL generation master. Therefore, the term server and replica are used interchangeably here depending on the context.

1.3. IdM and access control in RHEL: Central vs. local

In Red Hat Enterprise Linux, you can manage identities and access control policies using centralized tools for a whole domain of systems, or using local tools for a single system.

Managing identities and policies on multiple Red Hat Enterprise Linux servers: With and without IdM

With Identity Management IdM, the IT administrator can:

  • Maintain the identities and grouping mechanisms in one central place: the IdM server
  • Centrally manage different types of credentials such as passwords, PKI certificates, OTP tokens, or SSH keys
  • Apply policies uniformly to multiples of machines at the same time
  • Manage POSIX and other attributes for external Active Directory users
  • Set different access levels for users by using host-based access control, delegation, and other rules
  • Centrally manage privilege escalation rules (sudo) and mandatory access control (SELinux user mapping)
  • Maintain central PKI infrastructure and secrets store
  • Define how home directories are mounted

Without IdM:

  • Each server is administered separately.
  • All passwords are saved on the local machines.
  • The IT administrator manages users on every machine, sets authentication and authorization policies separately, and maintains local passwords.

1.4. IdM terminology

IdM master and replicas

The first server installed using the ipa-server-install command to create the domain is known as the master server or IdM master. A replica is any server that is installed by the system administrator running the ipa-replica-install command. A replication agreement exists by default between a replica and the IdM server from which it was created, enabling it to both receive and send updates to the rest of IdM.

There is no functional difference between a master and a replica. Both are fully functional IdM servers.

Alternative names: master, master server, IdM master server

Master CA server

If your IdM topology contains an integrated certificate authority (CA), one server has the role of the Certificate revocation list (CRL) generation master and the CA renewal master. This server is the master CA server. In a deployment without integrated CA, there is no master CA server.

Alternative names: master CA

Important

IdM master and master CA server are two different terms. For example, the first server is the IdM master and the replica is the master CA server in the following deployment scenario:

  1. You install the first IdM server in your environment without integrated CA.
  2. You install a replica.
  3. You install a CA on the replica.

In this scenario, the first server is the IdM master and the replica is the master CA server.

IdM CA server

An IdM server on which the ipa certificate authority service is installed and running.

Alternative names: CA server

Certificate authorities (CA) in IdM

An entity that issues digital certificates. In Red Hat Identity Management, the primary CA is the ipa CA. The ipa CA certificate is one of the following types:

  • Self-signed. In this case ipa is a root CA.
  • Externally signed. In this case ipa is subordinated to the external CA.

In IdM, you can create multiple sub-CAs. Sub-CAs are IdM CAs whose certificates are one of the following types:

  • Signed by the ipa CA.
  • Signed by any of the intermediate CAs between itself and ipa. The certificate of a sub-CA cannot be self-signed.
IdM topology
A term that refers to the structure of your IdM solution, more specifically how replication agreements are set up between and within individual data centers and clusters.
IdM deployment

A term that refers to the type of your IdM solution. Describe your IdM deployment by answering the following questions:

  • Is your IdM deployment a testing deployment or production deployment?

    • How many IdM servers do you have?
  • Does your IdM deployment contain an integrated CA?

    • If it does, is the integrated CA self-signed or externally-signed?
    • If it does, on which servers is the CA role available? On which servers is the KRA role available?
  • Does your IdM deployment contain an integrated DNS?

    • If it does, on which servers is the DNS role available?
  • Is your IdM deployment in a trust agreement with an AD forest?

1.5. Additional resources