Chat now with support
Chat with Support

On Demand Migration Current - Security Guide - Active Directory

Overview of Data Handled by ODMAD

Domain Migrations

During domain migrations, ODMAD collects data for a variety of Microsoft Entra ID objects. 

  • Directory objects are processed using Microsoft Graph API and PowerShell.
  • Objects include users, groups, contacts, teams, and Microsoft 365 groups.
  • Properties include account name, email addresses, contact information, department, membership and more.
  • Access to Microsoft Entra ID is granted by the customer using the Microsoft Admin Consent process and requires administrative credentials. Customers can revoke Admin Consent at any time. See https://msdn.microsoft.com/en-us/skype/trusted-application-api/docs/tenantadminconsent for details.
  • ODMAD does not store credentials for administrative accounts.
  • ODMAD generates and manages dedicated service accounts in each Microsoft 365 tenant used for PowerShell queries. The service accounts password is randomly generated to be unique and highly complex. The password is also encrypted with AES 256-bit encryption using Azure Key Vault and is never stored unencrypted.
Email Rewrite Service

During domain migrations from domain rewrite enabled projects, ODMAD rewrites email message recipients to provide seamless message delivery. There are two versions of the Domain Rewrite Service, and email messages are temporarily stored based on the rewrite mode.

  • Legacy Mode

    Email messages are temporarily stored during processing and deleted as soon as they are written to the target. The temporarily stored messages are encrypted using AES symmetric-key encryption with a 256-bit key that is unique per message, randomly generated and only held in memory.

  • Advance and Express Domain Rewrite Mode

    Email messages are temporarily stored in Azure blob storage during processing and deleted immediately after delivery. The temporarily stored messages are encrypted using Azure client-side encryption. Each message is encrypted using a unique 256-bit AES symmetric data encryption key, which is itself encrypted using a per-customer 2048-bit RSA asymmetric key pair stored in Azure Key Vault.

Directory Synchronization & Migration

ODMAD collects data for a variety of on premises and Microsoft Entra ID objects.  The directory locations, objects and properties collected are configurable to ensure only the desired objects and properties are processed.

Microsoft Entra ID
  • Directory objects are processed using Microsoft Graph API and PowerShell.
  • Objects include users, groups, contacts, teams, and Microsoft 365 groups.
  • Properties include account name, email addresses, contact information, department, membership and more.
  • Access to Microsoft Entra ID is granted by the customer using the Microsoft Admin Consent process and requires administrative credentials. Customers can revoke Admin Consent at any time. See https://msdn.microsoft.com/en-us/skype/trusted-application-api/docs/tenantadminconsent for details.
  • Neither ODMAD nor ODMSS store credentials for administrative accounts.
  • ODMAD generates and manages dedicated service accounts in each Microsoft 365 tenant used for PowerShell queries. The service accounts password is randomly generated to be unique and highly complex. The password is also encrypted with AES 256-bit encryption using Azure Key Vault and is never stored unencrypted.
On Premises Active Directory
  • On-premises directory sync agents, running within the customers network, process Active Directory objects using LDAP or LDAPS (TLS 1.2) as configured within the user interface. Objects include users, groups, and contacts, computers, and servers. Properties include account name, email addresses, contact information, department, membership and more.
  • When the optional password sync feature is enabled, the password hash of all user accounts in scope are collected using an encrypted connection to a signed Password Filter. The connection is encrypted using AES256 and a key derived from a customer-selected passphrase. Password hashes are stored encrypted with AES256 in Azure SQL Storage. The AES256 key is stored in Azure Key Vault. Once co-existence is no longer required for a specific user, the customer should use the reconcile option to ensure that information is promptly deleted.
  • When the optional password change propagation feature is enabled, a signed Password Filter receives notifications when source users change their passwords. It relays those changes to the Password Change Propagation Service, which uses LDAPS to update the passwords of target users. Passwords are stored on disk temporarily, doubly-encrypted, first using AES256 with a key derived from a customer-selected passphrase, then again using the Windows Data Protection API (DPAPI).
  • On-premises directory sync agents, running within the customers network, securely encrypt and store administrative credentials locally on the agent’s computer.
  • On-premises device agents running locally on the end user’s workstation collect device properties using WMI and PowerShell. Device properties include device name, domain name, user profile locations and more.
  • ODMAD optionally stores credentials required for network share re-permission and Active Directory domain joins. These credentials are provided by migration operators and are encrypted with AES 256-bit encryption using Azure Key Vault and are never stored unencrypted.
