2.5.1 Multivalue Attributes

The way the Active Directory driver handles multivalue attributes has changed from version 2.

Version 2 treated multivalue attributes as single-valued on the Subscriber channel by ignoring all but the first change value in an Add or Modify operation. Version 3 of the Active Directory Driver fully supports multivalue attributes.

However, when the Active Directory driver synchronizes a a multivalue attribute with a single-value attribute, the multivalue attribute is treated as single-valued. For example, the Telephone Number attribute is single-valued in Active Directory, and multivalue in the Identity Vault. When this attribute is synchronized from Active Directory, only a single value is stored in the Identity Vault.

This creates true synchronization and mapping between the two attributes, but can result in a potential loss of data if you have multiple values in an attribute that is mapped to an attribute with a single value. In most cases, a policy can be implemented to preserve the extra values in another location if required in your environment.

2.5.2 Managing Account Settings Using Custom Boolean Attributes

The Active Directory attribute userAccountControl is an integer whose bits control logon account properties, such as whether logon is allowed, passwords are required, or the account is locked. Synchronizing the Boolean properties individually is problematic because each property is embedded in the integer value.

In version 2, the Active Directory driver took a shortcut that let you map userAccountControl to the eDirectory Login Disabled attribute, but didn’t let you map the other property bits within the attribute.

In version 3, each bit within the userAccountControl attribute can be referenced individually as a Boolean value, or userAccountControl can be managed in-total as an integer. The driver recognizes a Boolean alias to each bit within userAccountControl. These alias values are included in the schema for any class that includes userAccountControl. The alias values are accepted on the Subscriber channel and are presented on the Publisher channel.

The advantage to this feature is that because each bit can be used as a Boolean, the bit can be enabled individually in the Publisher filter and accessed easily. You can also put userAccountControl into the Publisher filter to receive change notification as an integer.

The integer and alias versions of userAccountControl should not be mixed in a single configuration.

The following table lists available aliases and hexadecimal values. Read-only attributes cannot be set on the Subscriber channel.

For troubleshooting tips relating to the userAccountControl attribute, see Section 8.9, Active Directory Account Disabled after a User Add on the Subscriber Channel.

2.5.3 Provisioning Exchange Mailboxes using the homeMDB Attribute

Options for provisioning Exchange 2000 and Exchange 2003 mailboxes have changed from version 2.

In Version 2, Exchange provisioning was accomplished by setting attributes on User objects. A Microsoft program (the Recipient Update Service) used this information to provision the Exchange database.

This method still works in version 3 of the Active Directory Driver, but a new method (CDOEXM) has been added. With CDOEXM enabled, an Exchange mailbox is provisioned by setting the homeMDB attribute. When the homeMDB attribute is set, the driver automatically sets all required attributes.

The homeMDB attribute is set during initial configuration, but you can change the setting by modifying the driver policy. For a discussion of this parameter, see Section 4.3, Configuration Parameters.

2.5.4 Expiring Accounts in Active Directory

If you map the eDirectory attribute of Login Expiration Time to the Active Directory attribute of accountExpires, the account in Active Directory expire a day earlier than the time set in eDirectory.

This happens because Active Directory sets the value of the accountExpires attribute in full-day increments. The eDirectory attribute of Login Expiration Time uses a specific day and time to expire the account.

For example, if you set an account in eDirectory, to expire on July 15th, 2006, at 5:00 p.m., the last full day this account is valid in Active Directory is July 14th.

If you set the account in the Microsoft Management Console, to expire on July 15th, 2006, the eDirectory attribute of Login Expiration Time is set to expire on July 16th, 2006 at 12:00 a.m. Because the Microsoft Management Console doesn’t allow for a value of time to be set, the default is 12:00 a.m.

The driver uses the most restrictive settings. You can add an additional day to the expiration time in Microsoft depending upon what your requirements are.

2.5.5 Retaining eDirectory Objects When You Restore Active Directory Objects

Any Active Directory objects that are restored through the Active Directory tools delete the associated eDirectory object when the objects are synchronized. The Active Directory driver looks for a change in the isDeleted attribute on the Active Directory object. When the driver detects a change in this attribute, a delete event is issued through the driver for the object associated with the Active Directory object.

If you don’t want eDirectory objects deleted, you must add an additional policy to the Active Directory driver. Identity Manager 3.0.1 comes with a predefined rule that changes all Delete events into Remove Association events. For more information, see Command Transformation - Publisher Delete to Disable in the Policy Builder and Driver Customization Guide.