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

Red Hat Identity Management (IdM) provides a centralized and unified way to manage identity stores, authentication, policies, and authorization policies in a Linux-based domain.

The goal of IdM in Red Hat Enterprise Linux

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. A Windows client cannot be a member of the IdM domain but users 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, therefore 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.

1.2. Common IdM customer scenarios and their solutions

Below are examples of common identity management and access control use cases both in Linux and Windows environments, and their solutions.

Scenario 1


You are a Windows administrator in your company.

Apart from Windows systems, you also have several Linux systems to administer.

As you cannot delegate control of any part of your environment to a Linux administrator, you must handle all security controls in Active Directory (AD).


Integrate your Linux hosts to AD directly.

If you want sudo rules to be defined centrally in an LDAP server, you must implement a schema extension in the AD domain controller (DC). If you are not allowed to implement this extension, consider installing Identity Management (IdM) - see Scenario 3 below. As IdM already contains the schema extension, you can manage sudo rules directly in IdM.

Further advice if you are expecting to need more Linux skills in the future

Connect with the Linux community to see how others manage identities: users, hosts, and services.

Research best practices.

Make yourself more familiar with Linux:

  • Use the RHEL web console when at all possible.
  • Use easy commands on the command-line whenever possible.
  • Attend a Red Hat System Administration course.

Scenario 2


You are a Linux administrator in your company.

Your Linux users require different levels of access to the company resources.

You need tight, centralized access control of your Linux machines.

Install IdM and migrate your users to it.
Further advice if you are expecting your company to scale up in the future

After installing IdM, configure host-based access control and sudo rules. These are necessary to maintain security best practices of limited access and least privilege.

To meet your security targets, develop a cohesive identity and access management (IAM) strategy that uses protocols to secure both infrastructure and application layers.

Scenario 3


You are a Linux administrator in your company and you must integrate your Linux systems with the company Windows servers. You want to remain the sole maintainer of access control to your Linux systems.

Different users require different levels of access to the Linux systems but they all reside in AD.

As AD controls are not robust enough, you must configure access control to the Linux systems on the Linux side. Install IdM and establish an IdM-AD trust.
Further advice to enhance the security of your environment

After installing IdM, configure host-based access control and sudo rules. These are necessary to maintain security best practices of limited access and least privilege.

To meet your security targets, develop a cohesive identity and access management (IAM) strategy that uses protocols to secure both infrastructure and application layers.

Scenario 4

As a security administrator, you must manage identities and access across all of your environments, including all of your Red Hat products. You must manage all of your identities in one place, and maintain access controls across all of your platforms, clouds and products.
Integrate IdM, Red Hat Single Sign-On, Red Hat Satellite, Red Hat Ansible Tower and other Red Hat products.

Scenario 5

As a security and system administrator in a Department of Defense (DoD) or Intelligence Community (IC) environment, you are required to use smart card or RSA authentication. You are required to use PIV certificates or RSA tokens.
  1. Configure certificate mapping in IdM.
  2. Ensure that GSSAPI delegation is enabled if an IdM-AD trust is present.
  3. Configure the use of radius configuration in IdM for RSA tokens.
  4. Configure IdM servers and IdM clients for smart card authentication.

Additional resources

1.3. Introduction to IdM servers and clients

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

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 information, use DNS to detect where the servers and services are located and how to connect to them.

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

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 has the role of the Certificate revocation list (CRL) publisher server and one server has the role of the CA renewal server.

By default, the first CA server installed fulfills these two roles, but you can assign these roles to separate servers.


The CA renewal server is critical for your IdM deployment because it is the only system in the domain responsible for tracking CA subsystem certificates and keys. 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 an existing server. 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.


A replica and the server it was created from are functionally identical, except for the CA renewal and CRL publisher roles. Therefore, the term server and replica are used interchangeably here depending on the context.

1.4. Supported versions of RHEL for installing IdM clients

An Identity Management deployment in which IdM servers are running on the latest minor version of Red Hat Enterprise Linux 9 supports clients that are running on the latest minor versions of:

  • RHEL 7
  • RHEL 8
  • RHEL 9
While other client systems, for example Ubuntu, can work with IdM 9 servers, Red Hat does not provide support for these clients.

1.5. 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.6. IdM terminology

