MIIS 2003 Overview

Applies To: Windows Server 2003 with SP1

Download Instructions

This document is available for download as a Microsoft Word document at https://go.microsoft.com/fwlink/?LinkId=30737.

Overview

MIIS 2003 is a service that can be installed on a server running Microsoft Windows Server 2003, Enterprise Edition to synchronize and integrate identity information between similar and dissimilar data sources. The Identity Integration Feature Pack (IIFP) for Microsoft Windows Server Active Directory® performs this same functionality but is limited to connections with Active Directory, Active Directory Application Mode (ADAM), and Active Directory global address lists (GAL). Where this document discusses MIIS 2003, the technology applies to both MIIS 2003 and IIFP.

This subject describes the core components of MIIS 2003, the structure of the MIIS 2003 namespace, and how identity information is processed.

In this subject

• What Is MIIS 2003?

• How MIIS 2003 Works

What Is MIIS 2003?

Managing information about people, applications, and network devices is an essential element of managing computer networks. Typically, organizations store identity information as data objects in various data repositories. A typical organization has multiple data repositories for identity information. Integrating information that is stored in many data repositories is challenging, time-consuming, and expensive.

For example, an employee’s job title and address are usually stored in more than one data repository. When an employee moves or is promoted, the same information must be updated in each one. To further complicate matters, data repositories are often managed by independent departments.

MIIS 2003 addresses this challenge by providing a centralized point of administration for the combined view of related identity information. By synchronizing changes based on business rules, MIIS 2003 manages the lifecycle of the identity information.

An instance of a data object that is stored within a data repository is called an identity. An identity is the summary of information about people, applications, and resources. Examples of identities that are associated with people include: name, mailbox number, salary, and job title. Application identities include network addresses where clients can find servers and lists of services that the application provides. Network resources, such as printers, also have identity attributes (for example, their location and the printing capabilities they support).

To manage data objects, you use a data repository called a directory. A directory is a database application that is optimized for read operations. A directory provides a well-defined set of object classes with associated attributes and a hierarchical view for organizing objects.

Typically, directories are used for:

• E-mail address books or white pages that contain name and e-mail address information.

• E-commerce directories that contain information about users and profiles.

• Server operating system directories that contain information about users, computers, devices, and applications.

• Enterprise directories that contain information from multiple directories.

A directory service exposes the operations necessary to locate and manage the content of a directory and its database. A directory service consists of both the data repository and the service that makes the information available and usable.

Historically, directories were custom applications that were designed to fulfill a specific role within a corporate network environment. A new directory was often built each time the need for a directory arose. In recent implementations of directory services, open directory standards such as the Lightweight Directory Access Protocol (LDAP) allow a single directory to support multiple applications and uses simultaneously. For example, Active Directory® directory service can be used simultaneously for authenticating network users and for supporting Microsoft Exchange Server 2000. As a result, the role of directory services is becoming more complex.

The diversity of identity information and the number of places where this data resides presents unique identity management challenges for a number of common corporate tasks. The following table lists some of these tasks and their identity management requirements.

Identity Management Tasks and Requirements

Identity Management Task	Identity Management Requirements
Managing and synchronizing passwords	Manage user name, password, and access rights information across many different platforms and applications.
Hiring/retiring employees	Quickly propagate information about newly hired employees to all systems that require identity information, and quickly perform the same processes in reverse when employees leave.
Managing a global address book	Synchronize mailbox information among the e-mail directories that are used within a company.
Managing e-commerce applications	Synchronize information for suppliers and extranet users, such as digital certificates, with e-commerce directories that reside outside of firewalls.

Identity Management Challenges

Although managing identity information is critical to reducing administrative costs for all large corporate environments, adopting an identity management solution presents the following challenges:

• Not all identity information is kept in directories or exposed through a directory service interface such as LDAP. For example, many data repositories only expose identity information through specialized application programming interfaces (APIs).

• Frequently, identity information is duplicated in multiple data repositories, and instances do not remain synchronized.

• Typically, administrators and applications cannot access or manage an aggregated view of an enterprise’s identity information in a single place.

• The number of places where companies must manage identity information increases with the addition of each application and platform.

MIIS 2003 addresses these issues by integrating and synchronizing information that is stored in multiple corporate directories. MIIS 2003 creates an aggregated view of identity information stored in multiple repositories and automates management of redundant information, eliminating unnecessary duplication and discrepancies.

How MIIS 2003 Works

In this section

• MIIS 2003 Solutions

