Separation of customer data
A common concern related to cloud-based services is the prevention of co-mingling of data that belongs to different customers. The On Demand Migration architecture specifically prevents such data co-mingling by logically and virtually separating customer data stores.
Customer data are differentiated using a Customer Organization Identifier. The Customer Organization Identifier is a unique identifier obtained from the Quest On Demand Core that is created when the customer signs up with the application.
This identifier used throughout the solution to ensure strict data separation of customers' data in Elasticsearch storage and during processing.
A separate Elasticsearch server instance is used for each customer.
Network communications
The following schema shows the communication configuration between key components of On Demand Migration for Hybrid Exchange.
The network communication is secured with HTTPS TLS 1.2.
Inter-service communication uses OAuth authentication using a Quest Microsoft Entra ID service account with the rights to access the services. No back end services of ODMHE can be used by end-users.
On Demand Services accepts the following network communication from outside Azure:
- Customer access to ODMHE web UI.
- PowerShell cmdlets accessing ODMHE back end (PowerShell cmdlets are used internally by Quest Authorized Support personnel.)
The ODMHE user interface uses OAuth 2.0 authentication with JWT token issued to a logged in user.
PowerShell cmdlets used by Quest Authorized Support personnel are using Microsoft Entra ID authentication to access the ODMHE service.
For on-premise Microsoft Exchange migrations, the default port used (during the migration) is port 443 (HTTPS). A customer has the choice of using a non-encrypted connection using HTTP. It is also possible for a customer to use non-standard ports, and specifying these port numbers in the URL (e.g. https://xyz:454).
ODMHE communicates with on-premise Microsoft Exchange servers over port 443 by default. Port 80 may be used if the customer configures their on-premise server that way.
Self-signed certificates are allowed as well when connecting to on-premises servers. Such certificate must be valid and its Issuer DN must match its Subject DN.
Authentication of users
The customer logs in to the application by providing On Demand user account credentials.
The process of registering a Microsoft Entra ID tenant in On Demand Migration is handled through the well established Azure Admin Consent workflow. For more information about the Microsoft Entra ID Admin Consent workflow, please refer the Quest On Demand Global Settings User Guide.
Role based access control
On Demand Migration does provide the common authentication via Quest Identity Broker. Quest On Demand is configured with default roles that cannot be edited or deleted, and also allows you to add custom roles to make permissions more granular. Each access control role has a specific set of permissions that determines what tasks a user assigned to the role can perform. For more information on role-based access control, please refer the Quest On Demand product documentation.