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).

Figure 1: In the Authentication Configuration window, select Winbind and Kerberos.

Figure 2: The Kerberos configuration points to your Windows domain controller.

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.

Figure 3: To finish up, select the ADS security mode in the Winbind-template-based configuration.

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.

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.