• MIIS 2003 Core Components

• MIIS 2003 Architecture

• MIIS 2003 Identity Objects

• Relationships Between Staging Objects and Metaverse Objects

• MIIS 2003 Identity Management Process

• MIIS 2003 Administration User Interface

MIIS 2003 Solutions

MIIS 2003 provides identity management solutions for the following identity management challenges:

• Data source synchronization. Organizations that have many different directories and other data repositories, such as a Human Resources (HR) data repository, can use MIIS 2003 to synchronize user accounts in all of those systems, saving time and money that is currently spent on keeping data consistent and enforcing data ownership rules.

• Active Directory global address list (GAL) synchronization. Organizations can use MIIS 2003 to synchronize e-mail address lists that are maintained by heterogeneous e-mail systems, such as Microsoft Exchange Server 5.5, Exchange Server 2000, and Lotus Notes. Organizations that have multiple Active Directory and Exchange forests can use MIIS 2003 to build a single address book, improving communication throughout an organization.

• Password management and synchronization. MIIS 2003 provides a password management function that allows users to change passwords and administrators to reset them from a single location. MIIS 2003 then pushes the changes to all of the connected data sources, reducing Help desk support costs. In addition, MIIS 2003 with Service Pack 1 provides the password change notification service (PCNS), which synchronizes password changes that are initiated in Active Directory (when users change their passwords by pressing Ctrl+Alt+Del) with passwords for other data sources.

• Account provisioning. In many organizations, information about new employees is entered in a HR database first. Then, the IT department creates user accounts, mailboxes, and other identity information in different database systems. MIIS 2003 can create these user accounts, mailboxes, and other identity information that the IT department would have needed to create, and MIIS 2003 can deprovision an account when an employee leaves the company.

• Group management. In many directory implementations, users and resources are organized into groups for the purpose of managing access to resources. MIIS 2003 facilitates group management in two ways. It can create groups and distribution lists automatically based on organizational attributes, such as by job function or office location. In addition, MIIS 2003 can synchronize groups and distribution lists among different systems, reducing administrative overhead that is required to maintain group membership.

• Certificate publishing. Some organizations have an internal Active Directory forest and a second Active Directory forest in a perimeter network. Employees, vendors, and customers are authenticated for access to internal applications and resources by the Active Directory forest in the perimeter network. An organization with this type of configuration can use MIIS 2003 to publish certificates for the users from the internal directory to the directory in the perimeter network. MIIS 2003 also can help provide a secure e-mail solution when Secure/Multipurpose Internet Mail Extensions (S/MIME) certificates need to be synchronized between e-mail systems. This simplifies security management.

MIIS 2003 provides connectivity to many types of data repositories, including text files, LDAP Directory Interchange Format (LDIF) files, and directories, databases, and e-mail systems from vendors such as Microsoft, Oracle, Sun Microsystems, and Lotus. You can also create custom connections for other types of repositories. For a complete list of data repositories to which MIIS 2003 provides interfaces, see “Connected data sources and managements agents” in Microsoft Identity Integration Server 2003 Help.

MIIS 2003 Core Components

MIIS 2003 provides a complete identity management solution that includes the following components:

• A server service that manages identity information.

• A robust, scalable data repository for identity information.

• A customizable interface that you can use to extend the identity integration solution to suit your requirements.

MIIS 2003 data is stored in Microsoft SQL Server™ 2000.You use Microsoft Visual Studio® development system to customize rules extensions for your unique identity management solution.

Database

MIIS 2003 uses SQL Server 2000 as its database. SQL Server 2000 provides all of the tools and functionality that your enterprise needs to create and maintain Web-enabled, database-powered applications. SQL Server 2000 provides rich support for XML, easy Web access to identity information, and powerful analysis tools, coupled with high availability and tight security. SQL Server 2000 can be indexed for faster searches, and it has its own set of monitoring and maintenance tools. MIIS 2003 uses the SQL Server 2000 database to store all of the critical data that you need to restore your MIIS 2003 environment. You can install SQL Server 2000 on the same computer that is running the Microsoft® Windows Server™ 2003, Enterprise Edition operating system, and MIIS 2003, or you can install it on a remote server.

High Availability and Clustering

Enterprises demand performance, scalability, and high availability from the applications that they use. SQL Server 2000 failover clustering provides high availability.

