Sometimes, trying to follow security best practices can leave you in a quandary. For instance, one security best practice is to avoid burdening users with multiple accounts, which adds work for users and increases the risk of terminated users retaining accounts that weren't found and disabled during the termination process. Another security best practice suggests that you sometimes need to compartmentalize systems and applications so that they are isolated from each other, in case one a system exposed to higher risk is compromised. These priorities can sometimes come into conflict.
Consider an organization that runs Web servers to host a Web-based application and that deploys an Active Directory Application Mode (ADAM) directory hosted in a demilitarized zone (DMZ) to store user credentials and configuration information. The Web application needs to be accessed both by outsiders (customers or vendors) and by the organization's employees. The organization has two options. It can support access through the firewall to one directory hosted on the intranet, with all the security concerns that this option entails, or it can deploy two directories, in which case employees are burdened with two accounts. Microsoft Identity Integration Server (MIIS) 2003 gives organizations a tool for deploying directory-enabled applications while ensuring that data across individual directories remains synchronized.
By adding MIIS to this scenario, as Figure 1 shows, you can export objects that represent application users from Active Directory (AD) and import them into ADAM, where you can store them alongside objects that represent external users. MIIS doesn't need to export and import entire directories-you can configure it to replicate only pertinent attributes and only for selected objects. Through MIIS, AD and ADAM can synchronize the objects for users who access the Web-based application-a specific value or attribute can drive the decision about which objects to synchronize. Best of all, the Identity Integration Feature Pack (IIFP) for Microsoft Windows Server AD, a version of MIIS that supports a subset of directories, is available free to Microsoft customers who have Windows Server 2003, Enterprise Edition licenses.
Installing and Configuring MIIS
MIIS lets you import objects from one or more directories, reconcile conflicting attributes, and export the objects to other directories. You can create rules to determine which objects and attributes are imported from each directory, how conflicts are resolved, which objects and attributes are exported, and where they're exported. And you can extend MIIS's functionality by writing processing logic in Visual C# .NET or Visual Basic .NET.
Neither MIIS nor IIFP is a metadirectory in the truest sense of the term, but you can use either in conjunction with ADAM to build a metadirectory. The full version of MIIS supports several different directories, email systems, applications, databases, and file-based repositories. However, IIFP supports only ADAM, AD, and Microsoft Exchange Server 2003 and Exchange 2000 Server Global Address Lists (GALs). GALs list email-enabled users and groups and are created and used by Exchange and Messaging API (MAPI) applications, such as Microsoft Outlook and other Microsoft Office applications. In this article, I concentrate on IIFP, but everything I discuss also applies to the full version of MIIS.
Unlike ADAM, which runs on both Windows 2003 and Windows XP Service Pack 1 (SP1), IIFP runs only on Windows 2003, Enterprise Edition and requires Microsoft SQL Server 2000 Standard Edition or enterprise edition. (You can use the latest version of Microsoft SQL Server Desktop Engine-MSDE-for testing purposes, but IIFP isn't licensed for use with MSDE in production environments.) IIFP, which you can download at http://www.microsoft.com/windowsserver2003/technologies/directory/miis/default.mspx, is slightly less than 8MB in size and provides a wizard to help with installation and configuration.
Configuring Data Imports
With MIIS installed and running, you can create and configure management agents, which are responsible for connecting directories to MIIS. Although the power and flexibility of the management agents might make them appear daunting, the underlying theory is fairly simple. MIIS maintains a metaverse-a consolidated, synchronized view of all objects and attributes that management agents have imported. Each agent stores information about a particular connected directory, including its location and the credentials necessary to access it, in tables separate from the metaverse.
The agents import data from a connected directory to the agent's connector space, which you can think of as a staging area for import and export operations. MIIS must synchronize objects and attributes in the connector space with objects and attributes in the metaverse. During the synchronization process, MIIS checks join rules to determine whether an object in the connector space can be uniquely linked, or joined, to one object in the metaverse. When the object in the connector space can be joined to an object in the metaverse, MIIS synchronizes it. If MIIS can't join an object because no corresponding object exists in the metaverse, MIIS searches for a projection rule that governs whether the object should be created in the metaverse.
Figure 2 shows join and projection rules for the inetOrgPerson object type in a management agent that imports objects from AD. Metaverse objects aren't necessarily the same as the objects in the connector space or the connected directory. Directories often contain many types of objects that can be used interchangeably. For example, AD can use user, person, and inetOrgPerson object types to store information about an individual, but the metaverse can store information about an individual only in a person object type. If the metaverse has no suitable object type to represent an object type from a directory or you need to customize an existing object type, you can use Metaverse Designer to extend the metaverse schema.
To configure a management agent a wizard guides you through the agent-creation process. The process can vary slightly depending on the directory you want to import from. When configuring an agent to import data from a connected directory, you can select which object classes (aka object types) to import (e.g., user, inetOrgPerson). For AD and ADAM, three object types are mandatory: container, domainDNS, and organizationalUnit.
After you specify all the object types you want to import, you can select the attributes to import for those objects. To control which objects to import from the directory, you can use filters based on the attributes you want to import. Comparison operators for filters depend on the attribute type and include Equals, Does not equal, Starts with, Is present, and Contains.
You need to configure how attributes that belong to objects in the connector space flow to object types and attributes in the metaverse during synchronization. You configure attribute flow in the Create Management Agent window. Figure 3 shows attribute flow configured for a management agent that imports inetOrgPerson and user objects from AD to the metaverse.
You also need to configure deprovisioning to control how objects that are no longer joined are processed. Joins are broken when an object is removed from the metaverse-for example, when it's removed from a connector space as the result of its deletion from the connected directory. The final step in configuring a management agent lets you configure rules extensions and password-protection operations on directory partitions.
Configuring Data Exports
Using MIIS to build a metaverse isn't very useful in itself. What you really want MIIS to be able to do is to export data through connector spaces to connected directories, where applications can access the data. The process of configuring a management agent to export objects and attributes is almost identical to creating an agent to import data. The main differences are that an export management agent doesn't have join or protection rules for exported attributes, the attribute flow is from metaverse to connector space instead of in the reverse direction, and you need to implement a rules extension.
Working with rules extensions can be the most off-putting part of implementing MIIS. Rules extensions are DLLs written in Visual Basic .NET or Visual C# .NET, compiled, and stored in the Extensions folder under MIIS's installation root folder. A rules extension is required to create an anchor attribute, which uniquely identifies an object in the management agent's connector space. For Lightweight Directory Access Protocol (LDAP)-compliant directories such as AD and ADAM, the anchor attribute is the object's distinguished name (DN) attribute. For a SQL Server or plaintext file, both of which the full version of MIIS supports, the anchor attribute might be an employee ID or any one of several combinations of attributes defined by the MIIS administrator.
After you configure the management agent and put the rules extension in place, you can use an Export step to create a Run Profile for the agent. This step exports the objects in the metaverse to the connected directory. After the agent runs, MIIS displays the results of the operation. Figure 4 shows the results of an export operation. After you perform an export operation, it's a good idea to run an import operation to check that the export was successful.
Management agents don't need to be dedicated as import or export agents-they can both import and export attributes. Management agents that both import and export are typical for environments that require multiple directories to synchronize with each other. MIIS ships with a developer's guide and Help file, both of which contain details about how to implement rules extensions.
Synchronicity
Now you know how to use IIFP to synchronize AD and an ADAM directory by creating import and export agents. To successfully export to a directory such as ADAM, you need to write a rules extension in Visual Basic .NET or Visual C# .NET. The full version of MIIS supports databases such as SQL Server as well as many third-party LDAP directory products, and rules extensions can easily accommodate these sources of identity.
