Can Linux Desktops Live in an Active Directory World?

Why Does Active Directory Matter?
It still causes me uncomfortable dispepsia to admit that Microsoft’s directory coup worked so well. Since Windows desktop systems are so challenging to own without it, Microsoft succeeded at pushing Active Directory into wide deployment in the business world. As advocates for desktop Linux promote fitness and readiness for use in the business world, few seem to surmise what a strong fortress Microsoft has built around Windows. It’s not just about the platform; the enterprise infrastructure matters, too. When it comes to business information technology, the subtext beneath “just replace the desktops of the types of user for whom Linux is ready” reads “change your management system for all these user’s desktops, too.” Such a proposition is unsavory to the already change-averse IT culture.

What does Active Directory for Windows desktops? For brevity’s sake, let me risk over-summarizing. (I’ll suffer corrections in comments on this post.) Active Directory is more than mere authentication for users. It represents desktop systems as known objects for increased security and management purposes. For laptops (which I generalize here as a type of desktop), it provisions user accounts to locally for offline use. It provides basic application deployment, standardizes system configurations, and locks down user interfaces through Group Policy Objects. Lastly, it issues Kerberos tickets to enable single sign-on to enterprise applications.

So, what’s the net for desktop Linux in the business world? Essentially it’s that any benefits that Linux desktops might provide in lowered licensing costs, increasing security, and so on, are quickly offset if it means bucking the established security and management model. Businesses that use Active Directory for managing Windows desktop systems–and there are a lot of them–don’t have to be Microsoft adherents to resist adopting desktop Linux desktop.

Samba and SUSE Linux Enterprise Desktop

A lot of thinking and research went into the creation of SUSE Linux Enterprise Desktop in order to ensure that it could penetrate the Active Directory fortress and provide real business value. SUSE engineers Guenther Deschner and Lars Mueller focused intensely (over 14K lines of code) on adding Active Directory capabilities into Samba.

Here’s the short list of what they made accomplished, all with no configuration changes required to the Active Directory system:

• Linux desktops can join Active Directory, becoming actual objects within an Active Directory domain (as workstation objects)
• Users can authenticate using their Active Directory credentials
• Proper interfaces present to the user according to Active Directory password policy (such as password has expired, do you want to change, and failed attempt due to login time restrictions)
• Account credentials are securely cached for offline use (a requirement for mobile users)
• Active Directory-based single sign-on works (Kerberos tickets are requested, renewed and refreshed automatically)

Again I summarize, and perhaps too much. For a more thorough and adept introduction, Novell Open Audio presents an interview with Lars Mueller.

Supplementary Screen Shots

To augment and illuminate Lars’ just-released Novell Open Audio interview, here are some screenshots Lars and I did together while at the SUSE Labs Conference in the Czech Republic.

Installation

Installation Change for Better Networking
One of the base changes to installing SUSE Linux is that the installer no longer uses the generic default system name of “LINUX.” Instead, the installer appends a random four-character string to each machine name. Although the team originally implemented this to avoid naming conflicts when joining Active Directory, it is very helpful in Dynamic DNS and simple WINS environments, too.

Defining the Authentication Source During Install
At the end of the SLED10 installation process, you can define the install source as “Windows Domain” in order to join an Active Directory Domain.

Install: Specifying the Which Domain
If you choose to use a Windows Domain as the workstation’s install source, you will need to specify which domain to join. This interface is also where you specify whether to create a local home directory when a local user is created from the Active Directory domain, as well as whether to allow the locally-created user account to authenticate when the domain cannot be reached.

Install: Authorizing the Domain Join
Of course, in order to join the domain and create the workstation object, you need to authenticate using an Active Directory user account that has appropriate permissions.

Install: Confirmation for Successful Domain Join
It’s always nice to know whether something has worked.

SLED10 System Viewed in the Microsoft Management Console
It’s always nice to know whether something has worked. So here are thumbnails of the MMC interface before and after the above process has been done, showing that the workstation object has been created in the domain.

<- Before & After ->

Options for Already-Installed System

Enabling Through YaST on an Already-Installed System
This the management console interface for configuring a SLED10 workstation to use Active Directory for authentication. In it, you can see where to configure the AD domain name, whether to create a home directory on the server, and whether to cache credentials for offline use. Next steps after this one are the same in the installation steps shown above. (Click the image to embiggen.)

What the User Sees

The SLED10 Login Interface for Active Directory
When a user wants to log in to her workstation, she has a new “Domain” option. We show it here with the Domain drop-down activated so you can see where other Active Directory domains would show up, as well as how a user can select <local> for offline or local (/etc/passwd) accounts. This screenshot shows KDE’s login interface (kdm). Gnome’s is very similar. (click the image to embiggen)

Change Password at Login
If the user account setting is flagged “Change Password at Next Login,” the user will be prompted with an appropriate interfaces.

Kerberos Ticket Example

Service Ticket
Part of logging on to Active Directory includes the issue of a Ticket Granting Ticket, or TGT, for the user’s login session. The TGT essentially does what it’s name implies: it’s a Kerberos ticket used to request other types of Kerberos tickets, primarily Service Tickets. When you have a valid TGT and try to access a Kerberized service, which includes most *NIX-hosted applications and, more recently, most Windows Server applications that use Active Directory. This is how enterprise single sign-on is enabled for Windows clients–an advantage that few Linux advocates understand Windows has traditionally held over Linux on the business desktop.

The utility klist provides a quick look at the Kerberos ticket cache on a linux system. In the screenshot below, the console window in the back shows that we used klist to show our current tickets, including the TGT (listed as “krbtgt”) and our host ticket. There are no Service Tickets in the cache. We then used Firefox to open Outlook Web Access, which did not prompt us to log on because the Active Directory-based Kerberos system allowed the workstation to request and receive the Service Ticket for Outlook WebAccess. This is shown in the console window in the front as the new HTTP item in the klist output.

If you find this article interesting, please Digg it.

Addenda:

• Steven J. Vaughan-Nichols adds some good details in his related article
• Ireland’s Jorge O’Castro weighs in regarding relevance to Ubuntu
• Gizbuzz has posted the first SLED10 review that mentions AD integration
• Hay un pequeno version in espanol
• Et il y’a une petite version en francais, aussi

Read of my articles on desktop Linux advocacy and execution.