ODMSS user data is stored in On Demand which 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.
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.
- 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.