It departments charged with integrating Linux clients among the Windows desktops they're running can make life easier by administering Linux user accounts with Microsoft Corp.'s Active Directory. Samba, the open-source project for providing Windows-compatible file and print services, makes this possible, but it doesn't make it easy.

After some time spent consulting documentation and tweaking configuration files, eWEEK Labs recently set up a Red Hat Inc. Fedora Core 2 Linux system so that it authenticated reliably with a Windows 2003 domain controller using Samba 3.03. (Each distribution that ships with Samba requires slightly different steps to enable Active Directory authentication.)

Click here to read eWEEK Labs' review of Fedora Core 2.

The sometimes-rocky process we went through to configure the systems is detailed below.

We set up a Windows Server 2003 machine with all the latest patches applied and configured with Active Directory Domain Controller and DNS (Domain Name System) server roles. On the client side, we set up a Fedora Core 2 system with all the current updates installed.

For reference, we used the Official Samba-3 HowTo and Reference Guide (available online at http://samba.org/samba/docs/man) and the book "Samba-3 by Example," along with some assorted Google searches.

We first installed the Samba packages KRB5-workstation, Samba-Client and Samba.

Next, we used neat (the Red Hat network configuration client) to make our Windows system the DNS server for our Fedora client. This allowed the client to properly resolve the arbitrary name we'd given our server. We used a Red Hat setup tool, authconfig, to enable winbind, a Samba service for resolving user and group information from Windows servers.

In addition to starting the winbind service, authconfig makes most of the modifications required for the smb.conf configuration file.

Fedora Core 2 includes a nicer-looking version of authconfig called system-config-authentication, but we found during tests that we had to run system-config-authentication twice to get it to save all of the information we'd entered—a bug that caused quite a bit of confusion during testing.

We selected "use winbind" in the authconfig tool and hit "next" to enter our server information. Authconfig includes a button for joining a domain. When the button was selected, we were prompted for a user name and password with administrator rights on our Windows server.

If a join is successful, there will be a confirmation in the terminal window after closing authconfig. If you don't see this, something is amiss. If there is a problem and the server information settings entered in winbind are correct, there may be too much of a discrepancy between the client's and server's clocks.

To log on to our client system via a user account from our Windows server, we had to adjust a few of the PAM (pluggable authentication module) files on the client system. (To download these files, click here.)

The file system-auth needs to be adjusted to enable authentication through winbind, and the gdm and log-in files must be modified to create a home directory for new users automatically when they first log in.

A last piece of advice: Be sure to back up your PAM files before modifying them. More than once during testing, we had to boot with a rescue CD to restore our working PAM files.

Senior Analyst Jason Brooks can be reached at jason_brooks@ziffdavis.com.

Check out eWEEK.com's Linux & Open Source Center at http://linux.eweek.com for the latest open-source news, reviews and analysis.

Be sure to add our eWEEK.com Linux news feed to your RSS newsreader or My Yahoo page

PAM files

ftp://ftp.eweek.com/pub/eweek/pdf/printpub/Labs/system-auth
ftp://ftp.eweek.com/pub/eweek/pdf/printpub/Labs/gdm
ftp://ftp.eweek.com/pub/eweek/pdf/printpub/Labs/login
ftp://ftp.eweek.com/pub/eweek/pdf/printpub/Labs/smb.conf