This guide contains proprietary information protected by copyright. The software described in this guide is furnished under a software license or nondisclosure agreement. This software may be used or copied only in accordance with the terms of the applicable agreement. No part of this guide may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording for any purpose other than the purchaser’s personal use without the written permission of Quest Software, Inc.
The information in this document is provided in connection with Quest products. No license, express or implied, by estoppel or otherwise, to any intellectual property right is granted by this document or in connection with the sale of Quest products. EXCEPT AS SET FORTH IN QUEST'S TERMS AND CONDITIONS AS SPECIFIED IN THE LICENSE AGREEMENT FOR THIS PRODUCT, QUEST ASSUMES NO LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL QUEST BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF QUEST HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Quest makes no representations or warranties with respect to the accuracy or completeness of the contents of this document and reserves the right to make changes to specifications and product descriptions at any time without notice. Quest does not make any commitment to update the information contained in this document.
If you have any questions regarding your potential use of this material, contact: Quest Software World Headquarters
LEGAL Dept 5 Polaris Way
Aliso Viejo, CA 92656 email: [email protected]
Refer to our Web site (www.quest.com) for regional and international office information.
Trademarks
Quest, Quest Software, the Quest Software logo are trademarks and registered trademarks of Quest Software, Inc in the United States of America and other countries. For a complete list of Quest Software’s trademarks, please see
http://www.quest.com/legal/trademark-information.aspx . Other trademarks and registered trademarks are property of their respective owners.
Collaboration Services How it Works Guide Updated - June 2011
Introducing Quest Collaboration Services . . . 1
Unified Messaging Environment for All Users . . . 1
Transparency for End Users . . . 1
Secure Solution . . . 1
Architecture and Functionality . . . 2
Collaboration Services Structure . . . 2
Data Synchronization . . . 3
The Synchronization Process . . . 4
Publication and Subscription. . . 4
Automatic Synchronization of Changes . . . 6
Synchronized Groups. . . 7
Mappers. . . 7
Communication Among Forests. . . 10
Administrative Interface. . . 12
About Quest Software, Inc. . . . 13
Contacting Quest Software. . . 13
Contacting Quest Support . . . 13
Introducing Quest Collaboration Services
Security or other requirements may lead some companies to isolate corporate directory data in separate Active Directory forests. Quest® Collaboration Services™ securely synchronizes Active Directory and
Exchange data (such as users, groups, distribution lists, contacts, calendar, and free/busy information) between isolated forests in a multi-forest/multi-organization deployment of Active Directory.
Collaboration Services allows companies to establish secure collaboration between users in forests separated across the public internet. It is used on a continuous basis to reduce the costs and complexities associated with managing a decentralized, multi-forest network.
Unified Messaging Environment for All Users
Collaboration Services enables users in separate forests to see each other in their Global Address Lists (GALs). Consequently, users do not have to manage complex personal address lists or remember addresses for employees in other forests. Administrators for each organization do not have to manually add contacts for other employees into the address books and keep their personal information up-to-date. In addition, Collaboration Services synchronizes calendar and free/busy information so that users in separate forests can see their colleagues’ or partners’ free/busy information and schedule meetings with them.
Transparency for End Users
Using Collaboration Services means a zero learning curve for end users, since they do not have to study anything new—they just keep using Microsoft Outlook in the typical manner.
Secure Solution
Collaboration Services is a secure directory, calendar, and free/busy data synchronization solution. It has the following benefits compared to other directory synchronization solutions:
• No trusts, VPN tunnels, or supplementary accounts between forests are required.
• You do not have to open directory access port (LDAP port) for outbound access to let other forests’ accounts query your directory and Exchange data.
• No forest uses any account from any other forest.
• Full administrative autonomy is preserved: the administrator of each forest chooses which objects and data from that forest will be available in other forests, and which objects and data from other forests will be applied and available in his or her own forest.
• All Collaboration Services communications between forests are encrypted and signed.
Architecture and Functionality
This section provides a high-level overview of the Collaboration Services architecture and functionality.
Collaboration Services Structure
To achieve seamless inter-forest collaboration by providing a common GAL, Collaboration Services synchronizes the selected Active Directory objects between the selected forests using a “hub and spokes” architecture. The HQ forest is the hub, and the branch forests are the spokes.
This architecture optimizes synchronization traffic load balancing and makes deployment easy. Each forest participating in the collaboration sends its data to be published to the HQ forest, and the HQ forest distributes to each branch forest the data it requires. Thus, the HQ forest provides data distribution and manages the data flow between all collaboration partners.
Figure 1: Collaboration Services "hub and spokes" architecture
All forests that take part in collaboration are called synchronization partners.
The administrators of these forests can publish their data in one or more collections and subscribe to the collections published by other forests. When publishing a collection, a forest administrator can either allow it to be available for subscription by all synchronization partners, or allow only selected
synchronization partners to subscribe to it.
Data Synchronization
Even though all data sent between forests is encrypted, Collaboration Services does not store or transmit to other forests any security-related user data, such as account SIDs or passwords. Only data required to provide inter-forest user collaboration is transmitted, such as object names and other attributes, email addresses, and group membership.
Collaboration Services is capable of synchronizing the following mail or mailbox-enabled objects and information:
• Users
• Distribution and security groups • Query-based distribution groups • Contacts
• inetOrgPersons • Free/busy information • Calendar information
Each forest administrator decides which objects (and which of their attributes) should be published and added to the GAL in other forests after subscription, and whether the calendar or free/busy information of the published objects should be available for users in other forests.
Collections
To provide flexibility, the objects to be synchronized are grouped into collections—sets of objects and their attributes. You can either define the objects to be synchronized on per-container or per-group basis; or add groups, users, and contacts to collections explicitly.
Depending on your license type, you can create collections of mixed type, Active Directory-only collections, Calendar-only collections, and Free/Busy-only collections:
• In mixed collections, both Active Directory objects and their calendar or free/busy data are synchronized. As a result, collection objects are added to the common GAL in the subscribing forests, and objects’ calendar or free/busy information is also available in other forests. • In Active Directory-only collections, only selected Active Directory objects are synchronized;
their free/busy or calendar information data is not. As a result, collection objects are added to the common GAL in the subscribing forests, but objects’ calendar or free/busy information is not available.
• In Calendar-only collections, only the calendar information of the specified objects is synchronized (you can select to synchronize calendar date/time information, or all calendar details). As a result, collection objects themselves are not added to the common GAL in the subscribing forests, but objects’ calendar information is replicated over and matched to existing objects.
• In Free/Busy-only collections, only the free/busy information of the selected objects is synchronized. As a result, collection objects themselves are not added to the common GAL in the subscribing forests, but objects’ free/busy information is replicated over and matched to existing objects. Note that in this case you must either create objects to match free/busy information into manually or use some other directory object synchronization tool, such as Microsoft Identity Integration Server (MIIS), to synchronize Active Directory objects between all forests in the collaboration structure. Collaboration Services is able to match the free/busy data to the corresponding user or contacts created by any other software. Free/busy
information is matched to objects based on email addresses.
The Synchronization Process
Publication and Subscription
When a forest administrator publishes a collection, it becomes available for subscription to the forests specified by the publishing forest administrator.
When another synchronization partner’s administrator subscribes to a collection, Collaboration Services creates a stub object (either by creating a new, disabled mail-enabled user account, group, or contact, or by reusing an existing object) for each member of the collection in Active Directory. (If calendar information is published for the collection's object, mailbox-enabled user account is created.)
During this process, Collaboration Services automatically tracks synchronization conflicts and informs administrators, allowing quick resolution so that conflicts never affect users’ workflow.
Figure 2: Publication and synchronization process
Before a forest subscribes to a collection, the only information available for the forest’s administrator is the collection name, a short collection description provided by the collection creator, and the publishing forest’s description. A collection’s membership (that is, the objects it contains) is available only after its administrator subscribes to the collection. By subscribing to a collection, branch administrator can control which objects and attributes from a collection are applied to his or her forest on per object and per-attribute basis.
The stub objects for each collaboration partner are created in the dedicated OUs (within the OU specified during the setup).
You can monitor the stub objects as follows:
• Using the Active Directory Users and Computers MMC snap-in (you need to select the Advanced Features from the View menu to be able to view this OU)
• Using Microsoft Outlook or Outlook Web Access to view their appearance in the GAL.
Automatic Synchronization of Changes
The synchronization service also performs periodic scans of the AD and Exchange data in each forest to detect any modifications to objects free/busy or calendar information. If the modified objects or free/busy information belong to a published collection’s objects, the changes are collected. Thus, all changes made to the properties and free/busy or calendar information of a collection’s source objects (users, groups, and contacts) are tracked by Collaboration Services and all updates are automatically sent to the collection’s subscribers without requiring administrators to perform any actions. Incremental (delta) synchronization is used for sending updates, along with compression, resulting in very little bandwidth usage.
If some of the collection’s objects are deleted, their stubs will be automatically removed from all forests subscribing to the collection. If new objects fall into the synchronization scope (for example, new object is created in the published container), corresponding new stubs will be automatically created in all forests subscribing to the collection.
The HQ forest maintains a list of all collections that administrators can subscribe to, and distributes initial and update synchronization packets between subscribing branches. The synchronization data flow depends on which forest’s objects were modified:
• If HQ forest objects were modified, update data packets are sent to all branch forests that subscribe to the collections containing the modified objects.
Synchronized Groups
Collaboration Services supports synchronized groups: distribution groups whose membership is synchronized across all forests participating in collaboration. A group owner can add stub objects from other forests to any group. When a synchronized group is published to other forests, the group’s stub is created and its membership is re-calculated in every subscribing forest accordingly, with the original objects replacing the stubs.
Mappers
Sometimes publishing or subscribing administrators want to change the format or appearance of the data they publish or subscribe to. A mapper is a plug-in component that changes the appearance of data that you publish or subscribe to.
If you use mappers when creating a collection, the mappers modify the data before it is published, so all subscribers get modified data. If you use mappers while subscribing to a collection, the mappers modify the published data before it is applied to your particular forest.
Collaboration Services includes the following mappers: • User to Contact Mapper
• Group to Contact Mapper • Suffix Mapper
• Attribute Filter Mapper
• Simple Mail Transfer Protocol (SMTP) Filter Mapper • Custom Mappers
User to Contact Mapper
This mapper converts users and inetOrgPerson into contacts. Converting users to contacts may be required to meet internal regulations. This mapper may also be useful if you have software that is licensed by the number of user objects in Active Directory and you do not want to buy additional licenses.
To enable group membership synchronization, you must publish the group with members, which is not the default setting. Be sure to select the Synchronize members option when publishing synchronized groups.
Mappers applied during publication do not modify the original Active Directory objects; only the information to be published is modified before it is distributed to other forests.
Group to Contact Mapper
This mapper converts groups into contacts, allowing you to hide group membership from other forests. This is useful if you want users from other forest to be able to send mail to your distribution groups, but do not want the group members to be revealed.
Mapping Groups from Exchange 2007
If you want to use the Group to Contact Mapper for a source group from an Exchange 2007 organization, you must first turn off user authentication. You do this in the Exchange 2007 Management Console (clear the Require that all senders are authenticated check box on the Mail Flow Settings tab | Mail Delivery Restrictions).
Suffix Mapper
Use this mapper to add a specified suffix to the display name of the published objects so that the users can distinguish published objects from the objects of their own forest. For example, you may want to add the [PartnerCo] suffix to the display names of objects from a partner company in the subscribed collection to emphasize that they belong to another company.
Figure 4: Example of the suffix mapper
Attribute Filter Mapper
Simple Mail Transfer Protocol (SMTP) Filter Mapper
This mapper allows a subscribing administrator to defend against “address stealing." By adding an SMTP address to the published object, the publishing administrator effectively assigns his forest’s users email addresses from another forest. In a merger or acquisition scenario, this is usually a requirement. However, the same action can also be performed by a malicious administrator in a partner collaboration scenario, causing unsanctioned email address usage with all associated risks, including possible information leaks. By using this mapper and filtering out your own forest’s addresses from incoming objects, you protect your forest.
To configure the mapper, add all of your company’s SMTP email address namespaces (including the @ sign) to the list of namespaces to be filtered out. You can also import a list of namespaces from a text file by clicking the Import button and choosing the file. The file should list the SMTP namespaces, one namespace per line.
Figure 5: Example of the SMTP mapper
Custom Mappers
Communication Among Forests
Overview
All the instances of Collaboration Services installed in different forests communicate with each other using SMTP, which is a native mail exchange protocol for Exchange servers. To reduce traffic, all synchronization data is compressed before it is sent. Then the data is put into regular email messages, which are encrypted, signed, and sent to other synchronization partners.
To provide guaranteed delivery, Collaboration Services maintains a service email message history list. All messages are stored until their delivery is confirmed by the synchronization partner. If delivery of any messages is not confirmed within the specified time interval, those messages are re-sent.
Security
Collaboration Services provides a high level of security. A special dedicated Exchange mailbox in each forest is used for communication with other synchronization partners. All interactions between the services are encrypted.
Each synchronization partner has a password-protected public key file. The public key file (*.akf) contains the email address of the Collaboration Services mailbox used by the partner and the public key for data decryption.
The public key file of the HQ forest is generated during the installation of Collaboration Services in the HQ forest. When you install Collaboration Services in a branch forest, Collaboration Services prompts you for the HQ public key file. Installation of a new branch is impossible without the HQ public key file. After a branch is installed, the branch administrator needs to export and securely transfer the branch’s public key file to the HQ forest administrator, who can then register the branch in the collaboration structure.
Mail Forwarding
For each published object, Collaboration Services creates a stub object (disabled user account) in the forests that subscribe to the published object’s collection. For mail-enabled users and contacts included in the collection, the redirectors are already established, and therefore Collaboration Services simply sets and populates the proxy addresses and the target address of the original object to the corresponding attributes of the stub object.
For mailbox-enabled users, Collaboration Services assigns the following addresses to each stub object: • The targetAddress attribute of the stub object is set according to the namespaces settings in the publishing forest. For more information, see the Namespaces Usage section of the Quest Collaboration Services User Guide.
• The primary SMTP address of the original object is assigned as a primary SMTP address of the stub object.
Figure 6: A user who wants to send a message to a user from another forest just selects the recipient (Collaboration Services stub) from the Global Address List (GAL) and sends the message. As soon as a message is sent, Exchange server verifies the targetAddress attribute value and redirects the message to the other forest.
External mail always comes directly to the original object and does not use the Collaboration Services stubs.
Administrative Interface
All Collaboration Services administration is performed through a web interface. Extensive statistics provided by the web interface help you track the synchronization activities and provide all the information needed for effective administration.
About Quest Software, Inc.
Quest Software simplifies and reduces the cost of managing IT for more than 100,000 customers worldwide. Our innovative solutions make solving the toughest IT management problems easier, enabling customers to save time and money across physical, virtual and cloud environments. For more information about Quest go to www.quest.com.
Contacting Quest Software
Refer to our Web site for regional and international office information.
Contacting Quest Support
Quest Support is available to customers who have a trial version of a Quest product or who have purchased a Quest product and have a valid maintenance contract. Quest Support provides unlimited 24x7 access to SupportLink, our self-service portal. Visit SupportLink at http://support.quest.com. From SupportLink, you can do the following:
• Retrieve thousands of solutions from our online Knowledgebase • Download the latest releases and service packs
• Create, update and review Support cases
View the Global Support Guide for a detailed explanation of support programs, online services, contact information, policies and procedures. The guide is available at: http://support.quest.com.
Third Party Contributions
Quest Collaboration Services contains some third party components (listed below). Copies of their licenses may be found on our website at http://www.quest.com/legal/third-party-licenses.aspx
Email [email protected]
Mail Quest Software, Inc. World Headquarters 5 Polaris Way
Aliso Viejo, CA 92656 USA
Web site www.quest.com
COMPONENT LICENSE OR ACKNOWLEDGEMENT
