Introduction This article discusses the use of Microsoft's Active Directory as an authentication service for Linux systems. Although Linux has a perfectly good directory based authentication system (OpenLDAP), it may be desirable on some sites to authenticate Linux users against a Microsoft Windows 2000 server. Although this article discusses Linux (because that is the system I have available in my office), this authentication mechanism works well against other Unix systems that have a PAM/NSS mechanism. Currently that includes Solaris, although discussion has taken place on the possibility of getting this to work on HP-UX. Since most of the work is done at the Windows 2000 end, the instructions for getting this to work on Solaris are not too different from what I have described here. Before attempting any of this, you should be familiar with the concepts of PAM and NSS, and be familiar with how to set up PAM and NSS on your Linux distribution or operating system. Also, before I begin, I should state that I really do not believe that Active Directory is the best way to authenticate Linux clients, nor is it the best way to authenticate users in a multi platform environment. It may be the case that in your network, for political and financial reasons, you are constrained to using Active Directory as a directory product, however, and so this document may be of some benefit to you if you are unable to rethink your IT strategy in this area. Furthermore, I really recommend taking caution in implementing any of the instructions in this article. Microsoft does not support authenticating to Active Directory for any non-Microsoft client, and Microsoft does not support the instructions contained in this article in any way. If you wish to follow the instructions in this article then you do so at your own risk.

Authentication Systems The traditional way of authenticating users on a Linux system is to store the accounts and passwords in an /etc/passwd file or, more commonly, a combination of /etc/passwd and /etc/shadow. This is fine when there is only a single Linux system on a network, as the /etc/passwd file is local to the system on which it is stored. Although it is possible to share a single /etc/passwd file amongst multiple Linux systems, using such tools as rsync, it makes more sense to have a centralized authentication database containing all of the user accounts and passwords. There are many such centralized authentication systems available, including Kerberos, NIS, and others. LDAP is a protocol that can be used to enable a fairly powerful mechanism to store centralized authentication as well as user information. Cross-Platform Authentication The aim of cross-platform authentication is to have a single, centralized password database that can be used to authenticate users on both Unix, Windows, and perhaps even other systems such as Macintosh or NetWare. Because LDAP-based authentication is supported on the most recent Microsoft systems, including Windows 2000 and XP, and is also supported on Linux and other Unix systems (such as Solaris), it makes an excellent choice for a cross-platform authentication system. Note that there are limitations to this. Firstly, the Microsoft clients for Windows 2000 and XP are specific to authenticating against a Microsoft Active Directory server. Although OpenLDAP uses the same LDAP protocol, there are other features of Active Directory (including a modified version of Kerberos with a Microsoft specific mechanism called a "PAC") which means that Active Directory clients will not necessarily be able to authenticate against OpenLDAP. The second limitation of Active Directory is that clients for it (in LDAP mode, that is) are only available on Windows 2000 and Windows XP. Although Active Directory will work in a "down-level" mode to support older Microsoft clients, users of systems such as Windows NT and Windows ME/98/95 who wish to have full LDAP/Kerberos based authentication support are forced to upgrade. Of course, another limitation of Active Directory is that it only runs on Microsoft Windows 2000 servers. There are no releases of Active Directory for other platforms. In contrast, many of the other directory services available (such as those from iPlanet and Novell) are supported as servers on many platforms.

LDAP Alternatives Other alternatives to Active Directory exist where an LDAP-based authentication system is desired. These include:

• OpenLDAP. As mentioned earlier, this is an excellent authentication system for Linux clients; however, Microsoft clients will not be able to authenticate to it. An article on implementing OpenLDAP in a Linux environment is available here: http://online.securityfocus.com/infocus/1427
• iPlanet Directory Service. iPlanet directory service runs on Windows platforms, as well as on Linux and Solaris systems. Although the iPlanet directory server contains a Windows NT to LDAP password synchronisation system, direct authentication to iPlanet directory server is not possible from Windows systems.
• NDS. Novell's directory service is probably the most credible implementation of a cross-platform directory service. The server runs on Solaris, Linux, Windows, and NetWare. Clients are available for many platforms including nearly all Microsoft Windows platforms (including Windows 98 and Windows NT), and also Linux and Solaris. NDS is standards-compliant and I have found it to perform well in many implementations. If a true cross-platform directory service is required, then NDS is probably the best option. NDS's only limitation is the cost, which can be quite high in an environment with a large user base.

