Corelan Cybersecurity Research

Introduction

The title of this post may be a bit misleading – synchronizing multiple account domains to a single domain or forest is not limited to Exchange. There may be other reasons (e.g. Identity Management solution) that require you to replicate users from multiple domains into a single domain/forest, or even ADAM instance.

In this blog post, I will show you a possible IIFP implementation that has some specific requirements. In my scenario, IIFP will be used to replicate user objects from multiple account domains into one centralized resource forest, and it will be used replicate back the “mail” and “proxyAddresses” attributes from the Resource Forest to the account domains.  Furthermore, I also need to replicate user objects from a domain that is not used for authenticate users or link mailboxes to, but merely to add the users as contacts in the Resource Forest in order to further populate the address book.

So, in short :

• There are multiple account domains, that contain user accounts.  These user accounts are used to authenticate to Exchange server 2007 and will be used to link mailboxes to.  There will be two way replication for these objects, because we want to let Exchange populate the “mail” and “proxyAddresses” attributes, and send them back from the Resource Forest to the Account Domains.
• There is one Exchange Resource Forest, that contains all of the Exchange Servers.  This forest does not have real user accounts that have a mailbox.  It is only used to host the Exchange environment and to host the objects (disabled user accounts and contacts) that will populate the address book (GAL)
• There is one “foreign” domain (domain not managed by you) that contains user objects. You want to add those users to your GAL, so you want to sync the objects to the Resource Forest and store them as contacts.  There will be one way replication for these objects.

In order to accomplish this, we need MIIS (now ILM) or IIFP.  Since IIFP is free and will do what we want to do, we’ll use IIFP for this purpose.  You can download IIFP from here : Download details- Microsoft Identity Integration Feature Pack SP2. Before installing IIFP, make sure to check the system requirements (see Microsoft Download Page)

Requirements

In order to be able to install and run IIFP, you need to have

• Windows Server 2003 Enterprise Edition, standalone (you don’t need to make it member of a domain)
• SQL Server (2005 Standard Edition will do just fine)
• Visual C# (or VB) 2005 Express Edition (free) : Download Now
• User accounts with correct permissions :
  • For each Account Domain, you need to have a user account, that has a very strong password, and account set to never expire.  This is not really a requirement, so unless you have a process that will make sure you change all passwords when the account expires, you can set the account to never expire.  This user account must have
    • Read access on all user objects, all (or most) attributes.  If you really want to limit the read access, then check the list of attributes that will be synchronized below and make sure the account only has access to these attributes
    • On the domain level, the user account needs to have “Replicate Directory Changes” and “Replicate Directory Changes All” permissions. If not, it will not be able to synchronize.
    • Write permissions on the “mail” and “proxyAddresses” attributes.  By default, these 2 attributes are hidden when you edit security in AD Users & Computers.  You can make these fields visible by editing c:\windows\system32\dssec.dat on your management station, look for the [user] section, and then locate the mail and proxyAddresses entries. By default, the value for these attributes is set to 7, so you need to change it to 0 in order to make the fields visible.   Save the file and then open AD U&C again.  The fields will now be visible.
  • In the Resource Domain, you need to create a user account, with very strong password, never expire, that has permissions to
    • Create user objects and account objects and has permission to write all attributes (again, if you want to limit the permissions, you can have a look at the list of attributes later on, and further refine the permissions).
    • On the Domain Level, “Replicate Directory Changes” and “Replicate Directory Changes All”
    • Read access on all user objects
  • On the server hosting IIFP, a user account that will have access to the IIFP SQL database, and can be used to run Scheduled Tasks.

When you have the service accounts set up, you can install and configure IIFP

IIFP Installation

Install the following applications :

• SQL Server, with Mixed Mode Authentication. The user account that is used to run IIFP (and that will be used to run the scheduled tasks later on needs to have access to the IIFP database, and will need to have read/write permissions to c:\iifpconfig folder and files (see later))
• Visual C# 2005 Express Edition. Don’t forget to register so you get a registration key.
• IIFP with SP2