Failover clustering is a process in which Windows Server 2003 and SQL Server 2000 work together to provide application availability when an application or hardware fails, or when an operating-system error occurs. Failover clustering provides hardware redundancy by transferring mission-critical resources from a failing machine to a server with an identical configuration. Failover clustering allows you to perform system maintenance on a computer while work continues uninterrupted on another node, minimizing system downtime.

Rules Extensions

MIIS 2003 processes identity information by using a well-defined set of rules. You can configure most of these rules by using Identity Manager, which is included with MIIS 2003. You also can customize the way MIIS 2003 processes identity information by creating rules extensions. Rules extensions are created by using a programming language, such as Microsoft Visual Basic® development system, Microsoft Visual C++® development system, or Microsoft Visual C#® development tool. MIIS 2003 implements rules extensions as a Microsoft .NET Framework assembly, or dynamic-link library (DLL).

Visual Studio 2003 is a complete set of development tools for developers who build ASP.NET Web applications, XML Web services, desktop applications, and mobile applications. Visual Basic, Visual C++, and Visual C# use the same integrated development environment (IDE), which enables them to share tools and facilitates in the creation of mixed-language solutions. In addition, Visual Studio 2003 supports the Microsoft .NET Framework, which provides a common language runtime (CLR) and unified programming classes.

Instead of building extensions by using only one language (for example, Perl) or hard-to-understand Extensible Stylesheet Language Transformations (XSLT) or Extensible Markup Language (XML), you can extend MIIS 2003 by using any Visual Studio .NET 2003 language. Additionally, many Visual Studio .NET 2003 partners provide additional language support for administrators who prefer programming in Visual Perl, Visual Python, Pascal, or even COBOL. The rich IDE of Visual Studio .NET provides an easily understood object model with debugging tools. A developer can easily set breakpoints, debug rules, re-evaluate rules, and so on.

Microsoft .NET Framework Security Solution

When you use Visual Studio 2003 to extend MIIS 2003, you automatically take advantage of the .NET Framework security architecture. The .NET Framework security solution is based upon managed code, with security rules enforced by the common language runtime. Most managed code is verified to ensure type safety and the well-defined behavior of other properties. For example, in verified code, a method declared as accepting a 4-byte value, for example, will reject an attempted call with an 8-byte parameter as not type safe. Verification also ensures that execution flow transfers only to well-known locations, such as method entry points — a process that eliminates the ability to jump execution to an arbitrary location.

Verification also resolves many common programming errors before they cause damage. Common errors — such as buffer overruns, the reading of arbitrary memory or memory that has not been initialized, and arbitrary transfer of control — no longer occur. This benefits the MIIS 2003 administrator because code is checked before it is run. It also benefits developers, who will find that many of the bugs that have traditionally plagued development are now identified and fixed.

The CLR also enables unmanaged code to run. However, unmanaged code does not benefit from these security measures. Consequently, calling into unmanaged code requires specific permissions. A robust security policy ensures that those permissions are conservatively granted. Over time, the migration from unmanaged code to managed code reduces the frequency of calls to unmanaged code.

MIIS 2003 Architecture

MIIS 2003 creates an integrated view of objects that are stored in multiple connected data sources and manages identity information in those data sources. This integrated view is determined by the identity information retrieved from connected data sources and a set of rules that determine how to process this information.

Connected Data Sources and Management Agents

MIIS 2003 processes identity information from different data repositories, such as Active Directory or a SQL Server database, or information that is stored in a fixed-width text file. Every data repository that organizes its data in a database-like format and that provides standard data-access methods is a potential data source candidate for MIIS 2003. The data repositories that are synchronized by MIIS 2003 are called connected data sources.

MIIS 2003 encapsulates interaction with a connected data source within an object called a management agent. Each type of connected data source has a specific management agent. The management agent translates a required operation into the format that the connected data source understands.

Connected data sources provide either call-based or file-based access to data. Call-based data access is made by a well-defined set of APIs. For file-based data access, MIIS 2003 has direct access to raw data.

To accommodate both types of data access, MIIS 2003 provides two types of management agents:

• Call-based

• File-based

Call-based management agents make API calls to exchange identity information (both read and write) with a connected data source. File-based management agents read from and write to files in a special folder. MIIS 2003 also provides a management agent for extensible connectivity, which can be modified to connect to any call-based or file-based data repository. The following illustration shows how a management agent connects a connected data source to MIIS 2003.

Data can flow in either direction, but it cannot flow in both directions simultaneously. In other words, a management agent can be configured to allow data to flow from the connected data source to MIIS 2003 or from MIIS 2003 to the connected data source, but only one of those operations can occur at any one time.

To configure a management agent, you specify the object types that you want to synchronize. Specifying the object types defines the scope of objects that are included in the synchronization process. These objects are known as designated objects. The next step is to select the attributes to synchronize, which is known as an attribute inclusion list. These settings can be changed any time in response to changes to your business rules.

To export objects to a connected data source, the attribute inclusion list must include at least the minimum attributes required to create a specific object type in a connected data source. For example, the sAMAccountName attribute must be included in the attribute inclusion list to export a user object to Active Directory because all user objects in Active Directory must have a sAMAccountName attribute defined.

If the connected data source uses structural components, such as partitions or containers, to organize objects, you can limit the areas in the connected data source that are used for a given solution.

Internal Structure of the MIIS 2003 Namespace

The entire MIIS 2003 namespace consists of two namespaces that store the identity information. The two namespaces are:

• The connector space

• The metaverse

The connector space is a staging area that contains representations of the designated objects from a connected data source and the attributes specified in the attribute inclusion list. MIIS 2003 uses the connector space to determine what has changed in the connected data source and to stage incoming changes. MIIS 2003 also uses the connector space to stage outgoing changes for export to the connected data source. MIIS 2003 maintains a distinct connector space as a staging area for each management agent.

By using a staging area, MIIS 2003 remains independent of the connected data sources and is not affected by their availability and accessibility. As a result, you can process identity information at any time by using the data in the staging area. MIIS 2003 can request only the changes made inside the connected data source since the last communication session terminated or push out only the changes to identity information that the connected data source has not yet received, which reduces the network traffic between MIIS 2003 and the connected data source.

In addition, MIIS 2003 stores status information about all objects that it stages in the connector space. When new data is received, MIIS 2003 always evaluates whether the data has already been synchronized.

The metaverse is a storage area that contains the aggregated identity information from multiple connected data sources, providing a single global, integrated view of all combined objects. Metaverse objects are created based on the identity information that is retrieved from the connected data sources and a set of rules that allow you to customize the synchronization process.

The following illustration shows the connector space namespace and the metaverse namespace within MIIS 2003.

MIIS 2003 Identity Objects

The objects in the MIIS 2003 are representations of either objects in the connected data source or the integrated view that MIIS 2003 has of those objects. Every MIIS 2003 object must have a globally unique identifier (GUID). GUIDs provide data integrity and express relationships between objects.

Connector Space Objects

When MIIS 2003 communicates with a connected data source, it reads the identity information in the connected data source and uses that information to create a representation of the identity object in the connector space. You cannot create or delete these objects individually. However, you can manually delete all objects in a connector space.

All objects in the connector space have two attributes:

• A globally unique identifier (GUID)

• A distinguished name (also known as DN)

Objects in the connector space can also have an anchor attribute if the connected data source assigns a unique attribute to the object. The anchor attribute uniquely identifies an object in the connected data source. MIIS 2003 uses the anchor to locate the corresponding representation of this object in the connected data source. MIIS 2003 assumes that the anchor of an object never changes over the lifetime of the object.

Many of the call-based management agents use a known unique identifier to generate an anchor automatically for each object when it is imported. For example, the Active Directory management agent uses the objectGUID attribute for an anchor. For connected data sources that do not provide a clearly defined unique identifier, you can specify anchor generation as part of the management agent configuration.

In that case, the anchor is built from one or more unique attributes of an object type, neither of which changes, and that uniquely identifies the object in the connector space (for example, an employee number or a user ID).

A connector space object can be one of the following:

• A staging object

• A placeholder

Staging Objects

A staging object represents an instance of the designated object types from the connected data source. In addition to the GUID and the distinguished name, a staging object always has a value that indicates the object type.

Staging objects that have been imported always have a value for the anchor attribute. Staging objects that have been newly provisioned by MIIS 2003 and are in the process of being created in the connected data source do not have a value for the anchor attribute.

Staging objects also carry current values of business attributes, and operational information needed by MIIS 2003 to perform the synchronization process. Operational information includes flags that indicate the type of updates that are staged on the staging object. If a staging object has received new identity information from the connected data source that has not yet been processed, the object is flagged as “pending import.” If a staging object has new identity information that has not yet been exported to the connected data source, it is flagged as “pending export.”

A staging object can be an import object or an export object. MIIS 2003 creates an import object by using object information received from the connected data source. When MIIS 2003 receives information about the existence of a new object that matches one of the object types selected in the management agent, it creates an import object in the connector space as a representation of the object in the connected data source.

