Single Sign-On - Troubleshooting login problems with ADFS

Introduction

ZIVVER offers the option to set up Single Sign-On (SSO) with ADFS, which allows users to conveniently log in with their AD credentials. Are you experiencing a problem with the SSO configuration between ADFS and ZIVVER? This article will help you to troubleshoot such issues.

Prerequisites

For this guide, you will need the following: - A ZIVVER account with administrator rights. - Your account is a member of the ZIVVER organization for which your are troubleshooting SSO. - Administrator access to the ADFS server.

Quick fix

Of course, you will want to resolve the issue as quickly as possible. A quick way to fix many SSO-related problems, is to remove the configuration altogether from both ADFS and ZIVVER, and then setting it up from scratch. This will take approximately 15 minutes.

Warning
Only use this quick fix when SSO is not working for any of your users. Don’t remove the existing configuration when SSO is not working for one user, or a small selection of them. Keep in mind that none of the users can log in with SSO when you remove the configuration.

Resetting the SSO configuration

  1. Make sure Use Single Sign-On is checked under Single sign-on with SAML on the ZIVVER SSO Settings page.

  2. Remove all information from ZIVVER by clicking the Clear button at the bottom of the ZIVVER SSO Settings page.

  3. Remove the Relying Party Trust from ADFS by selecting it and then choosing the option Delete.

  4. Set up the SSO configuration again by following the ZIVVER installation manual.

  5. Test if the problem is resolved by logging in to ZIVVER.

Check the logs

Alternatively, or if the quick fix did not work, check the ADFS log in Event Viewer for any errors surrounding the problem. This log holds more information than a web browser typically shows, and might contain useful indications on how to solve the issue.

  1. Open Event Viewer (Run eventvwr.msc) on the ADFS server.

  2. Go to Applications and Services Logs.

  3. Go ADFS > Admin.

  4. Search the log for any errors that occurred on the corresponding time and date.

Does the error in Event Viewer provide a clear indication for the cause of the problem? For example, it might tell you that the user simply entered the wrong password.

Check the error in Chrome

Alternatively, you can try to log in via SSO using the Chrome browser.
Chrome is preferred in this case, because it shows more detailed error information than Internet Explorer for example.

If you or your users are experiencing errors while trying to log in, then the specific error information should help you to find the cause and troubleshoot the issue.

To retrieve the error, follow these steps:

  1. Go to app.zivver.com in Chrome and enter your, of the affected user’s, email address.
    A pop-up should appear.

  2. Choose Workplace to log in using SSO if you log in with an administrator account.
    The ADFS login page should appear.

  3. Log in to ADFS with your workplace credentials.
    An error message should appear now.
    The ZIVVER web app should appear, and you should be logged in with your ZIVVER account.

If the error in Chrome does not provide a direct indication to the cause of the problem, then search for this exact error online or in this troubleshooting guide - you may find a quick solution to your problem.

Does the problem persist after following the steps above? If so, please follow the rest of the guide to troubleshoot the issue.

Read more about these errors and the corresponding fixes.

Troubleshooting

This section of the guide will help you to troubleshoot any issues with SSO.

Troubleshooting steps

Note
If you have a specific description for your problem already, then use the search function of your browser to quickly find the information that is relevant for you.
For example: "A white screen appears while trying to log in to the mobile app using SSO", or "ZIVVER asks for my password after logging in to ADFS".

Please follow the steps below to pinpoint your problem:

  1. Check the error in Chrome to attempt to log in via SSO. This will help you determine where the problem occurs exactly, or may show a specific error message.

  2. Choose the description that is most similar to your problem:

    • SSO doesn’t seem active; it’s not redirecting from ZIVVER to ADFS.
      Nothing happens after entering the email address in the web app

    • SSO redirects from ZIVVER to ADFS (or tries to), but still can’t log in. ZIVVER tries to log you in after you enter the email address, but the problem occurs after that. Continue with step 3 below.

  3. Choose the option that matches your problem the best:

    • The ADFS login page does not appear.
      Nothing seems to happen when ZIVVER tries to redirect you. See this section of the guide for relevant fixes.

    • The ADFS login page appears, but login doesn’t work. For example, your credentials are not accepted while logging in to ADFS. See this section of the guide for relevant fixes.

    • Log in to ADFS works, but the problem occurs after that.
      You have logged in to ADFS, but you are not sent back to ZIVVER, because of an error or a white screen for example. Continue with step 4.

  4. Choose the description that is most similar to your problem:

