Mimecast for Outlook - Integrated Windows Authentication

Updated November 21, 2025 14:46

This article contains information on using Integrated Windows Authentication with Mimecast for Outlook, including its benefits, setup requirements, authentication process, security considerations, and troubleshooting authentication issues.

Also see Configuring IWA Authentication.

Introduction

Integrated Windows Authentication allows customers using Microsoft Exchange 2016 and later versions of On Premise Exchange, to allow users of the Mimecast for Outlook application to seamlessly log in without needing to enter a password.

Benefits

The primary benefit of the feature is that users do not have to enter a password to use the Mimecast for Outlook application. Consequently, this helps:

Accelerate user adoption of Mimecast features.
Simplify the implementation of the Mimecast for Outlook application.
Simplify end user education requirements.

Windows Extended Protection can interfere with Integrated Windows Authentication (IWA) in Mimecast for Outlook. When Extended Protection is enabled in your environment, it may cause authentication failures with IWA.
If you're experiencing IWA authentication issues, check if Windows Extended Protection is enabled in your environment. If it is, you may need to use alternative authentication methods like SAML.
You can can disable Windows Extended Protection by following these instructions from Microsoft.

Using Integrated Windows Authentication

Integrated Windows Authentication should be used when implementing the Mimecast for Outlook application, and the Microsoft Exchange and Windows client PC infrastructure meets the requirements below:

Commonly used tables, added here in case you need them:

Component	Description
Exchange Server	The Integrated Windows Authentication feature uses the Exchange Web Services API. This is supported in MicrosoftExchange Server 2016 and later releases of Microsoft Exchange. The feature is not supported for Microsoft 365 environments.
Client PC	As the Integrated Windows Authentication feature uses Windows to obtain user verification challenge response tokens, the machine where the Mimecast for Outlook application is installed must be an Active Directory domain member, and the logged in user must be a domain user and the same user as the Microsoft Outlook profile being used. Integrated Windows Authentication is not supported on WORKGROUP machines, or when the logged in user is not the same user as the Microsoft Outlook profile being used.

How Integrated Windows Authentication Works

Integrated Windows Authentication leverages Microsoft Exchange Web Services and Windows Operating System technologies, in conjunction with the Mimecast platform, to securely exchange authentication tokens to verify the identity of a user.

The authentication process starts with Mimecast for Outlook collecting a Negotiate Token from Windows.
The Token is sent to the admin-specified Client Access Server URL specified in the effective Authentication Profile via the Mimecast API.
The Client Access Server responds with an HTTP 401 response containing the following example HTTP header information:
```
Content-Length:0
Date:Fri, 21 Nov 2014 21:13:19 GMT Server:Microsoft-IIS/7.5
WWW-Authenticate:Negotiate
WWW-Authenticate:NTLM
WWW-Authenticate:Basic realm="server.domain.com" X-Powered-By : ASP.NET
```
The important line is WWW-Authenticate:Negotiate. Without this response from the Client Access Server, the process will not continue as the Exchange environment is not configured to support the required authentication method.

With the communication channel established, Mimecast for Outlook and the Mimecast API act as a proxy between Windows and the Client Access Server for the authentication negotiation.
This process continues until both the client and server have established that the user is authenticated. At this stage, the user is considered to be an authenticated Mimecast user and granted access to the application.

Security Considerations

All communication is sent securely over an Encrypted HTTPS channel.
Mimecast supports the TLS 1.2 Protocol for inbound connections to Public API's.
When connecting outbound to customer servers, Mimecast only supports TLS 1.2 Protocol during the SSL Handshake.

Authentication Issues

You can clearly identify where there are authentication issues. For example:

Should Mimecast for Outlook not be able to authenticate upon startup, the Authentication Wizard is automatically displayed when a user clicks on the notification.
The available authentication methods are displayed in the Authentication Settings dialog, along a clear indication as to the status of each.
If there are issues, you can fix them by clicking on the Fix button.