Chapter 2 Configuring System Authentication

This chapter describes how to configure various authentication methods that Oracle Linux can use, including NIS, LDAP, Kerberos, and Winbind, and how you can configure the System Security Services Daemon feature to provide centralized identity and authentication management.

2.1 About Authentication in Oracle Linux 8

Authentication is the verification of the identity of an entity, such as a user, to a system. A user logs in by providing a user name and a password, and the operating system authenticates the user's identity by comparing this information to data stored on the system. If the login credentials match and the user account is active, the user is authenticated and can successfully access the system.

The information that verifies a user's identity is located on the local system in the /etc/passwd and /etc/shadow files, or on remote systems by using Identity Policy Audit (IPA), the Lightweight Directory Access Protocol (LDAP), or Winbind. In addition, IPAv2, and LDAP data files can use the Kerberos authentication protocol, which allows nodes communicating over a non-secure network to prove their identity to one another in a secure manner.

2.1.1 About the authselect Utility

In previous releases, the authconfig command was used to control the authentication of user logins on local and remote systems. Over time, however, authentication methods have grown in number, and a variety of authentication configurations using each of these methods have also multiplied. Consequently, the authconfig command has become too complex to function as a central management tool as well as for troubleshooting problems with authentication setup.

The introduction of the authselect utility reflects a different approach to authentication, which is profile-based. It is automatically included in an Oracle Linux 8 installation.

The authselect utility consists of the following components:

  • authselect command to manage system authentication. This command can only be run by root.

  • Three ready-made profiles that implement specific types of authentication. The following profiles are automatically installed in the usr/share/authselect/default directory:

    • sssd profile. This profile uses the sssd service to perform system authentication. This profile is automatically selected by default after an Oracle Linux 8 installation.

    • winbind profile. This profile uses the winbind service to perform system authentication.

    • The nis profile is also included in the directory but only for purposes of maintaining compatibility with legacy configurations. NIS is deprecated in Oracle Linux 8. Thus, converting to using the sssd profile instead is highly recommended.

The authselect utility also enables you to create customized profiles if the ready-made profiles are not sufficient for your environment. Because of this flexibility offered by the utility, authentication profiles are stored depending on the type of profile:

  • /usr/share/authselect/default contains the ready-made profiles provided by Oracle Linux 8.

  • /usr/share/authselect/vendor contains the profiles that are provided by vendors. These profiles can override those that are in the default directory.

  • /etc/authselect/custom contains any profiles you create for your specific environment.

Important

The authselect utility applies the specifications in your selected profile. However, the utility does not modify the configuration files of the service on which the profile is based. If, for example, you use the sssd profile, you must configure SSSD for the service to function properly. Consult the proper documentation to configure the profile's service. You must also ensure that the service is started and enabled.

For more details about the utlity, refer to the authselect(8) manual page.

2.1.2 About Profiles and Supported Features

Each profile has associated features you can enable to make the profile's service perform a particular method of authentication, such as smart card authentication, fingerprint authentication, kerberos, and so on. After you select a profile and enable preferred features, authselect automatically reads the appropriate configuration files of those features to run the relevant authentication processes. Every user who logs in to the host is authenticated based on that configured profile.

The following table shows features for the sssd profile:

Table 2.1 Features Supported by sssd Profile
Feature Name Description
with-faillock Lock the account after too many authentication failures.
with-mkhomedir Create home directory on user's first log in.
with-ecryptfs Enable automatic per-user ecryptfs.
with-smartcard Authenticate smart cards through SSSD.
with-smartcard-lock-on-removal Lock the screen when the smart card is removed. Requires that with-smartcard is also enabled.
with-smartcard-required Only smart card authentication is operative; others, including password, are disabled. Requires that with-smartcard is also enabled.
with-fingerprint Authenticate through fingerprint reader.
with-silent-lastlog Disable generation of pam_lostlog messages during login
with-sudo Enable sudo to use SSSD for rules besides /etc/sudoers.
with-pamaccess Refer to /etc/access.conf for account authorization.
without-nullock Do not add the nullock parameter to pam_unix

The following table shows features for the winbind profile:

Table 2.2 Features Supported by winbind Profile
Feature Name Description
with-faillock Lock the account after too many authentication failures.
with-mkhomedir Create home directory on user's first log in.
with-ecryptfs Enable automatic per-user ecryptfs.
with-fingerprint Authenticate through fingerprint reader.
with-krb5 Use Kerberos authentication.
with-silent-lastlog Disable generation of pam_lostlog messages during login
with-pamaccess Refer to /etc/access.conf for account authorization.
without-nullock Do not add the nullock parameter to pam_unix

