1.4 Default Driver Configuration

The Active Directory driver is shipped with a default configuration file called ActiveDirectory.xml. When imported with Designer or iManager, this configuration file creates a driver with a set of rules and policies suitable for synchronizing with Active Directory. If your requirements for the driver are different from the default policies, you need to change them to effect the policies you want. Pay close attention to the default Matching policies. The data that you trust to match users usually is different from the default. The policies themselves are commented and you can gain a greater understanding of what they do by importing a test driver and reviewing the policies with Designer or iManager.

1.4.1 User Object Name Mapping

Management utilities for the Identity Vault such as iManager and ConsoleOne typically name user objects differently than the Users and Computers snap-in for the Microsoft* Management Console (MMC). Make sure that you understand the differences so the Matching policy and any Transformation policies you have are implemented properly.

1.4.2 Data Flow

Data can flow between Active Directory and an Identity Vault. The flow of data is controlled by the policies that are in place for the Active Directory driver.

Policies

Policies control data synchronization between Active Directory and an Identity Vault.

During the driver configuration, the Active Directory configuration file enables you to select several options that affect the default policies and filters created for you. The Table 1-1 lists these options and how they affect policies and filters that are created:

Table 1-1 Data Flow Options

Option

Description

Configure Data Flow establishes the initial driver filter which controls the classes and attributes that will be synchronized. The purpose of this option is to configure the driver to best express your general data flow policy. It can be changed after import to reflect specific requirements.

Bidirectional sets classes and attributes to synchronize on both the Publisher and Subscriber channels. A change in either the Identity Vault or Active Directory is reflected on the other side. Use this option if you want both sides to be authoritative sources of data.

AD to Vault sets class and attributes to synchronize on the Publisher channel only. A change in Active Directory is reflected in the Identity Vault but Identity Vault changes are ignored. Use this option if you want Active Directory to be the authoritative source of data.

Vault to AD sets classes and attributes to synchronize on the Subscriber channel only. A change in the Identity Vault is reflected in Active Directory but Active Directory changes are ignored. Use this option if you want the vault to be the authoritative source of data.

Publisher Placement controls where objects are created in the Identity Vault.

Mirrored places objects in the Identity Vault in the same hierarchy as they exist in Active Directory.

Flat places all objects in the base container in the Identity Vault specified during configuration.

Subscriber Placement controls how objects are placed in Active Directory.

Mirrored places objects in Active Directory in the same hierarchy as they exist in the Identity Vault.

Flat places all objects in the base container in Active Directory specified during configuration.

The Table 1-2 lists default policies and describes how selections during configuration affect the polices:

Table 1-2 Default Policies

Policy

Description

Create

Matching

Placement

In either the mirrored or flat hierarchy, you must define Full Name to create an Active Directory user as a user in the Identity Vault.

In a mirrored hierarchy, the Matching policy attempts to match an object in the same position in the hierarchy.

In a flat hierarchy, the Matching policy attempts to match the user with an object that has the same Full Name in the base container that you specify.

In a mirrored hierarchy, the Placement policy places all objects in a hierarchy that mirrors the hierarchy of the data store sending the operation.

In a flat hierarchy, the Placement policy places all objects in the base container that you specify.

Schema Mapping

The following Identity Vault user, group, and Organizational Unit attributes are mapped to Active Directory user and group attributes.

The mappings listed in the tables are default mappings. You can remap same-type attributes.

Table 1-3 Attributes Mapped for All Classes

eDirectory

Active Directory

CN

cn

Description

description

Facsimile Telephone Number

facsimiletelephoneNumber

Full name

displayName

Given Name

givenName

Initials

initials

Internet EMail Address

mail

L

physicalDeliveryOfficeName

Locality

locality

Login Disabled

dirxml-uACAccountDisabled

Login Expiration Time

accountExpires

Physical Delivery Office Name

l

Postal Code

PostalCode

Postal Office Box

postOfficeBox

S

st

SA

streetAddress

See Also

seeAlso

Surname

sn

Telephone Number

telephoneNumber

Title

title

eDirectory’s L attribute is mapped to Active Directory’s physicalDeliveryOfficeName attribute, and eDirectory’s Physical Delivery Office Name attribute is mapped to Active Directory’s L attribute. Because similarly named fields have the same value, mapping the attributes this way enable the attributes to work well with ConsoleOne and the Microsoft Management Console.

Table 1-4 Attribute Mapped for Users

eDirectory

Active Directory

CN

userPrincipalName

DirXML-ADAliasName

sAMAccountName

Login Allowed Time Map

logonHours

Table 1-5 Mapped Organizational Unit Attributes

eDirectory

Active Directory

Organizational Unit

organizationalUnit

OU

ou

Name Mapping Policies

The default configuration includes two name mapping policies that work together to help you reconcile different naming policies between the Identity Vault and Active Directory. When you create a user with the Active Directory Users and Computers tool (a snap-in for the Microsoft Management Console and abbreviated as MMC in this document) you see that the user full name is used as its object name. Attributes of the user object define Pre-Windows 2000 Logon Name (also known as the NT Logon Name or sAMAccountName) and the Windows 2000 Logon Name (also known as the userPrincipalName). When you create a user in the Identity Vault with iManager or ConsoleOne, the object name and the user logon name are the same.

If you create some users in Active Directory using MMC and other objects in the Identity Vault or another connected system that is synchronized with the Identity Vault, the object can look odd in the opposing console and might fail to be created in the opposing system at all.

The Full Name Mapping Policy is used to manage objects in Active Directory using the MMC conventions. When enabled, The Full Name attribute in the Identity Vault is synchronized with the object name in Active Directory.

The NT Logon Name Mapping Policy is used to manage objects in Active Directory using the Identity Vault conventions. When enabled, the Identity Vault object name is used to synchronize both the object name and NT Logon Name in Active Directory. Objects in Active Directory are named the same as the Identity Vault and the NT Logon Name matches the Identity Vault logon name.

When both of the policies are enabled at the same time, the Active Directory object name is the Identity Vault Full Name, but the NT Logon Name matches the Identity Vault logon name.

When both policies are disabled, no special mapping is made. The object names is synchronized and there will be no special rules for creating the NT Logon Name. Because the NT Logon Name is a mandatory attribute in Active Directory, you need some method of generating one during add operations. The NT Logon Name (sAMAccountName) is mapped to the DirMXL-ADAliassName in the Identity Vault, so you could either use that attribute to control the NT Logon Name in Active Directory or build your own policy in the Subscriber Create policies to generate one. With this policy selection, users created with MMC uses the object name generated by MMC as the object name in the Identity Vault. This name might be inconvenient for login to the Vault.

Windows 2000 Logon Name Policies

The Windows 2000 Logon name (also known as the userPrincipalName or UPN) does not have a direct counterpart in the Identity Vault. UPN looks like an e-mail address (user@mycompany.com) and might in fact be the user’s e-mail name. The important thing to remember when working with UPN is that it must use a domain name (the part after the @ sign) that is configured for your domain to be used successfully. You can find out what domain names are allowed by creating a user using MMC and inspecting the domain name drop-down box when adding the UPN.

The default configuration offers several choices for managing userPrincipalName. If your domain is set up so that the user’s e-mail address can be used as a userPrincipalName, then one of the options to track the user’s e-mail address is appropriate. You can make userPrincipalName follow either the Identity Vault or Active Directory e-mail address, depending on which side is authoritative for e-mail. If the user e-mail address is not appropriate, you can choose to have a userPrincipalName constructed from the user logon name plus a canned domain name. If more than one name can be used, update the policy after import to make the selection. If none of these options are appropriate, then you can disable the default policies and write your own.

Entitlements

Entitlements make it easier to integrate Identity Manager with Identity Manager User Application and Role-Based Services in eDirectory. When using User Application, an action such as provisioning an account in Active Directory is delayed until the proper approvals have been made. When using Role-Based Services, rights assignments are made based on attributes of a user object and not by regular group membership. Both of these services offer a challenge to Identity Manager because it is not obvious from the attributes of an object whether an approval has been granted or the user matches a role.

Entitlements standardize a method of recording this information on objects in the Identity Vault. From the driver perspective, an entitlement grants or revokes the right to something in Active Directory. You can use entitlements to grant the right to an account in Active Directory, to control group membership, and to provision Exchange mailboxes. The driver is unaware of User Application or Role-Based Entitlements. It depends on the User Application server or the Entitlements driver to grant or revoke the entitlement for a user based upon its own rules.

You should enable entitlements for the driver only if you plan to use User Application or Role-Based Entitlements with the driver.