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). 

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.

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.

Please note: Enabling Single Sign On is the only Two-Factor Authentication (2FA) we provide. We do not provide Two-Factor Authentication for our Prospect Username and Password log in option.

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 CRM 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 the CRM. 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.

For the best experience, an Administrator should link your 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 CRM data.

This set up is performed here.

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.

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.

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 the selection simply click the 'Save' button.

The final step is to authorise the CRM 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.

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 CRM user accounts need to exactly match the primary email address in Azure. If necessary, you can update a user's email address in User Management.