Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống
1
/ 78 trang
THÔNG TIN TÀI LIỆU
Thông tin cơ bản
Định dạng
Số trang
78
Dung lượng
2,87 MB
Nội dung
Contents
Overview 1
Lesson 1: The Cross-forest Specification 2
MIIS Components 8
Lab 8.1: Getting to know MIIS 2003 and GAL Sync Management Agent 26
Lesson 3: Cross-Forest SMTP Mailflow 32
Lesson 4: InterOrg Public Folder Replication 35
Lab 8.2: Cross Forest Practice 47
Appendix A GAL Sync Log and Error Messages 50
Appendix B: GAL Sync Mapping Types 54
Appendix C: GAL Sync Provisioning Rules 67
Acknowledgments 76
Module 8: Cross-
Forest/Multi-Forest
ii Module8: Cross-Forest/Multi-Forest
Information in this document, including URL and other Internet Web site references, is subject to
change without notice. Unless otherwise noted, the example companies, organizations, products,
domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious,
and no association with any real company, organization, product, domain name, e-mail address,
logo, person, place or event is intended or should be inferred. Complying with all applicable
copyright laws is the responsibility of the user. Without limiting the rights under copyright, no
part of this document may be reproduced, stored in or introduced into a retrieval system, or
transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or
otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual property.
2003 Microsoft Corporation. All rights reserved.
Microsoft, MS-DOS, Windows, Windows NT, Active Directory, ActiveX, Excel, Exchange Server
5.5, Exchange 2000 Server, Exchange Server 2003, Internet Explorer, Internet Information Server,
Word are either registered trademarks or trademarks of Microsoft Corporation in the United States
and/or other countries.
The names of actual companies and products mentioned herein (Groupwise, IBM, Lotus cc:Mail,
Lotus Notes, Netscape, Oracle) may be the trademarks of their respective owners.
Module8: Cross-Forest/Multi-Forest 1
Overview
Topic 1 The cross-forest Specification
Topic 2 Microsoft Identity Integration Services (MIIS) 2003 and Global
Address List (GAL) Sync
Topic 3 Cross-forest SMTP mail flow
Topic 4 Inter-Org public folder replication
At the time of this writing, only RC1 of MIIS 2003 was available for reference.
As such, many of the screenshots may be out of date. Additionally, the MIIS
product name was renamed prior to the Release To Manufacture RTM in July
2003. Thus, any references to MMS or “Microsoft Meta Directory Services”
should be considered MIIS or “Microsoft Identity Integration Services.”
Introduction
2 Module8: Cross-Forest/Multi-Forest
Lesson 1: The Cross-forest Specification
Introduction
Why do customers deploy multiple forests?
Customers deploy multiple forests because it is more secure. Since an Active
Directory domain was no longer a true security boundary, forests became the
entities in which future topologies were planned.
Customers want administration autonomy and data isolation. They could
achieve this in Exchange 5.5, by simply attaching any new Exchange 5.5 site to
an existing organization, and thus form a chain of peer sites with a common
GAL. Yet trusts were not necessary between each domain that was the realm of
an Exchange 5.5 site. Therefore data could be isolated, and administration could
be left in the hands of each site/Windows NT domain administrator.
Exchange 2000 introduced an architectural regression. Customers could no
longer achieve administration autonomy and data isolation because Exchange
2000 organizations were each bounded by a single forest. This meant that each
Global address list was limited to this same boundary. There was no way to
attach administrative groups to existing organizations outside of the forest to
share a common GAL. Thus, it was extremely difficult to replace traditional
site/domain boundaries with multi-domain, single-forest model. For those that
tried, they found that transitive trusts and Exchange groups were so invasive
that any domain administrators could potentially gain access to other domains’
mailboxes within the forest.
Goals:
The goal is to deploy multiple forests to achieve core messaging functionality
as it works in the single-forest case. This includes
- Basic mail functionality
- Calendaring
Module8: 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 Module8: 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.
Module8: 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 Module8: 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.
Module8: 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 Module8: 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
[...]... Management Agent that will import objects from forest1, select “Management Agents,” and choose “Create.” 14 Module8: Cross -Forest/Multi-Forest A designer dialog will appear, and the user is prompted through a wizard-like configuration Module8: Cross -Forest/Multi-Forest 15 16 Module8: Cross -Forest/Multi-Forest If either organization uses special address types (Notes/Gwise/custom), the checkbox for... unaltered, default state You can tell if any changes have been made (even those initially hidden by the “Show All” checkbox) by examining this screen 17 18 Module8: Cross -Forest/Multi-Forest Module8: Cross -Forest/Multi-Forest 19 20 Module8: Cross -Forest/Multi-Forest After selecting the defaults and finishing the Management Agent Designer, create another Management Agent, using the same previous steps... objects from multiple source forests will get dumped into a single OU in a target forest (Is there an exception?) 31 32 Module8: Cross -Forest/Multi-Forest Lesson 3: Cross-Forest SMTP Mailflow Introduction This topic covers mailflow and configuration of SMTP connectors used with the cross-forest spec Additionally, conditional forwarding, a new Windows 2003 feature in DNS, may be used Scenario 1: No two... the Exchange 2003 Migration Wizard has been modified to allow for cross-forest “mailbox moves.” This is somewhat of a misnomer, as the source mailbox is not deleted from its source organization Nevertheless, Exchange 2003’s Migration Wizard now has a detection mechanism that matches an MIIS-generated contact with a source Module8: Cross -Forest/Multi-Forest 23 mailbox When such a match is found, the Migration... 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 Module8: Cross -Forest/Multi-Forest 13 join to an already joined metaverse object is not allowed and an error is logged The following table lists and describes the joins between connector space attributes that.. .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... membership Note that the last seven dialogs in the GAL Sync Management Agent configuration are OK with their defaults, so click “Next” on each one until finished They are shown for reference purposes: Module8: Cross -Forest/Multi-Forest This dialog is displayed in its unaltered, default state You can tell if any changes have been made (even those initially hidden by the “Show All” checkbox) by examining 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 Module8: 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... in the metaverse and the end result is that any mail-enabled objects in a source forest (users/groups/contacts) are created as contacts in the target forests, as in the following illustration Module8: Cross -Forest/Multi-Forest 21 Additionally, any master objects that disappear (get deleted) from the source forest will eventually become de-provisioned and disappear from their target forests as well... examining the msExchOriginatingForest attribute In this example, the object came from darkforest.internal The legacyExchangeDN from the source forest is added in the form of the X500 address 22 Module8: Cross -Forest/Multi-Forest From the msExchPoliciesExcluded, MIIS-generated contacts, by default, have the following checkbox unchecked: “Automatically Update E-mail Address based on recipient policy” . Sync Provisioning Rules 67
Acknowledgments 76
Module 8: Cross-
Forest/Multi-Forest
ii Module 8: Cross -Forest/Multi-Forest
Information in this document,. through a wizard-like
configuration
Module 8: Cross -Forest/Multi-Forest 15
16 Module 8: Cross -Forest/Multi-Forest
If either organization