A Modest Proposal
With this in mind, I set out to accomplish what I considered to be a fairly straightforward goal: Configure the Linux desktops and servers in my office to accept logins using accounts stored in AD. My metrics for success were relatively modest. I wanted to sit down at a Linux desktop, enter a set of Windows credentials, and get a KDE or Gnome desktop with a home directory that has appropriate access permissions.

Achieving this goal turned out to be a bit more challenging than anticipated. After spending lots of time reading through docs and chasing down hints and configuration snippets, I finally found the right combination of settings for all the different Linux flavors in my lab. The results were gratifying, though. I had seamless authentication with AD that could be used for initial login, file sharing, secure shell (ssh) and other network services.

To save you a little time in case you decide to give this interoperability experiment a try, I put together notes and screen shots that show how to configure AD authentication for Fedora Core 2 (and the Core 3 beta). To see examples and instructions for these other Linux flavors: SuSE Linux 9.1 Professional, Mandrake 10.1 and Xandros Desktop 2.5, visit my Web site at www.billboswellconsulting.com/linux-ad.html.

If you're a bottom-line kind of person, here's a quick summary. Xandros 2.5 has the slickest AD configuration of the bunch. Mandrakelinux and Fedora are fairly simple once you know where to add a few settings. SuSE required the most work, but Novell should have this corrected in Novell Linux Desktop.

In the examples here, I used a Windows Server 2003 domain called Company.com, flat name COMPANY. I retained the default Windows 2003 security settings, including SMB signing, LDAP signing and anonymous logon restrictions. I set the domain and forest functional level to Windows Server 2003 and left the Authentication Users group in Pre-Windows 2000 Compatible Access, the default Windows 2003 setting.

I installed Fedora Core 2 with the Workstation package options. During setup, I assigned a unique computer name of Fedora.company.com. Following the installation, I updated all packages using Yum, the Yellowdog Updater, Modified. (Other Linux flavors use different package managers.)

Initial Configuration
Regardless of Linux flavor, you'll work with the same elements when configuring AD authentication:

• Name Service Switch (NSS): This is a set of capabilities built into the Linux C libraries that allow an application to select a source to validate authentication credentials.
• Pluggable Authentication Modules (PAM): This extends the standard Unix password authentication mechanism to include central authentication databases such as LDAP, Kerberos, AD and so on.
• Winbind with Samba: The winbind service uses Samba for configuration information. For AD interoperability, make sure your system is running a current version of Samba (3.05 or newer).
• Kerberos: Winbind uses Kerberos to get tickets for accessing AD. A Windows domain controller acts as the Key Distribution Center (KDC).

To configure winbind in Fedora, launch the authconfig utility (see Figure 1) as superuser (root). Fedora has a GUI utility—system-config-authentication—but it doesn't make all the required configuration settings.

Figure 1. A Fedora authconfig utility showing the User Information screen. (Click image to view larger version.)

Check the Use Winbind option, then click Next. The Winbind Settings screen opens (Figure 2.) Fill in the following settings (the entries you make in this screen aren't case sensitive):

• Security Model: ADS
• Domain: flat (NetBIOS) name for the domain (COMPANY)
• Domain Controllers: Fully Qualified Domain Name (FQDN) for a domain controller (dc1.company.com)
• ADS Realm: FQDN for the domain (company.com)
• Template Shell: /bin/bash

Figure 2. If you use Samba, this is the Winbind Settings screen in authconfig. (Click image to view larger version.)

There's a Join Domain option, but don't select it. It might not work, and you won't get sufficient feedback to help resolve problems. For now, just click OK to save the changes you just entered.

When the authconfig window closes, the console window should show that winbind starts. If this fails, try starting the service manually with the following command:

/etc/init.d/winbind start

If winbind starts, it will appear on a ps process list like this:

# ps -A | grep winbind
3132 ? 00:00:00 winbindd
3133 ? 00:00:00 winbindd

If you get an error, search the Internet with the error message. It may take a while, but nearly always someone with a similar error will have posted a solution.

Configuration Files
Authconfig makes changes to three configuration files. Listings 1-3 show their contents, with comments and irrelevant information removed.

• nsswitch (/etc/nsswitch.conf): The critical entries are passwd and group. Other Linux flavors don't bother assigning winbind to other services.
• system-auth (/etc/pam.d/system-auth): PAM uses a stackable authentication scheme, and each element in the stack must be separately configured. Thankfully, authconfig does a good job of setting up system-auth. Otherwise, you have to do quite a bit of experimenting.
• smb.conf (/etc/samba/smb.conf): The idmap entries are important because winbind uses them to maintain a correspondence between AD account names and the User IDs and Group IDs used by Linux. Fedora assigns a large range of potential IDs. Typically, other Linux flavors assign a range of 10000-20000.

Also, in smb.conf, note the home directory path inserted by authconfig, /home/%D/%U. A user, call him winuser1, from an AD domain, call it company.com, would get a home directory path of /home/COMPANY/ winuser1. Authconfig does not create the domain folder under /home. You must create it manually.

Joining an AD Domain
You can now join the Linux workstation to the AD domain using the Linux net command. Here's the syntax, with everything after the first line generated by net:

# net ads join -U administrator
administrator's password:
Using short domain name -- COMPANY
Joined 'FEDORA' to realm 'COMPANY.COM'

You'll see many different syntax examples for net ads if you browse the Internet. My example shows the bare minimum, which is all you really need.

Configure PAM
At this point, a Windows user trying to authenticate at the Linux desktop would get a series of errors because a local home directory isn't present. A PAM module—mkhomedir.so—automatically creates a home directory. To include this module as part of the login process, change two configuration files under /etc/pam.d (see Listings 4 and 5):

• login: This file controls authentication from a console prompt.
• gdm: This file controls login from a graphical screen.

Always make copies of the original files before changing PAM files. You can lock yourself out of a system if you aren't careful.

After changing the PAM files, restart the desktop. This is a quick way to ensure that authconfig made the correct boot settings for the required services.

At the login window following restart, Fedora prompts for a name. Enter the Windows account name in domain\user format, such as company\winuser1, then enter the password when prompted. (Other Linux flavors present a selection list of Windows accounts. The option to display a selection list is available in Fedora, but it is not the default setting.)

You can configure smb.conf so that you don't need to enter a domain name, which is fine if you have one AD domain but a little cumbersome if you have several.

At this point, when the login succeeds, you'll get an announcement about creating a home directory for the user. The permissions assigned to the home directory use the AD account of the user.

Rock On
If you can't get the steps to work, e-mail me with the particulars. This can be a finicky configuration, and you want to make sure you're in the right state of mind. During the testing I did for this column, I played Jeff Beck's album, You Had It Coming. I found track six, "Loose Cannon," especially good when setting PAM files. Give it a try.

Contributing Editor Bill Boswell, MCSE, is the principal of Bill Boswell Consulting, Inc. He's the author of Inside Windows Server 2003 and Learning Exchange Server 2003 both from Addison Wesley. Bill is also Redmond magazine's "Windows Insider" columnist and a speaker at MCP Magazine's TechMentor Conferences. You can contact Bill about "Linux-Windows Single Sign-On" at boswell@101com.com.