Dude, where is my Active Directory ?

Linux for Windows SysAdmins


this article complements A Walk in the Park : migration from Windows to Linux, and Linux for Windows Power Users and would-be SysAdmins


Advanced windows users (power users, sysadmins) may be at a lost the first time they encounter linux, because they try to "translate" what they know from Windows to the Linux environments (and sometimes fail). In order to apply your (Windows) knowledge of system and network administration to Linux, you need to be aware of some major conceptual differences between the two operating systems / environments. In this article, I will share some thoughts on Microsoft Active Directory - and how it appears so mysteriously absent in anything Linux.

If you are (were ?) a Windows Administrator, you may be wondering why Linux, supposedly such a "superior" operating system when it comes to servers and networking, does not have anything similar to Microsoft's Active Directory.
A superficial explanation could be that, in true Microsoft tradition, Active Directory is an agglomerate of functionality and services, all intertwined, interdependent, integrated into 1 huge "can be used for anything and everything" application. This goes very much against the Unix way of "do one thing and do it well". But it goes deeper than that.

To understand the present, we must study the past

Microsoft Windows was born in a tradition of stand-alone personal computers. First there was DOS (MS-DOS, PC-DOS, ...) : a stand-alone, single user operating system. Multitasking was unheard of : 1 user runs 1 program, and that's it. Later, Microsoft added a Window manager on top of it an called it Windows, and at some point added some networking protocols (netbios, smb). The purpose of the networking was to share files between personal computers : Windows for Workgroups. Note the "Workgroups" : no talk of servers - to goal was to be able to access files on someone else's personal computer.

At some point, it seemed advisable to add some security ("share permissions"), and therefore the need for user accounts so that users could be identified and authenticated before you'd let them use files from your personal computer. That was around 1995. For Windows, the main network concept was still the "workgroup" - and by consequence, a user who needed file access on multiple people's personal computer needed to have an account on each of these computers.

This became unmanageable for larger workgroups (e.g. in corporate use), and Microsoft developed a concept that could make management of user accounts easier : the domain, where a domain controller would manage user accounts centrally, in stead of spread out over tens or hundreds of PC's. That was Windows NT4 (also 1995 or so). While originally the NT4 domain was intended to deal with file sharing for authenticated users, Microsoft developed the domain concept further over the following years and by the release of Windows 2000 had added features to manage computers (which required the creation of computer accounts), policy objects as a means to manage user and computer configuration, and so on. All this was incorporated in 1 umbrella structure : the Active Directory.

So, although it is clear that a Microsoft Active Directory is meaningless without network, it is equally clear that the concept is deeply rooted in Windows origins as a stand-alone, single user personal computer and the emerging need to join them in a centralized, managed environment.


