Exploring Windows 2003 Security: Additional Active Directory Authentication Improvements
September 22, 2003
This article continues our discussion of authentication enhancements in Windows Server 20003, covering the following features:
Active Directory Application Mode
The main purpose of Active Directory Application Mode (ADAM) is to provide secure directory services, account data store, and an authentication mechanism without the need for creating a full-blown Active Directory forest. For that reason, ADAM is also referred to as "light-weight Active Directory."
ADAM is implemented as a non-core, installable Windows service running in a secure context of an arbitrarily chosen account with an arbitrarily chosen name (assigned during setup). It can be installed on a stand-alone computer in a workgroup or on a member server or domain controller in a domain. Multiple instances of ADAM can also run on the same system.
ADAM operates in distributed mode (as a so-called configuration set), with multiple computers containing replicas of the same instance of ADAM. Replicas, like Active Directory domain controllers, are synchronized via a replication mechanism (according to the configurable schedule). ADAM contains configuration, schema, and application partitions. It supports LDAP and SSL communication and exposes programmable interface, which can be used to automate common management tasks.
The ADAM authentication mechanism uses accounts defined within its own data store, Windows accounts valid on a system on which an ADAM instance instance resides, or it can redirect authentication request to Active Directory or Windows NT domains. In the latter case, the link to the Active Directory account is based on having its SID value stored in an ADAM userProxy object. Redirection via proxy not only provides a single sign-on, but also enables storage of application-specific data for an Active Directory user outside of the Active Directory database.
ADAM offers tremendous flexibility when dealing with applications that depend on LDAP-based directory services. Users no longer must wait until the Active Directory domains are in place before deploying such applications. In addition, the impact of schema changes that some applications require can be limited to a single computer running localized instances of ADAM. ADAM has been found to be extremely helpful in extranet environments, where user authentication must be handled via LDAP but direct access to Active Directory is restricted. Since ADAM supports both DNS (DC=Microsoft,DC=com) and X.500 (O=Microsoft,C=US), distinguished names for top-level directory application partitions, it can be used in migration scenarios from third-party directory services to Active Directory.
ADAM includes a few tools for managing its directory services. Most of them are equivalent to standard Active Directory Support Tools, such as ADSI Edit and LDP, although there are a few new ones. DSDIAG is a replacement for DCDIAG; DSDBUTIL and DSMGMT replace NTDSUTIL. DSDBUTIL enables administrators to run authoritative restore, set LDAP and SSL ports, and change accounts to provide a security context to the ADAM service. DSMGMT is used to run metadata cleanup and manage application partitions, and the ADAM Schema Management MMC snap-in (ADAMSCHMMGMT.MSC) enables the management of the schema of ADAM directory services. Finally, DSACLS is a command line utility for viewing and setting permissions on objects residing within ADAM.
Besides protecting ADAM objects with DSACLS, you can also secure connections to ADAM by configuring SSL (you enable it using DSMGMT and set the SSL port with DSDBUTIL). This requires certificates be installed on the computer running the ADAM service and each client computer. When operating in an intranet environment, the simplest solution is to use the Windows 2000 or Windows 2003 Certificate Authority. In addition, the ADAM service account must have full access to the computer certificate store (located in Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys).
Unfortunately, no administrator friendly account management Directory Services tool (equivalent to Active Directory Users and Computers) is currently available for ADAM installations. So although ADAM can serve as a fully functional store for any type of account information (including multi-tier organizational unit structures with their users and groups) just as well as Active Directory, administrators will have to resort to more challenging methods to populate and manage directory information (such as ADSI Edit, LDP, or programming and scripting). Examples illustrating the creation of users, groups, and organizational units are available in the Step-by-Step Reviewer's Guide that accompanies the ADAM installation files.
ADAM is not built into the operating system; it is available as a separate component downloadable from the Microsoft Web Site. Versions for Windows 2003 and Windows XP 32-bit and 64-bit are available. Windows XP requires Service Pack 1, an additional hotfix to enable full ADSI compatibility (Q817583), and registry modification (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\forceguest set to 0) when operating in a workgroup environment. Setting up ADAM (launched via ADAMSETUP.EXE) is straightforward and wizard-driven, like the majority of Microsoft-provided installations.
It follows this sequence of steps:
The ultimate goal of every directory services solution is to provide a unified, universal store of information, especially when it comes to user accounts. Unfortunately, in reality, such information typically resides in a number of disparate account repositories. Users, forced to remember multiple user names and passwords, become frustrated and frequently get into trouble by confusing them or, even worse, compromise security by writing them down (and posting them right on their monitors).
Microsoft decided to address this issue by implementing Credential Manager (accessible via the Stored User Names and Password applet in the Control Panel). The applet allows the admin to type in user credentials applicable to access a specific target resource. Once the username, password, and target server names are saved, they are retrieved and reused every time that server is accessed.
Alternate credentials are automatically stored in Credential Manager whenever a target server is accessed from the graphical interface (e.g., via drive mapping or a Web browser). In addition, you can force the same functionality when mapping drives from the Command Prompt with NET USE command by including /SAVECRED switch.
Although Windows 2000 Active Directory conformed to X.500 standards, significant problems still occur when attempting to integrate it with other directory services, such as iPlanet or Netscape. This was because inetOrgPerson class, which was used in other X.500 implementations to represent user accounts, was not available in Windows 2000. Schema changes introduced in Windows 2003 changed this situation. InetOrgPerson objects have been included in the Windows 2003 Active Directory as security principals (on par with user, group, and computer accounts). You can also create them as easily as regular users with Active Directory Users and Computers (simply right-click the target container and select New->InetOrgPerson from the context sensitive menu). However, since this feature requires schema changes, it is available only in Windows 2003 Domain mode.