- 1 Exploring Windows 2003 Security: More Active Directory Security Improvements
- 2 Exploring Windows 2003 Security: Active Directory and Authentication Security Improvements
- 3 Exploring Windows 2003 Security: Configuring Code Access Security
- 4 Exploring Windows 2003 Security: SID Filtering and Software Restriction Policies
- 5 Exploring Windows 2003 Security: SID Filtering and Software Restriction Policies
- 6 ServerWatch Articles by Marcin Policht
Exploring Windows 2003 Security: Additional Active Directory Authentication Improvements
This article continues our discussion of authentication enhancements in Windows Server 20003, covering the following features:
- Active Directory Application Mode (ADAM)
- Credential Manager
- InterOrgPerson compatibility
Active Directory Application ModeWe continue our overview of authentication enhancements in Windows Server 20003 with a discussion of Active Directory Application Mode, Credential Manager, and InterOrgPerson compatibility.
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:
- Specify whether you want to create a unique instance or a replica of existing instance (which leads to configuration set implementation). A unique instance is identified by a name, which is assigned next. Besides satisfying the uniqueness requirement, it is also good to make the name descriptive. This name is appended to ADAM_ prefix when creating the service under which the directory service operates (e.g., choosing the name HR_database would result in the creation of ADAM_HR_database service, although the display name, listed in the Services MMC snap-in, will be HR_database).
- Specify the ports intended for SSL (636 by default) and LDAP (389 by default) communication. These values cannot conflict with ports that will be occupied on the target system as the result of future changes (e.g., when installing ADAM on a system that will be promoted to a domain controller, values of both ports should be altered from defaults, since these will be taken by Active Directory). The wizard will, however, ensure that the default ports do not conflict with ports in use at the time of installation.
- Indicate whether you want to create an application partition (you have an option of creating it after the installation completes with LDP, DSMGMT.EXE, or via ADSI) will appear. If you decide to do this, you must specify the partition name. The ability to create an application partition separately from the Active Directory domain naming context is the essence of ADAM's functionality. Specifics of implementing the application partition are dependent on the application for which this partition is intended and are typically left to application developers. Application partition can be created in several ways, including importing Lightweight Directory Interchange Format (LDIF) files, using LDP and ADSI Edit utilities, and programmatic methods.
- Fill in the location of the data and data recovery files (which, by default, are stored in the Program Files\Microsoft ADAM\InstanceName\data folder). Since ADAM directory services store is separate from the operating system files, it can be backed up and restored independent of System State data.
- Provide an account in the security context in which the newly created service will be running. This can be either Network Service Account (by default) or an arbitrary account chosen by you. In the second case, you will need to ensure that the account is permitted to login as a service (using domain or local Group Policies - Machine Configuration->Windows Settings->Security Settings->Local Policies->User Rights Assignment) and has appropriate permissions to the machine certificate data store, when accessing ADAM via SSL. Selection of this account might also have implications if you intend to install the configuration set. When operating in a workgroup environment, Network Service cannot be used for replication since it does not have access rights to other members of the workgroup.
- Specify the account that will function as the administrator of the ADAM instance (by default this is the user account running the installation).
- If desired, modify the target schema by importing Lightweight Directory Interchange Format (LDIF) files. The ones provided by Microsoft (displayed in the dialog box during setup), enable you to modify the user class definition (affecting the creation of inetOrgPerson class objects), interaction with Windows Authorization Manager, and creation of userProxy object used to redirect authentication request to existing Active Directory accounts.
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.