×

Want to Search?

Go here

Switch Language

English

Contact Us

Get Help Give feedback

I am a Zivver admin

Configure and manage Zivver

Help Center >  Single Sign-On - Troubleshooting login problems with Azure AD

Single Sign-On - Troubleshooting login problems with Azure AD

Introduction

Audience: administrators who want to troubleshoot Single Sign-On (SSO) via Azure Active Directory (AAD). This troubleshooting guide can help if your organization uses AAD as Identity Provider (IdP) to log in to Zivver with SSO.
Read more about Single Sign-On

Prerequisites

  • You are a Zivver administrator.

  • You have access to and knowledge of AAD.

  • You configured SSO with AAD according to the configuration manual.
    Read the AAD SSO configuration manual

  • You have access to the Zivver Synctool.

Generic troubleshooting - check this first

  • Make sure that the user has a Zivver account and that the user status is enabled. Open the accounts page in the Zivver WebApp.

  • Use Google Chrome or Firefox. These browser are the best to see SAML errors. Do not use Internet Explorer.

Problem: password required

When users log in with their AAD credentials, they encounter this notification in Zivver:

Password required
For "name@example.com"
Please enter your password in order to start using Zivver. You will only have to do this once.

This means the Zivver password for this Zivver account is different from the password provided by AAD. Zivver needs the users' Zivver password, so that it can connect the Zivver password with the password provided by AAD. Those are the workplace credentials. Users can log in with their workplace credentials instead of a Zivver password after connecting the two. There are three main causes for the above notification in Zivver to occur.

Cause - The User Principal Name is different from the primary email address

By default, Azure AD returns the User Principal Name (UPN) of a user to Zivver as the Unique User Identifier. However, Zivver may ask the user for a password when the primary email address is not the same as the UPN.

Solution

Configure the Azure AD Enterprise application for SSO in Zivver to use the user.mail instead of user.userprincipalname as the Unique User Identifier.

  1. Go to https://portal.azure.com.

  2. Select Enterprise applications.

  3. Find and click Zivver in the list of Enterprise applications.

  4. Click the Single sign-on blade.

  5. At Step 2 click edit Edit.

  6. Click Unique User Identifier (Name ID).

  7. At Source attribute, select user.mail from the dropdown menu.

  8. Click Save.
    Azure AD returns the primary email address of the user instead of the UPN. The user who needed to enter a password can now log in to Zivver on https://app.zivver.com

Cause - account created before SSO implementation

A user created a Zivver account with a Zivver password Consider this example situations:

  • The user is part of your pilot implementation. But during the pilot phase, Zivver did not work with SSO.

  • You adopted free accounts in the WebApp. Free accounts have Zivver passwords, which the user must connected to the workplace credentials in Zivver at first login after adoption.

  • The user created a freemium account before your organization claimed your domain. Freemium Zivver accounts always log in with a Zivver password.

Solution

If the user knows their Zivver password, the solution is to enter their Zivver password at the notification Password required in Zivver. This is a one-time action.

If the user does not know their Zivver password, you can change the Zivver password in the admin panel. Do these steps to change the Zivver password of this user:

  1. Disable SSO temporarily in the SSO page.
    Clear Enable Single Sign-On with SAML. Then, click Save.
    Users stay logged in to their account you disable SSO. Users who try to log in during the period that SSO is disabled cannot log in again until you enable SSO again.

  2. Go to the Accountspage.

  3. Search for the specific user.

  4. Click Edit edit in the Actions column for that user.
    The Edit account page opens.

  5. Click CHANGE PASSWORD in the Password tab.

  6. Enter the user’s new password.

  7. Leave User should choose another password after the next login clear.

  8. Click OK.

  9. Enable SSO in the SSO page. Select Enable Single Sign-On with SAML and click Save.
    The user can enter the password that you created when Zivver says Password required at login.

Cause - mismatch between passwords in AAD and AD on-premise

The password that the user used to create the Zivver account does not agree with the password that AAD provided. The password (read: ZivverAccountKey) that that the user used to create accounts, must be identical to the ZivverAccountKey from the AAD SAML response. In other words, you must create an account with the same ZivverAccountKey that a user uses to log in.

Solution

First, make sure that Synctool uses the same attribute for the ZivverAccountKey for creating user accounts and AAD for login to Zivver. For example: if you create accounts with the Synctool with AADs' user.objectID as ZivverAccountKey, AAD must provide user.objectID too in the SAML response.

