How to Create an EntraID Application for Cloudiway

To allow Cloudiway to access your Microsoft 365 tenant and perform migrations (emails, files, Teams), you need to create an EntraID application (formerly Azure AD) with the appropriate permissions. This guide walks you through this configuration step by step.

Video Tutorial

Watch on YouTube

The following steps will generate the Client ID, the Client Secret, and the Certificate needed in your Cloudiway connector.

Prerequisites

Before you begin, make sure you have:

• Global Administrator or Application Administrator rights on the Microsoft 365 tenant
• Access to the Azure Portal
• PowerShell installed on your computer (for certificate creation)
• An active Cloudiway account

Step 1: Create the Certificate for the New Application

Using PowerShell, execute the following commands to create your certificate:

$certname = "{certificateName}"    ## Replace {certificateName} with your certificate name
$cert = New-SelfSignedCertificate -Subject "CN=$certname" `
    -CertStoreLocation "Cert:\CurrentUser\My" `
    -KeyExportPolicy Exportable `
    -KeySpec Signature `
    -KeyLength 2048 `
    -KeyAlgorithm RSA `
    -HashAlgorithm SHA256

Export the certificate (.cer):

Export-Certificate -Cert $cert -FilePath "C:\Users\admin\Desktop\$certname.cer"   ## Specify your preferred location

Step 2: Create the Private Key with a Password for Cloudiway

Execute the following command lines to define your password:

$mypwd = ConvertTo-SecureString -String "{myPassword}" -Force -AsPlainText   ## Replace {myPassword} with a strong password

Export the Private key (.pfx):

Export-PfxCertificate -Cert $cert -FilePath "C:\Users\admin\Desktop\$certname.pfx" -Password $mypwd   ## Specify your preferred location

Step 3: Create a New Application

Log in to the Azure portal using your Microsoft 365 administrator account:

1. Go to https://portal.azure.com
2. Select Microsoft Entra ID
3. Click on App Registration
4. Click on New Registration
5. Give a name to the application (e.g., Cloudiway Platform)
6. Supported Account types: Select "Accounts in this Organizational directory Only"

Redirect URI Configuration

If you are migrating Microsoft Teams and plan to migrate direct messages, you need to add these two redirect links in the source Application:

• https://portal.cloudiway.com/teams/callback
• https://portal.cloudiway.com/connector

In other cases, the redirect URL is not used. Enter any value, for example https://notused

7. Click on Register

Step 4: Upload Certificate

Upload the Certificate

1. Click on Certificates and Secrets
2. Click on the Certificates tab
3. Click on Upload Certificate
4. Select the .cer file you created in Step 1
5. Click Add

Enable Public Client Flows

1. Click on Authentication in the left menu
2. Scroll down to Advanced settings
3. Enable "Allow public client flows" and set it to Yes
4. Click Save

Step 5: Configure API Permissions

The required permissions depend on the type of migration you are performing and whether the connector is configured as Source or Target.

1. Click on API Permissions in the left menu
2. Click on Add a permission
3. Select Microsoft Graph or SharePoint depending on the workload
4. Choose Application permissions
5. Add the required permissions based on the tables below

Permissions Reference Tables

Below are the detailed permissions required for each connector type. Permissions marked with (Delegated) require delegated permissions instead of application permissions.

Microsoft Entra ID API Permissions — Source Connectors

Microsoft Entra ID API Permissions — Target Connectors

For Target connectors, you generally need Write permissions instead of Read permissions. Also, it's IMPORTANT to have the access level BOTH as Application type and Delegated type.

SharePoint Online API Permissions — Source vs Target

These permissions are granted under the Office 365 SharePoint Online API namespace in Entra ID and are distinct from the Microsoft Graph permissions of similar names. They cover CSOM (Client-Side Object Model) operations used by Cloudiway for SharePoint and OneDrive migration.

GalSync Permission Usage Details

This section documents how each declared permission is consumed by the GalSync product (used on both Source and Target connectors, internal identifier Product.Galsync). It is intended for security and compliance reviewers who need to validate why elevated Microsoft Graph permissions are required.

Declared permissions

• Directory.Read.All — read directory metadata required to resolve users, groups, and contacts.
• Group.Read.All — read distribution and mail-enabled security groups participating in GAL synchronization.
• OrgContact.Read.All — read organizational (mail) contacts that must be replicated to the target GAL.
• User.ReadWrite.All — read source user attributes and, when applicable, create or update target users (MailUsers / Guests).
• User.Invite.All — invite users as Guests in the target tenant when GAL entries are projected as B2B Guests.
• Exchange.ManageAsApp — Azure role required for app-only authentication against Exchange Online PowerShell (used for MailUser / mail-attribute provisioning that Microsoft Graph does not expose).

1. User.ReadWrite.All — Read path (list source users)

Business usage:

• Used to list all source users that must be projected into the target Global Address List.
• Paged enumeration (top=500) over the directory with a server-side $filter and an explicit $select projection to retrieve only the attributes needed for GAL synchronization.
• Retrieves GAL-relevant user properties, including:
  • displayName
  • mail
  • proxyAddresses
  • jobTitle
  • mobile
  • city
  • department
  • and other GAL-related user properties (e.g. givenName, surname, companyName, officeLocation, businessPhones).

Why elevated permission is required: User.Read.All would be sufficient for the read path in isolation, but the same service is reused for the write path below. Microsoft Graph does not grant cross-scope inheritance, so the broadest scope actually invoked at runtime (User.ReadWrite.All) is the one declared, in order to keep a single consistent application registration across Source and Target roles.

2. User.ReadWrite.All — Write path (create target users)

Business usage:

• Used to create users in the target tenant when a GAL entry must be materialised as a native Entra ID user object.
• This operation is uncommon: in the standard GalSync flow, MailUsers are provisioned through Exchange Online PowerShell (New-MailUser), which is the supported Microsoft path for setting mail-routing attributes such as ExternalEmailAddress and targetAddress.
• Retained for backward compatibility and for specific migration scenarios where direct Graph user creation is required (for example, tenants without an Exchange Online plan attached to the service principal, or hybrid topologies where the EXO endpoint is unavailable).

Why elevated permission is required: creating a user through Microsoft Graph requires the User.ReadWrite.All application scope; there is no narrower Graph permission that authorizes POST /users. This call is gated by an explicit per-job configuration flag and is never executed implicitly by the read path.

Step 6: Mail Migration - Additional Configuration

6.1 Add EWS Permissions (Office 365 Exchange Online)

For Mail migration, you need to add permissions from the Office 365 Exchange Online API (not Microsoft Graph):

1. Go to API Permissions and click Add a permission
2. Select the tab APIs my organization uses
3. Search for Office 365 Exchange Online and select it
4. Select Application permissions
5. Expand Other permissions and select full_access_as_app
6. Also add Exchange.ManageAsApp (required for Exchange administration)
7. Click Add permissions

6.2 Configure App-Only Authentication (Manifest)

To enable app-only authentication for Exchange, you need to modify the application manifest:

1. Select Manifest in the left-hand navigation under Manage
2. Locate the requiredResourceAccess property in the manifest, and add the following inside the square brackets ([]):

{
    "resourceAppId": "00000002-0000-0ff1-ce00-000000000000",
    "resourceAccess": [
        {
            "id": "dc890d15-9560-4a4c-9b7f-a736ec74ec40",
            "type": "Role"
        }
    ]
}

3. Click Save at the top of the page

6.3 Assign Microsoft Entra Roles

You need to assign the following roles to your application:

• Exchange Administrator
• Exchange Recipient Administrator

Steps to Assign Roles:

1. Navigate to the Microsoft Entra roles and administrators page:
   https://portal.azure.com/#view/Microsoft_AAD_IAM/AllRolesBlade
2. Search for Exchange in the roles filter
3. Select the Exchange Administrator role
4. Click on Add Assignment
5. Search for and select the app that you created
6. Click Add
7. Repeat the above steps for the Exchange Recipient Administrator role

Step 7: Grant Admin Consent

For the application to use the granted permissions:

1. Go back to "API permissions"
2. Click on "Grant admin consent for [your organization]"
3. Confirm by clicking "Yes"

All permissions should now display a green checkmark in the "Status" column.

Configuration in Cloudiway

Now that your application is created, configure it in Cloudiway:

1. Log in to the Cloudiway Portal
2. Navigate to your project and open the Connector Settings
3. Enter the following information:
   • Tenant Name: the Tenant Name is the unique prefix before .onmicrosoft.com in your Microsoft 365 initial domain.
   • Application ID: The Application (client) ID
   • Certificate: Upload the .pfx file created in Step 2
   • Certificate Password: The password you set when creating the private key
4. Test the connection to validate the configuration

Common Troubleshooting

"Insufficient privileges" Error

This error indicates that:

• Admin consent has not been granted
• Permissions are missing
• The secret has expired

Solution: Check in "API permissions" that all permissions have "Granted" status and that the secret is still valid.

"AADSTS700016: Application not found" Error

The Application ID is incorrect or the application has been deleted.

Solution: Verify the Application ID in the Azure portal and in the Cloudiway configuration.

"Invalid client secret" Error

The client secret is incorrect or has expired.

Solution: Generate a new secret or use certificate authentication (recommended) and update the configuration in Cloudiway.

"Certificate Error" or "Invalid Certificate"

The certificate is invalid, expired, or the password is incorrect.

Solution: Verify that:

• You uploaded the .cer file to Azure (not the .pfx)
• You provided the .pfx file and correct password to Cloudiway
• The certificate has not expired