Active Directory Federation Services (ADFS) Authentication

Document created by user.oxriBaJeN4 Employee on Sep 7, 2015Last modified by user.oxriBaJeN4 Employee on Jul 6, 2017
Version 9Show Document
  • View in full screen mode

Active Directory Federation Services (ADFS) is a Microsoft feature installed on a Windows server. It provides users with Same and Single Sign-On (SSO) access to applications located outside of the organizational boundary (e.g. Mimecast).

 

Benefits of ADFS Authentication

 

Using ADFS as an authentication provider for Mimecast applications has a number of benefits:

  • Web single sign on for the Mimecast Personal Portal and Administration Console.
  • Same sign on support for web, desktop and mobile applications.
  • Allows users to access Mimecast applications using their familiar email address and Active Directory password, accelerating user adoption and reducing administration overhead.
  • No additional licensing costs for customers already using Microsoft infrastructure.

 

Supported ADFS Versions

 

VersionHost Operating System
2.0Windows Server 2008 R2
2.1Windows Server 2012
3.0Windows Server 2012 R2

 

Supported Authentication Methods

 

When using ADFS as an authentication provider the following options are available:

 

SAML Single Sign-On (SSO)

 

  • Supported for:
    • Mimecast Personal Portal
    • Administration Console
    • Mimecast for Outlook 6.1 and later
    • Mimecast Mobile 3.1 and later
    • Mimecast for Mac 2.4 and later
  • Mimecast supports both Service Provider (SP) and Identity Provider (IdP) SSO.
  • Additionally both Integrated Windows Authentication and Password Protected Forms Authentication are supported.
  • Allowing seamless integration when users are inside the corporate network, and adding the security requirement of a password when accessing ADFS outside your organization's perimeter.

 

Same Sign-On Domain Authentication

 

  • Supported for:
    • Mimecast Personal Portal
    • Administration Console
    • Mimecast for Outlook
    • Mimecast Mobile
    • Mimecast for Mac
  • Allows users to authenticate using their email address and Active Directory password.
  • Users are required to present their password to the Mimecast application.

 

Authentication Workflows

 

Service Provider (SP) Initiated SAML Single Sign-On (SSO)

 

Supported Applications:

  • Mimecast Personal Portal
  • Administration Console
  • Mimecast for Outlook
  • Mimecast Mobile
  • Mimecast for Mac

When using Service Provider Initiated SAML Authentication your users must access the Mimecast Personal Portal and Administration Console using the regional URLs for the respective web application.

Due to the differences between each Identity Provider's implementation of SAML, Mimecast does not support this authentication type when using the global URLs:

SP_Initiated_SAML.png

  1. A user accesses the Mimecast application and enters their primary email address.
  2. Mimecast discovers the correct Authentication Profile for the user.
  3. When SAML Authentication is enforced in the user's effective Authentication Profile, Mimecast generates a SAML 2.0 AuthnRequest and redirects the user's browser to the *Identity Provider's login URL.
  4. If the user is not already authenticated with the *Identity Provider the user is prompted to authenticate. Alternatively, if the user is already authenticated with the *Identity Provider they will not need to authenticate again.
  5. Once the user is authenticated a SAML response is generated by the *Identity Provider and posted back to the Mimecast application via the user's browser.
  6. Mimecast verifies the SAML response.
  7. The authentication process competes and the user is granted access to the Mimecast application.

*Identity Provider is your organization's ADFS server(s).

 

Identity Provider (IdP) Initiated SAML Single Sign-On (SSO)

Supported Applications: Mimecast Personal Portal and Administration Console

IdP_initiated_SAML.png

  1. A user browses to the *Identity Provider's login page
  2. The *Identity Provider authenticates the user.
  3. The user selects the Mimecast application to access from the *Identity Provider's application catalogue page, and the *Identity Provider generates a SAML assertion which is sent to the selected Mimecast application via the user's browser.
  4. Mimecast accepts the request, establishes who the identity of the user from the NameID element of the SAML assertion, discovers the user's effective Authentication Profile and verifies the request.
  5. The authentication process competes and the user is granted access to the Mimecast application.

*Identity Provider is your organization's ADFS server(s).

 

Same Sign-On Domain Authentication

Supported Applications: All Mimecast applications can use Domain Authentication except SMTP authentication.

Domain_Authentication_Workflow.png