Short Introduction to IIFP

In a default installation, IIFP can only be used to “join” existing objects in multiple domains/ADAM instances together and synchronize attributes.  (Note : if you need to sync objects from instances other than AD or ADAM, you need to purchase the MIIS/ILM tool from Microsoft).

This means that, out of the box, IIFP cannot create new objects. You need custom scripting for that.  There is a second limitation : it cannot synchronize the unicodePwd field, which contains the AD password.  If you want passwords to be synched, you need to set up PCNS on your Domain Controllers, which will catch all password change events, and notify IIFP to set this new password on the target object.

IIFP uses a SQL database, called the “Metaverse” to host all objects and links between those objects (connectors).  When you are getting information from an Account Domain, you will be importing objects/attributes to the metaverse.  When you want to write information to the Resource Forest, you will be exporting objects and/or attributes from the metaverse.  When you want to get the “mail” and “proxyAddresses” attributes from the Resource Forest and sync them to the corresponding object in the Account Domain, you will be “importing” from the Resource Forest and “exporting” to the Account Domain.

You will need to create a Management Agent for each AD – Metaverse combination. So you need to create a Management Agent for each “Account Domain to/from Metaverse combination” and you need to create one Management Agent for the “Resource Forest to/from Metaverse link”.

For each Management Agent, you will need to create a “Run Profile”, that contains the import and/or export steps.  We will talk about the details of these Run Profiles later on, as well as the technique to trigger these steps using Windows Scheduled Tasks.

When a Management Agent has been created and when an import step has ran, it defines the “Connected Datasource” for an object.  When the object has a connector to an object in another domain, it becomes part of the Connector Space. All objects in the Connector Space (CS) have 2 attributes : a GUID and the distinguished Name (DN), and they may have an anchor attribute (which will help to uniquely identify the object in the Connected Datasource).  IIFP assumes that this anchor never changes over the lifetime of the object. (such as a GUID)

The Connected Datasource (CD) uses the Management Agent to connect to the Metaverse (MV). This connection can be one way or two way. It can only use a one-way step in the Run Profiles (so you can either run an import or an export, but not both at the same time), but a Run Profile can contain both an import and export step, allow the data to flow in both directions.

The metaverse has a couple of object type definitions (such as person,  group, computer, etc) and corresponding attributes.  You can create new object types and create attributes.  We will have to do both in order to make our scenario work.

When you want IIFP to create objects, you need to write a Rule Extension. The IIFP terminology to create anew object is called “provisioning”.    IIFP comes with a GALSync dll (Rule Extension) that will help you poplating/synchronizing GAL’s, but since we need to do more than this, we cannot use it.  However, the source code for Galsync.dll is also installed when you install IIFP, so you can use it to learn writing your own Rule Extension.

You can find more information about IIFP and the basics of Rule Extensions on the following websites :

• http://mostlyexchange.blogspot.com/2006/08/using-microsofts-iifp-identity.html
• http://msmvps.com/blogs/clustering/archive/2004/10/06/15141.aspx
• Setting up IIFP
• Configuring IIFP to Sync User Attributes
• http://www.microsoft.com/downloads/details.aspx?familyid=d7894cc9-eeeb-40d9-8f5f-573050624f67&displaylang=en (!! This page has some excellent documents about IIFP and how it works !  I recommend you to read these pages before you go on with this blog post)

Specific Features

The solution we are going to put in place has some specific features that will require some specific settings and scripts.

1. In our scenario, there are multiple Account Domains and there is only one Resource Forest. The various Account Domains are managed by different IT staffs.  An AD object needs to be unique.  The source objects (users in the Account Domains) will be unique by default (because they have to be unique within each domain). Because we have multiple “source” domains, we don’t know if the new object that needs to be created in the “target” Resouce Forest will be unique. So we need to take care of duplicate objects in the IIFP provisioning process..  Furthermore, when IIFP tries to create a user object that already exists, we need to warn the local Account Domain Administrator and ask them to rename the cn/sAMAccount attribute for that object so it can become unique.

