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
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.
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)
, andsssd(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
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.
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).
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.
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:
- 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:
# dnf install samba-common-tools realmd oddjob oddjob-mkhomedir sssd adcli krb5-workstation
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.NoteThe
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. Therealmd
suite edits all required configuration files automatically. For example, for a domain namedad.example.com
:# realm join ad.example.com
Verification
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
-
realm(8)
andnmcli(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:
- 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:
# dnf install realmd oddjob oddjob-mkhomedir sssd adcli krb5-workstation
Configure the local RHEL system with POSIX ID mapping disabled using the
realm join
command with the--automatic-id-mapping=no
option. Therealmd
suite edits all required configuration files automatically. For example, for a domain namedad.example.com
:# realm join --automatic-id-mapping=no 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:
rm -f /var/lib/sss/db/*
Restart SSSD:
systemctl restart sssd
-
Open the
SSSD now uses POSIX attributes from AD, instead of creating them locally.
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:
# getent passwd administrator@ad.example.com administrator@ad.example.com:*:10000:10000:Administrator:/home/Administrator:/bin/bash
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.
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 is86400
seconds (24 hours).NoteIf 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.[domain/ad.example.com] id_provider = ad ... dyndns_refresh_interval = 43200 dyndns_update_ptr = false dyndns_ttl = 3600
-
Save and close the
/etc/sssd/sssd.conf
configuration file. Restart the SSSD service to load the configuration changes.
[root@client ~]# systemctl restart sssd
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
- 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 thead_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:[domain/ad.example.com] id_provider = ad ... ad_site = ExampleSite
-
Save and close the
/etc/sssd/sssd.conf
configuration file. Restart the SSSD service to load the configuration changes:
# systemctl restart sssd
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.
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.
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 |
LDAP Global Catalog | 3268 | TCP |
If the |
LDAPS Global Catalog | 3269 | TCP | Optional |
NTP | 123 | UDP | Optional |
NTP | 323 | UDP | Optional |