Chapter 2. Connecting RHEL systems directly to AD using Samba Winbind
You need two components to connect a RHEL system to AD. One component, Samba Winbind, interacts with the AD identity and authentication source, and the other component, realmd, detects available domains and configures the underlying RHEL system services, in this case Samba Winbind, to connect to the AD domain.
This section describes using Samba Winbind to connect a RHEL system to Active Directory (AD).
2.1. Overview of direct integration using Samba Winbind
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:
- Configuring network authentication and domain membership in a standard way.
- Automatically discovering information about accessible domains and realms.
- Not requiring advanced configuration to join a domain or realm.
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_adplug-in handles remote forest users correctly.
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.
Additional resources
-
See the
realmdman page. -
See the
winbinddman page.
2.2. Supported Windows platforms for direct integration
You can directly integrate your RHEL system with Active Directory forests that use the following forest and domain functional levels:
- Forest functional level range: Windows Server 2008 - Windows Server 2016
- Domain functional level range: Windows Server 2008 - Windows Server 2016
Direct integration has been tested on the following supported operating systems:
- Windows Server 2022 (RHEL 9.1 and above)
- Windows Server 2019
- Windows Server 2016
- Windows Server 2012 R2
Windows Server 2019 and Windows Server 2022 do not introduce a new functional level. The highest functional level Windows Server 2019 and Windows Server 2022 use is Windows Server 2016.
2.3. Ensuring support for common encryption types in AD and RHEL
By default, Samba Winbind supports RC4, AES-128, and AES-256 Kerberos encryption types.
RC4 encryption has been deprecated and disabled by default, as it is considered less secure than the newer AES-128 and AES-256 encryption types. In contrast, Active Directory (AD) user credentials and trusts between AD domains support RC4 encryption and they might not support AES encryption types.
Without any common encryption types, communication between RHEL hosts and AD domains might not work, or some AD accounts might not be able to authenticate. To remedy this situation, modify one of the following configurations:
- Enable AES encryption support in Active Directory (recommended option)
- To ensure trusts between AD domains in an AD forest support strong AES encryption types, see the following Microsoft article: AD DS: Security: Kerberos "Unsupported etype" error when accessing a resource in a trusted domain
- Enable RC4 support in RHEL
- On every RHEL host where authentication against AD Domain Controllers takes place:
Use the
update-crypto-policiescommand to enable theAD-SUPPORT-LEGACYcryptographic subpolicy in addition to theDEFAULTcryptographic policy.[root@host ~]# update-crypto-policies --set DEFAULT:AD-SUPPORT-LEGACY Setting system policy to DEFAULT:AD-SUPPORT-LEGACY Note: System-wide crypto policies are applied on application start-up. It is recommended to restart the system for the change of policies to fully take place.- Restart the host.
Additional resources
2.4. Joining a RHEL system to an AD domain
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.
Procedure
If your AD requires the deprecated RC4 encryption type for Kerberos authentication, enable support for these ciphers in RHEL:
# update-crypto-policies --set DEFAULT:AD-SUPPORTInstall the following packages:
# dnf install realmd oddjob-mkhomedir oddjob samba-winbind-clients \ samba-winbind samba-common-tools samba-winbind-krb5-locator
To share directories or printers on the domain member, install the
sambapackage:# dnf install sambaBackup the existing
/etc/samba/smb.confSamba configuration file:# mv /etc/samba/smb.conf /etc/samba/smb.conf.bakJoin the domain. For example, to join a domain named
ad.example.com:# realm join --membership-software=samba --client-software=winbind ad.example.comUsing the previous command, the
realmutility automatically:-
Creates a
/etc/samba/smb.conffile for a membership in thead.example.comdomain -
Adds the
winbindmodule for user and group lookups to the/etc/nsswitch.conffile -
Updates the Pluggable Authentication Module (PAM) configuration files in the
/etc/pam.d/directory -
Starts the
winbindservice and enables the service to start when the system boots
-
Creates a
-
Optionally, set an alternative ID mapping back end or customized ID mapping settings in the
/etc/samba/smb.conffile.
For details, see the Understanding and configuring Samba ID mapping
Edit the
/etc/krb5.conffile and add the following section:[plugins] localauth = { module = winbind:/usr/lib64/samba/krb5/winbind_krb5_localauth.so enable_only = winbind }Verify that the
winbindservice is running:# systemctl status winbind ... Active: active (running) since Tue 2018-11-06 19:10:40 CET; 15s agoImportantTo enable Samba to query domain user and group information, the
winbindservice must be running before you startsmb.If you installed the
sambapackage to share directories and printers, enable and start thesmbservice:# systemctl enable --now smb
Verification steps
Display an AD user’s details, such as the AD administrator account in the AD domain:
# getent passwd "AD\administrator" AD\administrator:*:10000:10000::/home/administrator@AD:/bin/bashQuery the members of the domain users group in the AD domain:
# getent group "AD\Domain Users" AD\domain users:x:10000:user1,user2Optionally, verify that you can use domain users and groups when you set permissions on files and directories. For example, to set the owner of the
/srv/samba/example.txtfile toAD\administratorand the group toAD\Domain Users:# chown "AD\administrator":"AD\Domain Users" /srv/samba/example.txtVerify that Kerberos authentication works as expected:
On the AD domain member, obtain a ticket for the
administrator@AD.EXAMPLE.COMprincipal:# kinit administrator@AD.EXAMPLE.COMDisplay the cached Kerberos ticket:
# klist Ticket cache: KCM:0 Default principal: administrator@AD.EXAMPLE.COM Valid starting Expires Service principal 01.11.2018 10:00:00 01.11.2018 20:00:00 krbtgt/AD.EXAMPLE.COM@AD.EXAMPLE.COM renew until 08.11.2018 05:00:00
Display the available domains:
# wbinfo --all-domains BUILTIN SAMBA-SERVER AD
Additional resources
- If you do not want to use the deprecated RC4 ciphers, you can enable the AES encryption type in AD. See
- Enabling the AES encryption type in Active Directory using a GPO
-
realm(8)man page
2.5. realm commands
The realmd system has two major task areas:
- Managing system enrollment in a domain.
- Controlling which domain users are allowed to access local system resources.
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.
Table 2.1. realmd Commands
| Command | Description |
|---|---|
| Realm Commands | |
| discover | Run a discovery scan for domains on the network. |
| join | Add the system to the specified domain. |
| leave | Remove the system from the specified domain. |
| list | List all configured domains for the system or all discovered and configured domains. |
| Login Commands | |
| permit | Enable access for specific users or for all users within a configured domain to access the local system. |
| deny | Restrict access for specific users or for all users within a configured domain to access the local system. |
Additional resources
-
The
realm(8)man page.