Integrating RHEL systems directly with Windows Active Directory

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:

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.

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

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

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

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.

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:

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.

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.

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

dyndns_update = false

If you set the id_provider = ad option in the /etc/sssd/sssd.conf configuration file, SSSD handles trusted domains as follows:

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.

The realmd system has two major task areas:

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.

Samba Winbind emulates a Windows client on a Linux system and communicates with AD servers.

You can use the realmd service to configure Samba Winbind by:

Note that:

Samba’s winbindd service provides an interface for the Name Service Switch (NSS) and enables domain users to authenticate to AD when logging into the local system.

Using winbindd provides the benefit that you can enhance the configuration to share directories and printers without installing additional software. For further detail, see the section about Using Samba as a server in the Deploying Different Types of Servers Guide.

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

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

Samba Winbind is an alternative to the System Security Services Daemon (SSSD) for connecting a Red Hat Enterprise Linux (RHEL) system with Active Directory (AD). You can join a RHEL system to an AD domain by using realmd to configure Samba Winbind.

For details, see the Understanding and configuring Samba ID mapping

The realmd system has two major task areas:

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.

Using the ad_integration system role, you can directly connect a RHEL system to Active Directory (AD).

The role uses the following components:

SSSD automatically renews the Kerberos host keytab file in an AD environment if the adcli package is installed. The daemon checks daily if the machine account password is older than the configured value and renews it if necessary.

The default renewal interval is 30 days. To change the default, follow the steps in this procedure.

Follow this procedure to remove a Red Hat Enterprise Linux (RHEL) system that is integrated into Active Directory (AD) directly from the AD domain.

The command first attempts to connect without credentials, but it prompts for a password if required.

By default, you must specify fully qualified usernames, like ad_username@ad.example.com and group@ad.example.com, to resolve Active Directory (AD) users and groups on a RHEL host connected to AD with the SSSD service.

This procedure sets the domain resolution order in the SSSD configuration so you can resolve AD users and groups using short names, like ad_username. This example configuration searches for users and groups in the following order:

By default, domain-side access control is applied, which means that login policies for Active Directory (AD) users are defined in the AD domain itself. This default behavior can be overridden so that client-side access control is used. With client-side access control, login permission is defined by local policies only.

If a domain applies client-side access control, you can use the realmd to configure basic allow or deny access rules for users from that domain.

A Group Policy Object (GPO) is a collection of access control settings stored in Microsoft Active Directory (AD) that can apply to computers and users in an AD environment. By specifying GPOs in AD, administrators can define login policies honored by both Windows clients and Red Hat Enterprise Linux (RHEL) hosts joined to AD.

The following sections describe how you can manage GPOs in your environment:

If you want to allow a RHEL host to access an Active Directory (AD) domain without joining it, you can use a Managed Service Account (MSA) to access that domain. An MSA is an account in AD that corresponds to a specific computer, which you can use to connect to AD resources as a specific user principal.

For example, if the AD domain production.example.com has a one-way trust relationship with the lab.example.com AD domain, the following conditions apply:

This means that a host joined to the lab domain, such as client.lab.example.com, cannot access resources from the production domain through the trust.

If you want to create an exception for the client.lab.example.com host, you can use the adcli utility to create a MSA for the client host in the production.example.com domain. By authenticating with the Kerberos principal of the MSA, you can perform secure LDAP searches in the production domain from the client host.

This procedure creates a Managed Service Account (MSA) for a host from the lab.example.com Active Directory (AD) domain, and configures SSSD so you can access and authenticate to the production.example.com AD domain.

Managed Service Accounts (MSAs) have a complex password that is maintained automatically by Active Directory (AD). By default, the System Services Security Daemon (SSSD) automatically updates the MSA password in the Kerberos keytab if it is older than 30 days, which keeps it up to date with the password in AD. This procedure explains how to manually update the password for your MSA.

The Managed Service Accounts (MSAs) that the adcli utility creates have the following specifications:

In addition to the global options you can pass to the adcli utility, you can specify the following options to specifically control how it handles Managed Service Accounts (MSAs).