Simple Account Provisioning: Scenario Design

Applies To: Windows Server 2003 with SP1

Previous Steps in This Walkthrough

1. Simple Account Provisioning Walkthrough

In this scenario, Fabrikam uses three management agents (MAs). These MAs facilitate the import and export of data source objects and attributes to and from the metadirectory.

Architectural Overview

Figure 2.1 illustrates the Microsoft Identity Integration Server 2003 system for Fabrikam.

Table 2.1 lists the management agents that you use in the Simple Account Provisioning scenario and their purpose.

Table 2.1   Fabrikam MAs

Microsoft Identity Integration Server 2003 and all of the management agents are located on the server running Microsoft Identity Integration Server 2003. Active Directory is installed on a different computer. For more information about computer configuration, see the “Lab Requirements” later in this scenario.

Object Operations and Attributes

Figure 2.2 shows the sequence of events that are described in this scenario: It demonstrates how objects that represent employees from the HR and telephone systems are joined in the metaverse as a single person object. Each of these metaverse objects is then sent to Active Directory as a user object.

Attributes of an Employee in the HR System

Table 2.2 lists the attributes of an employee in the Fabrikam HR system and sample values for each. The employeeID is the anchor attribute (unique and immutable within the HR system). The managerID attribute is a reference to the employeeID of the employee’s manager. For the employeeType and employeeStatus attributes, all possible values are listed.

Table 2.2   Attributes and Values for an Employee in the HR System

Employee Attributes in the Telephone System

Following is a list of the attributes of an employee in the Fabrikam telephone system:

• EMPID

• NAME

• TELEPHONE

• MOBILE

• PAGER

• FAX

The EMPID is the anchor attribute (unique and immutable within the telephone system).

Attributes of a User Object in Active Directory

Following is a list of the attributes of a user object in Active Directory:

• c

• cn

• co

• company

• department

• displayName

• employeeID

• facsimileTelephoneNumber

• givenName

• l

• manager

• mobile

• pager

• sAMAccountName

• sn

• telephoneNumber

• title

• unicodePwd

• userAccountControl

• userPrincipalName

Active Directory has a natural anchor, objectGUID, which is unique and immutable. The objectGUID attribute is set when the object is created. It is not used for any rules in this scenario. The management agent for Active Directory maintains it automatically.

Object Operations

Table 2.3 lists the operations you will perform along with the result of each modification. Each action is described in greater detail below.

Table 2.3   Simple Account Provisioning Operations and Results

Joining Objects

Objects from the HR and telephone systems are joined based on the employeeID attribute from the HR system and EMPID attribute from the telephone system.

Object Relationships

The HR system maintains a manager attribute, which contains the employeeID attribute of the manager of that person.

Populating the Metaverse

The HR system is the only authoritative source. This design has the following implications:

• Only the HR system can project objects (persons) into the metaverse in this account provisioning scenario.

• Only the HR system can delete objects (persons) from the metaverse. Microsoft Identity Integration Server 2003 permits the HR system to delete objects by either processing a delta import from the HR system, which marks them as terminated, or by processing a full import from the HR system where no data for the person exists.

Rules Flow

This section describes the rules that you configure in Microsoft Identity Integration Server 2003 to process this scenario.

Importing Employees

When an employee record that is not yet in the Microsoft Identity Integration Server 2003 system is imported from the HR system, it passes through the Microsoft Identity Integration Server 2003 synchronization and rules engine in the following steps:

1. Connector filter: When processing the import file from the HR system, Microsoft Identity Integration Server 2003 does not join or project employee objects with an employeeStatus attribute value of “terminated.” Employee objects that have attributes with this value remain as normal disconnector objects in the connector space for the HR system.

2. Join rules: Join rules are not defined and the join rules are skipped for objects from the HR system.

3. Projection rules: Projection rules define the method for deciding when to project an employee object that meets a specific condition into the metaverse as a person object. The scenario defines a declared projection rule, and the rules engine projects metaverse person object types for each object imported from the HR system that satisfies the connector filter.

4. Import attribute flow: After the projection, the import attribute flow rules are evaluated. The direct attribute mappings flow attribute values directly from the source attribute in the connected data source to the target attribute in the metaverse. The scenario also defines scripted attribute flow mappings. The rules engine calls the MapAttributesForImport method in the rules extension DLL. (For more information about rules extensions in this scenario, see “Scenario Rules Extensions” later in this walkthrough.)

Provisioning is not active, and no further action is taken.

Importing Telephone Numbers

Employee telephone numbers are imported from the telephone system by using the Fabrikam Telephone MA. To process this import, you set up join rules in the MA and, when the MA reads a new telephone record, Microsoft Identity Integration Server 2003 processes the rules as follows:

1. Join rules: In the Fabrikam Telephone MA, a join rule specifies that if the value of the EMPID attribute from the telephone system is equal to the value of the employeeID attribute on the metaverse object, the telephone system object is joined to the metaverse object. The join rule is also scoped on the connector space person objectType. This means that the join rule is evaluated by the Microsoft Identity Integration Server 2003 rules engine only when the imported record is of objectType person.

2. Projection rules: In this scenario, you do not set up any projection rules for telephone system objects. Microsoft Identity Integration Server 2003 stops processing connector space objects that do not meet the join criteria, leaving the object as a disconnector object in the connector space.

3. Import attribute flow: If the join rules found a match and the connector space object and metaverse objects are linked (that is, the connector space object is a connector object), Microsoft Identity Integration Server 2003 evaluates all import attribute flow mappings. The Fabrikam Telephone MA contributes values for four different phone number attributes to the metaverse object.

Provisioning is still not active, and no further action is taken.

Importing Active Directory Containers

To provision Active Directory user accounts from metaverse person objects, the container hierarchy into which Microsoft Identity Integration Server 2003 must export user accounts must exist in the Fabrikam AD MA connector space. The container hierarchy is created by doing an Import run of Fabrikam AD MA, in which Microsoft Identity Integration Server 2003 processes the rules as follows:

1. Join rules: In the Fabrikam AD MA, no join rule is evaluated by the Microsoft Identity Integration Server 2003 rules engine.

2. Projection rules: You do not set up any projection rules for Active Directory objects. Microsoft Identity Integration Server 2003 stops processing the imported objects and maintains a disconnector object in the Fabrikam AD MA connector space for each of the three organizational units (OUs) that are imported with this run profile.

Enabling Account Management and Export

After the identity data is aggregated within Microsoft Identity Integration Server 2003, the next step in the walkthrough is to configure account management and then export the identity data to Active Directory by performing the following steps.

1. Enable account management (provisioning): This enables the server running Microsoft Identity Integration Server 2003 to call the account management (provisioning) rules extension when metaverse objects change or when existing metaverse objects are treated as though they are new.

2. Synchronization Only run: When the HR MA is run with this profile, Microsoft Identity Integration Server 2003 calls a rules extension that creates connectors in the Fabrikam AD MA connector space.

3. Export attribute flow: Export attribute flow is called to flow all changed metaverse attribute values to the corresponding attributes on the connector space user object within the Fabrikam AD MA connector space. During the Synchronization Only run, Microsoft Identity Integration Server 2003 evaluates all rules and treats all metaverse attribute values as if they were new and flows their values to attributes mapped for export. Because export attribute flow mappings are defined in the Fabrikam AD MA, the connector objects are marked as pending for export. If other MAs with export attribute mappings exist, Microsoft Identity Integration Server 2003 also evaluates their export attribute flow mappings.

4. MA export run: When you run the Fabrikam AD MA for an export, the newly added user objects are created in the Fabrikam Active Directory. This run profile also runs an import from Active Directory to confirm the creation of the objects in Active Directory.

Employee Deactivated and Reactivated in the HR System

The employeeStatus attribute for an employee account in the HR system can be temporarily set to inactive. If this happens, the related Active Directory user object is disabled and moved to another organizational unit, called Disabled Users. When the employee is activated again, the Active Directory user object is enabled and moved back to the Enabled Users organizational unit. The provisioning rules extension determines the change and takes the appropriate action on the export object that is staged in the connector space that is used by the Fabrikam AD MA, as described in the following steps:

1. Import attribute flow: During an import run from the Fabrikam HR MA, the change of the employeeStatus attribute on an employee record triggers import attribute flow to update the employeeStatus attribute on the metaverse person object that represents the employee.

2. Account management (provisioning): Because provisioning is active, the change of the metaverse object triggers the rules engine to call the Provision method in the provisioning DLL, passing an object modification type of update. The provision method investigates the metaverse object and detects that the employeeStatus attribute has changed. Based on the change (that is, either active to inactive, or inactive to active) it constructs a new distinguished name (DN) for the export object of the Fabrikam AD MA. It then creates a link between the metaverse object and the export object.

3. Export attribute flow: Export attribute flow occurs after the link relationship between the metaverse object and the export object is established. Because the value of the employeeStatus attribute has changed, Microsoft Identity Integration Server 2003 evaluates all export attribute flow mappings that have this attribute as a source. For this scenario, the userAccountControl attribute of the export object uses the employeeStatus attribute of the metaverse object as its source. Because it is a scripted mapping, the MapAttributesForExport method within the Fabrikam AD MA rules extension DLL is called. The userAccountControl attribute is manipulated to either disable or enable the user object in Active Directory. These changes are added to the export object.

4. Export run: When you run the Fabrikam AD MA with an export step, all objects in its connector space staged exports are pushed to the Fabrikam Active Directory. In this case a rename happens and the attribute change is exported to Active Directory.

Employee Manager Changed in the HR System

The manager attribute of the metaverse object is based on the managerID attribute in the Fabrikam HR system. Microsoft Identity Integration Server 2003 handles all reference attributes and makes it easy to handle changes by simply defining the correct attribute flow rules and provisioning the change as follows:

1. Import attribute flow: The managerID and manager attributes are defined as referencebased attributes. A direct attribute flow mapping is defined between managerID and manager. As the managerID is changed, the Microsoft Identity Integration Server 2003 synchronization process calls the rules engine to apply the attribute flow mapping. Because it is a referencebased attribute, the synchronization engine ensures that the links between the metaverse and connector space objects within Microsoft Identity Integration Server 2003 are updated correctly.

2. Account management (provisioning): As import attribute flow changes the metaverse object, the Provision method of the account management (provisioning) rules extension DLL is called for this object with an object modification type of update.

3. Export attribute flow: Within export attribute flow, a direct attribute flow mapping exists that maps the manager attribute for the metaverse object to the manager attribute of the export object that is staged in the connector space for the Fabrikam AD MA. In Active Directory, the manager attribute is defined as a DNbased attribute. A modify operation is staged on the export object in the connector space of the Fabrikam AD MA.

4. Export run: When the Fabrikam AD MA is run for export, all changes to export objects in its connector space are pushed to the Fabrikam Active Directory. In this case, the manager distinguished name change is exported to Active Directory.

Employee Terminated in the HR System

When the employeeStatus attribute in the HR system is set to “terminated,” the metaverse person object that represents the employee is removed from Microsoft Identity Integration Server 2003 and the user object is removed from Active Directory as follows:

1. Connector filter: During an import run from the Fabrikam HR MA, the change of the employeeStatus attribute to “terminated” triggers the connector filter matching an exclusion condition for this attribute. This exclusion condition means this object should be left as a disconnector object. Because a projection to a metaverse object exists at this point, this projection is broken and disconnected by this rule.

2. Metaverse deletion rule: The disconnection that is triggered by the connector filter invokes the metaverse deletion rule. Because this scenario has a metaverse deletion rule configured to delete the metaverse object when a connector space object from the Fabrikam HR MA is disconnected, the metaverse object is deleted. This metaverse deletion causes all connector objects that existed for the metaverse object to become disconnector objects.

3. Deprovisioning: Whenever a connector space object is disconnected from its corresponding metaverse object, the Microsoft Identity Integration Server 2003 deprovisioning rule is called to determine what should happen with this disconnector object. The deprovisioning rule is specific to the MA. The Fabrikam AD MA is configured to delete the connector space object. However, the connector space object is not actually deleted from the Microsoft Identity Integration Server 2003 connector space, instead a delete operation is staged to be pushed out to Active Directory on the next export run. For the HR and Telephone MAs, the default deprovisioning option of leaving the connector space object as an explicit disconnector is set. This leaves the connector space object in the connector space and signals to Microsoft Identity Integration Server 2003 that this disconnector object should never be joined or projected again to the metaverse (that is, it is explicitly disconnected). No outgoing operations are staged to the telephone or HR systems.

4. Export run: The staged delete on the connector space object causes the Fabrikam AD MA to send a delete command for this object to Active Directory. This deletes the user object in the Fabrikam Active Directory. The connector space object will, however, stay in the connector space until the next import run of the Fabrikam AD MA confirms that the user object was deleted in Active Directory.

Employees Not Present in HR System

The last case in this scenario explains what Microsoft Identity Integration Server 2003 does if employee accounts are physically removed from the HR system. Microsoft Identity Integration Server 2003 handles a full dump of all employee accounts that does not contain employee records that were previously projected to the metaverse as follows:

1. Full import deletions: When a full import is run on the Fabrikam HR MA, the Microsoft Identity Integration Server 2003 synchronization engine marks every object in the connector space that is not received in the full import as “obsolete.” At the end of the MA run, it then removes these connector space objects from the connector space. The result is a delete operation of these connector space objects.

2. Metaverse deletion rule: The metaverse deletion rule is evaluated whenever a connector space object that is connected to a metaverse object is deleted or disconnected by Joiner, provided that the connector space object is not the last connector for the metaverse object. The Microsoft Identity Integration Server 2003 rules engine checks if an existing deletion rule specifies the deletion of the metaverse object. In this scenario, a metaverse deletion rule is defined that deletes metaverse objects whenever a deletion is received from the Fabrikam HR MA.

3. Deprovisioning: As a metaverse object is deleted, the MA-specific deletion rules are called. In the HR system case, Microsoft Identity Integration Server 2003 evaluates the metaverse deletion rules that lead to the disconnection of all linked connector space objects. This triggers deprovisioning. The result is that a delete is staged to the Fabrikam AD MA, and the connector space objects of the Fabrikam Telephone MA and Fabrikam HR MA are marked as explicit disconnector objects.

4. Export run: The staged delete on the connector space object causes the Fabrikam AD MA to send a delete for this object to Active Directory. This deletes the user object in the Fabrikam Active Directory. The connector space object will, however, remain in the connector space until the next import run of the Fabrikam AD MA confirms that the user object was deleted in Active Directory.

Next

• Lab Setup