For details about each profile, refer to the profile's corresponding /usr/share/authselect/default/profile/README file. See also the authselect-profiles(5) manual page.

2.1.3 About the Default Authentication Profile

On an Oracle Linux 8 system, the sssd profile is selected by default to manage authentication on the system. This profile covers most authentication cases including PAM authentication, Kerberos, and so on. The sssd is recommended as the profile of choice.

As a default profile, some sssd features are automatically enabled. You can verify the information with the following command:

sudo authselect current
Profile ID: sssd
Enabled features:
- with-fingerprint
- with-silent-lastlog

The output of the command indicates that the SSSD service manages the system's authentication. At a minimum, authentication with the fingerprint reader is enforced through pam_fprintd. Additionally, no pam_lastlog message is displayed on the screen when users log in.

2.1.4 Enabling and Disabling Profile Features

Enabled features of a profile determine the manner of authentication on the system. You can enable profile features in one of two ways:

To enable more features of a profile, do the following:

  1. (Optional): Identify the current profile.

    Enabling additional features works only on the current profile. The procedure does not work on unselected profiles.

    sudo authselect current
  2. If necessary, identify the feature requirements for the feature to work properly.

    sudo authselect requirements profile feature
  3. Complete the indicated listed feature requirements as needed.

  4. Enable the feature.

    sudo authselect enable-feature feature

    Note that you can only enable features one at a time.

Disable a feature as follows:

sudo authselect disable-feature feature
Example 2.1 Enabling Profile Features

The following example shows how you would add additional functionalities to the default sssd profile.

  1. Automatically lock an account after too many authentication failures (with-faillock):

    sudo authselect requirements sssd with-faillock
    Make sure that SSSD service is configured and enabled. See SSSD documentation for more 
    information.
  2. Automatically create a user home directory at the user's first time log in (with-mkhomedir).

    sudo authselect requirements sssd with-mkhomedir
    Make sure that SSSD service is configured and enabled. See SSSD documentation for more 
    information.
     
    - with-mkhomedir is selected, make sure pam_oddjob_mkhomedir module
      is present and oddjobd service is enabled
      - systemctl enable oddjobd.service
      - systemctl start oddjobd.service
  3. Enable both profile features:

    sudo authselect enable-feature with-faillock
    sudo authselect enable-feature with-mkhomedir
  4. Confirm that both profile features have been enabled:

    sudo authselect current
    Profile ID: sssd
    Enabled features:
    - with-fingerprint
    - with-silent-lastlog
    - with-faillock
    - with-mkhomedir

The following example shows you would cause the system to check /etc/security/access.conf to authenticate and authorize users. In this case, the PAM access feature needs to be added as an enabled feature for sssd.

  1. Automatically enable PAM access:

    sudo authselect requirements sssd with-pamaccess
    Make sure that SSSD service is configured and enabled. See SSSD documentation for more 
    information.
  2. Enable the PAM access profile feature:

    sudo authselect enable-feature sssd with-pamaccess
  3. Confirm that the PAM access profile feature has been enabled:

    sudo authselect current
    Profile ID: sssd
    Enabled features:
    - with-fingerprint
    - with-silent-lastlog
    - with-faillock
    - with-mkhomedir
    - with-pamaccess
Note

The prevous example assumes that you have configured /etc/security/access.conf so that the feature functions correctly. For more information, see the access.conf(5) manual page.

2.1.5 Selecting the Winbind Profile

Winbind is a client-side service that resolves user and group information on a Windows server, and allows Oracle Linux to understand Windows users and groups.

If you do not want to use the current default profile (sssd) and use the winbind profile instead, do the following:

  1. Install the samba-winbind package.

    sudo dnf install samba-winbind
  2. Select the winbind profile.

    When selecting a profile, you can enable multiple features in the same command, for example:

    sudo authselect select winbind with-faillock with-mkhomedir [options]
    Profile "winbind" was selected.
    The following nsswitch maps are overwritten by the profile:
    - passwd
    - group
    
    Make sure that winbind service is configured and enabled. See winbind documentation for 
    more information.
     
    - with-mkhomedir is selected, make sure pam_oddjob_mkhomedir module
      is present and oddjobd service is enabled
      - systemctl enable oddjobd.service
      - systemctl start oddjobd.service

    For other options you can use with the authselect select command, see the authselect(8) manual page.

    Note that the output includes other information and instructions about additional actions that are required for the authentication to be properly implemented. The information is important especially for the different features you want to enable for the profile. Ensure that these requirements are also fulfilled.

  3. Start the winbind service.

    sudo systemctl start winbind
    sudo systemctl enable winbind
Note

If you use the authselect select to select a profile that is already current and active while enabling features at the same time, those features will replace whatever features were previously enabled.

2.1.6 Modifying Ready-Made Profiles

To modify and customize a ready-made profile, revisions must be applied to the system's /etc/nsswitch.conf file. However, you must not edit the /etc/nsswitch.conf directly. Instead, follow these steps:

  1. If necessary, select the profile to make it current, for example:

    sudo authselect select sssd
  2. Edit the /etc/authselect/user-nsswitch.conf file as required.

    Do not modify the any of following configuration in the file. If you do, those modifications will be ignored:

    • passwd

    • group

    • netgroup

    • automount

    • services

  3. Apply the changes.

    sudo authselect apply-changes

    The changes in /etc/authselect/user-nsswitch.conf are applied to /etc/nsswitch.conf and will be used by the current profile.

Note

If the system is part of an environment that uses either Identity Management or Active Directory, do not use authselect to manage authentication. When the host is made to join either Identity Management or Active Directory, their respective tools take care of managing authentication of the environment.

2.1.7 Creating Custom Profiles

If you do not want to use the ready-made profiles from Oracle Linux 8 or vendor-provided profiles, you can create your own specific profile. Follow these steps:

  1. Create the profile.

    sudo authselect create-profile newprofile -b template \
    --symlink-meta --symlink-pam
    newprofile

    Name of your custom profile.

    template

    Base to be used for the custom profile, which is either sssd or winbind.

    --symlink-meta

    Creates symbolic links to the meta files in the original directory of the template profile you are using as base.

    --symlink-pam

    Creates symbolic links to the PAM templates in the original directory of the template profile you are using as base.

    This command creates an /etc/authselect/custom/newprofile directory that contains the symbolic links to the files in the base's original directory. The only file that is not a symbolic link in this directory is nsswitch.conf.

  2. Edit the /etc/authselect/custom/newprofile/nsswitch.conf file according to your preference.

  3. Select your custom profile.

    sudo authselect select custom/newprofile

    This command also creates a backup of the original /etc/nsswitch.conf file and replaces it with a symbolic link to the corresponding file in your custom profile's directory.

    You can test this result by comparing the symbolic link /etc/nsswitch.conf with the original /etc/nsswitch.conf.bak and verify that the original file's contents remain intact.

  4. Enable features for your new profile as needed.

    See Section 2.1.4, “Enabling and Disabling Profile Features” for reference.

  5. (Optional) Verify the configuration of the custom profile.

    sudo authselect current

2.1.8 Migrating From authconfig to authselect

In Oracle Linux 8, authselect support for backward compatibility with authconfig is minimal. Thus, migrating to authselect is highly recommended. Migrating requires you to take several actions, including the following:

  • Convert scripts.

    If you use the ipa-client-install command or the realm join command to make the host join a domain, you can just remove any authconfig call in your scripts. Otherwise, you will need to replace each authconfig call with its equivalent authselect call.

  • Update configuration files.

    Files for the various services need to be reconfigured, including those that apply to the following: Kerberos, LDAP, NIS, SSSD, and Winbind.

  • Enforce password quality restrictions for authselect.

    The pam_pwquality module enforces password quality restrictions for local users. You configure this module in the /etc/security/pwquality.conf file, according to the information that is provided in the pam_pwquality(8) man page.

  • Switch from the authconfig's cacertdir_rehash tool to the native openssl rehash directory command.

  • Start the appropriate services.

    Depending on the profile you select for the authselect implementation, start the service for that profile. If you select the sssd profile, for example, then you would enable and start the SSSD service.

    sudo systemctl start sssd; systemctl enable sssd

For complete migration instructions and examples, see the authselect-migration(7) manual page. See also the authselect(8) manual page.

2.2 More About the System Security Services Daemon

The System Security Services Daemon (SSSD) feature provides access on a client system to remote identity and authentication providers. The SSSD acts as an intermediary between local clients and any back-end provider that you configure.

The benefits of configuring SSSD include the following:

  • Reduced system load

    Clients do not have to contact the identification or authentication servers directly.

  • Offline authentication

    You can configure SSSD to maintain a cache of user identities and credentials.

  • Single sign-on access

    If you configure SSSD to store network credentials, users need only authenticate once per session with the local system to access network resources.

Because the Oracle Linux 8 authselect sssd profile is used by default, the SSSD service is automatically installed and enabled on a newly installed system. The default configuration makes use of the Pluggable Authentication Modules (PAM) and the Name Service Switch (NSS) for managing access and authentication on a system. No further configuration is required, unless you wish to use different authentication services or wish to customize the configuration to use alternative values to the default settings.

2.2.1 Customizing SSSD

By default the SSSD service used by the sssd profile uses Pluggable Authentication Modules (PAM) and the Name Service Switch (NSS) for managing access and authentication on a system. As you enable additional features for the profile to customize SSSD authentication, you must also configure SSSD for the enabled feature.

Customized configuration is performed by creating configuration files within the /etc/sssd/conf.d directory. Each configuration file must have the .conf suffix to enable it when SSSD is started. Configuration files are formatted using ini-style syntax and consist of sections, indicated using square brackets, and parameters, listed as key = value entries. The man pages provided for SSSD are comprehensive and provide detailed information on the options that are available.

The following example demonstrates how one might configure SSSD to authenticate against an LDAP provider with Kerberos configured:

  1. Create a configuration file for the feature and store it in /etc/sssd/conf.d, for example /etc/sssd/conf.d/00-ldap.conf

  2. Configure /etc/sssd/conf.d/00-ldap.conf with parameter definitions, such as the following:

    [sssd]
    config_file_version = 2
    domains = LDAP
    services = nss, pam
    
    [domain/LDAP]
    id_provider = ldap
    ldap_uri = ldap://ldap.mydom.com
    ldap_search_base = dc=mydom,dc=com
    
    auth_provider = krb5
    krb5_server = krbsvr.mydom.com
    krb5_realm = MYDOM.COM
    cache_credentials = true
    
    min_id = 5000
    max_id = 25000
    enumerate = false
    
    [nss]
    filter_groups = root
    filter_users = root
    reconnection_retries = 3
    entry_cache_timeout = 300
    
    [pam]
    reconnection_retries = 3
    offline_credentials_expiration = 2
    offline_failed_login_attempts = 3
    offline_failed_login_delay = 5
    [sssd]

    Contains configuration settings for SSSD monitor options, domains, and services. The SSSD monitor service manages the services that SSSD provides.

    • services defines the supported services, which should include nss for the Name Service Switch and pam for Pluggable Authentication Modules.

    • The domains entry specifies the name of the sections that define authentication domains.

    [domain/LDAP]

    Defines a domain for an LDAP identity provider that uses Kerberos authentication. Each domain defines where user information is stored, the authentication method, and any configuration options. SSSD can work with LDAP identity providers such as OpenLDAP, Red Hat Directory Server, IPA, and Microsoft Active Directory, and it can use either native LDAP or Kerberos authentication.

    • id_provider specifies the type of provider (in this example, LDAP).

    • ldap_uri specifies a comma-separated list of the Universal Resource Identifiers (URIs) of the LDAP servers, in order of preference, to which SSSD can connect.

    • ldap_search_base specifies the base distinguished name (dn) that SSSD should use when performing LDAP user operations on a relative distinguished name (RDN) such as a common name (cn).

    • auth_provider entry specifies the authentication provider (in this example, Kerberos).

    • krb5_server specifies a comma-separated list of Kerberos servers, in order of preference, to which SSSD can connect.

    • krb5_realm specifies the Kerberos realm.

    • cache_credentials specifies if SSSD caches user credentials such as tickets, session keys, and other identifying information to support offline authentication and single sign-on.

      Note

      To allow SSSD to use Kerberos authentication with an LDAP server, you must configure the LDAP server to use both Simple Authentication and Security Layer (SASL) and the Generic Security Services API (GSSAPI). For more information about configuring SASL and GSSAPI for OpenLDAP, see https://www.openldap.org/doc/admin24/sasl.html.

    • min_id and max_id specify upper and lower limits on the values of user and group IDs.

    • enumerate specifies whether SSSD caches the complete list of users and groups that are available on the provider. The recommended setting is False unless a domain contains relatively few users or groups.

    [nss]

    Configures the Name Service Switch (NSS) module that integrates the SSS database with NSS.

    • filter_users and filter_groups prevent NSS from extracting information about the specified users and groups being retrieved from SSS.

    • reconnection_retries specifies the number of times that SSSD should attempt to reconnect if a data provider crashes.

    • enum_cache_timeout specifies the number of seconds for which SSSD caches user information requests.

    [pam]

    Configures the PAM module that integrates SSSD with PAM.

    • offline_credentials_expiration specifies the number of days for which to allow cached logins if the authentication provider is offline.

    • offline_failed_login_attempts specifies how many failed login attempts are allowed if the authentication provider is offline.

    • offline_failed_login_delay specifies how many minutes after the limit of allowed failed login attempts have been exceeded before a new login attempt is permitted.

  3. Change the mode of /etc/sssd/conf.d/00-ldap.conf to 0600:

    sudo chmod 0600 /etc/sssd/conf.d/00-ldap.conf
  4. If it is not started yet, enable the SSSD service:

  5. Select the sssd profile.

    sudo authselect select sssd

