Integrated Windows Authentication allows customers using Exchange 2007 SP 1 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.
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.
Using Integrated Windows Authentication
Integrated Windows Authentication should be used when implementing the Mimecast for Outlook application, and the Exchange and Windows client PC infrastructure meets the requirements below:
The Integrated Windows Authentication feature uses the Exchange Web Services API. This is supported in Exchange Server 2007 SP 1 and later releases of Exchange.
The feature is not supported for Office 365 environments.
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 a HTTP 401 response containing the following example HTTP header information:
Date:Fri, 21 Nov 2014 21:13:19 GMT
X-Powered-By : ASP.NET
The important line here 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 client and server have established the user is authenticated. At this stage the user is considered to be an authenticated Mimecast user and granted access to the application.
- All communication is sent securely over an encrypted HTTPS channel.
- Mimecast supports TLS 1.0, 1.1, and 1.2 protocols for inbound connections to public API's. SSL v3 is not supported for inbound connections to Mimecast.
- When connecting outbound to customer servers, Mimecast offers TLS 1.0, 1.1, 1.2 protocols during the SSL handshake.
- For backward compatibility, SSL v3 is offered for outbound connections from Mimecast. However, Mimecast strongly recommends that SSL v3 is disabled on customer servers.
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, alongside a clear indication as to the status of each.
- If there are issues, you can fix them by clicking on the Fix button.
To learn how to configure Integrated Windows Authentication see the Configuring Integrated Windows Authentication article.