Mapped Security with SharePoint and SharePoint Online

The SharePoint Remote Connector can retrieve information from SharePoint on-premise servers and SharePoint Online. This section explains how you might configure Mapped Security if you retrieve information from both sources.

When you retrieve documents from both sources the configuration can be more complex because the users and groups that the connector adds to ACLs can be in different formats. Typically, ACLs in documents retrieved from SharePoint have users and groups in NT-style (such as DOMAIN\USER or DOMAIN\GROUP) formats. In ACLs in documents retrieved from SharePoint Online, it can be more convenient to identify users and groups by email address.

A single IDOL user could therefore be identified in some ACLs by an NT-style user or group name or by an e-mail address. However, OmniGroupServer and the IDOL Community component can only associate one user name with each security type. As a result, OpenText recommends configuring separate security types for SharePoint on-premise and SharePoint Online. In general, all of the documents that belong to a specific security type should have ACLs that are formatted in a consistent way.

Having separate security types for SharePoint on-premise and SharePoint Online will affect the configuration of several components including the SharePoint Remote Connector, OmniGroupServer, Community, and Content].

Connector Configuration

When you configure the connector, configure the fetch tasks that retrieve information from SharePoint and SharePoint Online to add a different security type to documents. For example:

[SharePointOnPremise]
...
MappedSecurity=TRUE
UseEmailAsGroupName=FALSE
IngestActions=META:SecurityType=SharePoint

[SharePointOnline]
...
MappedSecurity=TRUE
UseEmailAsGroupName=TRUE
IngestActions=META:SecurityType=SharePointOnline

OmniGroupServer Configuration

When you configure OmniGroupServer, define separate repositories for SharePoint on-premise users and groups, and SharePoint Online users and groups. For example, you might configure:

  • A repository that combines all of the users and groups for SharePoint on-premise. The user and group names in this repository could be in NT-style format (such as DOMAIN\USER or DOMAIN\GROUP). This repository might combine users and groups from:

    • A repository that contains users and groups extracted from Active Directory (through LDAP) or from or an alternate claims provider.
    • A repository that contains SharePoint groups extracted from SharePoint on-premise through the SharePoint Remote Connector.
  • A repository that combines all of the users and groups for SharePoint Online. The reason for using a separate repository for SharePoint Online users and groups is because user and group names could be in a different format (such as e-mail addresses) to the user and group names extracted from SharePoint on-premise. This repository might combine users and groups from:

    • A repository that contains users and groups extracted from Active Directory (through LDAP) or from an alternate claims provider. So that OmniGroupServer can extract e-mail addresses rather than user names from Active Directory, you could set the parameters KeyUserName=mail and KeyGroupName=mail.
    • A repository that contains users and groups extracted from SharePoint Online through the SharePoint Remote Connector. You might configure the fetch task used by the Synchronize and SynchronizeGroups actions to return ACLs that contain e-mail addresses rather than group names. Do this by setting the configuration parameter UseEmailAsGroupName=TRUE in the fetch task configuration.

Only the repositories that contain the combined information should be queried by Community.

For information about how to configure these repositories, see Retrieve Security Group Information using OmniGroupServer.

IDOL Component Configuration

For more information about configuring security types in the IDOL Content component and IDOL Community component, refer to the IDOL Document Security Administration Guide.