The following illustration shows an import object that represents an object in the connected data source.

MIIS 2003 creates an export object by using object information in the metaverse. Export objects are exported to the connected data source during the next communication session. From the perspective of MIIS 2003, export objects do not exist in the connected data source yet. Therefore, the anchor attribute for an export object is not available. After it receives the object from MIIS 2003, the connected data source creates a unique value for the anchor attribute of the object.

The following illustration shows how an export object is created by using identity information in the metaverse.

MIIS 2003 confirms the export of the object by re-importing the object from the connected data source. Export objects become import objects as soon as MIIS 2003 receives them during the next import from that connected data source.

Placeholders

MIIS 2003 uses a flat namespace to store objects. However, some connected data sources such as Active Directory use a hierarchical namespace. To transform information from a hierarchical namespace into a flat namespace, MIIS uses placeholders to preserve the hierarchy.

Each placeholder represents a component (for example, an organizational unit) of an object's hierarchical name that has not been imported into MIIS 2003 but is required to construct the hierarchical name. They fill gaps created by references in the connected data source to objects that are not staging objects in the connector space.

Placeholders are stored in the connector space but are never further processed by MIIS 2003. Placeholders carry, at most, only two items of information: a distinguished name and, in many cases, an anchor. In most cases, placeholders for call-based management agents have anchors, although placeholders for file-based management agents do not.

For example, a user object in Active Directory might have the following fully qualified distinguished name:

• CN=Marie Reinhart,CN=Users,DC=fabrikam,DC=com

When MIIS 2003 receives an object with a hierarchically structured name, it has to dismantle it into individual components, as follows:

• CN= Marie Reinhart

• CN=Users

• DC=fabrikam

• DC=com

In this example, “Marie Reinhart” is a user object. Users, fabrikam, and com are containers that are used to organize the other objects. If only user object types are designated object types, MIIS 2003 creates a staging object for “Marie Reinhart”. All of the other components of the hierarchical name are required only to correctly describe the location of the object within Active Directory. Therefore, MIIS 2003 stores the other components of the fully qualified distinguished name as placeholders in the connector space.

MIIS 2003 also uses placeholders to store referenced objects that have not been imported. For example, if MIIS 2003 is configured to include the manager attribute for the Marie Reinhart object in the previous example and the received value is an object that has not been imported yet, such as “CN=Bruno Deniut,CN=Users,DC=fabrikam,DC=com”, the manager information is stored as placeholders in the connector space. If the manager object is later imported, the placeholder object is overwritten by the staging object that represents the manager.

MIIS 2003 preserves the hierarchical nature of objects from the connected data source in the connector space by storing the information about a parent entry (that is, if an object has a parent entry). For this example, therefore, only one placeholder is stored in the connector space for com, fabrikam, and users.

Metaverse Objects

A metaverse object contains the aggregated view that MIIS 2003 has of the staging objects in the connector space. MIIS 2003 creates metaverse objects by using the information in import objects. Several staging objects can be linked to a single metaverse object, but a staging object cannot be linked to more than one metaverse object.

Metaverse objects cannot be manually created or deleted. MIIS 2003 automatically deletes metaverse objects that do not have a link to any staging object in the connector space.

To map objects within a connected data source to a corresponding object type within the metaverse, MIIS 2003 provides an extensible schema with a predefined set of object types and associated attributes. Whereas connector space objects can be only one of two types, either a staging object or a placeholder, you can create new object types and attributes for metaverse objects because you can add new object classes and new attribute definitions. Attributes can be single-valued or multivalued, and the attribute types can be strings, references, numbers, and Boolean values.

Relationships Between Staging Objects and Metaverse Objects

Within the MIIS 2003 namespace, the data flow is enabled by the link relationship between staging objects and metaverse objects. A staging object that is linked to a metaverse object is called a connector object. A staging object that is not linked to a metaverse object is called a disconnector object.

Note

Placeholders are never linked to a metaverse object

A connector object comprises a staging object and its linked relationship to a single metaverse object. Connector objects are used to synchronize attribute values between a connector space object and a metaverse object.

When a staging object becomes a connector object during synchronization, attributes can flow between the staging object and the metaverse object. Attribute flow is bidirectional and is configured by using import attribute rules and export attribute rules.

A single staging object can be linked to only one metaverse object. However, each metaverse object can be linked to multiple staging objects in the same or in different connector spaces, as shown in the following illustration. The linked relationship between the staging object and a metaverse object is persistent and can be removed only by rules that you specify.

