Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.
Chapter 1. Introduction to system authentication
One of the cornerstones of establishing a secure network environment is ensuring that access is restricted to authorized users. When access is allowed, users can authenticate to the system, verifying their identities.
On any Red Hat Enterprise Linux system, various services are available to create and manage user identities. These can include local system files, services that connect to larger identity domains like Kerberos or Samba, or tools to create those domains.
1.1. Confirming user identities
Authentication is the process of confirming an identity. For network interactions, authentication involves the identification of one party by another party. There are many ways to use authentication over networks, such as simple passwords, certificates, passwordless methods, one-time password (OTP) tokens, or biometric scans.
Authorization defines what the authenticated party is allowed to do or access.
Authentication requires that a user presents some kind of credential to verify his identity. The kind of credential that is required is defined by the authentication mechanism being used. There are several kinds of authentication for local users on a system:
- Password-based authentication
- Almost all software permits the user to authenticate by providing a recognized username and password. This is also called simple authentication.
- Certificate-based authentication
- Client authentication based on certificates is part of the Secure Sockets Layer (SSL) protocol. The client digitally signs a randomly generated piece of data and sends both the certificate and the signed data across the network. The server validates the signature and confirms the validity of the certificate.
- Kerberos authentication
- Kerberos establishes a system of short-lived credentials, called ticket-granting tickets (TGTs). The user presents credentials, that is, user name and password, that identify the user and indicate to the system that the user can be issued a ticket. TGT can then be repeatedly used to request access tickets to other services, like websites and email. Authentication using Kerberos allows the user to undergo only a single authentication process in this way.
- Smart card-based authentication
This is a variant of certificate-based authentication. The smart card (or token) stores user certificates; when a user inserts the token into a system, the system reads the certificates and grant access. Single sign-on using smart cards goes through three steps:
- A user inserts a smart card into the card reader. Pluggable authentication modules (PAMs) on Red Hat Enterprise Linux detect the inserted smart card.
- The system maps the certificate to the user entry and then compares the presented certificates on the smart card, which are encrypted with a private key as explained under the certificate-based authentication, to the certificates stored in the user entry.
- If the certificate is successfully validated against the key distribution center (KDC), then the user is allowed to log in.
Smart card-based authentication builds on the simple authentication layer established by Kerberos by adding certificates as additional identification mechanisms as well as by adding physical access requirements. For more information see Managing smart card authentication.
- One-time password authentication
- One-time passwords bring an additional step to your authentication security. The authentication uses your password in combination with an automatically generated one time password. For more information see One time password (OTP) authentication in Identity Management.
- External identity providers
- You can associate users with external identity providers (IdP) that support the OAuth 2 device authorization flow. When these users authenticate with the SSSD version available in RHEL 9.1 or later, they receive RHEL Identity Management (IdM) single sign-on capabilities with Kerberos tickets after performing authentication and authorization at the external IdP. For more information see Using external identity providers to authenticate to IdM.
1.2. Planning single sign-on
Without a central identity store and every application maintaining its own set of users and credentials, a user has to enter a password for every single service or application they open.
By configuring single sign-on, administrators create a single password store so that users can log in once, by using a single password, and be authenticated to all network resources.
Red Hat Enterprise Linux supports single sign-on for several resources, including logging into workstations, unlocking screen savers, and accessing secured web pages using Mozilla Firefox. With other available system services such as Privileged Access Management (PAM), Name Service Switch (NSS), and Kerberos, other system applications can be configured to use those identity sources.
Single sign-on is both a convenience to users and another layer of security for the server and the network. Single sign-on hinges on secure and effective authentication. Red Hat Enterprise Linux provides two authentication mechanisms which can be used to enable single sign-on:
- Kerberos-based authentication, through both Kerberos realms and Active Directory domains
- Smart card-based authentication
Both of these methods create a centralized identity store (either through a Kerberos realm or a certificate authority in a public key infrastructure), and the local system services then use those identity domains rather than maintaining multiple local stores.
1.3. Services available for local user authentication
All Red Hat Enterprise Linux systems have some services already available to configure authentication for local users on local systems. These include:
- Authentication setup
-
The Authentication Configuration tool
authselectsets up different identity back ends and means of authentication (such as passwords, fingerprints, or smart cards) for the system.
-
The Authentication Configuration tool
- Identity back end setup
- The Security System Services Daemon (SSSD) sets up multiple identity providers (primarily LDAP-based directories such as Microsoft Active Directory or Red Hat Enterprise Linux IdM) which can then be used by both the local system and applications for users. Passwords and tickets are cached, allowing both offline authentication and single sign-on by reusing credentials.
-
The
realmdservice is a command-line utility that allows you to configure an authentication back end, which is SSSD for IdM. Therealmdservice detects available IdM domains based on the DNS records, configures SSSD, and then joins the system as an account to a domain. -
Name Service Switch (NSS) is a mechanism for low-level system calls that return information about users, groups, or hosts. NSS determines what source, that is, which modules, should be used to obtain the required information. For example, user information can be located in traditioal UNIX files, such as the
/etc/passwdfile, or in LDAP-based directories, while host addresses can be read from files, such as the/etc/hostsfile, or the DNS records; NSS locates where the information is stored.
- Authentication Mechanisms
- Pluggable Authentication Modules (PAM) provide a system to set up authentication policies. An application using PAM for authentication loads different modules that control different aspects of authentication; which PAM module an application uses is based on how the application is configured. The available PAM modules include Kerberos, Winbind, SSSD, or local UNIX file-based authentication.
Other services and applications are also available, but these are common ones.
