How Does Riva Communicate with Exchange or Office 365?

This article applies to Riva On-Premise.

Riva uses the Microsoft-provided data-access API, primarily the "Exchange Web Services" (EWS) technology, using HTTP with TLS/SSL to provide secure communication with Microsoft Exchange for Office 365, hosted Exchange, and Exchange on-premises.

Note: EWS is also used by Outlook for Mac and Mail apps to be able to access end-users mailbox contents.

Note: Microsoft Exchange Online will soon disable support for Basic Authentication, details on how to mitigate impacts for Riva can be found in this article.

Connecting and Communicating with Exchange

Exchange is a multi-layered communication system with a typical deployment that includes

• security gateways,
• network or HTTP load balancers,
• Exchange “edge services”, and
• Exchange “mailbox services”.

Riva connects to Exchange "edge services". Based on best practices, Riva is not installed on Exchange servers, nor does it connect directly to Exchange mailbox servers. All data access is performed via network communications.

During each sync cycle, Riva establishes a secure connection to the edge Exchange services responsible for the data-access service (EWS).

After the secure connection is established and the authentication confirmed, data synchronization is carried out for each user mailbox that is assigned to an enabled Riva sync policy.

When negotiating TLS/SSL versions, the Exchange "edge services" are responsible for advertising the supported versions as well as the supported cipher suite.

Safeguards to prevent MITM-style attacks can be configured by using the "Certificate Verification" option. This can be configured to require a trusted certificate or to ensure that a specific destination "edge service" always provides the expected certificate thumbprint — thereby preventing connections to unauthorized end-points. "Certificate Verification" provides additional safeguards for reducing MITM attacks where DNS hijacking, DNS spoofing (DNS poisoning), or other TCP redirection methods are used. This configuration option is recommended. See HTTPS communication certification validation.

Authenticating with Exchange

Riva does not require Exchange administrator role credentials and does not require the credentials for the individual mailboxes being accessed.

The connection established by Riva must be configured with the credentials of an Exchange "service user" that has been assigned permissions to access the mailboxes for the services that will be processed. These permissions can be provided using Application Impersonation (via Role-Based Access Control) or Delegate Access (either Full Access or per-folder permissions).

Different authentication mechanisms are supported by Exchange. These can work in conjunction with built-in Exchange security controls or in addition to using third-party security gateway devices.

For Exchange on-premises / hosted, Riva supports:

1. Basic (user name and password); ^{note 1}
2. NTLM; (See Microsoft TechNet.)
3. Client Certificate / Mutual SSL; ^{note 2}
4. Proxy / Reverse Proxy and;
5. Windows Integrated / Impersonation - Service configured with "Log On As" Domain User.

For Exchange Office 365, Riva supports:

1. Basic (Username/Password); ^{note 1  note 4}
2. OAuth 2.0 / Azure App Pre-Shared Key ^{note 3} and;
3. OAuth 2.0 / Azure App Certificate-based authentication.^{note 3}

Notes:

1. HTTP basic authentication is a simple challenge-and-response mechanism with which a server can request authentication information (a user ID and password) from a client. The client (in this case, Riva) passes the authentication information to the server (in this case, the Exchange "edge service") in an HTTP Authorization header. The authentication information is encoded before being transmitted.

   Warning: The HTTP basic authentication scheme can be considered secure only when the connection between the web client and the server is secure.

2. For deployments using Exchange on-premises or with some Exchange hosted providers, Riva can be configured to use Exchange "Client Certificate" authentication — commonly referred to as "mutual SSL". This replaces the need to use traditional user name and password-based credentials for the Riva service user account. This overcomes password-based authentication security concerns and challenges with password expiration policies.

3. For deployments using Office 365, full support for OAuth 2.0 based authentication was introduced in Riva 2.4.45. This optional configuration replaces the need to manage credentials for the service user and leverages Azure Active Directory (Enterprise / Application Registration). This allows for support of MFA. See Create a certificate-based Office 365 OAuth connection and Create a client secret-based Office 365 OAuth connection.

4. In September 2019, Microsoft announced that a move to Modern Authentication, due to an increase in bot attacks against the Office 365 infrastructure, support for "Basic Authentication" across all Office 365 services will be slowly deprecated.  This includes Exchange Web Services, one of the last services to be disabled.  More recently, Microsoft announced a delay with the world focused on COVID-19 pandemic responses, (as of this update) current dates have not yet been announced with a target for the second half of 2021.

For instructions on how to prepare to create an Exchange connection with Riva, see Prepare for a Riva Server Exchange Web Services connection.

Example: Exchange Configuration

Microsoft best practices for a secure internet-facing environment reflect the following:

Load Balancer > Security Gateway > Load Balancers > Exchange “Edge Services” > Exchange “Mailbox Services”

• Security Gateway: A device/appliance like a security access gateway, for example, Microsoft Forefront Unified Access Gateway (UAG) or any other Web Application Firewall (WAF).
• Load Balancer: A network layer VIP, a device, or appliance that uses Network Load Balancing (NLB), or a more advanced solution like a Cisco or F5 Load Balancer.

 
Each colour above represents a “network zone”. Each of these network zones provides different layers of security and isolation.

In the above flow,

• the YELLOW is “internet accessible”,
• the BLUE is in a “DMZ” / padded layer of the network, and
• the GREEN is in an internal private network.

Many of our large deployments in the financial services space use complex multi-layered deployments that include additional “network zones”. These are fully supported.

Riva On-Premise does not connect directly to any Exchange mail servers.

• Riva On-Premise, usually installed on the customer's premises, connects to the BLUE zone.

Each customer environment is different based on the complexity, compliance, and security needs of the specific target environment. Our team can work with each customer's risk, security, and messaging teams to ensure that all communication and system access complies with the customer's needs.

Your Exchange messaging team is likely already familiar with the technologies and processes used by Riva. If you have questions or require additional information, contact the Riva Success Team.