*Authentication Provider is your organization's ADFS server(s).

  1. A user opens or navigates to a Mimecast application, provides their primary email address and domain password, and then submits the authentication request to Mimecast.
  2. Mimecast uses the credentials supplied by the user to construct a request to the ADFS WSTrust endpoint (/adfs/services/trust/13/usernamemixed)
  3. ADFS validates the incoming request.
  4. If the authentication attempt is successful a success response is passed back to Mimecast. If the authentication attempt is not successful a failed response is passed back to Mimecast.
  5. Assuming that the authentication attempt is successful, the user is granted access to the application. If the authentication attempt fails the user is not granted access.

Security Considerations

  • 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 outboundto 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.

Domain Authentication User Experience

Web Applications: Administration Console, Mimecast Personal Portal, Secure Messaging Portal

  • Users navigate to the web application in their browser, enter their primary email address and click Next.
  • They will then choose Use Domain Password from the available dropdown list and enter their Active Directory Password followed by clicking Login.

 

Deployed Applications: Mimecast for Outlook

  • Users open Outlook, navigate to the Mimecast for Outlook Account Options, and choose to Set Credentials in the Domain Authentication section.
  • Mimecast for Outlook automatically detects the user's email address.
  • They will then enter their Active Directory Password and click Login.
  • This only has to be done once per device and then again when the user's Active Directory password changes.

 

Deployed Applications: Mimecast for Mac, Mimecast Mobile

  • Users open the application and are prompted to enter their primary email address.
  • Once entered they click Next and choose Domain from the Authentication Type drop down and enter their Active Directory password followed by clicking Next.
  • This only has to be done once per device and then again when the user's Active Directory password changes.

 

User Principal Name (UPN) Considerations

Mimecast identifies a user by their primary email address, which maps to the "mail" attribute in Active Directory.

 

This can cause a problem for Same Sign-On Domain Authentication as ADFS typically expects the UPN attribute to be provided as the user name input. In the situation where a user's UPN is not the same as their primary email address (mail attribute), authentication will fail because ADFS will not recognize the user.

 

Consequently it is critical that these values match in Active Directory to avoid authentication issues.

ADFS 3.0 AlternateLoginId

 

If your organization uses ADFS 3.0 hosted on Windows Server 2012 R2 you can work around this issue by using the AlternateLoginId feature.

 

This feature allows you to specify the "mail" Active Directory attribute as a recognized user name. For more details on this feature, its associated impact and how to configure it in your environment, please consult Microsoft's documentation.

In the situation where only the domain part of the user's email address is different to the UPN attribute it is possible to use the Alternate Domain Suffix setting in the Mimecast Authentication Profile.

 

When this setting is used Mimecast will substitute the domain part of the email address that the user enters into the Mimecast application with the alternate domain. For example,

 

  • alternate Domain Suffix is set as internal.local,
  • user enters email address of user@external.com into Mimecast the application,
  • Mimecast will use user@internal.local when authenticating the user against your AD FS environment and then grant access to the user@external.com address.

 

Federation Metadata

 

By default ADFS publishes a Federation Metadata URL (e.g. https://host.domain.com//FederationMetadata/2007-06/FederationMetadata.xml). This allows service providers like Mimecast to obtain the required details to create a trust with your ADFS environment. Mimecast uses this URL to initially import the minimum required settings, and to monitor for changes once the authentication profile has been saved.

Security Information: By default this URL is published using HTTPS, consequently the ADFS server will need to have a Mimecast Trusted SSL certificate installed.

Import

 

Mimecast issues a HTTP(S) connection to the URL provided and uses the data in the XML file to import the required settings.

For SAML Authentication, the values imported are,

  • the ADFS token signing certificate metadata,
  • the ADFS Issuer URL
  • the ADFS login URL

 

For Domain Authentication, the values imported are,

  • the ADFS token signing certificate metadata,
  • the ADFS login URL

 

Monitor

 

Once an authentication profile has been saved and the Monitor Metadata URL setting has been enabled, the Federation Metadata URL entered will be monitored for changes. The monitoring is triggered when a user with the relevant authentication profile applied attempts to login to a Mimecast application. This process will only happen once in a 24 hour period, not on every login attempt.

Multiple Token Signing Certificates: As SSL certificates expire it is common practice to have more than one token signing certificate installed on your ADFS server(s). In this situation the following behavior is expected:

  • During an import you should be presented with a page displaying metadata values of each of the certificates found, allowing you to select the one to use. Typically this will be the certificate with the latest expiry date.
  • During monitoring the certificate with latest expiry date and a valid from date before the date that the check is made will be used.

Next Steps

 

Use the links below to learn how to enable ADFS Authentication.

Attachments

    Outcomes