2. We would like to be able to filter the objects that must be created in the Resource Forest.  The Account domain not only contains regular user accounts, but also contains administrator accounts, service accounts, etc.  We don’t want these accounts to be provisioned and synchronized to the Resource Forest.

3. We need to be able to take the user accounts from various OU’s in a source Account Domain and store them into one or more OU’s in the target Resource Forest. The OU structure in the Resource Forest may have a different layout than the OU structure in the Account Domains.

4. We need to grab the user accounts from a third party domain and convert them into contacts in the Resource Forest.  Furthermore, these contacts must be visible in the GAL.

Solution

I have created a Rules Extension dll that will take care of all of these requirements.  This dll uses a couple of configuration files, that will help with

• mapping source OU’s to target OU’s (mapping.cfg), and (optionally) set a fixed password. If no fixed password is defined, a random strong password (20 characters) will be used.
• determine whether an object needs to be synchronized or not (allow groups and deny groups), and define how to connect to a domain in order to perform group member lookups for this purpose (allow.cfg and deny.cfg). Since the script needs to be able to connect to a domain and perform group member lookups, a connection file must be created (connection.cfg) The use of these groups is optional.
• determine whether an object needs to become a user or contact, and in case of a contact, define the GAL it needs to become part of (mapping.cfg)
• determine who needs to be alerted (and define smtp parameters for this purpose) in case an attempt to create a duplicate object was detected (admins.cfg and smtp.cfg)
• troubleshooting. A logfile is created that contains detailed information of the entire process, which will help you to troubleshoot in case of problems (Hardcoded path c:\iifpconfig\logfile.txt)

The Rules Extension dll, together with 2 other dll’s (that will help performing some of the other tasks as layed out above) need to be stored in the Extensions folder : C:\Program Files\Microsoft Identity Integration Server\Extensions

Download :

Furthermore, you will need to create some Attributes in the Metaverse Designer and you will also need to create a new Object type called “contact” so you can use this to create contacts in the Resource Forest.

After all Management Agents & Run Profiles have been created, and the configuration files have been put in place, the provisioning process will work like this (click image for a larger view):

Configuring IIFP

1. Create object type and additional attributes :

• Open IIFP “Identity Manager”.
• Click the Metaverse Designer button

Add attribute to “person” object type

• In the upper half of the window, select “Person”
• In the lower half of the window, click Add Attribute
• In the “Add Attribute to Object Type” window, click New Attribute
• Enter Attribute name  DistName. This attribute is required in the Rules Extension in order to determine the object’s source OU location (so we can map the source OU to the target OU). The attribute name is used in the dll, so pay attention to the exact object name.

Click OK to save the new attribute.

• Add a second attribute, called  proxyAddresses (multi-valued string)

Create “contact” object type and add attributes to the contact object.

• In the upper half of the window, select “person”
• In the right hand pane, under “Actions”, select “Copy Object Type”
• Provide a new Object type name :  contact
• Select the newly created contact object type and review the list of attributes in the lower half of the window.  You don’t need all of the attributes, but some of the attributes are really necessary.  In my setup, the following attributes are part of the “contact” object type, so it may be wise to use the same list of attributes :

• Create a new string attribute for “contact”, called “showInAddressBook”  and verify that it is now also member of the list of attributes for object type contact.

Make sure the “uid” attribute is indexed

The last step that is required before we can continue is to make sure the uid attribute is indexed. This attribute is mapped to the sAMAccountName attribute and in order to speed up the Metaverse lookups, we need to index this field.  Select “uid” from the list of attributes. Right-click and choose “Edit attribute”.

Enable “Indexed” and click OK to save

2. Put dll’s and configuration files in place

Put dll’s in place

After downloading the 3 dll’s (download link : see above), make sure they are saved under C:\Program Files\Microsoft Identity Integration Server\Extensions

Put configuration files in place

Create a folder called C:\IIFPConfig

This folder is hardcoded in the dll, so you must keep this folder name !

You will need to create the following configuration files :

c:\iifpconfig\mapping.cfg