Nothing happens after entering my email address

You’ve landed here because nothing happens after you enter your email address on app.zivver.com. Please answer the following question to further pinpoint the problem: Does the problem exist for all users, or only for 1 or some specific users?

  • The problem happens only for some specific user(s). Go here.

  • The problem exists for all users. Go here.

SSO is not active for specific users

This section lists possible causes for the problem where SSO does not seem to be active for specific user(s), meaning users are not directed to ADFS after entering their email address on app.zivver.com.

The user is not a member of the ZIVVER organization

If the email address you’ve entered is not a member of the ZIVVER organization, then SSO will not work for this specific account.

Fix: Check the accounts page if the email address is a member of the organization, and if that is not the case, create an account for them or invite them if they already have an account.

Note
If SSO is currently active for the organization, you will not be able to invite an existing account. First turn off SSO, then invite the account and wait for them to accept the invitation. Then turn SSO back on.

The email address does not match a claimed domain

ZIVVER can only log you in via SSO when the domain in the email address is recognized as one of the organization’s claimed domains. Perhaps a typo was made in the email address, or the user has an email address with a different domain than most other users.

Fix: Enter the email address again and avoid any typo’s, or claim the additional domain in the Domains pane of the organization settings on app.zivver.com.

SSO is not active for any users

This section lists possible causes for the problem where SSO seems to be inactive for all users of your organization.

The domain is not claimed in ZIVVER

The domain of the users that are logging in via SSO is not claimed within the organization in ZIVVER.

Fix: Follow these steps from the admin manual to claim the domain for the organization.

SSO is not enabled

After configuring the SSO connection in both ZIVVER and ADFS, it needs to be enabled within ZIVVER for it to work.

Fix: Enable SSO by checking the box next to Use Single Sign-On in the ZIVVER SSO settings page.

The metadata is incorrect

The ADFS metadata contains necessary information to make SSO work. Please check the following three subsections for solutions.

The ADFS metadata URL is incorrect

If the ADFS metadata URL is incorrect, then ZIVVER will not be able to retrieve the data necessary for SSO. This may happen when the FQDN of the ADFS server changes.

Fix: Follow these steps from the ADFS manual to update the metadata URL.

The ADFS server is blocked to external traffic

If the ADFS server is inaccessible from outside of the company network, then ZIVVER will not be able to access the metadata via the specified URL.

Fix: Allow the ADFS server to be reached from anywhere on the internet, or paste the static metadata XML into the ZIVVER SSO settings by following these steps in the AFDS manual.

The ADFS metadata XML is out of date

Only applies if you use the static metadata XML, instead of the metadata URL. In this case, the option Manually paste your organization’s Identity Provider (IdP) SAML metadata XML file contents. under Single sign-on with SAML is checked in the Single Sign-On pane of the organization settings on app.zivver.com.

The ADFS metadata may have become invalid. The metadata will change when there are changes made to the ZIVVER relying party trust’s settings in ADFS, or the settings of ADFS in general, such as the authentication method for example. It will also change when the certificate is renewed. This may have happened automatically on the ADFS server.

Fix: Paste the static metadata XML into the ZIVVER SSO settings by following these steps in the AFDS manual.

The ADFS login page does not appear

Are you not forwarded properly to ADFS from ZIVVER?
In this case, ZIVVER did not properly send you to the ADFS login page after you entered your email address in the web app.

Please check the following causes and fixes.

The Relying Party Trust is disabled in ADFS

In other words, the SSO connection is configured, but not enabled within ADFS management.

Fix: Open ADFS Management app and set the status of the ZIVVER relying party trust to Enabled.

ADFS metadata issues

The ADFS metadata contains information that is necessary for SSO to work. See this section for the causes and solutions.

The ADFS server can not be reached

Note
Only applies if the problem exists when users are trying to log in from outside the company network. If the ADFS server is blocked off to external network traffic, users will not be able to log in from outside the company network.

Fix: Allow users to connect to the ADFS server from external network locations.

No valid certificate on the AFDS server

If the ADFS server does not have an active/valid SSL certificate, an error will appear in the browser instead when users are directed to the ADFS log in page.

The exact error may differ, but will, for example, say the following: "There is a problem with the website’s security certificate.", or "Access is denied.", or simply "An error occurred".

Fix: Make sure there is a valid certificate on the ADFS server, for example by renewing an existing one. See this article for more information.

Warning
If you use the static metadata XML: After replacing or renewing the certificate, the metadata will change accordingly. Please see this section of the guide on updating the metadata and follow the instructions there.

