17.1 Microsoft's Directory Strategy

After the initial release of Active Directory, Microsoft thought, like many in the industry, that the direction most companies were headed was deployment of a single enterprise directory that would be all things to all clients. Microsoft's intent was for Active Directory to serve the NOS directory role, replacing NT 4.0, and also the application directory role, which had typically been dominated by SunOne (formerly iPlanet) and OpenLDAP. But after three years of implementations, it became evident that although most companies would like to implement a single directory, in practice it did not work out that way. A lot of applications are developed with a particular directory in mind and in some cases, like Exchange 2000, an application can work only with a specific directory. After Microsoft realized that multiple directories would be a reality in most organizations of any size, they decided to rework their strategy. This happened to coincide with their plans to release a major update of the Windows Server operating system, Windows Server 2003.

There are three main components to Microsoft's current Directory Services roadmap: Active Directory Application Mode (AD/AM) as the application directory, Microsoft Metadirectory Services (MMS) as the central provisioning source, and Active Directory as the NOS or Infrastructure directory. We'll now examine each of these products.

17.1.1 Active Directory Application Mode

When Microsoft announced plans in July 2002 to release a "lightweight" version of Active Directory sometime after the release of Windows Server 2003, many AD administrators breathed a sigh of relief. The reason for the relief is that when Active Directory serves as a NOS directory, as it does in the vast majority of implementations, it does not lend itself well to being a flexible application directory. We describe some of the challenges of using Active Directory in both roles in Section 17.3, later in the chapter.

Active Directory Application Mode, or AD/AM for short, will help reduce the need for Active Directory to serve dual purposes. AD/AM is closer to what most consider a traditional LDAP directory, such as that offered by SunONE and OpenLDAP. It has many AD-specific features stripped out, such as KDC support and DNS SRV requirements, which are necessary for the DC Locator process. AD/AM actually uses the same code base as Active Directory, but the unwanted features are disabled. Some of the similarities with Active Directory include:

• Support for many of the same tools (e.g., ADSI Edit and LDP)

• Support for ADSI and LDAP

• Support for multimaster replication

• Support for a fully extensible schema, although a very minimal schema is provided out of the box

• Inclusion of Configuration, Schema, and Application Partitions (but no Domain Partitions)

Some of the differences from Active Directory include:

• Easy setup process (not dcpromo) with no reboot required

• Support for installing multiple instances on a single computer

• Capability to run each instance as a service and to stop and start services without a reboot

• Support on Windows XP Professional

• Capability to have any root naming (e.g. o= or c=)

• No DNS SRV requirements

• No KDC capabilities

• No MAPI protocol support

• No FRS dependencies

One of the big benefits of AD/AM is that you can use Windows Integrated Authentication to control access to data in AD/AM. That means you can utilize Active Directory as an authentication directory, while at the same time compartmentalizing AD/AM instances to serve specific functions without impacting the NOS environment.

17.1.2 Microsoft Metadirectory Services

Metadirectories are used to centralize the provisioning of data across disparate systems. They allow you to define rules for how data should flow based on customized business logic. That is, you can set a rule stating that if system Y has attribute A updated, attribute B in system Z should be updated. Metadirectories become increasingly important as the number of directories and databases you have to support in your environment increase. As we mentioned, supporting multiple directories is a necessary evil that most organizations have to cope with, and metadirectories can help reduce the amount of time you have to spend provisioning data in each.

Microsoft's previous metadirectory offering, Microsoft Metadirectory Services (MMS) Version 2.2, was difficult to setup and maintain. In fact, to purchase MMS 2.2 you had to purchase a support contract from Microsoft as well, which included the installation and setup of the product. With the release of MMS 2003, Microsoft has completely revamped the application to make it easier to configure and manage. Microsoft is positioning MMS 2003 as the glue between Active Directory, AD/AM, and any other information repositories you may need to provision or extract data from.

The challenge with MMS 2003 is the fundamental issue behind metadirectories: they can be difficult to set up and configure. Other options exist to solve the provisioning problem. If you have in-house programming expertise or can hire contractors, you can write automation scripts that can provision data and accounts between systems. Programming with LDAP is not very complicated, and using ADSI is even easier. Going this route has its own challenges, such as the need for solid expertise and a good idea of exactly what you want to build, so in the long run a metadirectory may be more appealing.

MMS 2003 comes in two flavors, both requiring Windows Server 2003 Enterprise Edition: MMS 2003 Standard Edition and MMS 2003 Enterprise Edition.

The Standard Edition was made available as a free download from Microsoft's web site soon after Windows Server 2003's launch. It requires MSDE, SQL Server 2000 Standard Edition, or SQL Server 2000 Enterprise Edition as its database store, and supports AD, AD/AM, and Exchange Server 2000/2003 only. This version is meant to help you with compatibility between these core directories only. Standard edition enables easy and secure, synchronization and provisioning of identity information across multiple Active Directory forests, Exchange 2000/2003 implementations for GAL synchronization or with Active Directory/Application Mode installations.

The Enterprise Edition is a paid-for product from Microsoft, and requires SQL Server 2000 Enterprise Edition as its database store. This edition supports AD, AD/AM, DSML 2.0, XML, CSV files, text files, Exchange, LDIF, Lotus Notes/Domino v4.6/v5.0, Sun/iPlanet/Netscape directory 4.x/5.x, SQL Server 7.0, SQL Server 2000, Oracle, IBM DB2, Windows NT4, Novell NDS/DirXML, SunOne, Critical Path MetaConnect/X.500, and more. A significant number of partners also provide connectivity for other corporate repositories and directories like SAP.

The major changes since MMS 2.2 are as follows:

• MMS 2.2 Zstore replaced by SQL Server 2000 for the database store to aid performance, scalability, failover clustering, and the like.

• MMS 2.2 Zscript replaced by any .NET language for scripting purposes.

• MMS 2003 now supports unicode and double-byte character sets.

• MMS 2003 now supports self-service and helpdesk password management and resetting to enable those operations to be performed much more easily.

• MMS 2003 now is integrated with WMI for the first time.

There is a lot inside MMS that administrators have not been aware of simply due to the restricted nature of MMS 2.2's distribution. We encourage you to go and take a look in detail at MMS for your organization to see where it might be useful. More details can be found on Microsoft's web site by searching for MMS or Microsoft Metadirectory Services, or try here: http://www.microsoft.com/mms/.

17.1.3 Active Directory's Role

Under Microsoft's current direction, the role of Active Directory has been reduced, but its importance has by no means been lessened. Active Directory's primary purpose is that of a NOS directory, as which its main function is to authenticate and authorize clients so they can access directory and network resources. In some cases, applications may still want to integrate directly with Active Directory as opposed to using an application directory such as AD/AM. Since Exchange 2000 is so dependent on the directory store and ties heavily into AD resources such as users, groups, and contacts, it may make sense to keep it integrated directly with Active Directory as opposed to AD/AM. Thus, while the general trend will be to move to AD/AM in the application space, some applications will still need tight integration with Active Directory. Regardless, AD/AM will alleviate a lot of the pressure to integrate all applications with Active Directory and therefore allow you to maintain tight control in your NOS environment.