Syntax :

sourceOU[tab]targetOU[tab]type of object to create[tab]Name of Management Agent that connects to Resource Forest[tab]Optional DN of GAL / fixed password

• All of the fields in this file need to be tab separated.
• The “type of object to create” can be either “user”   or   “contact” (without the quote)
• The “Name of Management Agent that connects to Resource Forest” can be any name at this point, but you will need to use the same name when creating the Management Agent that connects to the Resource Forest later on.  In this example, I will use “MA Resource Forest” to refer to the MA that syncs users with users, and use “MA Resource Forest Contacts” to refer to the MA that syncs users with contacts.
• If you specify “user” as type of object, you can (optionally) add a fifth parameter that will be used as fixed password. If you don’t put in a fifth parameter, a random (strong) password (20 characters) will be created.
• If you specify “contact” as type of object, you will need to add a fifth parameter that contains the DN of the GAL where the contact needs to be added to.  You can find this name using the following Exchange cmd-let :

[PS] C:\>Get-GlobalAddressList | FL Name,DistinguishedName

Name              : Default Global Address List
DistinguishedName : CN=Default Global Address List,CN=All Global Address Lists,CN=Address Lists Container,CN=Testlab,
                    CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=resourceforest,DC=com

This file is very important because it describes the layout of the OU’s in the Account Domains and the mapping to the Resource Forest.

Example :

Account Domain 1 :  domain.com

Account Domain 2 :  domain2.com

Domain 3 : remotedomain.com (contains user accounts that need to be converted into contacts in the resource forest, and added to the GAL on the Resouce Forest)

Resource Forest : resourceforest.com

Suppose you want to provision user objects

from   OU=City1,OU=Company,DC=domain,DC=com  and

from   OU=City2,OU=Company,DC=domain,DC=com  and

to     OU=Users,OU=Company,DC=resourceforest,DC=local

and from   OU=Location1,OU=City,DC=domain1,DC=com, and set a fixed password of “FixedPassW0rd!”

to   OU=Users,OU=Company2,DC=resourceforest,DC=local

and you want to add the user objects

from  OU=All Users,DC=remotedomain,DC=com   and convert them into contacts

to    OU=Remote Domain,DC=resourceforest,DC=local

(Since we need to use a separate Management Agent to sync users with contacts, we will specify a different Management Agent.)

then you need to put the following 4 lines in the mapping.cfg file :

OU=City1,OU=Company,DC=domain,DC=com    OU=Users,OU=Company,DC=resourceforest,DC=local    user    MA Resource Forest
OU=City2,OU=Company,DC=domain,DC=com    OU=Users,OU=Company,DC=resourceforest,DC=local    user    MA Resource Forest
OU=Location1,OU=City,DC=domain1,DC=com    OU=Users,OU=Company2,DC=resourceforest,DC=local    user    MA Resource Forest    FixedPassW0rd!
OU=All Users,DC=remotedomain,DC=com    OU=Remote Domain,DC=resourceforest,DC=local    contact    MA Resource Forest Contacts    _
                                         CN=Default Global Address List,CN=All Global Address Lists,CN=Address Lists Container, _

                                         CN=Testlab,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=resourceforest,DC=local

Notes :

1. Make sure to put the name of the GAL on the same line, separated by a tab from the “Management Agent” name. I have used underscores to indicate that the text that follows should be added to the same line. After all, you can only put one entry on a line, and an entry should be place on one line only.

2. You need to create the OU structure in the Resource Forest yourself.   The provisioning process will not create any OU’s. Based on the example, you need to create the following OU structure in the Resource Forest :

BaseDN : DC=resourceforest,DC=local

OU : All Users

OU : City

Sub OU : Location 1

OU : Company

Sub OU : City 1

Sub OU : City 2

c:\iifpconfig\connection.cfg

This file describes how the dll can connect to the various domains in order to perform group membership lookups.

For each domain involved, you need to create a single line, using the following syntax :

BaseDN of the domain[tab]DNS Domain Name[tab]hostname/ipaddress(es) of the DC’s[tab]ldap port[tab]username[tab]password

