2.5 Becoming Familiar with Driver Features

This section discusses driver features you should become familiar with before deploying the Active Directory driver.

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 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 this is required in your environment.

2.5.2 Using Custom Boolean Attributes to Manage Account Settings

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 difficult 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 of this is that each bit can be used as a Boolean, so 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.

Table 2-3 Aliases and Hexadecimal Values

Alias

Hexadecimal

Notes

dirxml-uACAccountDisable

0x0002

Read-write

dirxml-uACDontExpirePassword

0x10000

Read-write

dirxml-uACEncryptedTextPasswordAllowed

0x0080

Read-write

dirxml-uACHomedirRequired

0x0008

Read-write

dirxml-uACInterdomainTrustAccount

0x0800

Read-only

dirxml-uACNormalAccount

0x0200

Read-only

dirxml-uACPasswordCantChange

0x0040

Read-only

dirxml-uACScript

0x0001

Read-write

dirxml-uACPasswordNotRequired

0x0020

Read-write

dirxml-uACServerTrustAccount

0x2000

Read-only

dirxml-uACWorkstationTrustAccount

0x1000

Read-only

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

2.5.3 Provisioning Exchange Mailboxes

The Active Directory driver can be configured to provision Exchange accounts as well as Active Directory accounts. The Active Directory driver can provision Exchange 2003 and Exchange 2007 accounts. For information on configuring the driver to provision the Exchange mailboxes, see Section C.0, Provisioning Exchange Accounts.

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, an account in Active Directory expires 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 15, 2007, at 5:00 p.m., the last full day this account is valid in Active Directory is July 14.

If you use the Microsoft Management Console to set the account to expire on July 15, 2007, the eDirectory attribute of Login Expiration Time is set to expire on July 16, 2007 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 4.0 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 Policies in Designer 3.5 guide.