Active Directory forest
An Active Directory (AD) forest is a set of one or more domain trees which share a common global catalog, directory schema, logical structure, and directory configuration. The forest represents the security boundary within which users, computers, groups, and other objects are accessible. For more information, see the Microsoft document on Forests.
Active Directory global catalog
The global catalog is a feature of Active Directory (AD) that allows a domain controller to provide information about any object in the forest, regardless of whether the object is a member of the domain controller’s domain. Domain controllers with the global catalog feature enabled are referred to as global catalog servers. The global catalog provides a searchable catalog of all objects in every domain in a multi-domain Active Directory Domain Services (AD DS).
Active Directory security identifier
A security identifier (SID) is a unique ID number assigned to an object in Active Directory, such as a user, group, or host. It is the functional equivalent of UIDs and GIDs in Linux.
Ansible play
Ansible plays are the building blocks of Ansible playbooks. The goal of a play is to map a group of hosts to some well-defined roles, represented by Ansible tasks.
Ansible playbook
An Ansible playbook is a file that contains one or more Ansible plays. For more information, see the official Ansible documentation about playbooks.
Ansible task
Ansible tasks are units of action in Ansible. An Ansible play can contain multiple tasks. The goal of each task is to execute a module, with very specific arguments. An Ansible task is a set of instructions to achieve a state defined, in its broad terms, by a specific Ansible role or module, and fine-tuned by the variables of that role or module. For more information, see the official Ansible tasks documentation.
Apache web server
The Apache HTTP Server, colloquially called Apache, is a free and open source cross-platform web server application, released under the terms of Apache License 2.0. Apache played a key role in the initial growth of the World Wide Web, and is currently the leading HTTP server. Its process name is httpd, which is short for HTTP daemon. Red Hat Identity Management (IdM) uses the Apache Web Server to display the IdM Web UI, and to coordinate communication between components, such as the Directory Server and the Certificate Authority.
A certificate is an electronic document used to identify an individual, a server, a company, or other entity and to associate that identity with a public key. Such as a driver’s license or passport, a certificate provides generally recognized proof of a person’s identity. Public-key cryptography uses certificates to address the problem of impersonation.
Certificate Authorities (CAs) in IdM

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

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

In IdM, you can also 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 CA. The certificate of a sub-CA cannot be self-signed.

See also Planning your CA services.

Cross-forest trust

A trust establishes an access relationship between two Kerberos realms, allowing users and services in one domain to access resources in another domain.

With a cross-forest trust between an Active Directory (AD) forest root domain and an IdM domain, users from the AD forest domains can interact with Linux machines and services from the IdM domain. From the perspective of AD, Identity Management represents a separate AD forest with a single AD domain. For more information, see How the trust works.

Directory Server
A Directory Server centralizes user identity and application information. It provides an operating system-independent, network-based registry for storing application settings, user profiles, group data, policies, and access control information. Each resource on the network is considered an object by the Directory Server. Information about a particular resource is stored as a collection of attributes associated with that resource or object. Red Hat Directory Server conforms to LDAP standards.
DNS PTR records
DNS pointer (PTR) records resolve an IP address of a host to a domain or host name. PTR records are the opposite of DNS A and AAAA records, which resolve host names to IP addresses. DNS PTR records enable reverse DNS lookups. PTR records are stored on the DNS server.
DNS SRV records
A DNS service (SRV) record defines the hostname, port number, transport protocol, priority and weight of a service available in a domain. You can use SRV records to locate IdM servers and replicas.
Domain Controller (DC)
A domain controller (DC) is a host that responds to security authentication requests within a domain and controls access to resources in that domain. IdM servers work as DCs for the IdM domain. A DC authenticates users, stores user account information and enforces security policy for a domain. When a user logs into a domain, the DC authenticates and validates their credentials and either allows or denies access.
Fully qualified domain name

A fully qualified domain name (FQDN) is a domain name that specifies the exact location of a host within the hierarchy of the Domain Name System (DNS). A device with the hostname myhost in the parent domain has the FQDN The FQDN uniquely distinguishes the device from any other hosts called myhost in other domains.

If you are installing an IdM client on host machine1 using DNS autodiscovery and your DNS records are correctly configured, the FQDN of machine1 is all you need. For more information, see Host name and DNS requirements for IdM.


The Generic Security Service Application Program Interface (GSSAPI, or GSS-API) allows developers to abstract how their applications protect data that is sent to peer applications. Security-service vendors can provide GSSAPI implementations of common procedure calls as libraries with their security software. These libraries present a GSSAPI-compatible interface to application writers who can write their application to use only the vendor-independent GSSAPI. With this flexibility, developers do not have to tailor their security implementations to any particular platform, security mechanism, type of protection, or transport protocol.

Kerberos is the dominant GSSAPI mechanism implementation, which allows Red Hat Enterprise Linux and Microsoft Windows Active Directory Kerberos implementations to be API compatible.

Hidden replica

A hidden replica is an IdM replica that has all services running and available, but its server roles are disabled, and clients cannot discover the replica because it has no SRV records in DNS.

Hidden replicas are primarily designed for services such as backups, bulk importing and exporting, or actions that require shutting down IdM services. Since no clients use a hidden replica, administrators can temporarily shut down the services on this host without affecting any clients. For more information, see The hidden replica mode.