A disconnector object is a staging object that is not linked to any metaverse object. The attribute values of a disconnector object are not processed any further within the metaverse. This means that the attribute values of the corresponding object in the connected data source are not updated by MIIS 2003.

By using disconnector objects, you can store identity information in MIIS 2003 and process it at a later time. Keeping a staging object as a disconnector object in the connector space has many advantages. Because the system has already staged the required information about this object, it is not necessary to create a representation of this object again during the next import from the connected data source. This way, MIIS 2003 always has a complete snapshot of the connected data source, even if there is no current connection to the connected data source. Disconnector objects can be converted into connector objects, and vice versa, depending on the rules that you specify.

An import object is created as a disconnector object. An export object must be a connector object. The system logic enforces this rule and deletes every export object that is not a connector object. Without additional configuration, these objects are known as normal connector objects and normal disconnector objects.

You can prevent the identity management process from changing an object’s status as a connector object or disconnector object by marking it as an explicit disconnector object or explicit connector object. When you specify an object as an explicit disconnector object, MIIS 2003 continues to store identity information about the staging object, but it does not process the object until the object is converted to a normal disconnector object (that is, when it is no longer an explicit disconnector object). This enables you to change the synchronization logic that is applied during the identity management process without establishing another communication session with the connected data source. For example, you can change the criteria that you use to create e-mail names without having to reimport data from the connected data sources.

MIIS 2003 Identity Management Process

The identity management process controls how identity information is updated between different connected data sources. Identity management occurs in three processes:

• Staging

• Synchronization

• Export

During the staging process, MIIS 2003 evaluates the incoming identity information from a connected data source. When changes are detected, it either creates new staging objects or updates existing staging objects in the connector space for synchronization.

During the synchronization process, MIIS 2003 updates the metaverse to reflect changes that have occurred in the connector space and updates the connector space to reflect changes that have occurred in the metaverse.

During the export process, MIIS 2003 pushes out changes that are staged on staging objects and that are flagged as pending export.

The following illustration shows where each of the processes occurs as identity information flows from one connected data source to another.

Staging Process

During the staging process, MIIS 2003 evaluates updates to identity information. MIIS 2003 compares the identity information received from the connected data source with the identity information about a staging object and determines whether the staging object requires updates. If it is necessary to update the staging object with new data, the staging object is flagged as pending import.

By staging objects in the connector space prior to synchronization, MIIS 2003 can process only the identity information that has changed. This provides the following benefits:

• Efficient synchronization. The amount of data processed during synchronization is minimized.

• Efficient resynchronization. You can change how MIIS 2003 processes identity information without reconnecting MIIS 2003 to the data source.

• Opportunity to preview synchronization. You can preview synchronization to verify that your assumptions about the identity management process are correct.

For each object specified in the management agent, MIIS 2003 first tries to locate a representation of the object in the connector space of the management agent. MIIS 2003 examines all of the staging objects in the connector space and tries to find a corresponding staging object that has a matching anchor attribute. If no existing staging object has a matching anchor attribute, MIIS 2003 tries to find a corresponding staging object with the same distinguished name.

When MIIS 2003 finds a staging object that matches by distinguished name but not by anchor, the following special behavior occurs:

• If the object located in the connector space has no anchor, then MIIS 2003 removes this object from the connector space and marks the metaverse object it is linked to as “retry provisioning on next synchronization run.” Then it creates the new import object.

• If the object located in the connector space has an anchor, then MIIS 2003 assumes that this object has either been renamed or deleted in the connected directory. It assigns a temporary, new distinguished name for the connector space object so that it can stage the incoming object. The old object then becomes “transient,” waiting for the management agent to import the rename or deletion to resolve the situation.

If MIIS 2003 locates a staging object that corresponds to the object specified in the management agent, it determines what kind of changes to apply. For example, MIIS 2003 might rename or delete the object in the connected data source, or it might only update the object’s attribute values.

Note

MIIS 2003 handles changes from the connected data source for disconnector objects differently during staging. Instead of staging changes to the object so that they can be processed during synchronization, it applies the changes to the staging object immediately. In particular that means that if MIIS 2003 receives a deletion for a disconnector object, it deletes the object immediately.

Staging objects with updated data are marked as pending import. Different types of pending imports are available. Depending on the result of the staging process, a staging object in the connector space has one of the following pending import types:

• None. No changes to any of the attributes of the staging object are available. MIIS 2003 does not flag this as pending import.

• Add. The staging object is a new import object in the connector space. MIIS 2003 flags this as pending import for additional processing in the metaverse.

• Update. MIIS 2003 finds a corresponding staging object in the connector space and flags this as pending import so that updates to the attributes can be processed in the metaverse. Updates include object renaming.

• Delete. MIIS 2003 finds a corresponding staging object in the connector space and flags this as pending import so that the connector object can be deleted.

• Delete/Add. MIIS 2003 finds a corresponding staging object in the connector space, but the object types do not match. In this case, a “delete-add” modification is staged. A “delete-add” modification indicates to the synchronization engine that a complete resynchronization of this object must occur because different sets of rules will apply to this object when the object type changes.

By setting the pending import status of a staging object, it is possible to reduce significantly the amount of data processed during synchronization because doing so allows the system to process only those objects that have updated data.

Synchronization Process

Synchronization consists of two related processes:

• Inbound synchronization, when the content of the metaverse is updated by using the data in the connector space.

• Outbound synchronization, when the content of the connector space is updated by using data in the metaverse.

By using the information staged in the connector space, the inbound synchronization process creates in the metaverse the integrated view of the data that is stored in the connected data sources. Either all staging objects or only those with pending import information are aggregated, depending on how the rules are configured.

The outbound synchronization process updates export objects when metaverse objects change but are not deleted.

The following illustration shows how the synchronization process occurs within the two MIIS 2003 namespaces.

Inbound Synchronization

Inbound synchronization creates the integrated view in the metaverse of the identity information that is received from the connected data sources. MIIS 2003 can process identity information at any time by using the latest identity information that it has from the connected data source.

Inbound synchronization includes the following processes:

• Projection. MIIS 2003 creates a new metaverse object based on a staging object and links them. Projection is an object-level operation.

• Join. MIIS 2003 links a staging object to an existing metaverse object. A join is an object-level operation.

• Import attribute flow. MIIS 2003 updates the attribute values, called attribute flow, of the object in the metaverse. Import attribute flow is an attribute-level operation that requires a link between a staging object and a metaverse object.

Projection is the only process that creates objects in the metaverse. Projection affects only import objects that are normal disconnector objects. During projection, MIIS 2003 creates a metaverse object that corresponds to the object type of the import object and establishes a link between both objects, thus creating a connector object.

The following illustration shows the relationship between three distinct objects: an object in the connected data source, its representation as an import object in the connector space, and the corresponding metaverse object that MIIS 2003 creates during projection. Note that the import object that represents an object in the connected data source holds only a specified subset of the attributes associated with the original object, and that the object also has attributes that MIIS 2003 assigns to all connector space objects.

During staging, MIIS 2003 first performs object-level operations by creating a representation of object A in the form of an import object B in the connector space. During projection, MIIS 2003 creates object C in the metaverse based on information stored in object B and links them. After this object-level operation is complete, MIIS 2003 performs attribute-level operations. During these attribute-level operations, Object C is updated with the attributes from Object B.

The join process also establishes a link between import objects and a metaverse object. The difference between join and projection is that the join process requires that the import object be linked to an existing metaverse object, where the projection process creates a new metaverse object.

MIIS 2003 tries to join an import object to a metaverse object by using criteria that is specified in the management agent configuration.

The following illustration shows how multiple import objects can be joined to one metaverse object.

During the projection and join processes, MIIS 2003 links a disconnector object to a metaverse object, thereby making them connector objects. After these object-level operations are completed, MIIS 2003 can update the attribute values of the associated metaverse object. This process is called import attribute flow.

Import attribute flow occurs on all import objects that carry new data and are linked to a metaverse object.

Outbound Synchronization

Outbound synchronization updates export objects when a metaverse object changes but is not deleted. The objective of outbound synchronization is to evaluate whether changes to metaverse objects require updates to staging objects in the connector spaces. In some cases, the changes can require that staging objects in all connector spaces be updated. Staging objects that are changed are flagged as pending export, making them export objects. These export objects are subsequently pushed out to the connected data source during the export process.

Outbound synchronization has three processes:

• Provisioning

• Deprovisioning

• Export attribute flow

Provisioning and deprovisioning are both object-level operations. Deprovisioning depends on provisioning because only provisioning can initiate it. Deprovisioning is triggered when provisioning removes the link between a metaverse object and an export object.

