Verify Linux client identity through Active Directory (1)

Linux and Windows have been in opposition for a long time and are rapidly developing. Applications in enterprises are gradually divided into two camps. They neither compete nor collaborate with each other. Despite the fierce competition between Windows and Linux, the goal is to provide high-quality, cost-effective IT services for the company. As an enterprise IT manager, one way to achieve this goal is to share ActiveDirectory. Almost all IT organizations use ActiveDirectory to provide authentication services for their Windows desktops and servers. Instead of maintaining a different Authentication Infrastructure (with a set of different usernames and passwords added) for the Linux environment, is it better for Linux computers to adopt ActiveDirectory? This article describes how to achieve this purpose.

Windows Authentication

It has been some time since Windows launched Integrated Network Authentication and a single logon system. Before Windows2000, The WindowsNT Domain Controller (DC) used the nt lan Manager (NTLM) protocol to provide authentication services for Windows clients. Although NTLM is not as secure as originally imagined, it is still very useful. It perfectly solves the need to maintain duplicate user accounts across multiple servers on the network.

Microsoft has moved from NTLM to ActiveDirectory and its integrated Kerberos Authentication Service since Windows2000. Compared with NTLM, Kerberos is safer and more suitable for adjustment. In addition, Kerberos is an industry standard that has long been adopted by Linux and UNIX systems, opening the door for integration with Windows.

Linux Authentication

Linux (and the GNU tools and libraries running on it) was not originally built with a single identity authentication mechanism design philosophy. Therefore, Linux application developers gradually develop a habit of creating their own authentication solutions. They try to achieve this by querying the name and password hash in/etc/passwd, or providing a completely different (and individually) mechanism.

As a result, many authentication mechanisms are generated, so that they cannot be managed. In 1995, Sun proposed a mechanism called "pluggable authentication module" (PAM. PAM provides a set of universal authentication APIs that all application developers can use, as well as backend configured by the Administrator, allowing multiple "pluggable" authentication schemes. By using PAMAPI for authentication and using the Name Server Switch (NSS) API to query user information, Linux application developers can write less code, in addition, the Linux administrator can configure and manage the authentication process from the same place.

Most Linux versions are accompanied by multiple PAM Authentication Modules, including those that support identity authentication for LDAP directories and Kerberos authentication. You can use these modules to authenticate ActiveDirectory, but there are some obvious restrictions.

Samba and Winbind

Samba is an open-source project designed to provide integration between Windows and Linux environments. Samba components allow Linux computers to Access Windows file and print services, and provide Linux-based services to simulate WindowsNT4.0 DC. Using the Samba client component, Linux computers can use the Windows authentication service provided by Windows NT and Active DirectoryDC.

The most interesting part of Samba in this project is Winbind. Winbind is a background program (called a service in Windows) running on the Samba client ), it acts as a proxy for communication between PAM running on Linux computers and NSS and ActiveDirectory running on DC. Specifically, Winbind uses Kerberos to authenticate ActiveDirectory and LDAP to retrieve user and group information. Winbind also provides other services, such as using a function similar to the DCLOCATOR Algorithm in ActiveDirectory to find DC, and using RPC to communicate with DC to reset the ActiveDirectory password.

Winbind solves multiple problems that cannot be solved only by using Kerberos and PAM. Specifically, Winbind does not hard-code the DC for authentication by the PAMKerberos module. Instead, it searches for DNS locating program records to select DC in a way similar to that of the MicrosoftDC LOCATOR module.

Three authentication policies

If LDAP, Kerberos, and Winbind authentication are provided on a Linux computer, we can use three different implementation policies to allow Linux computers to use ActiveDirectory for authentication.

The simplest but least efficient way to use LDAP for authentication using Active Directory is to configure PAM to use LDAP for authentication, as shown in 1. Although Active Directory is a LDAPv3 service, Windows clients use Kerberos (back to NTLM) instead of LDAP for authentication.

LDAP identity authentication (LDAP binding) transmits the user name and password in plaintext over the network. For most purposes, this is not only insecure, but also unacceptable.

Use LDAP to authenticate Active Directory

The only way to reduce the risk of passing creden in plain text is to use SSL-like protocols to encrypt the channel used by clients to communicate with ActiveDirectory. This is absolutely feasible, but it will increase the burden of managing SSL certificates on DC and Linux computers. In addition, the PAMLDAP module does not support changing reset or expired passwords.

Another policy for Linux authentication using LDAP and Kerberos Using Active Directory is to configure PAM to use Kerberos Authentication and NSS to use LDAP to find user and group information, 2. The advantage of this solution is that it is relatively secure and uses the "built-in" function of Linux. However, it does not use the DNS service location (SRV) record published by ActiveDirectoryDC, so you are forced to select a specific set of DC for authentication. It is not intuitive to manage expired ActiveDirectory passwords or to query the nearest member identity.

Use LDAP and Kerberos to authenticate Active Directory

The third method for Linux authentication using Winbind and Active Directory is to configure PAM and NSS to call the Winbind background program. Winbind will use LDAP, Kerberos, or RPC (the most suitable one) to convert different PAM and NSS requests into corresponding ActiveDirectory calls. Figure 3 illustrates this policy.

Use Winbind to authenticate Active Directory

Implementation Plan

Due to the enhancement of integration with Active Directory, I chose to use Winbind on Red Hat Enterprise Linux 5 (RHEL5) for my Linux and Active Directory integration project. RHEL5 is the latest commercial version of RedHatLinux, and it is quite popular in enterprise data centers.

To enable RHEL5 to authenticate Active Directory, You need to perform the following five steps:

· Find and download appropriate Samba and other dependent components.

· Construct Samba.

· Install and configure Samba.

· Configure Linux, especially PAM and NSS.

· Configure Active Directory.

The following sections detail these steps.