Page can’t be found

Internet explorer 11 displays an error that says "The page can’t be found." when trying to connect to ADFS. This might happen because of the security settings of IE11.

Fix: Add https://[wildcard].zivver.com as a trusted website in Internet Options.

White screen in mobile app

SSO works as expected when logging in from app.zivver.com, but not from the ZIVVER mobile app. When you enter your email address in the mobile app, a white screen or an error appears and you are not forwarded to the ADFS login page. This happens because Windows Integrated Authentication is enabled, but the Windows pop-up can’t be displayed properly on mobile devices.

Cause: The problem is caused by the fact that Global Primary Authentication method for ADFS is set to Windows Authentication and not Forms-based Authentication. Forms Authentication cannot be used as a secondary authentication method, when Windows Authentication is set as the primary authentication method. This is due to a known issue with ADFS. You can verify this by logging in to app.zivver.com, as described in subchapter Check the error in Chrome, and checking if you get a web-based form to log in to, or a Windows pop-up.

Fix: The work-around for this is to enable Windows Authentication for Intranet access to ZIVVER, and Forms Authentication for Extranet access. This will allow users to log in to the mobile app using SSO from outside of the company network.

The information below only applies if an IIS server is used in combination with ADFS. If you use an IIS server, read the information below.

Redirect users to a login form (forms-based authentication), instead of a Windows pop-up. For this, you need to change the web.config file, which can be found under c:\inetpub\adfs\ls on the ADFS server.

Find the localAuthenticationTypes element, and make sure that Forms is the first entry.

I can not log in to ADFS

This section describes the several causes and solutions for the problem where you can not log in to ADFS.
Describe the scope of the problem you are experiencing:

Specific users can not log in to ADFS

If some of your users can not log in to ADFS, please check the following causes and solutions:

Check the logs

If only specific user(s) can not log in to ADFS, the cause may simply be that they entered the wrong password for example.

Fix: Check the logs for errors such as failed login attempts due to invalid credentials.

The account is disabled in AD

Accounts that are locked out or disabled in Active Directory can’t log in via ADFS.

Fix: Enable the user account in AD to log in via ADFS.

Duplicate UPN present in AD

If multiple objects (users) exist in AD with the same User Principal Name (UPN), both of them will not be able to log in to ADFS.

Fix: Search the AD for the UPN of the user that is experiencing the problem to see if any duplicates exist, and remove or change them.

No users can log in to ADFS

If none of your users can log in to ADFS, please check the following cause and related fixes: === Users are not able to log into ADFS using their email address In most cases, the UPN is used to log in, but this may not always be the same as the email address - for example @zivver.com vs @zivver.local.

Fix: Change the logon name manually on the ADFS login page to log in.

User friendly fix: To make the login process easier for users, apply one of the options below:

  • Modify the ADFS onload.js, so that the username field is empty by default. To do this, add the following line: document.forms['loginForm'].UserName.value = ' '

  • Modify the ADFS onload.js, so that the username is automatically entered in the appropriate field. Do this by adding the following line: document.forms['loginForm'].UserName.value = 'yourdomain.local\yourusername'

  • Allow users to log in with their email address, instead of the SamAccountName. Implement this by executing the following PowerShell command: Set-AdfsClaimsProviderTrust -TargetIdentifier “AD AUTHORITY” -AlternateLoginID mail -LookupForests [forest domain]

ZIVVER does not appear after logging in to ADFS

You can log into ADFS with your workplace credentials, but you are not redirected to ZIVVER properly. For example, an error appears.

Many fixes in this section of the guide are for specific errors that may appear when trying to log in via SSO in the browser. See subchapter Check the error in Chrome for instructions on how to determine the error.

Below are the causes for this problem, as well as the related fixes.

ADFS metadata problem

The ADFS metadata contains information that is necessary for SSO to work. See this section for the causes and solutions.

An error appears

Are you experiencing an error after logging in to ADFS? The following errors and related fixes are currently known. If the error you’ve encountered is not listed here, or if the corresponding solution is not working, then please notify ZIVVER support.

