Menu Close

Chapter 1. Connecting RHEL systems directly to AD using SSSD

You need two components to connect a RHEL system to Active Directory (AD). One component, SSSD, interacts with the central identity and authentication source, and the other component, realmd, detects available domains and configures the underlying RHEL system services, in this case SSSD, to connect to the domain.

This section describes using the System Security Services Daemon (SSSD) to connect a RHEL system to Active Directory (AD).

1.1. Overview of direct integration using SSSD

You use SSSD to access a user directory for authentication and authorization through a common framework with user caching to permit offline logins. SSSD is highly configurable; it provides Pluggable Authentication Modules (PAM) and Name Switch Service (NSS) integration and a database to store local users as well as extended user data retrieved from a central server. SSSD is the recommended component to connect a RHEL system with one of the following types of identity server:

  • Active Directory
  • Identity Management (IdM) in RHEL
  • Any generic LDAP or Kerberos server
Note

Direct integration with SSSD works only within a single AD forest by default.

The most convenient way to configure SSSD to directly integrate a Linux system with AD is to use the realmd service. It allows callers to configure network authentication and domain membership in a standard way. The realmd service automatically discovers information about accessible domains and realms and does not require advanced configuration to join a domain or realm.

You can use SSSD for both direct and indirect integration with AD and it allows you to switch from one integration approach to another. Direct integration is a simple way to introduce RHEL systems to an AD environment. However, as the share of RHEL systems grows, your deployments usually need a better centralized management of the identity-related policies such as host-based access control, sudo, or SELinux user mappings. Initially, you can maintain the configuration of these aspects of the RHEL systems in local configuration files. However, with a growing number of systems, distribution and management of the configuration files is easier with a provisioning system such as Red Hat Satellite. When direct integration does not scale anymore, you should consider indirect integration. For more information on moving from direct integration (RHEL clients are in the AD domain) to indirect integration (IdM with trust to AD), see Moving RHEL clients from AD domain to IdM Server.

For more information on which type of integration fits your use case, see Deciding between indirect and direct integration.

Additional resources

  • The realm(8) man page.
  • The sssd-ad(5) man page.
  • The sssd(8) man page.

1.2. Supported Windows platforms for direct integration

You can directly integrate your RHEL system with Active Directory forests that use the following forest and domain functional levels:

  • Forest functional level range: Windows Server 2008 - Windows Server 2016
  • Domain functional level range: Windows Server 2008 - Windows Server 2016

Direct integration has been tested on the following supported operating systems:

  • Windows Server 2019
  • Windows Server 2016
  • Windows Server 2012 R2
Note

Windows Server 2019 does not introduce a new functional level. The highest functional level Windows Server 2019 uses is Windows Server 2016.

1.3. Ensuring support for common encryption types in AD and RHEL

By default, SSSD supports RC4, AES-128, and AES-256 Kerberos encryption types.

RC4 encryption has been deprecated and disabled by default, as it is considered less secure than the newer AES-128 and AES-256 encryption types. In contrast, Active Directory (AD) user credentials and trusts between AD domains support RC4 encryption and they might not support AES encryption types.

Without any common encryption types, communication between RHEL hosts and AD domains might not work, or some AD accounts might not be able to authenticate. To remedy this situation, modify one of the following configurations:

Enable AES encryption support in Active Directory (recommended option)
To ensure trusts between AD domains in an AD forest support strong AES encryption types, see the following Microsoft article: AD DS: Security: Kerberos "Unsupported etype" error when accessing a resource in a trusted domain
Enable RC4 support in RHEL

On every RHEL host where authentication against AD Domain Controllers takes place:

  1. Use the update-crypto-policies command to enable the AD-SUPPORT cryptographic subpolicy in addition to the DEFAULT cryptographic policy.

    [root@host ~]# update-crypto-policies --set DEFAULT:AD-SUPPORT
    Setting system policy to DEFAULT:AD-SUPPORT
    Note: System-wide crypto policies are applied on application start-up.
    It is recommended to restart the system for the change of policies
    to fully take place.
  2. Restart the host.

Additional resources

1.4. Connecting directly to AD

The System Security Services Daemon (SSSD) is the recommended component to connect a Red Hat Enterprise Linux (RHEL) system with Active Directory (AD). This section describes how to integrate directly with AD by using either ID mapping, which is the default for SSSD, or by using POSIX attributes.

1.4.1. Discovering and joining an AD Domain using SSSD

This procedure describes how to discover an AD domain and connect a RHEL system to that domain using SSSD.

Prerequisites

  • Ensure that the following ports on the RHEL host are open and accessible to the AD domain controllers.

    Table 1.1. Ports Required for Direct Integration of Linux Systems into AD Using SSSD

    ServicePortProtocolNotes

    DNS

    53

    UDP and TCP

     

    LDAP

    389

    UDP and TCP

     

    Samba

    445

    UDP and TCP

    For AD Group Policy Objects (GPOs)

    Kerberos

    88

    UDP and TCP

     

    Kerberos

    464

    UDP and TCP

    Used by kadmin for setting and changing a password

    LDAP Global Catalog

    3268

    TCP

    If the id_provider = ad option is being used

    NTP

    123

    UDP

    Optional

  • Ensure that you are using the AD domain controller server for DNS.
  • Verify that the system time on both systems is synchronized. This ensures that Kerberos is able to work correctly.

Procedure

  1. Install the following packages:

    # dnf install samba-common-tools realmd oddjob oddjob-mkhomedir sssd adcli krb5-workstation
  2. To display information for a specific domain, run realm discover and add the name of the domain you want to discover:

    # realm discover ad.example.com
    ad.example.com
      type: kerberos
      realm-name: AD.EXAMPLE.COM
      domain-name: ad.example.com
      configured: no
      server-software: active-directory
      client-software: sssd
      required-package: oddjob
      required-package: oddjob-mkhomedir
      required-package: sssd
      required-package: adcli
      required-package: samba-common

    The realmd system uses DNS SRV lookups to find the domain controllers in this domain automatically.

    Note

    The realmd system can discover both Active Directory and Identity Management domains. If both domains exist in your environment, you can limit the discovery results to a specific type of server using the --server-software=active-directory option.

  3. Configure the local RHEL system with the realm join command. The realmd suite edits all required configuration files automatically. For example, for a domain named ad.example.com:

    # realm join ad.example.com

Verification steps

  • Display an AD user details, such as the administrator user:

    # getent passwd administrator@ad.example.com
    administrator@ad.example.com:*:1450400500:1450400513:Administrator:/home/administrator@ad.example.com:/bin/bash

Additional resources

  • See the realm(8) man page.
  • See the nmcli(1) man page.

1.4.2. Options for integrating with AD: using ID mapping or POSIX attributes

Linux and Windows systems use different identifiers for users and groups:

Important

After connecting a RHEL system to AD, you can authenticate with your AD username and password. Do not create a Linux user with the same name as a Windows user, as duplicate names might cause a conflict and interrupt the authentication process.

To authenticate to a RHEL system as an AD user, you must have a UID and GID assigned. SSSD provides the option to integrate with AD either using ID mapping or POSIX attributes. The default is to use ID mapping.

Automatically generate new UIDs and GIDs for AD users

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

See Discovering and joining an AD domain using SSSD.

Note

When all client systems use SSSD to map SIDs to Linux IDs, the mapping is consistent. If some clients use different software, choose one of the following:

  • Ensure that the same mapping algorithm is used on all clients.
  • Use explicit POSIX attributes defined in AD.

Use POSIX attributes defined in AD

AD can create and store POSIX attributes, such as uidNumber, gidNumber, unixHomeDirectory, or loginShell.

When using ID mapping described above, SSSD creates new UIDs and GIDs, which overrides the values defined in AD. To keep the AD-defined values, you must disable ID mapping in SSSD.

See Connecting to AD using POSIX attributes defined in Active Directory.

1.4.3. Connecting to AD using POSIX attributes defined in Active Directory

For best performance, publish the POSIX attributes to the AD global catalog. If POSIX attributes are not present in the global catalog, SSSD connects to the individual domain controllers directly on the LDAP port.

Prerequisites

  • Ensure that the following ports on the RHEL host are open and accessible to the AD domain controllers.

    Table 1.2. Ports Required for Direct Integration of Linux Systems into AD Using SSSD

    ServicePortProtocolNotes

    DNS

    53

    UDP and TCP

     

    LDAP

    389

    UDP and TCP

     

    Kerberos

    88

    UDP and TCP

     

    Kerberos

    464

    UDP and TCP

    Used by kadmin for setting and changing a password

    LDAP Global Catalog

    3268

    TCP

    If the id_provider = ad option is being used

    NTP

    123

    UDP

    Optional

  • Ensure that you are using the AD domain controller server for DNS.
  • Verify that the system time on both systems is synchronized. This ensures that Kerberos is able to work correctly.

