The Azure AD provider connects to the Microsoft Azure AD cloud tenant to collect data for time traveling that is not available to AADSync / DirSync.
The Azure AD provider uses the MSOnline PowerShell module to collect information about Azure AD, including groups, users, and licensing data. It uses Office 365 Exchange PowerShell sessions to collect host of identity information from Exchange in the cloud, including mailbox settings and usage, email last logon, mobile device, and auto-reply settings. The Azure AD provider is also able to connect and time travel data from on-premises Exchange 2013.
To use Azure AD PowerShell you must first download and install the MSOnline PowerShell (MSDN) module. On Server 2012 R2, this should install to C:\Windows\SysWOW64\WindowsPowerShell\v1.0\Modules\MSOnline by default. If MSOnline is installed to a different location, you will need to edit SoftwareIDM.PanelService.exe.config, and PanelTool.exe.config to contain the correct install directory.
Before attempting to configure an Azure AD connection, ensure that you can connect to Exchange Online PowerShell (Technet) and
Before using the Azure AD provider you must configure a connection in the Providers settings tab. If your organization has multiple Azure AD cloud tenants you can create separate connections for each one. It is also possible to create multiple environments pointed at the same tenant, in order to collect separate subsets of cloud data in different silos.
Each environment must have a unique name, but this name may be changed at any time. Because the environment name will be prefixed onto MSOnline and Exchange silos, short names are preferred (e.g. Azure, O365).
Before adding a provider of type Azure Connection, you may need to apply an additional license key. If an additional key is required the dropdown list will say "Azure Connection – License Required".
Unlike most other provider types The Password Storage feature (and accompanying license key) is mandatory with the Azure Provider. This is because Identity Panel must store the credentials supplied to the PowerShell connection.
The first part of the environment settings is account credentials. The username should be the UPN login for an account with global read access to the cloud tenant. If you plan to use the Workflow engine for tasks like assigning and removing licenses the account should be a global administrator. The account does not have to be mailbox enabled. Additionally the account should not have MFA enabled as it will cause issues with PowerShell.
In order to collect data from the cloud, the Azure AD provider must do a regular scan with PowerShell. The largest performance bottleneck for this scan is the throttling limits applied by the Exchange PowerShell provider. The Azure AD provider is designed to respect these throttling limits from the client side, so as not to lockout the account. Certain data cmdlets are more demanding than others. Mobile device statistics and mailbox statistics are the slowest.
The best way to improve scan performance is to use multiple user accounts in parallel, since Exchange throttling is applied on a per-user session basis, and each organization is permitted up to 9 simultaneous concurrent PowerShell user sessions. If you provide multiple user credentials the Azure AD provider is able to run more commands in parallel to maximize scan performance.
To collect data using the Azure AD provider select strips from the Data Type drop-down list and press the Add icon. Each data type corresponds to a PowerShell command that returns an iterable result. For example, the Mailbox — Exchange command iterates over Get-Mailbox in the Exchange PowerShell environment.
Once a command pipeline is added, you can select and deselect which attributes to collected for the time traveller.
Strips are treated as a pipeline because they can have Child commands. A child command is invoked once for each record returned by the parent command. The Azure AD scan dispatch logic runs each command pipeline in parallel. Threading enables the child commands within each pipeline to also run in parallel.
The included object scan types are:
- User - MSOnline
- Group - MSOnline
- Group Membership - MSOnline
- Role - MSOnline
- Role Membership - MSOnline
- License Sku - MSOnline
- Contact - MSOnline
- Mailbox - Exchange
- Mailbox Statistics - Exchange
- Mailbox Junk Mail - Exchange
- Mailbox Message - Exchange
- Mailbox Regional - Exchange
- Mailbox Permissions - Exchange
- Mailbox Auto Reply - Exchange
- Mailbox Calendar - Exchange
- Contact - Exchange
- Distribution Group - Exchange
- Distribution Group Membership - Exchange
- Mobile Device - Exchange
- Mobile Device Stats - Exchange
- Role Group - Exchange
- Retention Policy - Exchange
- Federated Organization - Exchange
- Federation Trust - Exchange
Azure data may be scanned using Panel Tools or with a schedule step. It is generally advisable to perform an initial scan with Panel Tool as it gives realtime diagnostic output on any connection issues that may need resolution, such as PowerShell credential problems or firewall issues.
The Azure Scan schedule step reads data from an Azure Provider. It saves a history record using the same Add, Update, and Delete counters used by the run management agent steps. Because the same counters are used charts of Azure AD data should specify either the provider or history record type to filter out MA data.
Depending on organization size the Azure scan can take a considerable amount of time to run due to PowerShell throttling performed by Microsoft. In most scenarios it is appropriate to target a daily scan.
The only field required for the Azure Scan schedule step is the Environment.