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, and pam_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. The recent versions of the System Security Services Daemon (SSSD) closed a feature gap between Samba Winbind and SSSD and SSSD can now be used as a replacement for Winbind. In certain corner cases, Winbind might still be necessary to use but it is no longer the first choice in general.
Note that:
  • 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. For multi-forest setup, configure manual domain enumeration as described in this Knowledgebase solution: Joining SSSD to domains in different forests.
  • 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.