By contrast, Linux is a recent re-creation of Unix, and Unix was (is) an operating system meant for "central computers" where (lots of) people would log in to from terminals (roughly : a screen, a keyboard, and a serial cable to the computer). That means that all logged on users would be working "on" that central computer (Maybe you're familiar with Microsoft Terminal Services. It's similar to that - and decades ahead of it). Therefore, Unix had to be a multitasking, multi user system from the start, with security designed in to it (users were limited to access to their home directory and had no access whatsoever to the system itself, that was reserved for 'root'), and very robust (if 1 user ran a program and it crashed, the system shouldn't crash on all other users as well). On a side note : by the time Microsoft started putting MS-DOS on the newly invented PC's (1980, IBM), Unix systems ware running TCP/IP to exchange data and get the internet on the tracks.


Looking at it that way, it is quite clear why Linux doesn't have something similar to an Active Directory and doesn't know the concept of an (Active Directory) "Domain". User accounts were already centralized on the central computer, so there was no need to invent a domain controller. Users only had access to their home directory, not to the system, and the features required to allow them to execute programs were incorporated in the OS and the filesystem, so no need for "Group Policy Objects" to define (i.e. mostly limit) user rights in terms of access to system areas, executables, network neighborhood, and so on. Multiple users used the same computer, so there was no need to develop something like computer accounts and Group Policy Objects to configure individual pc's. Unix is a robust, centralized, managed environment by design, so it didn't require an additional "Active Directory" to configure, manage and maintain it.

But times have changed. Linux runs on personal computers as well, in networked environments. Luckily, most networking technology was invented in the Unix world, and Linux/Unix have a much longer tradition in networked system than Windows has, so while there is no real Linux equivalent to Active Directory, you'll find that there is quite a bit of software that is useful for interconnected computers with lots of users all over the place.

So let's have a look at what Active directory really does, and see how Linux approaches the problem that these Active Directory features try to solve ...

What an Active Directory Domain really ?

# a Directory service

Active Directory is a directory service (that's where it got it's name). In fact Active directory is based on (and more or less compatible with) LDAP (Lightweight Directory Access Protocol). LDAP servers are often used to implement centralized user authentication, organize users in a hierarchical structure (the "Organizational Units" you know from Windows AD) and provide information about users (the "user properties" or attributes). So maybe you'll need to look at some LDAP implementations on Linux. check out OpenLDAP. Novell, networking pioneers of old, had their own Novell Directory Services, (now called eDirectory ) long before Microsoft entered the picture, and it is also available for Linux. Newer developments include Sun's OpenDS, Fedora Directory Serviceand others.

# a means for centralized user management.

Centralized user management : In stead of local user accounts you manage domain user accounts so that you can share resources on multiple computers (domain members) without the need for a local account for every user on every computer. Clearly, a server-based environment would only require user accounts on the server(s), greatly reducing the need for a separate system to centralize user accounts - but it can be an advantage if users need access to multiple servers.

You may want to look for implementations of LDAP and Kerberos. A combination of Samba, Winbind (support for Active Directory Users and Groups in a Linux environment) and Kerberos can be used to "join" a Linux workstation to a Active Directory Domain.

# a means to provide "Single Sign-on"

The idea was that by logging on to a domain, users would have access (provided they were given the necessary rights and permissions) to all resources in the domain : servers and the files thereon, printers, applications, databases, etc - as opposed to having to logon and authenticate separately to each resource, possibly with different user names and passwords, and so on. This would not only require centralized user management and authentication, but also integration of applications into the domain. 2 typical examples are Exchange Server (where the mail account and access to all Exchange's features is directly linked to an AD domain user account) and MS-SQL Server, where you have the choice between managing users in the rdbms itself, or use domain accounts in stead. The latter is called 'AD Integrated mode'.

Although user-friendly and to some extend easier on the sysadmin (less accounts top manage), AD integration poses a severe risk : If the domain goes down, the AD integrated applications are inaccessible. If the domain can not be recovered to a working state, the data may be lost as well, since the access to the data depends on domain accounts - and easy workarounds to this problem would at the same constitute easily exploitable security holes. Recovery of Exchange servers and directory integrated MS-SQL servers are among Windows sysadmins' worst nightmares.

Implementing Single Sign-On, unless you're using a (Terminal) Server with Terminal clients (eg LTSP or Edubuntu), might be quite a challenge (Here's a start). But then, it's also quite a challenge in a Windows environment.

# a means for (policy based) remote configuration (users and computers).

These are the "Group Policy Objects" (GPO's), and I do not know of any Linux counterparts. Probably, this is an example of the Unix legacy, the server-based approach : less to no need for 'remote' configuration. Also, (ordinary, non-admin) Linux users have limited impact on their systems so if computers are configured correctly before roll-out you may need less policy enforcement tools afterward.

Lots of the GPO settings have to do with implementing a security policy and limit what users can do to the system - something Linux achieves natively because its just designed differently from the start. Still, you may need to review your requirements on this one.

Where AD and GPO's are used for configuration of applications and the desktop , a lot of work has been done in the development of (mandatory and/or preferred) configurations of desktops. The gnome desktop, for one, is extremely configurable by means of xml files and templates, allowing for highly configurable desktops and applications - both for mandatory settings and sensible but user-customizable defaults ("preferences"). ( more : Gnome Desktop Configuration Guide, Sabayon : desktop and user profile management)

# a software delivery and remote installation service

Microsoft Active Directory can be used to manage software delivery and remote installation, but similar results can be achieved with a combination of scripting, automated installation procedures and installation from network servers. In fact, Linux pioneered in installation from remote sources (via http, ftp, nfs, ...), for the operating system itself as well as for software, security updates, and patches. At the same time, even in a Windows environment, centralized software management is often implemented by third party applications of Microsoft's own Software Management Server, rather than via Active Directory.

What helps greatly in software and patch management is that (most, if not all) Linux distributions have each their own software repositories on the internet, from which you can easily download and install the operating system itself plus all (free) software that has been compiled for it, plus bug fixes and security updates. So there is no need to create your own distribution points, although you can still choose to cache or mirror the repositories on your local network and add your own, customized and re-compiled versions to it.

Loose ends

roaming profiles, logon scripts, redirected folders etc are often associated with Active Directory, but don't really depend on it or are not really a part of it. They may also not all be required, given that the Linux environment is different from a windows environment and deals with users, profiles, remote file systems and startup and logon procedures differently. Again, you may need to review your requirements. Since most of these features build on file sharing, they can (to some extend) be implemented with Samba.

integration of network services such as dhcp and dns. There is not really a need for these, as modern dhcp and dns implementations offer sufficient configurable options that relay on network parameters - no need for additional domain integration. For example, you can make a dhcp server 'authoritative' to a subnet, not necessarily to a domain. DNS servers are perfectly capable of replicating/synchronising with each other without having to rely on the AD replication mechanisms. Some Windows sysadmins always prefer the native DNS synchronization over AD replication, even in an AD environment.

SAMBA kinda seems to follow the "Windows Server" development by offering additional functionality such as WINS, NT4-style domain controller, AD Domain integration, and so on. AD Domain Controller roles will be next ...

Conclusion

While lots of what Active Directory has to offer is either not necessary in a Linux environment, or can be achieved with a combination of other software, there is no simple "one size fits all" solution. You'll have to rethink your "managed environment" in Linux terms, not just try implementing 'your' Active Directory with Linux software. ( And if you expected to integrate a bunch of Linux desktops in an Windows 2000/2003 Active Directory Domain, you'll have to redo your homework.

On the other hand, a product such as " "Active Directory on Linux" shows that you may "expect the unexpected". Other software vendors (Sun, Oracle, Red Hat, ...) are also actively pursuing (Active) Directory Services.


Koen Noens
January 2007

Interesting Links
Linux File Servers (Samba) in an Active Directory Domain
domain member file server
Domain Controller
Software deployment
WPKG is a software deployment tool that builds on Samba file sharing and domain integration to provide software deployment (.msi, installshield, ...) to Windows clients. It will also let you (remotely / automatically) run scripts on Windows clients, which in turn may be used to write/modify registry keys on the Windows clients. This could be a way to emulate / mimic GPO functionality from a Samba server. See also Real Men Don't Click : scripts and commands for Windows System Administration
"Corporate Ubuntu"
The Ubuntu Community Documentation article Corporate Ubuntu describes how ubuntu can be used as a corporate desktop system. It's oriented towards a thin client setup, but also shows how you could deal with home directories, shared folders, network printing, a standardized desktop environment, and other issues of interest to the corporate sysadmin ...