Ce contenu n'est pas disponible dans la langue sélectionnée.
1.2. Direct Integration
You need two components to connect a Linux system to Active Directory (AD). One component interacts with the central identity and authentication source, which is AD in this case. The other component detects available domains and configures the first component to work with the right identity source. There are different options that can be used to retrieve information and perform authentication against AD. Among them are:
- Native LDAP and Kerberos PAM and NSS modules
- Among these modules are
nss_ldap
,pam_ldap
, andpam_krb5
. As PAM and NSS modules are loaded into every application process, they directly affect the execution environment. With no caching, offline support, or sufficient protection of access credentials, use of the basic LDAP and Kerberos modules for NSS and PAM is discouraged due to their limited functionality. - Samba Winbind
- Samba Winbind had been a traditional way of connecting Linux systems to AD. Winbind emulates a Windows client on a Linux system and is able to communicate to AD servers.Note that:
- The Winbind service must be running if you configured Samba as a domain member.
- Direct integration with Winbind in a multi-forest AD setup requires bidirectional trusts.
- Remote forests must trust the local forest to ensure that the
idmap_ad
plug-in handles remote forest users correctly.
- System Security Services Daemon (SSSD)
- The primary function of SSSD is to access a remote identity and authentication resource through a common framework that provides caching and offline support to the system. SSSD is highly configurable; it provides PAM and NSS integration and a database to store local users, as well as core and extended user data retrieved from a central server. SSSD is the recommended component to connect a Linux system with an identity server of your choice, be it Active Directory, Identity Management (IdM) in Red Hat Enterprise Linux, or any generic LDAP or Kerberos server.Note that:
- Direct integration with SSSD works only within a single AD forest by default.
- Remote forests must trust the local forest to ensure that the
idmap_ad
plug-in handles remote forest users correctly.
The main reason to transition from Winbind to SSSD is that SSSD can be used for both direct and indirect integration and allows to switch from one integration approach to another without significant migration costs. The most convenient way to configure SSSD or Winbind in order 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.
Direct integration is a simple way to introduce Linux systems to AD environment. However, as the share of Linux systems grows, the deployments usually see the need for a better centralized management of the identity-related policies such as host-based access control, sudo, or SELinux user mappings. At first, the configuration of these aspects of the Linux systems can be maintained in local configuration files. With a growing number of systems though, distribution and management of the configuration files is easier with a provisioning system such as Red Hat Satellite. This approach creates an overhead of changing the configuration files and then distributing them. When direct integration does not scale anymore, it is more beneficial to consider indirect integration described in the next section.
1.2.1. Supported Windows Platforms for direct integration
You can directly integrate your Linux machine with Active Directory forests that use the following forest and domain functional levels:
Direct integration has been tested on the following supported operating systems using the mentioned functional levels:
- Windows Server 2019
- Windows Server 2016
- Windows Server 2012 R2
[1]
Windows Server 2019 does not introduce a new functional level. The highest functional level Windows Server 2019 uses are Windows Server 2016.