Windows And Linux Integration Hands-on Solutions for a Mixed Environment - 2005 publication.

Overview

In the last chapter, we talked about using Linux to house the user accounts. When our Windows or Linux clients logged on, they had three ways of getting authenticated on the network:

• NIS server Old and crusty, but still in heavy use. There are native NIS clients on Linux, and third-party NIS clients for Windows.

• OpenLDAP server Offers much better security and the potential for a hierarchical namespace. Again, there are native OpenLDAP clients on Linux and third-party add-in LDAP clients for Windows.

• SAMBA server Allows Windows clients to authenticate to Linux servers without third-party software on the client. In one scenario, we built this on top of our OpenLDAP server. This gave us the best of both worlds . Linux clients authenticated directly to LDAP, and unmodified Windows clients authenticated to Samba. In an alternative scenario, we configured Samba without OpenLDAP. Samba without OpenLDAP is an acceptable solution when all clients run Windows and the network is not expected to grow to a size that requires backup domain controllers.

In this section, we'll turn the tables a bit. We'll use Active Directory as the "go to" place to authenticate our users. We'll do so in two major ways:

• We'll use Active Directory out of the box. Here, we'll have both native XP clients authenticate directly to Active Directory (easy!), as well as Linux clients authenticating directly to Active Directory. We'll do it using only the tools contained within Windows and Linux. This is called the Winbind method.

• We'll extend Active Directory to house special Linux user and group data with Microsoft's "Services for Unix" toolkit. Then we'll contact Active Directory via LDAP but ultimately authenticate using Kerberos.

We'll also explore some third-party tools which make this whole business easier. These tools hook into both Active Directory and Linux to help them talk more easily.