HTTP server
See Web server.
ID mapping

SSSD can use the SID of an AD user to algorithmically generate POSIX IDs in a process called ID mapping. ID mapping creates a map between SIDs in AD and IDs on Linux.

  • When SSSD detects a new AD domain, it assigns a range of available IDs to the new domain. Therefore, each AD domain has the same ID range on every SSSD client machine.
  • When an AD user logs in to an SSSD client machine for the first time, SSSD creates an entry for the user in the SSSD cache, including a UID based on the user’s SID and the ID range for that domain.
  • Because the IDs for an AD user are generated in a consistent way from the same SID, the user has the same UID and GID when logging in to any Red Hat Enterprise Linux system.
ID ranges

An ID range is a range of ID numbers assigned to the IdM topology or a specific replica. You can use ID ranges to specify the valid range of UIDs and GIDs for new users, hosts and groups. ID ranges are used to avoid ID number conflicts. There are two distinct types of ID ranges in IdM:

  • IdM ID range

    Use this ID range to define the UIDs and GIDs for users and groups in the whole IdM topology. Installing the first IdM server creates the IdM ID range. You cannot modify the IdM ID range after creating it. However, you can create an additional IdM ID range, for example when the original one nears depletion.

  • Distributed Numeric Assignment (DNA) ID range

    Use this ID range to define the UIDs and GIDs a replica uses when creating new users. Adding a new user or host entry to an IdM replica for the first time assigns a DNA ID range to that replica. An administrator can modify the DNA ID range, but the new definition must fit within an existing IdM ID range.

    Note that the IdM range and the DNA range match, but they are not interconnected. If you change one range, ensure you change the other to match.

For more information, see ID ranges.

ID views

ID views enable you to specify new values for POSIX user or group attributes, and to define on which client host or hosts the new values will apply. For example, you can use ID views to:

  • Define different attribute values for different environments.
  • Replace a previously generated attribute value with a different value.

In an IdM-AD trust setup, the Default Trust View is an ID view applied to AD users and groups. Using the Default Trust View, you can define custom POSIX attributes for AD users and groups, therefore overriding the values defined in AD.

For more information, see Using an ID view to override a user attribute value on an IdM client.

IdM CA server

An IdM server on which the IdM certificate authority (CA) service is installed and running.

Alternative names: CA server

IdM deployment

A term that refers to the entirety of your IdM installation. You can 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?

IdM server and replicas

To install the first server in an IdM deployment, you must use the ipa-server-install command.

Administrators can then use the ipa-replica-install command to install replicas in addition to the first server that was installed. By default, installing a replica creates a replication agreement with the IdM server from which it was created, enabling receiving and sending updates to the rest of IdM.

There is no functional difference between the first server that was installed and a replica. Both are fully functional read/write IdM servers.

Deprecated names: master server

IdM CA renewal server

If your IdM topology contains an integrated certificate authority (CA), one server has the unique role of the CA renewal server. This server maintains and renews IdM system certificates.

By default, the first CA server you install fulfills this role, but you can configure any CA server to be the CA renewal server. In a deployment without integrated CA, there is no CA renewal server.

Deprecated names: master CA

IdM CRL publisher server

If your IdM topology contains an integrated certificate authority (CA), one server has the unique role of the Certificate revocation list (CRL) publisher server. This server is responsible for maintaining the CRL.

By default, the server that fulfills the CA renewal server role also fulfills this role, but you can configure any CA server to be the CRL publisher server. In a deployment without integrated CA, there is no CRL publisher server.

IdM topology
A term that refers to the structure of your IdM solution, especially the replication agreements between and within individual data centers and clusters.
Kerberos authentication indicators

Authentication indicators are attached to Kerberos tickets and represent the initial authentication method used to acquire a ticket:

  • otp for two-factor authentication (password + One-Time Password)
  • radius for Remote Authentication Dial-In User Service (RADIUS) authentication (commonly for 802.1x authentication)
  • pkinit for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT), smart card, or certificate authentication
  • hardened for passwords hardened against brute-force attempts

For more information, see Kerberos authentication indicators.

Kerberos keytab

While a password is the default authentication method for a user, keytabs are the default authentication method for hosts and services. A Kerberos keytab is a file that contains a list of Kerberos principals and their associated encryption keys, so a service can retrieve its own Kerberos key and verify a user’s identity.

For example, every IdM client has an /etc/krb5.keytab file that stores information about the host principal, which represents the client machine in the Kerberos realm.

Kerberos principal

Unique Kerberos principals identify each user, service, and host in a Kerberos realm:

EntityNaming conventionExample










