Single Sign-On - Troubleshooting login problems with Azure AD

Introduction

This article is meant for 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 have set up 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

  • Check in ZIVVER if the user has a ZIVVER account and check if the user status is enabled.
  • The best way to troubleshoot AAD SSO problems is in a browser. Google Chrome or Firefox display SAML errors the best. Internet Explorer 11 is not recommended for troubleshooting.

Problem: Password required

When users log in with their AAD credentials, they encounter the following 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 password provided by AAD (i.e. the workplace credentials). Users can log in with workplace credentials instead of a ZIVVER password after connecting the two. There are two main causes for the above notification in ZIVVER to occur.

Cause - account created before SSO was used

A ZIVVER account can be created with a ZIVVER password in the following example situations:

  • The user is part of your pilot implementation and during the pilot phase, ZIVVER was not configured to work with SSO.
  • You adopted free accounts in the WebApp. Free accounts have ZIVVER passwords, which need to be 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 his ZIVVER password, the solution is to enter their ZIVVER password at the notification Password required in ZIVVER. This will be a one time action only.

If the user does not know his ZIVVER password, you can change the ZIVVER password in the admin panel. Follow these steps to change the ZIVVER password of this user:

  1. Disable SSO temporarily in the SSO page by unchecking Enable Single Sign-On with SAML and hitting SAVE afterwards.
    Users will remain logged in to their account when disabling SSO. Users that try to log in during the period that SSO is disabled will not be able to log in again until you have enabled 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 unchecked.
  8. Click OK.
  9. Enable SSO in the SSO page by checking Enable Single Sign-On with SAML and hit SAVE.
    The user can enter the password you have just created when ZIVVER says Password required at login.

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

The password used to create the ZIVVER account does not match with the password provided by AAD. The password (read: ZivverAccountKey) that is used to create accounts, should be identical to the ZivverAccountKey that is provided in the SAML response by AAD. In other words, you should create an account with the same ZivverAccountKey which a user logs in.

Solution

First check if the same attribute for the ZivverAccountKey is used in the SyncTool for creating user accounts and AAD for login to ZIVVER. For example: if you create accounts using the SyncTool with AADs’ user.objectID as ZivverAccountKey, then AAD should provide user.objectID as well 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.

The following 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 is used as ZivverAccountKey to create accounts. However, not all attributes are synced to AAD by default. For example objectGUID is not synced to AAD by default. Therefore, if you want to use objectGUID as ZivverAccountKey to create accounts, then 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 was created with the SyncTool before ZIVVER was configured to work with SSO. If you have chosen Users log in via SSO at step 2 in the SyncTool and create accounts, SSO should have always be enabled before you do so. Otherwise accounts will be 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

You should update the ZivverAccountKey for the affected users, after you have configured ZIVVER to work with SSO. Follow these steps in the SyncTool to update the ZivverAccountKey for the users that were created from the SyncTool before you have configured ZIVVER to work with SSO.

Make sure SSO is enabled in ZIVVER before continuing with the following steps.
  1. Open the SyncTool.
  2. Select the profile which created the accounts before SSO was enabled at the first tab Step 1: Select sync profile.
  3. Select the fourth tab: Step 4: Synchronise users/groups.
    You are prompted 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. Uncheck 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: Synchronise 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. Uncheck 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 and users who got the “Password required” prompt should be able to log in.

AADSTS error codes

AAD has a large array of error codes that can be returned from the Security Token Service (STS). Microsoft has dedicated a document listing all the AADSTS codes with their description, fixes, and suggested workarounds. An Azure AD STS error code always has the following format: AADSTS12345. The first part AADSTS standing for Azure Active Directory Security Token Service, the latter part being the actual error code.

Please checkout Microsofts’ AADSTS error codes document if a user gets aan AADSTS error code returned while logging in.

Still need help?

Could not find the information that solves your problem? Please contact support with the following 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 VDI sessions
  • Are you using AAD in conjunction with AD on-premise?

Please attach this information to a support request.
Contact support

Was this article helpful?

thumb_up thumb_down