Again, parameters in this file must be tab separated.
In the hostname/ipaddress(es) field, you can specify multiple hostnames/ip addresses, but they must be comma separated.

Currently, the dll only supports doing regular ldap lookups (not ldaps)

In our example, we need an entry for each account domain (3 entries in total), so the connection.cfg file would look like this :

DC=domain,DC=com    domain.com    192.168.0.1,192.168.0.2    389    IIFPReadAccount    MyStr0ngP@ssword!
DC=domain1,DC=com   domain1.com   192.168.10.1,dc2.domain1.com    389    IIFReadOnlyAccount    MyStrOnGP4sSw0rd!
DC=remotedomain,DC=com    remotedomain.com    10.1.1.2,10.2.2.3    389    RemoteIIFPROAccount    ThisIsMyStrongPasswordAgain?

c:\iifpconfig\allow.cfg and c:\iifpconfig\deny.cfg

These 2 optional files must be created as follows :

BaseDN[tab]Name of group

If the deny.cfg group is present, the provisioning process will see if there is an entry for the new object in the deny group.   If the DN of the object ends with with one of the entries in the deny.cfg file, the dll will get all members of the matching group (recursively !) and if the object appears to be a member, it will not be synced.

If the deny.cfg file is not present, or if the deny.cfg file has no match, the process will continue (assuming that it needs to provision).

Next, it will check the allow.cfg file.  If the file is not present (and if the deny.cfg file has no match either), the object will be provisioned.

If there is an allow.cfg file, a lookup in this cfg file will be performed.  If it does not find a valid entry for the object (and if the deny.cfg file did not have a match either), the object will be provisioned.

If there is an allow.cfg file, a lookup in this cfg file will be performed. If a valid match for the object is found (so if the DN of the object ends with one of the entries in the allow.cfg file), then the dll will get all members of the matching group (recursively !). If the object appears to be a member, it will be provisioned.  If not, it will not be provisioned. (So pay attention when you create an allow.cfg file.  Using an allow.cfg file may be harder to troubleshoot than using a deny.cfg file)

Suppose we do not want to provision the members of Administrators, Domain Admins and a group called “IIFP-DontSync” for each of the Account Domains, and you also don’t want to sync the users from the remotedomain when they are in a group called IIFP-DoNotSync  then you need to put the following entries in a deny.cfg file :

DC=domain,DC=com    Administrators
DC=domain,DC=com    Domain Admins
DC=domain,DC=com    IIFP-DontSync
DC=domain1,DC=com    Administrators
DC=domain1,DC=com    Domain Admins
DC=domain1,DC=com    IIFP-DontSync
DC=remotedomain,DC=com    IIFP-DoNotSync

I would strongly recommend to only use a deny.cfg file, and only use a allow.cfg file if it is really necessary.  Also, try to limit the number of groups. The more groups, the longer a group membership lookup cycle may take, and the longer the provisioning process will take.

c:\iifpconfig\admins.cfg  and  c:\iifpconfig\smtp.cfg

These 2 files

– describe who (email address) is responsible for a certain domain or OU in a domain

– describe smtp server parameters so the dll can send out emails

These files are used to alert admins when an attempt to create a duplicate object is detected.  If you don’t create those files, or if these files are empty, no email alerts will be sent.

The admins.cfg file looks like this :

DN of OU or domain in the source Account Domain[tab]comma separated email address(es) of admins to alert

Sample file (again, tab separated fields. The email addresses must be comma separated)

OU=City1,OU=Company,DC=domain,DC=com    city1admin@domain.com,globaladmin@domain.com
OU=City2,OU=Company,DC=domain,DC=com    city2admin@domain.com,globaladmin@domain.com
DC=domain1,DC=com    adminteam@domain1.com

The smtp.cfg file contains the entries that are required to send an email. It has 4 parameters  :

smtpserver=ip address of the smtp server

smtpport=smtp server port (default is 25)

smtpfrom=email address to use in From: field