For more information about the SSSD service, see the sssd(8) man page as well as https://pagure.io/SSSD/sssd/. Additionally, you can consult sssd.conf(5), sssd-ldap(5), sssd-krb5(5), sssd-ipa(5), and other man pages.

2.2.2 About Pluggable Authentication Modules

The Pluggable Authentication Modules (PAM) feature is an authentication mechanism used by the sssd profile that allows you to configure how applications use authentication to verify the identity of a user. The PAM configuration files, which are located in the /etc/pam.d directory, describe the authentication procedure for an application. The name of each configuration file is the same as, or is similar to, the name of the application for which the module provides authentication. For example, the configuration files for passwd and sudo are named passwd and sudo.

Each PAM configuration file contains a list or stack of calls to authentication modules. For example, the following listing shows the default content of the login configuration file:

#%PAM-1.0
auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so
auth       include      system-auth
auth       include      postlogin
account    required     pam_nologin.so
account    include      system-auth
password   include      system-auth
# pam_selinux.so close should be the first session rule
session    required     pam_selinux.so close
session    required     pam_loginuid.so
session    optional     pam_console.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session    required     pam_selinux.so open
session    required     pam_namespace.so
session    optional     pam_keyinit.so force revoke
session    include      system-auth
session    include      postlogin
-session   optional     pam_ck_connector.so

Comments in the file start with a # character. The remaining lines each define an operation type, a control flag, the name of a module such as pam_rootok.so or the name of an included configuration file such as system-auth, and any arguments to the module. PAM provides authentication modules as shared libraries in /usr/lib64/security.

For a particular operation type, PAM reads the stack from top to bottom and calls the modules listed in the configuration file. Each module generates a success or failure result when called.

The following operation types are defined for use:

auth

The module tests whether a user is authenticated or authorized to use a service or application. For example, the module might request and verify a password. Such modules can also set credentials, such as a group membership or a Kerberos ticket.

account

The module tests whether an authenticated user is allowed access to a service or application. For example, the module might check if a user account has expired or if a user is allowed to use a service at a given time.

password

The module handles updates to an authentication token.

session

The module configures and manages user sessions, performing tasks such as mounting or unmounting a user's home directory.

If the operation type is preceded with a dash (-), PAM does not add an create a system log entry if the module is missing.

With the exception of include, the control flags tell PAM what to do with the result of running a module. The following control flags are defined for use:

optional

The module is required for authentication if it is the only module listed for a service.

required

The module must succeed for access to be granted. PAM continues to execute the remaining modules in the stack whether the module succeeds or fails. PAM does not immediately inform the user of the failure.

requisite

The module must succeed for access to be granted. If the module succeeds, PAM continues to execute the remaining modules in the stack. However, if the module fails, PAM notifies the user immediately and does not continue to execute the remaining modules in the stack.

sufficient

If the module succeeds, PAM does not process any remaining modules of the same operation type. If the module fails, PAM processes the remaining modules of the same operation type to determine overall success or failure.

The control flag field can also define one or more rules that specify the action that PAM should take depending on the value that a module returns. Each rule takes the form value=action, and the rules are enclosed in square brackets, for example:

[user_unknown=ignore success=ok ignore=ignore default=bad]

If the result that is returned by a module matches a value, PAM uses the corresponding action, or, if there is no match, it uses the default action.

The include flag specifies that PAM must also consult the PAM configuration file specified as the argument.

Most authentication modules and PAM configuration files have their own manual pages. Relevant files are stored in the /usr/share/doc/pam directory.

For more information, see the pam(8) manual page. In addition, each PAM module has its own manual page, for example pam_unix(8), postlogin(5), and system-auth(5).