Questo contenuto non è disponibile nella lingua selezionata.

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.
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:
  • Forest functional level range: Windows Server 2008 - Windows Server 2016[1]
  • Domain functional level range: Windows Server 2008 - Windows Server 2016[1]
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.
Red Hat logoGithubRedditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita ilBlog di Red Hat.

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

© 2024 Red Hat, Inc.