IBM MaaS360 - Cloud Extender: Certificate-Based Authentication for Office 365 Exchange ActiveSync Access

Author - @Lakshmeesh C Hegde

As organizations continue to strengthen their security posture in Microsoft 365, traditional authentication models based on usernames and passwords are increasingly becoming a liability. This is especially true for backend integrations that require persistent administrative access—such as managing Exchange ActiveSync (EAS) devices in Exchange Online.

In this post, we’ll explore why certificate-based authentication (CBA) is a better approach for Exchange ActiveSync management, the challenges of the existing credential-based model, and how app-only authentication using certificates aligns with Microsoft’s modern security guidance.

📘 Microsoft reference:
https://learn.microsoft.com/en-us/powershell/exchange/app-only-auth-powershell-v2?view=exchange-ps

Architecture diagrams

The Problem with Service Accounts and Passwords

Many enterprise EAS integrations today rely on the ExchangeOnlineManagement PowerShell module, authenticated using a service account and password. This model enables solutions to:

• Discover mailboxes and mobile devices
• Approve, block, or quarantine EAS devices
• Update ActiveSync policies based on MDM changes
• Synchronize Exchange Configuration Data

While functional, this approach introduces several significant security and operational challenges.

1. MFA Must Be Disabled

To support non-interactive authentication, MFA is often disabled on service accounts. This directly contradicts Microsoft’s Zero Trust and identity security best practices.

2. Security Defaults Must Be Turned Off

In many tenants, Security Defaults must also be disabled to allow legacy authentication, weakening tenant-wide security protections.

3. Password Storage and Rotation Risks

Administrative credentials are often:

• Stored on-premises or in a cloud extender
• Rotated manually
• Vulnerable to exposure through misconfiguration or compromise

This creates discomfort and risk for customers managing sensitive environments.

4. Microsoft Is Actively Moving Away from This Model

Microsoft continues to deprecate legacy authentication patterns and strongly recommends moving to passwordless, app-based authentication wherever possible.

The Shift to Certificate-Based (App-Only) Authentication

To address these challenges, Microsoft supports application-only authentication using certificates with the ExchangeOnlineManagement PowerShell module.

Instead of authenticating as a user, this approach authenticates as an Azure AD (Microsoft Entra ID) application, using a cryptographic certificate rather than a password.

What Changes?

How Certificate-Based Authentication Works

At a high level, the authentication flow is straightforward:

1. An application is registered in Microsoft Entra ID
2. A public certificate is uploaded to the application
3. The application is granted Exchange application permissions
4. The private certificate is securely stored by the integration
5. PowerShell connects to Exchange Online using app-only authentication

No usernames. No passwords. No MFA prompts.

Exchange ActiveSync Support with App-Only Authentication

A common concern is whether app-only authentication supports the Exchange cmdlets required for EAS management. The good news is—it does.

Supported operations include:

• Retrieving mailboxes
• Listing and inspecting mobile devices
• Approving, blocking, or wiping EAS devices
• Managing ActiveSync mailbox policies

This makes certificate-based authentication an ideal fit for MDM-driven EAS workflows, where actions are system-initiated rather than user-driven.

Improved Security Through Scoped Access

One of the most powerful advantages of the app-only model is granular access control.

Using Application Access Policies, organizations can restrict the app’s access to:

• Only mailboxes managed by the MDM
• A specific subset of users
• Dedicated mail-enabled security groups

This significantly reduces the blast radius and enables least-privilege access, something that’s difficult to achieve with a global Exchange admin service account.

Operational Benefits for Customers

From a customer perspective, certificate-based authentication offers clear benefits:

• No administrative passwords stored or shared
• MFA and Conditional Access remain fully enforced
• Alignment with Microsoft security recommendations
• Reduced risk of credential compromise
• Increased transparency and trust in third-party integrations

Certificates can be proactively rotated and monitored for expiration, making them easier to manage securely at scale than passwords.

Prerequisites to Configure on Cloud Extender Configuration Tool and Configuration Overview

To use certificate-based credentials, the application must be registered in Microsoft Entra ID, assigned the appropriate API permissions, and associated with a certificate.

Application Registration in Entra ID

1. Log in to the Microsoft Entra ID portal
2. Navigate to App registrations
3. Select New registration and register your application

Important: Copy the Tenant ID and Client ID from the application overview page.

📘 Reference:
https://learn.microsoft.com/en-us/powershell/exchange/app-only-auth-powershell-v2?view=exchange-ps#step-1-register-the-application-in-microsoft-entra-id

Grant Exchange API Permissions

1. Open the registered application
2. Navigate to Manage → API permissions
3. Select + Add a permission
4. Choose APIs my organization uses → Office 365 Exchange Online
5. Select Application permissions → Exchange.ManageAsApp
6. Grant Admin consent

📘 Reference:
https://learn.microsoft.com/en-us/powershell/exchange/app-only-auth-powershell-v2?view=exchange-ps#step-2-assign-api-permissions-to-the-application

Certificate Creation and Upload

The customer must generate a PKCS#12 certificate (self-signed or CA-issued).

• A self-signed certificate can be generated using OpenSSL
• Public certificate (e.g., .pem) is uploaded to the Entra ID app
• Private certificate path and password are configured in the Cloud Extender

📘 OpenSSL reference:
https://www.ibm.com/docs/en/app-connect/12.0.x?topic=source-generating-self-signed-ssl-certificate

UI Changes in Cloud Extender Configuration Tool

The Cloud Extender Configuration Tool introduces new settings to:

• Enable certificate-based authentication
• Specify certificate file path and password
• Authenticate Exchange PowerShell using app-only credentials

This ensures seamless integration without storing or handling administrative passwords.

Configure settings for the Exchange module for certificate-based authentication.

Procedure

1. Open the Cloud Extender Configuration Tool and select Exchange.

2. Select Office 365, and click Next.

3.Enter Email Server Configuration.

4. Select Certificate from the type of credentials.

5.Enter the credential and click on Validate Certificate button.

6.Checking  the Exchange Power Shell

7. Validating the Certificate

8.Click on  Save.

IBM MaaS360 Portal Changes 

1. Login to MaaS portal
2. Navigate to Setup > Cloud Extender page

3.Click On Exchange ActiveSync tab

Type of Credential it will show as Certificate 

For Certificate Expiry Date we can check here 

In the Coud Extender Settings page, a health check alert subscription for credentials expiry is added for Exchange Active Sync module:

Navigate to Health Check Configuration > Exchange Alerting - Enable  to get the alert


Video for reference - How to configure Certificate Based Authentication on Cloud Extender Configuration

Video link - https://ibm.box.com/s/s1a26yv704qjcyu6krp16fveyscmryky

Conclusion

Credential-based service accounts for Exchange ActiveSync management no longer align with modern security expectations. Certificate-based, app-only authentication provides a secure, scalable, and Microsoft-recommended alternative that:

• Eliminates passwords
• Preserves MFA and Conditional Access
• Enables least-privilege access
• Reduces operational risk