smtptls=false   (or true, indicating whether TLS must be used or not)

Sample file :

smtpserver=mail.domain.com
smtpport=587
smtpfrom=peter.ve@telenet.be
smtptls=true

This is the only configuration file that uses =  as a field separator

When all of the configuration files are in place, you can continue with the IIFP configurations

3. Enable Rules Extension

First, enable Rules Extensions. Open Identity Manager, go to “Tools – Options

Enable “Enable metaverse rules extension”

CLick “Browse” and select “GroupMVExtension.dll”

Click OK

Make sure “Enable Provisioning Rules Extension” is checked

Click OK to save

4. Create Management Agent for Account Domain 1 (users need to be projected to users)

Go to “Management Agents”. Right click and choose “Create”

Management Agent for : select “Active Directory”

Name : MA Account Domain 1

Click Next

Connect to Active Directory Forest

Forest name : domain.com

Username : enter the username that has the required permissions (see above)

Password : enter the corresponding password

Domain : domain.com

Click Next

Configure Directory Partitions

Locate the directory partition that contains the user objects from the domain.com domain

(DC=domain,DC=com)

Click “containers” to only select the source OU’s that contain user objects that need to be provisioned/synchronized by IIFP

In our example, this is OU=City1,OU=Company,DC=domain,DC=com and OU=City2,OU=Company,DC=domain,DC=com

Deselect all OU’s/containers that are irrelevant to the IIFP process. Click OK to close the containers window

Click OK to continue

Select Object Type

Make sure “user” is selected.

Click Next

Select attributes

Select the following attributes :

• c
• cn
• co
• company
• department
• description
• displayName
• givenName
• homePhone
• info
• initials
• l
• mail
• mobile
• ou
• postalcode
• proxyAddresses
• sAMAccountName
• sn
• st
• streetAddress
• telephoneNumber
• title

(you may have to enable the “Show All” checkbox at the top in order to see all required attributes). The attributes in blue are mandatory. Without these attributes, the dll will fail to provision objects (“cn” and “sAMAccountName”) and/or to synchronize information back to the account domain (“mail” and “proxyAddresses”)

Click Next

Configure Connector Filter

You can use this if you want to filter based on certain AD attributes. Since we are using an allow.cfg and/or deny.cfg group, we can almost achieve the same functionality, however using a filter may speed up the selection process as bit. The only difference is that IIFP is not aware of group membership, so you can use both a connector filter and allow.cfg/deny.cfg setting for maximum functionality.

In my example, I did not use a connector filter, so just click Next.

Configure Join and Projection Rules

This step allows you to define how object must be joined together, and what the target object type must be.

If you only have one account domain, and one resource forest, you can choose to allow IIFP to join source and target object together. After all, you would not have duplicate objects you need to take care of (that is, if you think about excluding the default administrator account etc).  But if you have multiple source Account Domains, you cannot allow IIFP  to join objects. After all, it would join a Resource Object with multiple Account Domain objects automatically.  So during the sync of the mail and proxyAddresses fields, it may overwrite account domain data with incorrect information.

This does not mean that the object from the account domain with the provisioned object in the Resource Forest won’t be joined together. The provisioning process dll will take care of this.

So all we should do is tell IIFP to project the source objects to person objects, and the dll will take care of the rest.

Select “user” and click “New Projection Rule”

Set the projection type to “Declared” and set Metaverse Object type to “person”

Click OK

Click Next

Configure Attribute Flow

This step defines the direction of the attributes. When creating the Management Agent for an Account Domain, most of the attributes need to be imported into the Metaverse.  Only the mail and proxyAddresses fields must be exported from the Metaverse to the Account Domain (because the contents of those 2 fields will be managed within Exchange in the Resource Forest)

Set up the attribute flow as follows :

Data source object type : user

Metaverse object type : person

Mapping type : direct

For “mail” and “proxyAddresses”, set the Flow direction to Export, and enable “Allow Nulls” if you want to (not mandatory)

For all other attributes, set the flow to Import