Error: \{"error": "SAML Response is not valid before: …​}

This error appears in the Chrome browser, while Internet Explorer 11 will show an Error 400. This error occurs when the timestamp in the SAML response is different between ADFS and ZIVVER. Even a minor difference in milliseconds may cause this issue.

Fix: This can be fixed by synchronizing the clocks across the Domain Controllers, so that the timestamp in the SAML response will match UTC again.

Note
After synchronizing, the time may not be corrected instantly. If there is a delay of 6 seconds for example, this difference will be fixed within the next hour.

If the problem persists after synchronizing the clocks on the DC’s, there are several possible causes and fixes:

Clock on ADFS server is not synced

The clock on the ADFS server hasn’t synchronized yet with the DC.

Fix: Synchronize the clock manually. See this page for more information, as well as this article from Microsoft.

Delay because of server configuration

A system time mismatch between the ADFS server and the DC may exist, because the ADFS server is a virtual machine, or because there is a multi-tenant configuration. If the virtual machine checks the host or the master for the correct time, this may cause a small delay between the ADFS and DC systems.

Fix: Synchronize the virtual machine or the slave with time.windows.com directly, instead of using the host or master clock. See this page for more information, as well as this article from Microsoft.

Additional solutions

If the error ({"error": "SAML Response is not valid before: …​}) still appears after trying the solutions above, try the following fixes:

  1. Fix: Try synchronizing with other NTP (Network Time Protocol) servers, such as ntppool.org or Amazon.

  2. Fix: Increase value of -NotBeforeSkew using the Set-AdfsRelyingPartyTrust command in Powershell. This increases the validity period of the SAML response. The exact command would be: Set-ADFSRelyingPartyTrust -TargetRelyingParty "" -NotBeforeSkew 5, to increase the skew to 5 minutes for example. The relying party name is generally "ZIVVER", or "app.zivver.com".
    See this article for more information.

Error: \{"error": "SAML response was not properly signed. Make sure to sign at least the SAML response or the assertion(s)."}

This error appears in the Chrome browser, while Internet Explorer 11 will show an Error 400. This issue occurs because there are discrepancies between the certificates used by the Identity Provider (IdP) and the Service Provider (SP) in the SAML response.

Fix: Fix this by retrieving the new Federation Metadata from the ADFS server, and entering this in the ZIVVER SSO settings by overwriting the existing metadata. Please see these steps in the AFDS manual for further instructions.

Error: \{"warn": "Response wasn’t properly signed (resp:false, unenc:true, end:false) for …​"}

This error appears in the Chrome browser, while Internet Explorer 11 will show an Error 400. This issue occurs because there are discrepancies between the certificates used by the Identity Provider (IdP) and the Service Provider (SP) in the SAML response.

Fix: Fix this by retrieving the new Federation Metadata from the ADFS server, and entering this in the ZIVVER SSO settings by overwriting the existing metadata. Please see these steps in the AFDS manual for further instructions.

Error: urn:oasis:names:tc:SAML:2.0:status:Requester

Complete error is as follows

{“error”: “The IdP sent us the status code 'urn:oasis:names:tc:SAML:2.0:status:Requester'. The optional second-level status code was: 'urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy'. Consult paragraph 3.2.2.2 of the SAML spec for more info: https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

While ADFS log will show the following error:

MSIS7070: The SAML request contained a NameIDPolicy that was not satisfied by the issued token. Requested NameIDPolicy: AllowCreate: False Format: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress SPNameQualifier: . Actual NameID properaties: null.

This error can have one of several different causes:

Account has no email address in AD

The problem occurs because the account you are trying to log in with has no email address in Active Directory.

Fix: Fix this by adding the email address to the affected user in Active Directory. Alternatively, log in with a ZIVVER account for which there is an email address added to the corresponding user in Active Directory.

Problem with ADFS claim rules

The problem is caused by an error with the claim rules in ADFS, resulting in this error.

Fix: Split the first claim rule (often named AD Attributes) into two separate claim rules. To do this, simply create one claim rule that will map the LDAP attribute ObjectGUID to the outgoing claim type https://zivver.com/SAML/Attributes/ZivverAccountKey, and then create another claim rule that will map the LDAP attribute E-mail Addresses to the Outgoing Claim Type E-Mail Address.

Error: urn:oasis:names:tc:SAML:2.0:status:Responder

This error appears when logging in to ADFS. The complete error is as follows:

{“error”: “The IdP sent us the status code 'urn:oasis:names:tc:SAML:2.0:status:Responder'. The optional second-level status code was: Consult paragraph 3.2.2.2 of the SAML spec for more info: https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

Fix: This problem can be fixed by removing the SSO configuration, and setting it up again from scratch according to the ZIVVER ADFS installation manual.

I am not logged in with my ZIVVER account

You are logged in to ADFS successfully. However, when ADFS sends you back to ZIVVER, you are not logged in with your ZIVVER account. See this section for possible causes and solutions for this problem.

Before you follow the steps listed below, please check if there are any errors displayed while logging in via SSO while using Chrome (see subchapter Check the error in Chrome).

After logging in, I get a notification to enter my password.

After being redirected back to ZIVVER, you are instructed to enter your ZIVVER password. The notification will also say that this is a one-time occurrence, and that this is necessary to enable SSO for the account.

This problem has several causes and corresponding solutions:

User account was created before configuring SSO

The user already had an account that was created (or invited to the organization) before SSO was configured and enabled.

Fix: Enter the ZIVVER password when the notification appears. This only has to be done once. After entering the password, the account will be matched to the account in the IdP, and it will be possible to log in via SSO from now on.

ZivverAccountKey attribute mismatch between SSO and the Synctool

The ZivverAccountKey attribute is different between the SyncTool and the SSO configuration. For example: SyncTool uses ObjectGUID, while ADFS uses ObjectSID.

Fix: Re-configure ADFS or the SyncTool so that the attribute for the ZivverAccountKey is the same. For example, they both use ObjectGUID. Then run the SyncTool again to synchronize the correct ZivverAccountKey. Make sure that Update the password/account key for all x users in local data is enabled in Step 4 of the SyncTool. It’s important that you manually run the Synctool with this option only once, and then turn it off again for future (automatic) syncs.

Synctool was run with SSO disabled

The SyncTool was executed while SSO was disabled.

Fix: If the users knows their ZIVVER password, enter this to fix the problem. However, users might not know their ZIVVER password, because they usually log in via SSO.

In that case, run the SyncTool again and make sure that Update the password/account key for all x users in local data is enabled in Step 4 of the SyncTool. It’s important that you manually run the Synctool with this option only once, and then turn it off again for future (automatic) syncs.

A notification appears to change the password

SSO is enabled for the organization, and users are created with the SyncTool. However, you are still requested to change your ZIVVER password when logging in. Several different possible causes for this issue are detailed in the following subchapters.

Synctool was run without SSO

The SyncTool was run before activating SSO in ZIVVER. Some examples why this might have happened: SSO is not configured completely yet. SSO was set up, but not enabled yet in SSO Settings page. SSO was set up and enabled, but the "Save" button wasn’t clicked.

Alternatively: The SyncTool was run with the option Users log in without SSO. In this case, the SyncTool will assign a temporary password for the accounts that users have to change on first login.

Warning
User accounts will be deleted if you apply this fix, so all of the users' messages will be permanently deleted as well. Please discuss this with your organization before applying this solution. Consider exporting any important data from ZIVVER before you remove the accounts.

Fix: The fix for both causes is the same: Remove all of the accounts using the SyncTool, and then re-create them. Make sure that the option Users log in with SSO is enabled in step 2 of the Synctool when you run it again to create the accounts.

SSO works, but it does not log me in automatically in the Office plug-in

If SSO is working, but users are not logged in automatically in the plug-in, then the required registry keys may not have been set up properly. These registry keys need to be deployed for each user, to enable the setting that logs them in automatically via SSO.

Fix: Please see this chapter of the ZIVVER installation manual for further instructions.

Still experiencing issues?

Are you still experiencing issues after following the guide, or is your problem not listed here? Then try the following:

Remove the existing SSO configuration and then set it up again from scratch.

See the Quick fix section at the start of this guide for instructions on how to reconfigure SSO for ZIVVER.

Still need help?

Could not find the information that solves your problem? Please contact support with the following information:

  1. ADFS configuration

    • How is the AD FS setup?

    • Are you using multiple servers for example?

  2. User scope

    • How many users are experiencing the problem?

    • What are the email addresses of the affected users?

  3. Product scope

    • What products are affected?

    • Does the problem occur in multiple products?
      For example some specific products like the Office plugin, WebApp, OWA, or all products?

  4. Network location

    • From what location on the network does the problem occur?
      For example, from inside or outside the company network, or both?

  5. Steps to reproduce

    • Where in the login process does the problem happen exactly?

    • What are the steps to reproduce the problem?

  6. Security measures

    • Are there any security measures present in the company network that may cause the problem?
      For example a firewall or proxy?

  7. Recent changes

    • Have there been any recent changes to the network- or working environment that may have caused an issue?

  8. Logging information

    • Please search the ADFS log in event viewer for the corresponding error and send this along with your email.

Please attach this information to a support request.
Contact support

Was this article helpful?

thumb_up thumb_down