Chapter 1. Connecting RHEL systems directly to AD using SSSD To connect a RHEL system to Active Directory (AD), use: System Security Services Daemon (SSSD) for identity and authentication realmd to detect available domains and configure the underlying RHEL system services. 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 about 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. Important If IdM is in FIPS mode, the IdM-AD integration does not work due to AD only supporting the use of RC4 or AES HMAC-SHA1 encryptions, while RHEL 9 in FIPS mode allows only AES HMAC-SHA2 by default. For more information, see the Red Hat Knowledgebase solution AD Domain Users unable to login in to the FIPS-compliant environment . IdM does not support the more restrictive FIPS:OSPP crypto policy, which should only be used on Common Criteria evaluated systems. Additional resources realm(8) , sssd-ad(5) , and sssd(8) man pages on your system Deciding between indirect and direct integration 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 2022 (RHEL 9.1 or later) Windows Server 2019 Windows Server 2016 Windows Server 2012 R2 Note Windows Server 2019 and Windows Server 2022 do not introduce a new functional level. The highest functional level Windows Server 2019 and Windows Server 2022 use is Windows Server 2016. 1.3. 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). You can integrate directly with AD by using either POSIX ID mapping, which is the default for SSSD, or by using POSIX attributes defined in AD. Important Before joining your system to AD, ensure you configured your system correctly by following the procedure in the Red Hat Knowledgebase solution Basic Prechecks Steps: RHEL Join With Active Directory using 'adcli', 'realm' and 'net' commands . 1.3.1. Options for integrating with AD: using POSIX ID mapping or POSIX attributes Linux and Windows systems use different identifiers for users and groups: Linux uses user IDs (UID) and group IDs (GID). See Introduction to managing user and group accounts in Configuring Basic System Settings . Linux UIDs and GIDs are compliant with the POSIX standard. Windows use security IDs (SID). 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 POSIX ID mapping or POSIX attributes in AD. The default is to use POSIX ID mapping. 1.3.2. Connecting to AD using POSIX ID mapping SSSD uses the SID of an AD user to algorithmically generate POSIX IDs in a process called POSIX ID mapping. POSIX ID mapping creates an association 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 RHEL system. 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. For more information, see the section on ID mapping in the sssd-ad man page. 1.3.2.1. Discovering and joining an AD Domain using SSSD Follow this procedure to discover an AD domain and connect a RHEL system to that domain using SSSD. Prerequisites Ensure that the required ports are open: Ports required for direct integration of RHEL systems into AD using SSSD 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 Install the following packages: To display information for a specific domain, run realm discover and add the name of the domain you want to discover: 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. 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 : Verification Display an AD user details, such as the administrator user: Additional resources realm(8) and nmcli(1) man pages on your system 1.3.3. Connecting to AD using POSIX attributes defined in Active Directory AD can create and store POSIX attributes, such as uidNumber , gidNumber , unixHomeDirectory , or loginShell . When using POSIX ID mapping, SSSD creates new UIDs and GIDs, which overrides the values defined in AD. To keep the AD-defined values, you must disable POSIX ID mapping in SSSD. 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 required ports are open: Ports required for direct integration of RHEL systems into AD using SSSD 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 Install the following packages: Configure the local RHEL system with POSIX 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 : If you already joined a domain, you can manually disable POSIX ID Mapping in SSSD: Open the /etc/sssd/sssd.conf file. In the AD domain section, add the ldap_id_mapping = false setting. Remove the SSSD caches: 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 Display an AD user details, such as the administrator user: Additional resources sssd-ldap(8) man page on your system 1.3.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.4. 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 sssd-ad(5) man page on your system 1.5. 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 Open the /etc/sssd/sssd.conf configuration file in a text editor. 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. Save and close the /etc/sssd/sssd.conf configuration file. Restart the SSSD service to load the configuration changes. Note You can disable dynamic DNS updates by setting the dyndns_update option in the sssd.conf file to false : Additional resources How the AD provider handles dynamic DNS updates sssd-ad(5) man page on your system 1.6. How the AD provider handles trusted domains If you set the id_provider = ad option in the /etc/sssd/sssd.conf configuration file, SSSD handles trusted domains as follows: 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 sssd.conf(5) man page on your system 1.7. Overriding Active Directory site autodiscovery with SSSD Active Directory (AD) forests can be very large, with numerous different domain controllers, domains, child domains and physical sites. AD uses the concept of sites to identify the physical location for its domain controllers. This enables clients to connect to the domain controller that is geographically closest, which increases client performance. This section describes how SSSD uses autodiscovery to find an AD site to connect to, and how you can override autodiscovery and specify a site manually. 1.7.1. How SSSD handles AD site autodiscovery By default, SSSD clients use autodiscovery to find its AD site and connect to the closest domain controller. The process consists of these steps: SSSD performs an SRV query to find Domain Controllers (DCs) in the domain. SSSD reads the discovery domain from the dns_discovery_domain or the ad_domain options in the SSSD configuration file. SSSD performs Connection-Less LDAP (CLDAP) pings to these DCs in 3 batches to avoid pinging too many DCs and avoid timeouts from unreachable DCs. If SSSD receives site and forest information during any of these batches, it skips the rest of the batches. SSSD creates and saves a list of site-specific and backup servers. 1.7.2. Overriding AD site autodiscovery To override the autodiscovery process, specify the AD site to which you want the client to connect by adding the ad_site option to the [domain] section of the /etc/sssd/sssd.conf file. This example configures the client to connect to the ExampleSite AD site. Prerequisites You have joined a RHEL host to an Active Directory environment using the SSSD service. You can authenticate as the root user so you can edit the /etc/sssd/sssd.conf configuration file. Procedure Open the /etc/sssd/sssd.conf file in a text editor. Add the ad_site option to the [domain] section for your AD domain: Save and close the /etc/sssd/sssd.conf configuration file. Restart the SSSD service to load the configuration changes: 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.1. realmd commands Command Description 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 realm(8) man page on your system 1.9. Ports required for direct integration of RHEL systems into AD using SSSD The following ports must be open and accessible to the AD domain controllers and the RHEL host. Table 1.2. Ports Required for Direct Integration of Linux Systems into AD Using SSSD Service Port Protocol Notes DNS 53 UDP and TCP LDAP 389 UDP and TCP LDAPS 636 TCP Optional 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 LDAPS Global Catalog 3269 TCP Optional NTP 123 UDP Optional NTP 323 UDP Optional

Commands:
dnf install samba-common-tools realmd oddjob oddjob-mkhomedir sssd adcli krb5-workstation
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
realm join ad.example.com
getent passwd administrator@ad.example.com administrator@ad.example.com:*:1450400500:1450400513:Administrator:/home/administrator@ad.example.com:/bin/bash
dnf install realmd oddjob oddjob-mkhomedir sssd adcli krb5-workstation
realm join --automatic-id-mapping=no ad.example.com
rm -f /var/lib/sss/db/*
systemctl restart sssd
getent passwd administrator@ad.example.com administrator@ad.example.com:*:10000:10000:Administrator:/home/Administrator:/bin/bash
[domain/ ad.example.com ] id_provider = ad dyndns_refresh_interval = 43200 dyndns_update_ptr = false dyndns_ttl = 3600
systemctl restart sssd
[domain/ ad.example.com ] id_provider = ad dyndns_update = false
[domain/ad.example.com] id_provider = ad ad_site = ExampleSite
systemctl restart sssd