Professional Documents
Culture Documents
aspx
Interop
Authenticate Linux Clients with Active Directory
Gil Kirkpatrick
At a Glance:
Contents
Windows Authentication
Linux Authentication
Samba and Winbind
Three Authentication Strategies
Our Implementation Plan
Finding the Right Software
Building Samba
Configuring Linux Networking
Configuring Linux Time Synchronization
Configuring PAM and NSS
Installing and Configuring Samba
The ID Mapping Problem
Joining the Domain and Logging In
What if It Doesn't Work?
Now that It Works, What Do You Have?
Third-Party Solutions
Republicans and Democrats. Toothpaste and orange juice. Linux and Windows. Some things just dont mix, right? Every IT shop Ive ever been involved with has been divided into
two camps: the Windows team and the Linux team. They dont really compete with each other, but they sure don't collaborate either. In fact, some places even go so far as to put
a yellow line on the floor just to make absolutely sure that there's no inappropriate fraternization between the two groups.
I'm a Windows guy, and I've certainly poked fun at my Linux-oriented colleagues, but we all have the same goal of providing high-quality and cost-effective IT services to the
organization. One way we can do that is by sharing core software infrastructure like Active Directory. Just about all IT organizations have settled on Active Directory to provide
authentication services to their Windows desktops and servers. Instead of maintaining a separate authentication infrastructure for the Linux environment (along with a separate
set of user names and passwords), wouldn't it be better if the Linux computers used Active Directory as well? I think it would, and I'll show you how to do it in this article.
Windows Authentication
Windows has shipped with an integrated network authentication and single sign-on system for quite some time now. Before Windows 2000, Windows NT domain controllers
(DCs) provided authentication services to Windows clients using the NT LAN Manager (NTLM) protocol. Although NTLM was not as secure as was originally thought, it was very
helpful because it neatly solved the problem of needing to maintain duplicate user accounts across multiple servers on the network.
Starting with Windows 2000, Microsoft moved from NTLM to Active Directory and its integrated Kerberos authentication services. Kerberos was considerably more secure than
NTLM, and it scaled better, too. And Kerberos was an industry standard already used by Linux and UNIX systems, which opened the door to integrating those platforms with
Windows.
Linux Authentication
Originally, Linux (and the GNU tools and libraries that run on it) was not built with a single authentication mechanism in mind. As a result of this, Linux application developers
generally took to creating their own authentication scheme. They managed to accomplish this by either looking up names and password hashes in /etc/passwd (the traditional
text file containing Linux user credentials) or providing an entirely different (and separate) mechanism.
The resulting plethora of authentication mechanisms was unmanageable. In 1995, Sun proposed a mechanism called Pluggable Authentication Modules (PAM). PAM provided a
common set of authentication APIs that all application developers could use, along with an administrator-configured back end that allowed for multiple "pluggable"
authentication schemes. By using the PAM APIs for authentication and the Name Server Switch (NSS) APIs for looking up user information, Linux application developers could
write less code, and Linux administrators could have a single place to configure and manage the authentication process.
Most Linux distributions come with several PAM authentication modules, including modules that support authentication to an LDAP directory and authentication using Kerberos.
You can use these modules to authenticate to Active Directory, but there are some significant limitations, as I will discuss later in this article.
Figure 1 Aut hent icat ing t o Act ive Direct ory using LDAP (Click the image for a larger view)
The only way to mitigate this risk of passing credentials in the clear is to encrypt the client-Active Directory communication channel using something such as SSL. While this is
certainly doable, it imposes the additional burden of managing the SSL certificates on both the DC and the Linux machine. Furthermore, using the PAM LDAP module does not
support changing reset or expired passwords.
Using LDAP and Kerberos Another strategy for leveraging Active Directory for Linux authentication is to configure PAM to use Kerberos authentication and NSS to use LDAP to
look up user and group information, as shown in Figure 2. This scheme has the advantage of being relatively more secure, and it leverages the "in-the-box" capabilities of Linux.
But it doesn't take advantage of the DNS Service Location (SRV) records that Active Directory DCs publish, so you are forced to pick a specific set of DCs to authenticate to. It also
doesn't provide a very intuitive way of managing expiring Active Directory passwords or, until recently, for proper group membership lookups.
Figure 2 Aut hent icat ing t o Act ive Direct ory using LDAP and Kerberos (Click the image for a larger view)
Using Winbind The third way to use Active Directory for Linux authentication is to configure PAM and NSS to make calls to the Winbind daemon. Winbind will translate the
different PAM and NSS requests into the corresponding Active Directory calls, using either LDAP, Kerberos, or RPC, depending on which is most appropriate. Figure 3 shows this
strategy.
Figure 3 Aut hent icat ing t o Act ive Direct ory using Winbind (Click the image for a larger view)
1. Locate and download the appropriate Samba and other dependent components.
2. Build Samba.
3. Install and configure Samba.
4. Configure Linux, specifically PAM and NSS.
5. Configure Active Directory.
The next few sections in this article describe these steps in more detail.
out with a complete working operating system, but the packages that are preinstalled sometimes conflict with software you wish to install later.
I did not include Samba when I installed Red Hat (normally Samba is installed by default) because I wanted to use a more current version. However, the newer version of Samba
requires new versions of several other libraries and utilities that were already installed. These sorts of dependency problems are quite annoying, but they are easily solved using
the RPM.
There are many Web sites that host binary RPM packages. The one I used (for no other reason that it was the first one I found) is called PBONE, located at rpm.pbone.net. It has a
convenient way of searching for packages and had all the binaries that I needed for my CPU architecture (i386) and operating system distribution (Red Hat Enterprise Linux
5/Fedora 7&8).
I had to download and update the packages listed in Figure 4 to build and install the latest 3.0 version of Samba (there is an even later 3.2 version tree that I have not tried).
Note that these packages target the Fedora Core (fc) distribution. Red Hat is based on the same sources Fedora uses and is completely interoperable with it. Packages built for
Fedora Core 7 and later will run on RHEL5 with no modification. Place the downloaded RPM files in the /usr/src/redhat/RPMS directory.
Building Samba
The first step in building Samba is to download the proper source RPM. I downloaded the source RPM for Samba 3.0.31 from the PBONE site. Next, place the downloaded source
RPM file in /usr/src/redhat/SRPMS; this is the standard directory for source RPMs during the build process.
Open a terminal session (command-line window in Windows parlance) and move to the SRPMS folder. Once that is done, install the source package using the command, as
shown in Figure 5.
Figure 5 Inst alling t he Samba source RPM (Click the image for a larger view)
If you see the error warning "user mockbuild does not existusing root," don't worry. This error indicates that the Mock build utilities aren't installed. The build process will work
without them.
Next, move to the /usr/src/redhat/SPECS directory and edit the file SAMBA.SPEC, which contains the Samba build options. Search for the line that starts with "CFLAGS=", and
make sure the option "--with-shared-modules=idmap_ad,idmap_rid" is present. This option ensures that the build process will include the code that translates Linux UIDs (unique
identifiers) properly to Active Directory. Figure 6 shows this option.
Figure 6 The wit h-shared-modules build opt ion (Click the image for a larger view)
Next, you may have to update some of the libraries on your machine to properly build and install Samba; it depends on what versions of the libraries you happen to have
installed. In my case, I had to install the packages listed in Figure 4 using the rpm --install command; in some cases I had to use the --force option to get past some of the
dependency problems.
To build Samba, move to the /usr/src/redhat directory and run the command rpmbuild bb SPECS/samba.spec, as shown in Figure 7. The process will leave a new samba-
3.0.31-0.i386 RPM file in the /usr/src/redhat/RPMS directory. We will install this RPM file later in the project.
Figure 7 Creat ing t he Samba binary RPM f ile (Click the image for a larger view)
Figure 8 Conf iguring t he net work (Click the image for a larger view)
Next, ensure that the DNS resolver for the Linux machine is set to use the same DNS name server that your DCs use; in the majority of cases, this is a DC in the domain to which
you want to join the Linux machine, assuming you are using Active Directory-integrated DNS. You configure the DNS resolver on the DNS tab of the same Network configuration
utility you used to configure the network, as shown in Figure 9.
Figure 9 Set t ing t he primary DNS resolver (Click the image for a larger view)
Finally, once you have completed those steps, you must set the host name of the Linux computer to reflect its name in the domain. Even though you can set the host name using
the Network configuration app, this doesn't seem to always work properly.
Instead, edit the /etc/hosts file directly, and add an entry below the localhost.localdomain entry that has the form <ip address> <FQDN> <host name>. (An example would be
"10.7.5.2 rhel5.linuxauth.local linuxauth".) I should note that failure to do this will result in the creation of an incorrect computer object in the directory after you join the Linux
computer to the domain.
Figure 10 Conf iguring t he Net work Time Prot ocol (Click the image for a larger view)
Figure 11 PAM conf igurat ion f ile f or Gnome Deskt op M anager (Click the image for a larger view)
Each entry in a PAM configuration file has the form <management group> <control> <module> <parameters>, where <management group> corresponds to the facility the
configuration entry pertains to: auth, account, password, or session. The control keywords, which are described in Figure 12, tell PAM how to process the configuration entry. The
third column of the file contains the name of a PAM shared library in the /lib/security directory. Shared libraries contain dynamically loadable executable code, similar to DLLs in
Windows. Additional terms after the module name are parameters that PAM passes to the shared library.
Required If the module succeeds, PAM continues evaluating the remaining entries for the management group, and the results will be determined by the results of the
remaining modules. If the module fails, PAM continues evaluation but will return failure to the calling application.
Requisite If the module succeeds, PAM continues evaluating the management group entries. If the module fails, PAM returns to the calling application with no further
processing.
Sufficient If the module succeeds, PAM will return success to the calling application. If the module fails, PAM continues evaluation, but the results will be determined
by subsequent modules.
Optional PAM ignores the results of the module unless it is the only module specified for the management group.
Include PAM includes the contents of the referenced PAM configuration file and processes the entries it contains.
You can see that each management group has several entries. PAM processes the entries in order by calling the named module. The module then returns either success or failure,
and PAM proceeds according to the control keyword.
You'll notice that the PAM configuration file for GDM includes system-auth in all of its management groups. This is how PAM establishes default authentication behavior for
GDM. By modifying system-auth, you can modify the authentication behavior for all of the applications that include the system-auth file in their PAM configurations. The default
system-auth file is shown in Figure 13.
Figure 13 PAM syst em-aut h f ile (Click the image for a larger view)
The Name Service Switch (NSS) module hides the specifics of system data storage from the application developer, in much the same way that PAM hides the details of
authentication. NSS lets the administrator specify the way system databases are stored. In particular, the administrator can specify how user name and password information is
stored. Because we want applications to look up user information in Active Directory using Winbind, we have to modify the NSS configuration file to show that.
Red Hat includes a little graphical applet for configuring PAM and NSS called system-config-authentication. It takes care of most (but not all) of the changes you need to make to
the system-auth and nss.conf files.
Run the system-config-authentication application and you will see a dialog like the one shown in Figure 14. Check the Winbind option on both the User Information tab (which
configures the nss.conf file) and the Authentication tab (which modifies system-auth file).
Figure 16 Creat ing a home direct ory f or users (Click the image for a larger view)
Figure 17 Act ive Direct ory ID mapping (Click the image for a larger view)
The only downside to Active Directory ID mapping is that we have to provide a mechanism to ensure that every user and group has an identifier, and that these identifiers are all
unique in the forest. See the sidebar, "Configuring Active Directory for Active Directory ID Mapping," for more information.
Happily, there is another ID mapping strategy that has a lot less administrative overhead. Recall that the Windows SID uniquely identifies the user within a domain as well as the
domain itself. The portion of the SID that uniquely identifies the user within the domain is called the Relative Identifier, or RID, and is in fact a 32-bit integer. So, Winbind can
simply extract the RID from the SID when the user logs in and then use the RID as the unique internal UID. Winbind refers to this strategy as RID mapping, or idmap_rid. Figure
18 illustrates how RID mapping actually works.
Figure 19 Specif ying t he name of t he home direct ory (Click the image for a larger view)
The net command will prompt you for the user's password. If everything works properly, the net command will join your machine to the domain. You can use Active Directory
Users and Computers to locate the newly created computer account.
You can test the state of the join using the Winbind test tool called wbinfo. Running wbinfo t will test the trust relationship between the machine and the domain. Running
wbinfo u lists all the users in the domain, and wbinfo g lists all the groups.
If you successfully join the Linux machine to the domain, the next step is to try to log in using an Active Directory user account and password. Log off the Linux machine, and log
in using an Active Directory user name. If everything works properly, you should be able to log in.
Configuring Active Directory for Active Directory ID Mapping
This information applies only if you're using Active Directory ID mapping. If you've decided to use RID mapping, feel free to skip this sidebar.
Before you can start logging in to your Red Hat server using an Active Directory account, you have to make some changes to Active Directory itself. First, the Active Directory
schema has to accommodate the attributes that Winbind uses to store user information. If you are running Windows Server 2003 R2, the schema is ready to go. If you have an
earlier version of the Active Directory schema, you will have to extend it using the Microsoft Services for UNIX (SFU) package.
You can find more on Services for UNIX on TechNet. SFU also includes an additional property page for the Active Directory Users and Computers Microsoft Management
Console (MMC) snap-in that lets you manage the user ID and group ID information that Linux requires.
Once the schema is properly set up, you have to provide Linux identifiers for all of the users (and the groups to which they are members) that might log in to your Linux machine.
This means that you have to define values for the uidNumber and gidNumber attributes for the users and groups that might log in to your Linux machines. But you should be
aware of some requirements for these attributes:
1. Linux requires a UID for every user that authenticates. Because you want to manage user information in Active Directory, every user account that will log in to a Linux
machine must have a unique uidNumber attribute. The specific value you use for a uidNumber isn't important, but it must be unique across all the users that might log in
to the Linux machine.
2. Every Linux user must also have a default group identifier, so each Active Directory user that will log in to a Linux machine requires a value for the gidNumber attribute as
well. This value doesn't have to be unique among users, but it must uniquely identify the group.
3. Every group in Active Directory should have a unique value for its gidNumber attribute. Strictly speaking, it's OK for groups to not have a value for the gidNumber
attribute, but Winbind expects, when it authenticates a user, that every group to which that user is a member will have a unique gidNumber value. It's probably easiest just
to make sure that every group has a unique gidNumber value.
4. Winbind expects that every user it looks up in Active Directory is a member of the Domain Users group, so it also expects that the Domain Users group has a value for its
gidNumber attribute.
Third-Party Solutions
Authenticating Linux machines with Active Directory is clearly A Good Thing, but rolling your own solution using Samba Winbind is tedious if not downright painful. You would
think some innovative software vendors would step up with an easier-to-use solution, and you would be right.
There are four commercial software vendors that have developed easy-to-install-and-use versions of what I've demonstrated in this article. They provide the code and migration
tools for nearly every popular version of Linux, UNIX, and Apple Macintoshes, as well as support for managing Linux machines using Group Policy.
The four companies are Centrify , Likewise Software, Quest Software and Symark . All four vendors provide similar functionality, including Group Policy management, across a
wide array of Linux distributions. Likewise Software has recently open-sourced its implementation, called Likewise Open, although its Group Policy component remains a
commercial product. Likewise Open will be available with several major Linux distributions. (Full disclosure: while in the process of writing this article, my company, NetPro, was
acquired by Quest Software.)
Does it make sense to build your own authentication system using Samba and Winbind when there are commercial options available? If spending money on integration software
isn't in the budget, then going the open-source route with Samba has the advantage of being free. You also get all the source code, which can be a compelling benefit. But
migrating existing Linux machines and their existing UIDs is a very thorny problem.
On the other hand, if you want to save installation and implementation time, you have existing Linux machines you need to migrate, or you would rather have someone to call for
an authoritative answer to your question, then checking out one of the commercial solutions makes sense. And if you need Group Policy management, then the commercial
alternative is your only choice.
But whichever way you go, integrating Linux authentication with Active Directory reduces the effort you spend managing multiple user accounts, improves system security, and
provides you with a single identity store to manage and audit. And those are all pretty compelling reasons to give it a try.
Gil Kirkpat rick has designed or developed dozens of successful commercial software products in his 30-year career, and he is the founder of the Directory Experts Conference
(now called The Experts Conference). Gil is the author of Active Directory Programming and is a frequent contributor to Windows IT Pro and TechNet Magazine. In his current role
as Expert-in-Residence at NetPro (now part of Quest Software), Gil consults on various security, identity, and marketing projects and speaks at technology seminars and
conferences around the world.
2016 Microsoft