Enabling User Single Sign-On (SSO) using AD FS

Administrator -

This article explains how to integrate your Enterprise Account with Active Directory Federation Services (AD FS) in order to enable user single sign-on (SSO).

Note: This article is intended for Enterprise Account Administrators.


Administrators can enable Single Sign-On (SSO) for their users, using AD FS – with the WS-Federation protocol (SAML protocol is not supported).
Note: Supported versions: AD FS 2.1 and higher / Windows Server 2012 and higher.

With this functionality enabled, all users of the Enterprise Account will be able to log in to their XMedius Cloud account (including all subscribed services) using their Active Directory user credentials.

This article:
  • describes all configurations to perform (SSO Configuration) on your AD Server as well as on your Enterprise Account in order to enable the SSO functionality, and
  • provides specific information for creating user accounts (User Accounts in SSO Context), which is still necessary when the SSO functionality is enabled.

SSO Configuration

To enable SSO, it is required to perform configurations on your AD Server as well as on your Enterprise Account (for which you need to provide some values retrieved from your AD FS).

AD Server Configuration

Setup AD FS role, Relying Party Trust and Claim Rules on your AD Server:

  1. Setup the AD FS role on your AD Server, according to Microsoft’s instructions.
    1. Install the AD FS role.
    2. Setup firewalling/NATing, DNS, public certificates according to your corporate environment/policies.
  2. Configure a Relying Party Trust using the AD FS Management console:

    Go to Trust Relationships and add a Relying Party Trust with the following minimum required properties (follow the wizard):

    Select Data Source Select Enter data about the relying party manually
    Choose Profile Select AD FS Profile
    Configure URL Select Enable support for the WS-Federation Passive Protocol
    Provide the Relying party WS-Federation Passive protocol URL: https://login.[domain]
    Note: Use the [domain] that corresponds to the region of your enterprise account (i.e. xmedius.com for USA, xmedius.ca for Canada or xmedius.eu for Europe).
    Choose Issuance Authorization Rules Select Permit all users to access this relying party
    Tip: Before finishing, select Open the Edit Claim Rules dialog... to directly step on the next required configuration.
  3. Add a Claim Rule to the Relying Trust Party you just created:

    In Edit Claim Rules, Issuance Transform Rules tab, add a rule with the following minimum required properties (follow the wizard):

    Choose Rule Type Select Send LDAP Attributes as Claims
    Configure Claim Rule Select Active Directory as Attribute Store
    Set Mapping of LDAP attributes to outgoing claim types: User-Principal-Name to E-Mail Address

AD FS Values Required for Further Configuration

You need to get some values from your AD FS in order to use them while configuring your XMedius Enterprise Account for SSO.

  1. Get the Thumbprint of your Token-Signing certificate:
    1. Go to AD FS > Service > Certificates.
    2. Locate the Token-signing certificate and open it.
    3. Go to Details and get the value of Thumbprint.
  2. Get the Federation Service Identifier:
    1. Go to AD FS > Service and Edit Federation Service Properties.
    2. Get the value of Federation Service Identifier.

Enterprise Account Configuration

Enable the SSO functionality in your Enterprise Account:

  1. Login to your XMedius Cloud account using a Web browser.
  2. Edit your Enterprise Settings
    1. From the main menu of your Web Portal, select enterprise_account > Enterprise Settings.
    2. Go to Single Sign-On section and select WS-Fed / WS-Trust.
    3. Provide the following required information:
      Web Endpoint (URL) The URL to your AD FS login server. This URL will most likely end with /adfs/ls.
      Federation Service Identifier This is the Federation Service Identifier you previously retrieved.
      Token-Signing Certificate Fingerprint This is the Thumbprint you previously retrieved.
    Important: Keep the fail-safe URL (https://login.[domain]/[account]/no-sso) provided at the bottom of the SSO configuration section, it will allow you to log in using your XMedius Cloud account credentials if you lock yourself after SSO activation.

User Accounts in SSO Context

Even with SSO functionality enabled, it is always required to create user accounts within the Enterprise Account. SSO will apply to all user accounts created either before or after enabling the functionality.

You must also be aware of some behaviors and requirements related to SSO activation (Password / Email Address Required to Log in / Two-Factor Authentication).

Creating User Accounts

A tool (AD Sync) can be used to ease the user account creation process by synchronization with your Active Directory (see Synchronizing Users from Active Directory).

Otherwise, the XMedius Cloud Platform always allow administrators to create user accounts, either manually or by sending invitations (see Managing Users).


In SSO context, users won't need a password dedicated to their XMedius Cloud account (even if such a password can technically be defined) because they will use the password of their corporate (AD) account. As such:
  • Administrators have the option to manually create user accounts with no password.
  • The form to create an account following a User Invitation does not ask users to set a password.
Note: If you are using the AD Sync tool, it is recommended to set the option disable_emails, which disables the automatic sending of password setup emails to newly created users.

Email Address Required to Log in

In SSO mode, the key element of a user account is its email address. As such, to login using client applications (e.g. SendFAX, XM SendSecure for Outlook...) as well as to access the Web Portal, the users will have to authenticate using their email address (and not the username defined in their XMedius Cloud account).

Two-Factor Authentication

In SSO context, XMedius Cloud user accounts cannot be configured for Two-Factor Authentication (2FA). However, your AD FS technically allows to enable 2FA on its side.

Have more questions? Submit a request


Powered by Zendesk