MKS AD4Unix What is AD4Unix? MKS AD4Unix is a plug-in extension for Microsoft's Active Directory Server, that enables Unix-related authentication and user information to be stored in Active Directory. AD4Unix includes a schema update, and an extension to Microsoft's User & Group manager (part of the Active Directory administration interface, which is in turn part of the Microsoft Management Console). The primary goal of AD4Unix is to create a unified account database for Windows and Unix servers via Active Directory. This is what specifically enables cross-platform authentication using Active Directory. AD4Unix was written by Maxim Batourine of the Faculty of Architecture, Landscape, and Design at the University of Toronto. Full credit should be given to Maxim for the assistance that I received during preparation of this article. Obtaining MKS AD4Unix MKS AD4Unix can be obtained via the AD4Unix download page. AD4Unix is delivered as a single .MSI (Microsoft Installer) file that can be installed directly onto a Windows 2000 server.

Installing MKS AD4Unix The original installation instructions for AD4Unix, and guidelines for its use were written by JJ Streicher-Bremer for AD4Unix 1.1.1. Things have changed somewhat since then, there is now an installation package (MSI format), however there are still a few hairy parts of the installation because the installation package is not perfect. JJ has also been particularly helpful in preparing this article, both personally and in discussions and posts to the nss_ldap mailing list. My goal in installing AD4Unix was to take a machine with a blank, formatted, hard disk, and install Windows 2000 and then AD4Unix from scratch. This took a bit of messing about. These instructions are based on Windows 2000 server, service pack 2, and AD4Unix version 1.5. Here follows a log of what I did to get the product up and running:

• Installed Windows 2000, from the installation CD. Since I had a single empty hard disk, I just told Windows 2000 to install onto the hard disk and use all available disk space. If you have multiple hard disks (to use Microsoft's guidelines of having separate physical disks for directory and log files) then you will need to mess with the installation a little. For me, I just followed the step-by-step installation instructions and chose the defaults.
• Note that although I am in Australia, I chose to install only the US English language support (which was the default during the Windows 2000 installation). I had some trouble installing AD4Unix when I chose an alternative default language, and Maxim Batourine's comment was that "AD4Unix does not currently support the full zoo of languages on Windows". I can understand this limitation, and in any case it only affected the server on which I was installing Windows 2000 and not any other workstations. Maxim promised better language support in future versions of AD4Unix.
• Installed the Windows 2000 High Encryption Pack. I am not sure if this is still required, since it appears to be installed with service pack 2 which I installed next. It did appear to make the AD4Unix installation go more smoothly when it was installed first, however. Perhaps this is another case of the DLL hell that all Microsoft Windows administrators are faced with? The installation of this pack required a reboot.
• Installed Windows 2000 Service Pack 2. Note that all Windows 2000 service packs are available from the Microsoft Web site - I won't detail the specifics of whereabouts in the site to obtain the service packs from because the site does tend to change periodically; however, they are usually to be found in the "Downloads" area. This required a reboot.
• Using the "Configure Your Server" wizard, I set up Active Directory. In this case, since it was a new installation in an isolated environment, I created a new domain, new tree, new forest of trees, and created a new DNS zone. You may wish to configure your server differently, or join it to an existing tree or forest. Beware that we are about to install schema updates, which could play hell with any existing directory tree or forest that you have, unless you install them correctly.
• Allowed schema updates on the domain controller. To do this, I followed these instructions of JJ's:
• Open a command window (Start->Run->CMD)
• Type the command: regsvr32 c:\winnt\system32\schmmgmt.dll This registers schmmgmt.dll as a MMC (Microsoft Management Console) snap in. You can now close the command window by typing exit.
• Create a Schema Management MSC, as follows:
• Start -> Run -> MMC
• From the console menu, select "add/remove snapin" and then click the "Add..." button.
• Select Active Directory Schema and click "Add"
• click "Close"
• click "OK"
• Choose the domain controller you want to update the schema on:
• Right click on "Active Directory Schema" and select "Change Domain Controller"
• Select "Specify name" and type in the DNS name or address of your Domain controller
• Allow updates on the domain controller
• Right click on "Active Directory Schema" and select "Operations Master"
• Click the checkbox labelled "The Schema may be modified on this Domain Controller"
• Click OK
• Now it is possible to install the ADS4Unix plugin. To do this, find the location where the .MSI installer file was downloaded to, and double click on it in file manager.
• Say Yes to the questions about schema updates.
• On the Start menu under "Programs" there should now be an extra menu titled "AD4Unix". This contains the AD4Unix configuration program (MKSADPluginSettings). Run this configuration program, and set up an NIS name -- I just used babelads, which was the lower case version of my Windows NT (downlevel) domain name. It doesn't matter much what you enter in here, as you will not be using NIS, but something needs to be entered.