Tools for integrating Linux systems with Microsoft Active Directory
Strange Land
We explore some leading tools for integrating your Linux network with an Active Directory environment.
The benefits of keeping user and group information in one place are many. A central user management system is both more convenient and more secure. Walking around the network, changing user and group information on multiple systems takes time and increases the possibility of errors when creating or deleting an account. Maintaining different user information on different systems can also lead to insecure practices, such as password proliferation.
If your network is big enough to be managed at all, you have probably considered managing user accounts from a central location. Many tools exist for managing users in homogeneous environments; however, central management becomes difficult if users want to access a variety of operating systems.
Active Directory is Microsoft's grandiose, enterprise-grade central management solution. Although Active Directory is built from many open technologies, such as LDAP and Kerberos, Microsoft didn't exactly create Active Directory with Linux in mind. Over the years, however, several tools have emerged for combining Linux user resources with Active Directory. This article includes some popular options, such as:
- FreeIPA – An open source integrated security system that combines Linux with LDAP, Kerberos, NTP, DNS, and the Dogtag certificate system.
- Samba Winbind – A tool included with the Samba suite that supports Active Directory authentication for Linux systems.
- System Security Services Daemon – A client-side tool that provides integrated support for Linux and Windows AD user environments through LDAP, Kerberos, and other necessary components.
In this article, I describe these popular options for Active Directory (AD) integration. I'll assume you have some familiarity with Active Directory tools and concepts. Look online [1] for more information on Microsoft's Active Directory environment.
AD Integration with FreeIPA
The FreeIPA framework is asserting itself within the Linux environment. FreeIPA combines various open source tools under one roof – for example, an LDAP and a Kerberos server. The FreeIPA framework has supported integration with existing Windows domains for some time. The framework also offers the option of synchronizing user objects from the AD on FreeIPA servers, so they are available as separate objects in the LDAP tree of the FreeIPA server. In version 3.1, FreeIPA added the ability to establish a trust relationship with a Windows Server 2008 R2 domain; after doing so, users from the AD domain can access the resources of the FreeIPA domain.
The synchronization of AD objects imposes very few requirements on the existing environment, and the setup is correspondingly simple. One thing to keep in mind is you are relatively limited in the number of LDAP attributes that are transferred during synchronization. To keep the user passwords identical in both domains, you need to install additional software on the Windows domain controllers (DCs); the software then transfers the passwords to the FreeIPA servers.
To ensure that operations use a secure communication path, both environments must have the corresponding CA certificate. Only then is it ensured that the correct computers are talking to one another. Although both environments use an LDAP server to store the objects, the server schemas differ. Many LDAP attributes are identical, but others need to be mapped. If RFC 2307 attributes exist in the AD, such as a POSIX user ID, most of these attributes are not synchronized. Instead, users on the FreeIPA side are assigned new user IDs.
Setting up a trust between the Kerberos realms of the two domains involves very strict requirements for the DNS systems. It is imperative that the FreeIPA domain have a separate DNS zone and that the respective name entries in the two domains are found with the help of DNS forwarders. Ideally, the FreeIPA domain will use a DNS subzone of the Windows AD zone. The DNS servers are identified by zone delegation.
One of the advantages of setting up a trust is that no data needs to be synchronized, and a Windows DC can dynamically retrieve user and group information when a user logs in. This information can then be stored in a local cache. Unlike synchronizing AD objects, no changes on the AD side are necessary with this approach. This is often a decisive factor in favor of setting up a trust. One disadvantage of this type of integration is that the Windows AD users and groups need to be mapped to POSIX groups on the FreeIPA servers, which requires greater administrative overhead in the initial setup of the environment.
Pure AD Using Winbind
Integrating Linux clients with Samba Winbind requires a completely different approach. No separate identity store is established on the Linux side; instead, all authentication requests are to the DC target of the Windows AD domain. For this to happen, you need to join each client to the Windows domain. For the configuration work, use the system-config-authentication
tool or the text-based authconfig-tui
. You need to configure Winbind and the Kerberos subsystem (Figure 1). Kerberos is necessary so that the Windows LDAP server can be queried through GSSAPI (Figure 2).
You then create the Kerberos keytab
file for the client with the help of Samba. (You can also create this file on the Windows side and then transfer it to the client; however, the procedure is much more complex.) The resulting configurations are given in Listings 1 and 2 (Figure 3). Only the idmap backend
parameter needs to be changed from tdb
to rid
. This parameter sets how the Windows SIDs are converted into POSIX UIDs and GIDs. The default parameter tdb
maps the values and keeps the results in a local database, which can differ from client to client. The rid
back end works in a deterministic manner; the SID to UID/GID mapping is identical in each case. Thus, you have no need to store this information in a database.
Listing 1
/etc/samba/smb.conf
Listing 2
/etc/krb5.conf
The client system then joins the AD domain using the following command:
$ net join ads -U Administrator
If the join worked, a call to getent passwd
and getent group
should now also show the accounts from your Windows domain in addition to the local user and group accounts. The Samba service does not need to be active, by the way. For performance reasons, it is a good idea to disable the two options winbind enum users
and winbind enum groups
after completing your tests.
More Stable than Winbind: SSSD
System Security Services Daemon (SSSD) presents another option for making accounts from an AD domain available to Linux clients. SSSD makes an AD provider available, which reads the objectSID
attribute of an AD object and uses this to generate a matching POSIX attribute – very much like the rid
in Winbind's idmap
parameter.
The SSSD AD provider works faster and is usually more stable than Winbind; therefore, this configuration is preferable. The prerequisite for the use of the AD provider discussed here (version 1.9), however, is that the client is part of the Windows domain and has a valid Kerberos keytab
file. Winbind is again used for this task.
You can again use the authconfig-tui
tool for configuration. Select LDAP instead of Winbind when configuring the User Information section (Figure 1). Alternatively, you can use the authconfig
command-line tool:
$ authconfig -enablesssd -enablesssdauth \ -enablelocauthorize -enablemkhomedir-update
The three configuration files /etc/krb5
, /etc/Samba/samba.conf
, and /etc/sssd/sssd.conf
then need to be edited manually, as shown in Listings 1, 2, and 3. The prerequisite is that the name server from the Windows domain is used on the client, and that at least SSSD version 1.9.2 is installed on the clients. If Identity Management for UNIX (IMU) is used on the Windows DC, and if the user and group objects in AD thus already have POSIX attributes, disable attribute mapping in sssd.conf
. For this purpose, you use the statement ldap_id_mapping = false
in the domain section.
Listing 3
/etc/sssd/sssd.conf
nonumber 01 [domain/example.com] 02 id_provider = ad 03 [sssd] 04 services = nss, pam 05 config_file_version = 2 06 domains = example.com 07 [nss] 08 [pam]
Then use the following commands to join the client to the domain:
$ kinit Administrator $ net ads join -k
After this step, it should be possible to log in on the client with any account from the Windows domain. You can use SSSD filters to restrict access appropriately.
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
ESET Discovers New Linux Malware
WolfsBane is an all-in-one malware that has hit the Linux operating system and includes a dropper, a launcher, and a backdoor.
-
New Linux Kernel Patch Allows Forcing a CPU Mitigation
Even when CPU mitigations can consume precious CPU cycles, it might not be a bad idea to allow users to enable them, even if your machine isn't vulnerable.
-
Red Hat Enterprise Linux 9.5 Released
Notify your friends, loved ones, and colleagues that the latest version of RHEL is available with plenty of enhancements.
-
Linux Sees Massive Performance Increase from a Single Line of Code
With one line of code, Intel was able to increase the performance of the Linux kernel by 4,000 percent.
-
Fedora KDE Approved as an Official Spin
If you prefer the Plasma desktop environment and the Fedora distribution, you're in luck because there's now an official spin that is listed on the same level as the Fedora Workstation edition.
-
New Steam Client Ups the Ante for Linux
The latest release from Steam has some pretty cool tricks up its sleeve.
-
Gnome OS Transitioning Toward a General-Purpose Distro
If you're looking for the perfectly vanilla take on the Gnome desktop, Gnome OS might be for you.
-
Fedora 41 Released with New Features
If you're a Fedora fan or just looking for a Linux distribution to help you migrate from Windows, Fedora 41 might be just the ticket.
-
AlmaLinux OS Kitten 10 Gives Power Users a Sneak Preview
If you're looking to kick the tires of AlmaLinux's upstream version, the developers have a purrfect solution.
-
Gnome 47.1 Released with a Few Fixes
The latest release of the Gnome desktop is all about fixing a few nagging issues and not about bringing new features into the mix.