Module 8: Cross-Forest/Multi-Forest 3
- Common GAL
Important: There are certain features which are not available in Cross-forest
deployment, such as the ability to view distribution group membership whose
members are stored in another forest. Further, Delegate Access will not be
supported across forests. (Currently, a contact cannot be given delegate access
to a mailbox). Thus, customers should not expect to achieve full full-feature
parity with single-forest installations.
Added benefits:
- Customers have an alternative to using the Active Directory
Connector’s inter-organizational connection agreements, which were not
supported for coexistence between different organizations.
- Provide an administrative model somewhat similar to peer-to-peer
directories as was the case in Exchange 5.5, so that Exchange 5.5 customers
may ease into Exchange 2003 without destroying their existing administrative
model.
The bare requirements to make a multi-forest topology work for just basic
messaging (basically sending messages and no free/busy features) is Directory
Synchronization and mail flow. Essentially, a synchronized global GAL needs
to be available to all forests and a transport route needs to be in place to allow
mail to flow between them.
Since there is no built-in feature to automate sharing of GAL information
between forests, the cross-forest spec combines unrelated technologies to
achieve the goals. These technologies include
Microsoft Identity Integration Server (MIIS) to achieve directory
synchronization.
Customized SMTP connectors for mailflow between forests.
Optional components (IORepl, x-forest movemailbox) may be added to
the cross-forest scenario so that the multi-forest deployments come
closer to parity with a single-forest scenario.
Components
4 Module 8: Cross-Forest/Multi-Forest
MIIS 2003 and GAL Sync
Definition
This topic covers Microsoft Identity Integration Server version 2003 and the
Global Address List Synchronization (Galsync) process, which perform the
directory synchronization. Once set up, users in one forest may look up
recipients in different forests, and the infrastructure for cross-forest mail flow is
established.
History of MIIS
•Previous version bought from Zoomit, Inc.
•Version 2.2 is no longer for “sale.” “Sale” is in quotes because if a customer
has a Windows 2000 Advanced Server license, then this product is available at
no extra cost. However, in order to implement this product they will need to
engage Microsoft Consulting Services (MCS) or an Authorized MIIS Partner.
Version 2.2 is a high-touch, complex, difficult to deploy product. As it is
particularly difficult to setup and configure, in the hands of the untrained, it is
possible to do considerable damage to the connected systems. For this reason
MMS 2.2 was never actually sold as a “product” in the true sense. It did not
have a SKU, and was not on any parts list from Microsoft. However, Microsoft
would license the product to customers who had a Windows 2000 Advanced
Server license (at no additional cost), and took a services engagement from
MCS, or from an Authorized MIIS Partner.
•Version 3.0 (renamed to MMS 2003, then renamed to MIIS 2003) – Rewritten
from the ground-up. There is still an MIIS 2003 partner program, and
http://www.microsoft.com/windows2000/partners/mms2003.asp lists those that
have been trained on
MIIS 2003 and are ready to help customers. The 3.0/2003
version is considerably improved, and Microsoft believes customers can use the
information (based on scenarios) that ships on the product CD to conduct their
own evaluation, design, test and deployment.
Module 8: Cross-Forest/Multi-Forest 5
Intro to MIIS 2003
Companies often store data about users and objects in multiple data sources –
some within Active Directory forests, but others within other types of data
repositories. Therefore, the identity of a user could be scattered across several
different locations on several different incompatible platforms. Often,
companies need to aggregate (combine) that information into a logical view that
represents the sum of all the identify information for a given object.
Thus, Metadirectories are utilized for identity management, or for massaging
complex data from multiple data sources so that they may be managed easily.
Because the concept is so universal, IBM®, Oracle®, Netscape®, and others
market their own Metadirectory products. Microsoft’s latest offering is called
Microsoft Integrity Information Services (MIIS) version 2003.
MIIS 2003 is a service that collects information from different data sources
throughout an organization and then combines all or part of that information
into an integrated, unified view. This unified view presents all of the
information about an object, such as a person or network resource, that is
contained throughout the organization. In most organizations, the sources data
is typically stored in different directories, databases, and other data repositories
throughout the Information Technology (IT) infrastructure.
After all of the information about a person or resource is combined in the
metadirectory, rules can be applied to decide how this information is managed
and how changes to this information flow out to all of the directories that are
connected to the metadirectory. Therefore, the metadirectory propagates any
changes that originate in one directory to the other directories in the
organization.
6 Module 8: Cross-Forest/Multi-Forest
Glossary:
To use MIIS to manage data, it is important to become familiar with key
concepts and definitions that will assist you in understanding the architecture
and function of MIIS.
Objects and Attributes - Each entry in the Metadirectory is an object, of a
specific type, which is comprised of a number of attributes. For example, the
entry for Kim Rallsis a specific “Person” object, which possesses attributes
(e.g. displayName, Title, Department, telephoneNumber) that are defined for
the “Person” Object Type. Examples of other object types include “Computer,”
“Group,” and “Organizational Unit.” Although Object Types are similar in
function to Lightweight Directory Access Protocol (LDAP) Object Classes,
they do not exhibit inheritance, and an object may be of only one type.
Metaverse and connected directories - The external sources of data for MIIS
are referred to collectively as connected directories. The collection of objects
and attributes which are stored and managed in the MIIS system is the
metaverse. Because one object in the metaverse is likely to represent entries in
more than one connected directory, there will be a conflict if attributes differ for
that object in each connected directory. Therefore, it is important to understand
which connected directory has authority for each object type and attribute, and
therefore which source takes precedence if there is a conflict. This
understanding comes primarily from discussions with the business owners of
the various systems, and is one of the key requirements for success of a
metadirectory implementation project.
Management Agents and Connector Space - The data flow between MIIS
and a specific connected directory is defined in a Management Agent, and data
flows only when a Management Agent is run. Each Management Agent has a
connector space. The connector space is an area (separate from the metaverse)
in which a management agent stores holograms from which changes in data-
state are calculated. A Management Agent may handle all objects in a
connected directory or may be configured to manage only a subset of objects
and their attributes. Every object and attribute from the connected directory
handled by a Management Agent is represented in the connector space. The
Management Agent configuration defines which objects are attributes are
synchronized into the metaverse.
Joins and Projection - If an object from a connected directory is represented in
the metaverse, it is said to be joined. The process by which the synchronization
engine makes the association between an entry in a connector space and a
corresponding entry in the metaverse is known as joining. If an entry in the
connector space is to be represented in the metaverse, but no corresponding
entry in the metaverse can be found by the Join process, a new metaverse object
may be created for this entry (according to how the Management Agent is
configured). The creation of a new metaverse object is known as projection,
and following projection, the connector space entry will be joined to the new
metaverse object.
Connectors and Disconnectors - An object in the connector space may or may
not be joined to an object in the metaverse. If a connector space object is joined
to a metaverse object, it is referred to as a Connector. If it is not joined to a
metaverse object, it is referred to as a Disconnector.
Module 8: Cross-Forest/Multi-Forest 7
GUIDs and Anchor IDs - Each metaverse object is identified by a unique
value know as its Globally Unique ID (GUID). The Join between a connector
space object and its corresponding metaverse object is achieved by storing the
GUID with each connected connector space object.
Similarly, there must be a link between each object in the connected directory
and the connector space, so that the Management Agent can manage the entries
in the connector space with the corresponding entries in the connected
directory. This is achieved through a unique attribute (or a unique combination
of attributes) which originates in the connected directory, and is referred to as
the Anchor ID.
Provisioning and Deprovisioning - It is possible to define object flow rules in
MIIS that imply that the presence of an entry in one connected directory
requires the presence of a corresponding entry in another connected directory.
For example, the existence of an entry in a Human Resources system
(representing an employee) might require the existence of an Active Directory
account for this employee. In order to enforce this rule, MIIS can be configured
to create and remove entries in a connected directory (for example, in Active
Directory). The creation of entries is referred to as provisioning and the removal
of entries is referred to as deprovisioning.
8 Module 8: Cross-Forest/Multi-Forest
MIIS Components
There are three basic areas of storage. The unified view (metaverse), connector
space (where data manipulation takes place), and the connected data sources
from where data is pulled/pushed. The actual manipulation
(joins/adds/extension rules) are performed by the Management Agents. There
are different Management Agents for different types of data sources. Pertaining
to Exchange 2003, there is the Active Directory Global Address List
Synchronization Management Agent (GAL Sync Management Agent) where
our attention will focus later.
Connected Directory
z
Source and/or
destination for
synchronized objects
and attributes
Connector Space (CS)
z
Staging area for all
objects that
synchronize with MMS
z
Persists the import
and export state on
each object
z
Each MA has its own
CS
Metaverse (MV)
z
Central (SQL) store of
identity information
z
Matching CS entries to
a single MV entry is
called “join”
Active Directory
Active Directory
Oracle
Oracle
IPlanet
IPlanet
SAP,JDEdwards
SAP,JDEdwards
,
,
Peoplesoft
Peoplesoft
, etc.
, etc.
Connected
Connected
Data Sources
Data Sources
Metaverse
Metaverse
User
User
Connector
Connector
Space
Space
Module 8: Cross-Forest/Multi-Forest 9
Management Agents can also read/write to/from flat files. For Exchange 2003,
we use cell-based Management Agents. Regardless of the Management Agent
type, the connector space and metaverse components are stored in SQL. Each
Management Agent is capable of performing bidirectional replication between a
data source and the metaverse. However, at least two Management Agents are
necessary for end-to-end replication from a source connected directory to a
target connected directory.
Information flow example
This graphic shows how data flows from a data source through the metaverse,
onward to another system. This is just an example of the ability to merge
objects in different data sources which represent the same entity.
Metadirectory
Metadirectory
Connector Namespace Metaverse Namespace
Sue Fine
Name
Post Office
Location
Employee #
Sue Fine
Name
Post Office
Location
Employee #
Suzan Fine
Full Name
Title
Employee #
Suzan Fine
Full Name
Title
Employee #
Forest1
Forest1
Forest1
1
1
1
Full Name
Title
Employee #
Full Name
Title
Employee #
Suzan Fine
Suzan Fine
Suzan Fine
Name
Post Office
Location
Employee #
Name
Post Office
Location
Employee #
Sue Fine
Sue Fine
Sue Fine
2
2
2
= Management Agents
= Management Agents
Full Name
Title
Employee #
Full Name
Title
Employee #
Suzan Fine
Suzan Fine
Suzan Fine
3
3
Full Name
Title
Employee #
Full Name
Title
Employee #
Suzan Fine
Suzan Fine
Suzan Fine
Name
Post Office
Location
Employee #
Name
Post Office
Location
Employee #
Sue Fine
Sue Fine
Sue Fine
Full Name
Title
Employee #
Name
Post Office
Location
Full Name
Title
Employee #
Name
Post Office
Location
Suzan Fine
Suzan Fine
Suzan Fine
4
4
5
5
5
5
5
Suzan Fine
Name
Post Office
Location
Employee #
Suzan Fine
Name
Post Office
Location
Employee #
Suzan Fine
Suzan Fine
Suzan Fine
Forest2
Forest2
Forest2
1. The management agent for the first connected directory creates entries
in the connector namespace. The management agent creates these entries (and
their attributes) in its portion of the connector namespace.
2. The management agent for the second connected directory creates
entries in its portion of the connector namespace. Note that in the preceding
illustration, there is an entry for Kim Ralls each of the connected directories.
Therefore, there will be two entries in the connector namespace that represent
Kim Ralls.
3. The Management Agent for one of the connected directories creates an
entry in the metaverse namespace that corresponds to the entry in its connector
namespace. Note that an administrator determines which connected directory to
use to initially create entries in the metaverse namespace.
4. The management agent for the second connected directory then
attempts to match its entry in the connector namespace with the corresponding
entry in the metaverse namespace. This action is called a join because each
entry in the connector namespace that represents the same real-world object is
joined together, or integrated, as one entry in the metaverse namespace.
10 Module 8: Cross-Forest/Multi-Forest
To ensure that the entries that are joined together in the metaverse namespace
represent the same real-word object, you can configure MIIS to use a unique
attribute (such as an employee number) as the criteria by which entries are
joined.
At this point, as shown in the preceding illustration, Kim Ralls represented by
an entry in each of the connected directories, by an entry in the portion of the
connector namespace for each connected directory, and by the integrated entry
in the metaverse namespace.
5. After entries for the same real-world object are joined together in a
single entry in the metaverse namespace, you can determine which attributes
the metaverse namespace entry contains and from which connected directory
the values for these attributes originate. This is determined by something called
attribute flow rules.
When attribute values differ, an attribute flow rule specifies which attribute
value (from the metadirectory or from the connected directory) takes
precedence. For example, in the preceding illustration, if the values for a
common attribute in the entries for Kim Ralls are different, attribute flow rules
inform the management agents of the value that takes precedence so that the all
the entries for Kim Ralls can be synchronized.
If an attribute does change in the entry in the metaverse namespace, the
appropriate management agent makes that change in the entry in the connector
namespace and then propagates the change to the connected directory.
Although the Management Agent above was customized for HR databases, a
pre-built Management Agent will be available to accomplish replicating global
address lists.
Module 8: Cross-Forest/Multi-Forest 11
The GAL Sync Management Agent
The pre-built GAL Sync Management Agent will allow Exchange
administrators to easily configure MIIS 2003 without having the need of an
MCS consultant to help design the attribute and rules. Once configured with the
data sources (FQDNs of domain controllers), two GAL Sync Management
Agents will be used to replicate mail-enabled objects from each Active
Directory forest into the metaverse. As in the example above, it also has the
ability to join different objects if certain attributes match. In the GAL Sync
Management Agent, flows and joins are discussed below:
The flows that are addressed are the one-to-one mappings listed in the
following table.
Source Active Director
y
Metaverse Target Active Director
y
User Person Contact
Contact Contact_forest Contact
Group Group Contact
Most of the attributes from the Source Active Directory are preserved and
copied into the target Active Directory. For example, a telephone number of
UserA in Forest1 will be synchronized to the target contacts UserA in Forest2
and Forest3. However, there are some exceptions where additional rules are
called. More detailed information on the mapped attributes and rules are
provided in Appendix B: Mapping Rules.
The flows that are not addressed are the one-to-one mappings in the following
table, and any one–to-many or many-to-one mappings listed the preceeding or
following tables.
Source Active Director
y
Metaverse Tar
g
et Active Director
y
User Person User
Group Group Group
12 Module 8: Cross-Forest/Multi-Forest
Microsoft Metadirectory Services 2003 does not handle multi mastering of
these objects in any environment. All target attributes will typically be
overwritten by attributes from the source. Exceptions are proxyAddresses and
legacyExchangeDN, which have values assigned in the target forest that must
be preserved.
The decision to exclude multi mastering arises from the fact that GAL
synchronization should not have multi-mastering of objects as it is necessary
for exchange functionality to have a single source object.
When MIIS looks for objects in the “Source Active Directory” column, the
objects must match certain criteria to be written into the metaverse:
Object Conditions
User The homeMDB or TargetAddress attribute is defined.
Contains at least one proxyAddress attribute value.
The MSExchHideFromAddressList is not set to ‘true’.
Contains a LegacyExchangeDN attribute value.
Contact The TargetAddress attribute is defined.
At least one proxyAddress attribute value is defined.
The MSExchHideFromAddressList is not set to ‘true’.
Must have a LegacyExchangeDN attribute value, but only if the method of
creation for the object was projection and not provisioning.
Group The MSExchHideFromAddressList attribute is not set to ‘true’.
A LegacyExchangeDN attribute value is defined.
Join rules are applied to contact objects only. When you run Management
Agents, they will search for joins by using a list of metaverse object attributes.
The search attempts to match metaverse object attributes with connector space
object attributes. If any of the search criteria are met, then a join is established.
When the Apply Rules run profile is run, the following join rules are applied to
contact objects only:
If there is more than one candidate in the metaverse for a join, an exception
occurs and an error is logged. The Management Agent cannot determine
where to flow the data because it cannot determine which object from which
to export data.
If a contact that exists in the authoritative contact organizational unit in the
source forest is joined to any object in the metaverse, an error is logged.
Contacts in the authoritative contact organizational unit in the source forest
are used for projection only. An exception does not occur because contacts
are not supposed to flow into the target forest. The error is shown in the
Event Viewer logging section.
A join to a metaverse object that is already joined is only allowed if the
joined metaverse object is a provisioned contact. In this case, provisioning
clears up this duplicate. A warning is logged when this join occurs. In all
other cases (where the joined metaverse object is a provisioned contact), a
Không có nhận xét nào:
Đăng nhận xét