Don’t forget to map with DistName (which is required for the dll to work properly) and to map sAMAccountName to uid (which is also required for the provisioning process to work correctly)

When the attribute flow settings have been configured, click Next

Configure Deprovisioning

Set to “Make them disconnectors” and click Next

Configure Extensions

Leave default settings.  Complete the process and you should have a new Management Agent.

Repeat these steps for all of the Account Domains that need to be synchronized, setup is very similar to what has been described above.

There is one exception : the MA for the “Remote Domain” (containings user objects that need to be provisioned/projected into contacts in the Resource Forest) requires some specific settings (see next chapter)

5. Create Management Agent for RemoteDomain (user objects need to be projected into contacts)

The procedure to create the Management Agent is almost the same, but has the following changes compared to a MA that provisions/syncs user objects to user objects :

Join & Projection Rules : Set the project rule to create a contact object type in the metaverse. Select the user Data Source Object Type.

Create a new projection rule and set it to project the object into a contact object.

Attribute flow : Map “User” to “Contact” and set the Flow Directory to “import” for all attributes

6. Create Management Agent for Resource Forest : users to users

The Management Agent for the Resource Forest is mainly responsible for synchronizing information towards the Resource Forest (mainly Export), and to Import the “mail” and “proxyAddresses” attributes back to the Metaverse.

The connectors in the metaverse will make sure each object is correctly mapped, so you only need to create one Management Agent for the Resource Forest, in order to provision/sync user objects, and you need one MA for the Resource Forest to deal with the contacts.

The name of the Management Agent is very important. You will need to use the name of this MA in the mapping.cfg file, so this name needs to match the entry in the connection.cfg (or vice versa for that matter).  In my example, I have used “MA Resource Forest” and “MA Resource Forest contacts”, so these are the names that we will use when creating the Management Agents.

Create another Management Agent and connect to the Resource Forest.   We’ll start with the “MA Resource Forest” Management Agent first.

Don’t limit the containers, as you need to make sure all objects are visible, in order to detect duplicates.

Object types = users

Attributes :

• c
• cn
• co
• company
• department
• description
• displayName
• givenName
• homePhone
• info
• initials
• l
• mail
• mobile
• ou
• postalcode
• proxyAddresses
• sAMAccountName
• sn
• st
• streetAddress
• telephoneNumber
• title
• unicodePwd
• userAccountControl

Again, the atrributes in blue are mandatory.  You need the unicodePwd and userAccountControl attributes because the Rules Extension dll needs those attributes when creating a new user.      When the dll creates a new user in the Resource Forest, it will generate a random strong password of 20 characters, and the user object will be disabled (which is what we need in order to link an Exchange mailbox to)

Join and Projection Rules :

– create a join rule that performs a direct map between sAMAccountName to uid, for person objects

Next, create a projection rule to project to “person” objects

Attribute flow : Most of the attributes flow from the Account Domain to the Resource Forest. So most of the attributes need to have “Export” as flow direction (Export = from Metaverse to Domain/Resource Forest).

The only attributes that must be sent to the metaverse (import) are mail and proxyAddresses, so they can be synced to the Account Domains.

Deprovisioning : make them disconnectors.

7. Create Management Agent for Resource Forest : users to contacts

Create a new MA, make sure to match the name with what you have specified in mapping.cfg

Connect to the Resouce Forest again, and don’t limit the scope to specific containers. Leave all OU’s selected

Object type is “contact” and not “user”, so don’t select user this time

Attributes : select all relevant attributes, but make sure to select “showInAddressBook”, because this is the field that will be used to make the contact visible in the GAL.

© 2008 – 2021, Peter Van Eeckhoutte (corelanc0d3r). All rights reserved.

Similar/Related posts:

Exchange 2007 : Resource Room Mailboxes Delegating Exchange 2007 Distribution List Management to End Users Free tool – Attachment filtering with Exchange 2007/2010 (custom transport agent) Exchange 2007/2010 : Renaming attachments ‘on the fly’ – custom transport agent Exchange 2007 Administration : Setup and Delegation