AI-Powered Migration Assistant

On Demand Migration for Active Directory uses Artificial Intelligence to generate summary reports from logging data produced during directory synchronization operations. Reports may contain suggestions from the On Demand Migration Knowledge Base. This feature is optional and requires the operator to initiate the analysis.

  • All data stays within your On Demand Region and reports are only available to view in the On Demand organization where they were generated.
  • AI generated reports are cached for a period and then subsequently removed on the same schedule as the logs used to generate the report.
  • Data is consumed by AI only when you request a report be generated.
  • Data is used only to generate the summary report and will never be used for AI training.
  • AI does not have access to privileged accounts or application consents and is not provided with the rights to perform any migration activities. All user-initiated AI activities are recorded for auditing purposes via the Activity Trail module in On Demand.

Admin Consent and Service Principals

ODMAD requires access to the customer’s Microsoft Entra ID and Office 365 tenants. The customer grants that access using the Microsoft Admin Consent process, which will create a Service Principal in the customer's Microsoft Entra ID with minimum consents required. The Service Principal is created using Microsoft's OAuth auth code grant flow https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow

Customers can revoke Admin Consent at any time. See https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/delete-application-portal and https://docs.microsoft.com/en-us/skype-sdk/trusted-application-api/docs/tenantadminconsent for details.

Below is the Admin Consent screen, see Operational Security > Permissions Required to Configure and Operate for a complete list of permissions required by ODMAD.

Location of Customer Data

When a customer signs up for On Demand, they select the region in which to run their On Demand organization. All computation is performed in and all customer data is stored in the selected region. The currently supported regions can be found here: https://regions.quest-on-demand.com/. ODMAD customer data is stored in the selected region, entirely within Azure Services provided by Microsoft. For more information, see Achieving Compliant Data Residency and Security with Azure.

  • Customer data is stored in Azure SQL and is automatically replicated for failover using Azure SQL Active Geo replication.  See this Microsoft reference for details: https://docs.microsoft.com/en-us/azure/azure-sql/database/active-geo-replication-overview
  • Application logs are stored in Azure storage tables. Windows Azure Storage, including the Blobs, Tables and Queues storage structures, by default get replicated three times in the same datacenter for resiliency against hardware failure. The data are replicated across different fault domains to increase availability. All replication datacenters reside with the geographic boundaries of the selected region. See this Microsoft reference for details: https://docs.microsoft.com/en-us/azure/storage/common/storage-redundancy
  • DKIM and TLS certificates used by ODMAD Email Rewrite Services are stored in Microsoft Key Vault.

When the optional password change propagation feature is enabled, passwords are stored temporarily on the local disks of source domain controllers and a server in the target domain, all within the customer’s on-premises environment. Passwords are doubly-encrypted, first using AES256 with a key derived from a customer-selected passphrase, then again using the Windows Data Protection API (DPAPI)

Privacy and Protection of Customer Data

Sensitive customer data collected and stored by ODMAD from Microsoft Entra ID and on premises Active Directory includes users, password hashes, groups, contacts, and teams.

  • All data is secured at rest using SQL Transparent Data Encryption (TDE) with Microsoft managed keys.  For more information see https://docs.microsoft.com/en-us/azure/azure-sql/database/transparent-data-encryption-tde-overview
  • Azure storage account data is secured at rest using storage service encryption with Microsoft managed keys.  For more information see https://docs.microsoft.com/en-us/azure/storage/common/storage-service-encryption
  • Service account passwords and password hashes (while already encrypted at-rest) are additionally encrypted with AES 256-bit encryption using Azure Key Vault.
  • ODMAD Email Rewrite Services encrypt email messages using AES encryption and a unique, randomly generated 256-bit key that is unique per message and only held in memory.
  • When the optional password change propagation feature is enabled, passwords are stored temporarily on the local disks of source domain controllers and a server in the target domain, all within the customer’s on-premises environment.
Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating