Single Sign On (SSO) with Azure AD (AAD)

Simplify the log in flow for your users, whilst increasing security and control by implementing Single Sign On (SSO) with Azure AD (AAD). All you need is an Azure AD subscription...which sounds a bit complicated...but you've probably already got one as it comes bundled in with Office 365 (or can be set up separately). 

Prerequisites

  • A Prospect Account

    • If your organisation has a Prospect subscription but you don't have a login, contact your Administrator

    • If your organisation hasn't signed up yet, then sign up for free here

  • An Azure AD Account

    • If you use Office 365 then you already have an Azure AD Account

    • If you don't use Office 365, you can create an Azure AD Tenant by visiting this link

To start using integrated logins on a personal level, you don't need any more than an account on each, but to set up full integration for all your users, you'll also need to be an Administrator for both products.

What is Single Sign On (SSO)?

Single Sign On (SSO) allows you to log in to multiple applications. Essentially, in the case of Azure AD SSO, we trust Microsoft to validate your identity on our behalf. Through strong encryption and tight security standards, we can be sure that Microsoft logged you in, and on that basis we log you into our application without asking for another password.

The benefits are of course less clicks and less typing of passwords, but with less passwords to manage, users are more likely to use stronger passwords and change them more regularly. And, as an IT administrator, you have greater control in being able to centrally block users from applications, centrally enforce security standards and best practice (e.g. password length or even two-factor authentication), etc. For more information please visit this page.

Personal Single Sign On

Without setting up any integration or using administrative privilege, any user can start using SSO. Just so long as your Prospect user ID, i.e. your email address, matches the primary email address in Office 365, then you can use your Office 365 credentials to log into Prospect.

Simply visit the Prospect log in page here and click 'Sign in using Office 365', where you'll be redirected to the Microsoft log in. If you're already logged into Office 365, you'll be bounced straight back to Prospect. If your login details match, then you'll be logged in automatically. If not, it'll tell you the email address supplied by Microsoft and you'll need your Administrator to update your user record in Prospect to match before being able to use Single Sign On.

Setting up Account-Wide Single Sign On

For the best experience, an Administrator should link your Prospect subscription to your Office 365/Azure tenant. This requires Administrator privilege on both solutions, but ultimately allows you to enforce SSO for a whole domain and ensure that all users must use SSO to access your Prospect data.

This set up is performed here.

Step 1: Register your Domain

A user with CRM Admin rights will first need to register the domain you'd like to use via this link. Type in the domain you wish to register and click the '+ Add Domain' button.

Step 2: Verifying Domain

A pop-up will appear providing you with instructions on how to verify your domain with the necessary changes for your DNS record.

You'll most likely need to contact your domain provider to get this added. If you need to send these instructions to a colleague, use the 'Email instructions to' option by typing in the recipient's email address and clicking the 'Send' button.

Once you've followed the instructions provided and completed the changes to your DNS Record, you'll be able to click the 'Verify' button, or you can select the 'Verify Later' option if you need to do this at a later date.

Step 3: Configure Single Sign On

Now that you've verified your domain, you'll be able to configure SSO. To start this process, click the 'Configure SSO' button for the required domain.

Select 'Office 365/Azure AD 'as the Sign-in Provider from the drop-down. You can also enforce users to use SSO rather than their CRM username and password by ticking the box on this window (recommended). Without this, users will still be able to log in either with SSO, or with their email and passwords. This reduces security and centralised control as you cannot use your Azure settings to control password strength, disable users etc. Only uncheck this option if you want users to be able to have different means of logging in.

Once happy with selection simply click the 'Save' button.

Step 4: Authorise Prospect CRM with Azure

The final step is to authorise Prospect to access the information provided by Azure.

Having completed this final step, you're all almost ready to go.

Don't forget - you can go back to the beginning and add more domains if some of your users log in with different domains.

Step 5: Matching User IDs

Finally, SSO relies upon being able to match an Azure identity to a ProspectSoft identity. In order for this to work, the email addresses in the Prospect user accounts need to exactly match the primary email address in Azure. If necessary, you can update a user's email addresses in the Admin Portal here.

Did this answer your question?