Procedure

  1. Install the following packages:

    # dnf install realmd oddjob oddjob-mkhomedir sssd adcli krb5-workstation
  2. Configure the local RHEL system with ID mapping disabled using the realm join command with the --automatic-id-mapping=no option. The realmd suite edits all required configuration files automatically. For example, for a domain named ad.example.com:

    # realm join --automatic-id-mapping=no ad.example.com
  3. If you already joined a domain, you can manually disable ID Mapping in SSSD:

    1. Open the /etc/sssd/sssd.conf file.
    2. In the AD domain section, add the ldap_id_mapping = false setting.
    3. Remove the SSSD caches:

      rm -f /var/lib/sss/db/*
    4. Restart SSSD:

      systemctl restart sssd

SSSD now uses POSIX attributes from AD, instead of creating them locally.

Note

You must have the relevant POSIX attributes (uidNumber, gidNumber, unixHomeDirectory, and loginShell) configured for the users in AD.

Verification steps

  • Display an AD user details, such as the administrator user:

    # getent passwd administrator@ad.example.com
    administrator@ad.example.com:*:10000:10000:Administrator:/home/Administrator:/bin/bash

Additional resources

  • For further details about ID mapping and the ldap_id_mapping parameter, see the sssd-ldap(8) man page.

1.4.4. Connecting to multiple domains in different AD forests with SSSD

You can use an Active Directory (AD) Managed Service Account (MSA) to access AD domains from different forests where there is no trust between them.

See Accessing AD with a Managed Service Account.

1.5. How the AD provider handles dynamic DNS updates

Active Directory (AD) actively maintains its DNS records by timing out (aging) and removing (scavenging) inactive records.

By default, the SSSD service refreshes a RHEL client’s DNS record at the following intervals:

  • Every time the identity provider comes online.
  • Every time the RHEL system reboots.
  • At the interval specified by the dyndns_refresh_interval option in the /etc/sssd/sssd.conf configuration file. The default value is 86400 seconds (24 hours).

    Note

    If you set the dyndns_refresh_interval option to the same interval as the DHCP lease, you can update the DNS record after the IP lease is renewed.

SSSD sends dynamic DNS updates to the AD server using Kerberos/GSSAPI for DNS (GSS-TSIG). This means that you only need to enable secure connections to AD.

Additional resources

  • The sssd-ad(5) man page.

1.6. Modifying dynamic DNS settings for the AD provider

The System Security Services Daemon (SSSD) service refreshes the DNS record of a Red Hat Enterprise Linux (RHEL) client joined to an AD environment at default intervals. The following procedure adjusts these intervals.

Prerequisites

  • You have joined a RHEL host to an Active Directory environment with the SSSD service.
  • You need root permissions to edit the /etc/sssd/sssd.conf configuration file.

Procedure

  1. Open the /etc/sssd/sssd.conf configuration file in a text editor.
  2. Add the following options to the [domain] section for your AD domain to set the DNS record refresh interval to 12 hours, disable updating PTR records, and set the DNS record Time To Live (TTL) to 1 hour.

    [domain/ad.example.com]
    id_provider = ad
    ...
    dyndns_refresh_interval = 43200
    dyndns_update_ptr = false
    dyndns_ttl = 3600
  3. Save and close the /etc/sssd/sssd.conf configuration file.
  4. Restart the SSSD service to load the configuration changes.

    [root@client ~]# systemctl restart sssd
Note

You can disable dynamic DNS updates by setting the dyndns_update option in the sssd.conf file to false:

[domain/ad.example.com]
id_provider = ad
...

dyndns_update = false

Additional resources

1.7. How the AD provider handles trusted domains

This section describes how SSSD handles trusted domains if you set the id_provider = ad option in the /etc/sssd/sssd.conf configuration file.

  • SSSD only supports domains in a single AD forest. If SSSD requires access to multiple domains from multiple forests, consider using IPA with trusts (preferred) or the winbindd service instead of SSSD.
  • By default, SSSD discovers all domains in the forest and, if a request for an object in a trusted domain arrives, SSSD tries to resolve it.

    If the trusted domains are not reachable or geographically distant, which makes them slow, you can set the ad_enabled_domains parameter in /etc/sssd/sssd.conf to limit from which trusted domains SSSD resolves objects.

  • By default, you must use fully-qualified user names to resolve users from trusted domains.

Additional resources

  • The sssd.conf(5) man page.

1.8. realm commands

The realmd system has two major task areas:

  • Managing system enrollment in a domain.
  • Controlling which domain users are allowed to access local system resources.

In realmd use the command line tool realm to run commands. Most realm commands require the user to specify the action that the utility should perform, and the entity, such as a domain or user account, for which to perform the action.

Table 1.3. realmd Commands

CommandDescription

Realm Commands

discover

Run a discovery scan for domains on the network.

join

Add the system to the specified domain.

leave

Remove the system from the specified domain.

list

List all configured domains for the system or all discovered and configured domains.

Login Commands

permit

Enable access for specific users or for all users within a configured domain to access the local system.

deny

Restrict access for specific users or for all users within a configured domain to access the local system.

Additional resources

  • The realm(8) man page.