Kerberos protocol
Kerberos is a network authentication protocol that provides strong authentication for client and server applications by using secret-key cryptography. IdM and Active Directory use Kerberos for authenticating users, hosts and services.
Kerberos realm
A Kerberos realm encompasses all the principals managed by a Kerberos Key Distribution Center (KDC). In an IdM deployment, the Kerberos realm includes all IdM users, hosts, and services.
Kerberos ticket policies

The Kerberos Key Distribution Center (KDC) enforces ticket access control through connection policies, and manages the duration of Kerberos tickets through ticket lifecycle policies. For example, the default global ticket lifetime is one day, and the default global maximum renewal age is one week.

For more information, see IdM Kerberos ticket policy types.

Key Distribution Center (KDC)

The Kerberos Key Distribution Center (KDC) is a service that acts as the central, trusted authority that manages Kerberos credential information. The KDC issues Kerberos tickets and ensures the authenticity of data originating from entities within the IdM network.

For more information, see The role of the IdM KDC.

The Lightweight Directory Access Protocol (LDAP) is an open, vendor-neutral, application protocol for accessing and maintaining distributed directory information services over a network. Part of this specification is a directory information tree (DIT), which represents data in a hierarchical tree-like structure consisting of the Distinguished Names (DNs) of directory service entries. LDAP is a "lightweight" version of the Directory Access Protocol (DAP) described by the ISO X.500 standard for directory services in a network.
Lightweight sub-CA

In IdM, a lightweight sub-CA is a certificate authority (CA) whose certificate is signed by an IdM root CA or one of the CAs that are subordinate to it. A lightweight sub-CA issues certificates only for a specific purpose, for example to secure a VPN or HTTP connection.

For more information, see Restricting an application to trust only a subset of certificates.

Password policy

A password policy is a set of conditions that the passwords of a particular IdM user group must meet. The conditions can include the following parameters:

  • The length of the password
  • The number of character classes used
  • The maximum lifetime of a password.

For more information, see What is a password policy.

POSIX attributes

POSIX attributes are user attributes for maintaining compatibility between operating systems.

In a Red Hat Identity Management environment, POSIX attributes for users include:

  • cn, the user’s name
  • uid, the account name (login)
  • uidNumber, a user number (UID)
  • gidNumber, the primary group number (GID)
  • homeDirectory, the user’s home directory

In a Red Hat Identity Management environment, POSIX attributes for groups include:

  • cn, the group’s name
  • gidNumber, the group number (GID)

These attributes identify users and groups as separate entities.

Replication agreement

A replication agreement is an agreement between two IdM servers in the same IdM deployment. The replication agreement ensures that the data and configuration is continuously replicated between the two servers.

IdM uses two types of replication agreements: domain replication agreements, which replicate identity information, and certificate replication agreements, which replicate certificate information.

For more information, see:

Smart card
A smart card is a removable device or card used to control access to a resource. They can be plastic credit card-sized cards with an embedded integrated circuit (IC) chip, small USB devices such as a Yubikey, or other similar devices. Smart cards can provide authentication by allowing users to connect a smart card to a host computer, and software on that host computer interacts with key material stored on the smart card to authenticate the user.
The System Security Services Daemon (SSSD) is a system service that manages user authentication and user authorization on a RHEL host. SSSD optionally keeps a cache of user identities and credentials retrieved from remote providers for offline authentication. For more information, see Understanding SSSD and its benefits.
SSSD backend
An SSSD backend, often also called a data provider, is an SSSD child process that manages and creates the SSSD cache. This process communicates with an LDAP server, performs different lookup queries and stores the results in the cache. It also performs online authentication against LDAP or Kerberos and applies access and password policy to the user that is logging in.
Ticket-granting ticket (TGT)

After authenticating to a Kerberos Key Distribution Center (KDC), a user receives a ticket-granting ticket (TGT), which is a temporary set of credentials that can be used to request access tickets to other services, such as websites and email.

Using a TGT to request further access provides the user with a Single Sign-On experience, as the user only needs to authenticate once to access multiple services. TGTs are renewable, and Kerberos ticket policies determine ticket renewal limits and access control.

For more information, see Managing Kerberos ticket policies.

Web server
A web server is computer software and underlying hardware that accepts requests for web content, such as pages, images, or applications. A user agent, such as a web browser, requests a specific resource using HTTP, the network protocol used to distribute web content, or its secure variant HTTPS. The web server responds with the content of that resource or an error message. The web server can also accept and store resources sent from the user agent. Red Hat Identity Management (IdM) uses the Apache Web Server to display the IdM Web UI, and to coordinate communication between components, such as the Directory Server and the Certificate Authority (CA). See Apache web server.

Additional Glossaries

If you are unable to find an Identity Management term in this glossary, see the Directory Server and Certificate System glossaries:

1.7. Additional resources