Chat now with support
Chat with Support

On Demand Migration Current - Security Guide - Active Directory

Separation of Customer Data

ODMAD is designed to prevent data commingling by logically separating customer data. Customer data are differentiated using a Customer Organization Identifier. The Customer Organization Identifier is a unique identifier obtained from Quest On Demand that is created when the customer signs up the application. This identifier is used throughout the solution to ensure strict data separation of customers' data.

Customer data is further separated as customer related services are isolated from any other OS process by the Microsoft Service Fabric exclusive process model.  See https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-hosting-model#exclusive-process-model for more information.

Network Communications

  • All communication to the ODMAD - including the user interface and associated Azure services - are secured with HTTPS. There are no unsecured external HTTP calls within ODMAD.
  • All communication with Microsoft Entra ID uses OAuth2 access tokens for Microsoft Graph API operations and HTTPS for PowerShell operations.
  • On-premises directory sync agents communicate with on-premises Active Directory using LDAP or LDAPS over TLS 1.2 as configured within the user interface and communicate with ODMAD cloud services using HTTPS.
  • When the optional password sync feature is enabled, on-premises directory sync agents communicate with a signed Password Filter over an encrypted named pipe. The connection is encrypted using AES256 and a key derived from a customer-selected passphrase. On-premises device agents poll the Device Agent Cache Service (DACS) using unencrypted UDP or HTTP for efficiency. No sensitive information is exchanged, just a Boolean value indicating when there are jobs queued for the device agent. If DACS indicates there are jobs queued, the device agent communicates securely with the ODMAD web service using HTTPS to retrieve the job details.
  • When the optional password change propagation feature is enabled, password changes are relayed between on-premises servers doubly-encrypted, first using AES256 and a key derived from a customer-selected passphrase, then using HTTPS over TLS 1.2. Target passwords are updated using LDAPS, with optional SSL certificate pinning to verify the identity of the target domain controller.
  • ODMAD reads and writes content using HTTPS over TLS 1.2 data channels.
  • ODMAD Email Rewrite Services communicates with Microsoft 365 tenants using TLS 1.2 encrypted data channels.

 

A diagram of a computer Description automatically generated

Authentication of Users

  • ODMAD relies Microsoft Entra ID for authentication which provides customers with an integrated authentication experience where you can move from ODMAD to a Microsoft portal seamlessly, without multiple logins and passwords. All while keeping your account security under your organization’s policies, rules, and security protocols.
  • ODMAD also supports Multi Factor Authentication (MFA) for organizations that have enabled MFA within Microsoft 365.
  • Registering a Microsoft Entra tenant into ODMAD is handled through the Azure Admin Consent workflow and customers can revoke Admin Consent at any time. See https://msdn.microsoft.com/en-us/skype/trusted-application-api/docs/tenantadminconsent  for details.

Role Based Access Control

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 to the Quest On Demand product documentation.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating