Questo contenuto non è disponibile nella lingua selezionata.
Chapter 6. Planning integration with AD
The following sections introduce the options for integrating Red Hat Enterprise Linux with Active Directory (AD).
6.1. Direct integration of Linux systems into Active Directory
In direct integration, Linux systems are connected directly to Active Directory (AD). The following types of integration are possible:
- Integration with the System Security Services Daemon (SSSD)
SSSD can connect a Linux system with various identity and authentication stores: AD, Identity Management (IdM), or a generic LDAP or Kerberos server.
Notable requirements for integration with SSSD:
- When integrating with AD, SSSD works only within a single AD forest by default. For multi-forest setup, configure manual domain enumeration.
-
Remote AD forests must trust the local forest to ensure that the
idmap_adplug-in handles remote forest users correctly.
SSSD supports both direct and indirect integration. It also enables switching from one integration approach to the other without significant migration costs.
- Integration with Samba Winbind
The Winbind component of the Samba suite emulates a Windows client on a Linux system and communicates with AD servers.
Notable requirements for integration with Samba Winbind:
- Direct integration with Winbind in a multi-forest AD setup requires bidirectional trusts.
-
A bidirectional path from the local domain of a Linux system must exist to the domain of a user in a remote AD forest to allow full information about the user from the remote AD domain to be available to the
idmap_adplug-in.
Recommendations
- SSSD satisfies most of the use cases for AD integration and provides a robust solution as a generic gateway between a client system and different types of identity and authentication providers - AD, IdM, Kerberos, and LDAP.
- Winbind is recommended for deployment on those AD domain member servers on which you plan to deploy Samba FS.
6.2. Indirect integration of Linux systems into Active Directory by using Identity Management
In indirect integration, Linux systems are first connected to a central server which is then connected to Active Directory (AD). Indirect integration enables the administrator to manage Linux systems and policies centrally, while users from AD can transparently access Linux systems and services.
- Integration based on cross-forest trust with AD
The Identity Management (IdM) server acts as the central server to control Linux systems. A cross-realm Kerberos trust with AD is established, enabling users from AD to log on to access Linux systems and resources. IdM presents itself to AD as a separate forest and takes advantage of the forest-level trusts supported by AD.
When using a trust:
- AD users can access IdM resources.
- IdM servers and clients can resolve the identities of AD users and groups.
- AD users and groups access IdM under the conditions defined by IdM, such as host-based access control.
- AD users and groups continue being managed on the AD side.
- Integration based on synchronization
This approach is based on the WinSync tool. A WinSync replication agreement synchronizes user accounts from AD to IdM.
WarningWinSync is no longer actively developed in Red Hat Enterprise Linux 8. The preferred solution for indirect integration is cross-forest trust.
The limitations of integration based on synchronization include:
- Groups are not synchronized from IdM to AD.
- Users are duplicated in AD and IdM.
- WinSync supports only a single AD domain.
- Only one domain controller in AD can be used to synchronize data to one instance of IdM.
- User passwords must be synchronized, which requires the PassSync component to be installed on all domain controllers in the AD domain.
- After configuring the synchronization, all AD users must manually change passwords before PassSync can synchronize them.
6.3. Guidelines for deciding between direct and indirect integration
These guidelines can help you decide which type of integration fits your use case.
Number of systems to be connected to Active Directory
- Connecting less than 30-50 systems (not a hard limit)
- If you connect less than 30-50 systems, consider direct integration. Indirect integration might introduce unnecessary overhead.
- Connecting more than 30-50 systems (not a hard limit)
- If you connect more than 30-50 systems, consider indirect integration with Identity Management. With this approach, you can benefit from the centralized management for Linux systems.
- Managing a small number of Linux systems, but expecting the number to grow rapidly
- In this scenario, consider indirect integration to avoid having to migrate the environment later.
Frequency of deploying new systems and their type
- Deploying bare metal systems on an irregular basis
- If you deploy new systems rarely and they are usually bare metal systems, consider direct integration. In such cases, direct integration is usually simplest and easiest.
- Deploying virtual systems frequently
- If you deploy new systems often and they are usually virtual systems provisioned on demand, consider indirect integration. With indirect integration, you can use a central server to manage the new systems dynamically and integrate with orchestration tools, such as Red Hat Satellite.
Active Directory is the required authentication provider
- Do your internal policies state that all users must authenticate against Active Directory?
- You can choose either direct or indirect integration. If you use indirect integration with a trust between Identity Management and Active Directory, the users that access Linux systems authenticate against Active Directory. Policies that exist in Active Directory are executed and enforced during authentication.