You can find the ZivverAccountKey in the Synctool at step 3: Set up local user/group settings. You can find the ZivverAccountKey in AAD via portal.azure.com > Enterprise applications > Zivver - Single sign-on > SAML-based sign-on.

Note
 This solution is valid when you run a hybrid environment with Active Directory on-premise and AAD.

When you run a hybrid environment with Active Directory on-premise and AAD, you can use Active Directory attributes to create users with the Synctool. Often the Active Directory attribute objectGUID serves as ZivverAccountKey to create accounts. But not all the attributes are synced to AAD by default. An example is the objectGUID. Thus, if you want to use objectGUID as ZivverAccountKey to create accounts, AAD must be able to insert objectGUID in the SAML response.

The solution to this problem is to synchronize objectGUID (or any other Active Directory attribute used as ZivverAccountKey to create accounts) to AAD with the Azure AD Connect Tool and the Synchronization Rules Editor.
Please contact support

Cause - account created before Zivver was configured to work with SSO

The user existed with the Synctool before Zivver was configured to work with SSO. If you chose Users log in via SSO at step 2 in the Synctool and create accounts, SSO must always be enabled before you do so. Otherwise, the new accounts have a temporary password. But when your organization uses SSO, the created account cannot use a temporary password. The reason is that the identity provider manages passwords, not in Zivver.

Solution

Configure Zivver to work with SSO. Then, update the ZivverAccountKey for the affected users. Do these steps in the Synctool to update the ZivverAccountKey for the users that the Synctool created before you configured Zivver to work with SSO.

Note
 Make sure SSO is enabled in Zivver before you continu with these steps.

  1. Open the Synctool.

  2. Select the profile which created the accounts before SSO enablement at the first tab Step 1: Select sync profile.

  3. Select the fourth tab: Step 4: Synchronize users/groups.
    The prompt appears to *Get changes?*

  4. Click Yes.

  5. Check Update the password/account key for all [amount] users in local data under Special functions (do not run automatically).

  6. Hit Run synchronisations.
    You are prompted to Confirm actions.

  7. Click Yes.

  8. Click No.

  9. Click OK.

  10. Clear Update the password/account key for all [amount] users in local data under Special functions (do not run automatically).

  11. Close the Synctool.

The ZivverAccountKey is now updated and users who got the Password required prompt should be able to log in.

Cause - account created with temporary password

If you have chosen Users need to log into Zivver with a password at step 2 of the Synctool, accounts are created with a temporary password. However, when your organization uses SSO, the created account cannot use a temporary password, since passwords are managed by the Identity Provider, not in Zivver.

Solution

After selecting Users log in via SSO at step 2 in the Synctool, overwrite the ZivverAccountKey for the affected users:

  1. Open the Synctool.

  2. Select the profile which created the accounts with a temporary password.

  3. Select the second tab: Step 2: Set up Zivver settings.

  4. Select Users log in via SSO.

  5. Select the fourth tab: Step 4: Synchronize users/groups.
    You are prompted to *Get changes?*

  6. Click Yes.

  7. Check Update the password/account key for all [amount] users in local data under Special functions (do not run automatically).

  8. Hit Run synchronisations.
    You are prompted to Confirm actions.

  9. Click Yes.

  10. Click No.

  11. Click OK.

  12. Clear Update the password/account key for all [amount] users in local data under Special functions (do not run automatically).

  13. Close the Synctool.

The ZivverAccountKey is now updated. Users who got the "Password required" prompt can log in now.

AADSTS error codes

AAD has a large array of error codes that can be returned from the Security Token Service (STS). An Azure AD STS error code always has this format: AADSTS50105. The first part AADSTS stands for Azure Active Directory Security Token Service, the latter part (50105) is the actual error code.

For an example, refer to AADSTS50105 at login with Azure AD.

For a list of AADSTS error codes, refer to Microsofts' AADSTS error codes document. The document contains description, fixes, and workarounds.

Still need help?

Did you find the information that solves your problem? If not, speak to Zivver support. Give this information:

  • What error do you get in your browser when logging in to https://app.zivver.com?

    • Password required

    • An AADSTS error

    • Something else, namely …​

  • Which email addresses are affected?

  • Does SSO work for applications other than Zivver?

  • Does SSO work on a different machine? For example:

    • Local or virtual

    • Different Virtual Desktop Infrastructure (VDI) sessions

  • Are you using AAD in conjunction with AD on-premise?

You can attach this information to a support request.
Contact support

Updated on 2024-03-13

Was this article helpful?

thumb_up thumb_down