Authentication Profiles - AD FS Authentication

Updated

This article outlines the configuration process for Active Directory Federation Services (AD FS) Authentication for Mimecast, including supported authentication methods, SAML workflows, domain authentication, user experience, UPN considerations, and managing federation metadata for secure access.

Active Directory Federation Services (AD FS) 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 AD FS Authentication

Using AD FS as an authentication provider for Mimecast applications has a number of benefits, including:

  • Web Single Sign-On for the Mimecast Personal Portal and Mimecast Administration Console.
  • Same Sign-On support for web, desktop, and Mobile applications.
  • Allows End Users to access Mimecast applications using their familiar email address and Active Directory password, accelerating user adoption and reducing administration overhead.
  • There are no additional licensing costs for customers already using Microsoft infrastructure.

Supported AD FS Versions

Version Host Operating System
4.0 Windows Server 2016
3.0 Windows Server 2012 R2
2.1 Windows Server 2012
2.0 Windows Server 2008 R2

Supported Authentication Methods

When using AD FS as an authentication provider, the following options are available:

  • SAML Single Sign-On (SSO):
    • Supported for:
      • Mimecast Personal Portal.
      • Administration Console.
      • Mimecast for Outlook.
      • Mimecast Mobile.
      • Mimecast for Mac.
    • 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 AD FS 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 Mimecast 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:

  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 is complete and the user is granted access to the Mimecast application.

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

Supported Applications:

  • Mimecast Personal Portal.
  • Administration Console.

  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 catalog 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 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 is complete and the user is granted access to the Mimecast Application.

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

Same Sign-On Domain Authentication

Supported Applications:

All Mimecast applications can use Domain Authentication, except SMTP authentication

*Authentication Provider is your organization's AD FS 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 AD FS WSTrust endpoint (/adfs/services/trust/13/usernamemixed).
  3. AD FS 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.2 for inbound connections to public API's.
  • When connecting outbound to customer servers, Mimecast offers TLS 1.2 during the SSL handshake.

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 drop-down 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./li>

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 AD FS 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 AD FS will not recognize the user. Consequently, it's critical that these values match in Active Directory to avoid authentication issues.

AD FS 3.0 AlternateLoginId

If your organization uses AD FS 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.
  • The user enters the email address of  user@external.com into the Mimecast 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, AD FS 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 AD FS environment. Mimecast uses this URL to initially import the minimum required settings and to monitor for changes once the authentication profile has been saved.

By default, this URL is published using HTTPS; consequently, the AD FS server will need to have a Mimecast Trusted SSL certificate installed.

Import

Mimecast issues an 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:

  • AD FS token signing certificate metadata.
  • AD FS Issuer URL.
  • AD FS login URL.

For Domain Authentication, the values imported are:

  • AD FS token signing certificate metadata.
  • AD FS 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 attempts to log in 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 AD FS server(s). In this situation, the following behavior is expected:

  • During an import, you should be presented with a page displaying the 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 expiration date.
  • During monitoring, the certificate with the latest expiration date and a valid date before the date that the check is made will be used.

See Also...

Use these pages to learn how to enable AD FS Authentication:

Related to

Was this article helpful?
0 out of 0 found this helpful

Comments

0 comments

Please sign in to leave a comment.