I've written before about how Active Directory handles two basic functions: directory lookup (which Linux handles with an implementation of LDAP, such as OpenLDAP) and user authentication, which is done through Kerberos.
So when you're moving from AD, the most important thing to consider is the scope of the migration -- not just in the sense of how many machines or servers, or how big a directory, but what jobs the new directory is going to take. Are you going to be migrating to a new groupware mail system, where you might want to preserve much of the same user metadata that was in AD, or are you simply performing simple user authentications?
Work in parallel
With a little work, you can set up your Windows Active Directory box as an LDAP server and authenticate your Linux machines against it. Then you can leave your existing AD environment in place and continue to use it while you set up a new Linux-only user directory in parallel for a gradual migration.
To authenticate Linux against AD, you'll need to set up the Linux machine with a Kerberos client, which is included and available by default in many Linux distributions in the form of a PAM (pluggable authentication module). The only information you need to authenticate, aside from the username and password, is to use the domain name as the default domain and realm. Use the fully qualified domain name of the AD server as your KDC server address.
Here's one example of how to do this in SuSE Linux 9.1; thanks to the configuration GUI for the Kerberos client, the whole process is trivially easy.
Some more manual configuration is needed for individual applications that use Kerberos. If you want to perform more sophisticated work other than basic user authentication, you'll need to install Microsoft Services for Unix on the Windows server; here's an example for how this works with Red Hat's Fedora Core 1 as the Linux client.
One fell swoop
The second method is to export user information from Active Directory and re-import it into an LDAP repository on Linux. This is where things can get potentially complicated, mainly because of proprietary schema extensions and privilege separation.
Proprietary schema extensions are additions to the schema (or the Active Directory database) that are typically created and used by applications. Active Directory supports a whole slew of custom schema extensions that aren't replicated in LDAP by default.
Most of these extensions, however, are application-specific; Microsoft Exchange is the most obvious example. If you're planning to move from AD and you have a number of existing applications that rely on it, work on replacing the applications first, since they will constitute the biggest hurdle. Exchange could be swapped with Open-Xchange, for instance, which has an Exchange migration tool available.
Privilege separation is how Active Directory lets you divide up users into groups and hierarchies. This is function is native to AD itself, as well as the rest of Windows; for instance, the whole concept of a "Backup operator" or "Power user" is not something you find in Linux (or Unix at large).
One of the most common non-administrative scenarios for user groups is, again, Microsoft Exchange; if you're migrating from that to something else, make sure what you're migrating to has some native way to replicate that functionality. Privilege separation and user roles in Linux are handled more by the apps you're using than by any kind of native mechanism in the OS.
If you're not locked into any particular set of applications and just want to move user account information, that's easy enough. Tobias Rice's AD to LDAP HOWTO provides a simple and direct way to migrate user password information from Active Directory into an OpenLDAP repository. It uses a tool called pwdump2 and a Perl script to export an LDIF file from AD into OpenLDAP.
One of the best places to look for a thoroughly complete overview of how to migrate from Active Directory is a book called Windows to Linux Migration Toolkit, by David Allen; the book includes scripts that allow, among other things, movement of user accounts and other AD data into LDAP.
Most of what you'll end up sacrificing when you leave Active Directory behind are things that are tied strongly to applications on the Windows side. If you plan your migration with care, you'll find that what you've left behind isn't anything you can't replace in a different form, and one that (most importantly) doesn't come with the burden of vendor lock-in.
This was first published in October 2006