Provisioning is always triggered when changes are applied to objects in the metaverse. When changes are made to metaverse objects, MIIS 2003 can perform any of the following tasks as part of the provisioning process:

• Create connector objects, where a metaverse object is linked to a newly created export object.

• Rename a connector object.

• Disconnect links between a metaverse object and staging objects, thereby creating a disconnector object.

If provisioning requires MIIS 2003 to create a new connector object, the staging object to which the metaverse object is linked is always an export object, because the object will not yet exist in the connected data source.

If provisioning requires MIIS 2003 to disconnect a connector object, thereby creating a disconnector object, deprovisioning is triggered. The deprovisioning process determines how MIIS 2003 processes the disconnector object. MIIS 2003 can either keep the staging object as a normal or explicit disconnector object in the connector space, or delete the object.

Note

During deprovisioning, deleting an export object does not physically delete the object. The object is flagged as “deleted,” which means that the delete operation is staged on the object.

Export attribute flow also occurs during the outbound synchronization process, similar to the way that import attribute flow occurs during inbound synchronization. Export attribute flow occurs only between metaverse and export objects that are linked.

Export Process

During the export process, MIIS 2003 examines all export objects that are flagged as pending export in the connector space, and then sends updates to the connected data source.

In some cases, MIIS 2003 has no way to determine whether the export has succeeded or failed. Connected data sources that use call-based management agents, such as Active Directory, can indicate the success or failure of the operation. But connected data sources that use file-based management agents cannot indicate to MIIS 2003 whether the export succeeded or failed.

However, even though MIIS 2003 can determine the success of an export for a call-based management agent, it cannot sufficiently determine that the identity management process is complete. Objects in the connected data source can always be changed by other processes. Because MIIS 2003 does not have a persistent connection to the connected data source, it is not sufficient to make assumptions about the properties of an object in the connected data source based only on a successful export notification.

For example, a process in the connected data source could change the object’s attributes back to their original values (that is, the connected data source could overwrite the values immediately after the data is pushed out by MIIS 2003 and successfully applied in the connected data source).

MIIS 2003 stores export and import status information about each staging object. If values of the attributes that are specified in the attribute inclusion list have changed since the last export, the storage of import and export status enables MIIS 2003 to react appropriately. MIIS 2003 uses the import process to confirm attribute values that have been exported to the connected data source. A comparison between the imported and exported information, as shown in the following illustration, enables MIIS 2003 to determine whether the export was successful or if it needs to be repeated.

For example, if MIIS 2003 exports attribute C, which has a value of 5, to a connected data source, it stores C=5 in its export status memory. Each additional export on this object results in an attempt to export C=5 to the connected data source again because MIIS 2003 assumes that this value has not been persistently applied to the object (that is, unless a different value was imported recently from the connected data source). The export memory is cleared as soon as C=5 is received during an import operation on the object.

From the perspective of MIIS 2003, export objects do not exist in the connected data source. To set the export object’s anchor attribute, MIIS 2003 has to import the object that has been exported.

Identity Management Process Summary

The following illustration summarizes the processes that occur during the identity management process and how they relate to MIIS 2003 namespaces. Note that the illustration summarizes only the processes that occur and does not represent an exhaustive list of the various rules that can be configured within MIIS 2003.

MIIS 2003 Administration User Interface

Identity Manager is the administrative interface for Microsoft® Forefront Identity Manager (FIM) 2010. Identity Manager includes the following features that you can use to accomplish specific tasks:

• Operations—Use Operations to track the run history of all management agents, including their status, errors, and synchronization statistics. You can also run management agents, save management agent run histories to file, and view the properties of the objects involved in the synchronization.

• Management Agents—Use Management Agents to create and edit management agents, configure run profiles for each management agent, or import or export management agents. You can also view import statistics and errors for the most recent run of a management agent, search the connector space for that management agent, or create a rules extension project.

• Metaverse Designer—Use Metaverse Designer to create new object types in the metaverse or to delete object types from the metaverse. In addition, you can add, edit, or delete attributes from any object type currently in the metaverse. This is also where you will specify attribute flow precedence for an attribute and configure object deletion rules for object types.

• Metaverse Search—Use Metaverse Search to locate and view objects in the metaverse. You can view the properties of the metaverse object and the properties of the connector objects that link to it.

• Joiner—Use Joiner to view the disconnected objects for a management agent. You can use Joiner to manually join a disconnected connector space object to a metaverse object, to project a connector space object into the metaverse, or change the type of the disconnector object.