Elevate: Azure SSO Identity

Created by Jonathan Rees, Modified on Tue, 12 Nov, 2024 at 1:48 PM by Jonathan Rees

What is Azure SSO?

Azure Single Sign-On (SSO) feature allows customer's end-users to sign in to most Company applications ( Elevate, Online Meeting, Contact Center, ShareSync, OWA, MyServices ) using their Azure credentials. Lots of companies have Microsoft accounts and many services support the same features which basically lets employees use a single set of credentials to access all their applications enhancing overall security and usability. 


If you wish to setup M365 SSO please reach out to our support team for assistance!

How to activate Azure SSO?

enablement

 

  1. Account Contact with Security Manager role assigned needs to log into CONTROL PANEL and navigate to: Account > Security Policies > Identity Management > Start Azure Integration
  2. You will be prompted to sign in to your Azure account and accept terms and conditions.

    MSlogin

     

Once Azure AD is connected it will allow to:

  • Enable or disable SSO for all users.
  • Create an exception list that will exclude users from using SSO, thus meaning they will have to use Company credentials to sign in.
 

What is changing?

Users with SSO enabled will be redirected to Azure sign-in page on the second step of authentication (step 1 being entering the email address - we check whether this email has SSO enabled or not) where they will sign into their Azure account, upon successful sign-in, they will be signed into the Company app. 

Why is it changing?

  1. Enhanced usability by allowing users to sign in to Azure & Company services with a single set of credentials
  2. Enhanced security by applying Azure's security measures to Company end-users
  3. A step towards user sync from Azure to Control Panel

What products/services will be impacted as a result of the change?

Elevate, Online Meeting, Contact Center, ShareSync, OWA, MyServices  - all these will now be accessible using Azure credentials (if SSO is enabled for that user)

Note: Azure SSO for admin portals is not yet available, it is only available for end-user applications listed above.  Also note, that the service will work for OWA only in case 2FA is enabled for the end-user.

In order to enable SSO navigate to Account > Security Policies > Identity Management > Enable SSO with Azure ID for all users.

enable SSO

 

second screenshot

 

third screenshot

 

FAQ:

Q: We enabled Azure SSO in CONTROL PANEL for the app. Are the local credentials still required on the portal itself?
A: Azure SSO is currently only available for “end users” accessing services. It has no impact on administrators' access to the control panels.
 
Q: Are the local credentials still enabled for the systems that use Azure SSO? In other words, can someone bypass SSO?
A: There are local credentials, but they are essentially disabled/inactive when SSO is enabled for a user.
 
Q: Can users log in with local credentials in case of an outage of Azure and Azure SSO?
A: In this event you could certainly disable SSO or add users to the “SSO exclusion” list – this will revert a user back to using local credentials.
 
Q: If SSO is disabled or some users are added to exclusion list, will they be prompted then to setup password or do we need to send them a new invitation?
A: The users will not automatically be prompted or invited – you would need to reset or re-invite them, or they could perform a “password reset” themselves in the case that the credential is unknown to them.
 
Q: I created a new user in CONTROL PANEL. Do I need to create the same user in Azure?
A: Yes, in order for the SSO to work, the user has to exist both in CONTROL PANEL and your Azure organization.
 
Q: What will be with the local credentials when SSO is re-enabled (e.g., in case of the outage)?
A: The local credentials will remain only not to be used.
 
Q: Is there a plan/ETA to enable SSO for the admin portals?
A: There is no specific ETA, however, longer term it is planned to consolidate user and admin objects (they are current separate), and when it is achieved, all user types will be covered by the same identity system and will have the same capabilities (including SSO).

Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article