Scenario

Forest ONE:  Single Windows 2003 domain.  Exchange 2003.
Forest TWO:  Single Windows 2003 domain.  Exchange 2003.

Forest ONE has mailbox-enabled user accounts that need to appear as contacts in Forest TWO.

Forest ONE user accounts are located in an OU named ONE Users.
Forest TWO contacts representing the Forest ONE users are located in an OU named ONE Contacts.

The following new accounts have been created for use with the IIFP Management Agents (MAs):

ONE\IIFPSVC
TWO\IIFPSVC 

These accounts are specified during the setup of the MAs, as shown in the screenshot below.

DomainDNS object permissions

 
In both domains, the MA needs to be able to capture the information that has changed (the delta).  This allows the MA to be more efficient – the alternative would be to import the entire set of information every time and then work out the changes.  In order to determine the information that has changed, the account used by the MA must have Replicate Directory Changes permission on the domainDNS object (i.e. the top of the domain partition).  The screenshot below shows this permission in place for the one.dom domain (DC=ONE,DC=DOM) in the ONE Forest. 

Note.  The same permission must be set in the second forest (TWO in our scenario).

Permissions required on source OU containing mailbox-enabled user objects.

You might expect that the MA account would only require READ permissions on the source OU containing the user objects to be synchronised.  This is true for the most part, but the account also needs to be able to write the proxyAddresses attribute value.  The reason for this is that, as part of its joining rules, IIFP GAL Sync copies the value of the legacyExchangeDN attribute on the mailbox-enabled user object and appends this as a new X500 address into the proxyAddresses attribute (which is multi-valued).  Why it does this is not entirely clear to me.  One explanation is that it is a helpful measure to ensure that replies to migrated mailboxes are routed correctly.  Whatever the underlying reason, the IIFP generates errors if this explicit permission is not set. 

In our scenario the ONE\IIFPSVC account needs Write Proxy Addresses permissions on User objects in the ONE Users OU.

Hint.  Unfortunately, Proxy Addresses does not appear in the default list of properties in the SACL editor.  You have to modify the DSSEC.DAT file to expose the property.  For information on how to do this see: 

http://www.activedir.org/article.aspx?aid=24#11

Permissions required on AdminSDHolder container object.

Something I noticed was that I received permissions errors when synchronising some objects, but not others.  Those that generated the errors turned out to be objects that are protected by the AdminSDHolder.  To work around this it is necessary to allow the MA account permissions to write the proxy addresses property value on the AdminSDHolder container object.  The write property must be set on This Object (as opposed to User Objects).  The ACL associated with the AdminSDHolder container is matched once per hour (by default) to all protected objects (i.e. those that have an adminCount attribute value equal to 1).  If the protected object's ACL differs to that of the ADminSDHolder it is overwritten so that the two match.

You will not be able to to set permissions on the AdminSDHolder container object using Active Directory Users and Comptuers.  Use ADSIEdit instead.

The path of the adminSDHolder container is: CN=AdminSDHolder,CN=System,DC=<Domain>,DC=<TLD>

Permissions required on target OU containing contact objects

The IIFP MA responsible for Forest TWO needs to be able to create, delete and modify Contacts.  To do this the associated account must have the following permissions on the target OU (ONE Contacts in our scenario).  The screenshots below show the appropriate settings.

Exchange permissions.

The documentation from Microsoft indicates that the accounts used by the MA should have View-Only Administrator permissions within Exchange – see below.

Among other permissions, the Gal Sync management agent requires the Read Only Delegation permission on the Exchange Organization object. Without this permission, the management agent will be unable to browse Administrative Groups.

I found that I did not need to set this permission, but your experience may differ.  I suspect that this is only required in environments that have mixed mode Exchange organisations with Exchange 5.5.

Troubleshooting

The IIFP interface is fairly quick to show permissions errors if you configure something incorrectly.  You will see this as individual export errors in the Connection Status pane of the Management Agents window.  The information provided in the errors is not usually sufficient to show you exactly what the problem is.  I found it helpful to configure Directory Service Access auditing (including Failure events) on the OUs I was working with.  Once you have done this, look for 566 events in the security event logs on your DCs.  An example is shown below.

 Tony Murray

25th September 2006