I am a Zivver admin
Configure and manage Zivver
Single Sign-On - Troubleshooting login problems with ADFS
Introduction
Zivver offers the option to configure Single Sign-On (SSO) with ADFS, allowing users to conveniently log in using their AD credentials. If you experience issues with the SSO configuration between ADFS and Zivver, this article helps you troubleshoot these problems.
Prerequisites
For this guide, you need the following:
- A Zivver account with administrator rights.
- Your account must be a member of the Zivver organization for which you are troubleshooting SSO.
- Administrator access to the ADFS server.
Quick fix
A quick way to resolve many SSO-related issues is to remove the configuration from both ADFS and Zivver and then configure it again from scratch. This process takes approximately 15 minutes.
Resetting the SSO configuration
- Check if Single Sign-On is active on the Zivver SSO settings page.
When active, a green banner appears:
Single sign-on is enabled.
- Remove all SSO information from Zivver. Select at the bottom of the Zivver SSO settings page.
- Remove the Relying Party Trust from ADFS. Select it, then choose Delete.
- Follow the steps from the SSO installation manual again.
- Test if the problem is resolved by logging in to Zivver.
Examine the logs
If the quick fix does not work, or if you prefer to investigate first, examine the ADFS logs in the Event Viewer. These logs contain more detailed information than a web browser.
- Open Event Viewer (
eventvwr.msc
) on the ADFS server. - Go to Applications and Services Logs.
- Open ADFS > Admin.
- Search the log for errors that occurred at the relevant time and date.
If the Event Viewer shows an error, it may provide clues about the cause of the problem. For example, it might indicate that the user entered an incorrect password.
Check the error in Chrome
Alternatively, you can try to log in with SSO using the Chrome browser. Chrome is preferred because it displays more detailed error information than Internet Explorer.
If you or your users encounter errors during login, the specific error message can help identify and troubleshoot the issue.
To retrieve the error, follow these steps:
- In Chrome, go to app.zivver.com.
- Enter your email address, or the affected user’s email address. A pop-up window opens.
- Select to log in with SSO if you are using an administrator account. The ADFS login page should appear.
- Log in to ADFS with your workplace credentials. Check the displayed error message.
If the error message does not provide enough information to determine the cause, search online or refer to the rest of this troubleshooting guide.
If the issue persists, continue reading.
Read more about specific error messages and their solutions.
Troubleshooting
This section explains how to troubleshoot SSO issues.
Troubleshooting steps
Follow these steps to identify the cause of your problem:
- Check the error in Chrome to attempt logging in with SSO. This helps determine exactly where the problem occurs, or may show a specific error message.
- Choose the description that most closely matches your problem:
- SSO does not seem active; it is not redirecting from Zivver to ADFS. Nothing happens after entering the email address in the web app
- SSO redirects from Zivver to ADFS (or attempts to), but login still fails. Zivver attempts to log you in after entering your email address, but the problem occurs afterwards. Continue with step 3 below.
- Choose the option that best matches your situation:
- The ADFS login page does not appear. Nothing seems to happen when Zivver attempts to redirect you. See this section of the guide for relevant fixes.
- The ADFS login page appears, but login does not work. For example, your credentials are not accepted while logging in to ADFS. See this section of the guide for relevant fixes.
- Logging in to ADFS works, but the problem occurs afterwards. You have logged in to ADFS, but are not sent back to Zivver due to an error or a white screen. Continue with step 4.
- Choose the description that most closely resembles your problem:
- Zivver does not appear. You logged in to ADFS successfully, but are not redirected to Zivver properly. See this section of the guide for relevant fixes.
- Zivver appears, but you are not logged in yet. After logging in to ADFS, Zivver appears as expected, but you are not yet logged in with your Zivver account. See this section of the guide for relevant fixes.
Nothing happens after entering my email address
You landed here because nothing happens after entering your email address on app.zivver.com. Answer the following question to further pinpoint the problem: Does the issue exist for all users, only one user, or 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 when SSO does not appear to be active for specific users, meaning users are not redirected to ADFS after entering their email address on app.zivver.com.
The user is not a member of the Zivver organization
If the entered email address is not a member of the Zivver organization, SSO will not work for this account.
Fix: Check the accounts page to see if the email is part of the organization. If not, create an account or invite them if they already have one.
If SSO is currently active for the organization, you cannot invite an existing account:
- Disable SSO.
- Invite the account.
- Wait for them to accept the invitation.
- Enable SSO again.
The email address does not match a claimed domain
Zivver can log users in via SSO only if the domain in the email is recognized as a claimed domain of the organization. Typos or a different domain than other users may prevent login.
Fix: Enter the email correctly, or claim the additional domain on the Domains page.
SSO is not active for any users
This section lists possible causes when SSO seems inactive for all users in the organization.
The domain is not claimed in Zivver
The domain of users logging in via SSO must be claimed in the organization in Zivver.
Fix: Follow the steps in How to claim your email domain in Zivver.
SSO is not enabled
After configuring SSO in both Zivver and ADFS, it must be enabled in Zivver.
Fix: Enable SSO by clicking on the Zivver SSO settings page.
The metadata is incorrect
ADFS metadata contains essential information for SSO. Check the subsections below for solutions.
The ADFS metadata URL is incorrect
If the ADFS metadata URL is wrong, Zivver cannot retrieve required data. This can occur if 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 unreachable from outside the company network, Zivver cannot access metadata via the specified URL.
Fix: Allow external access to the ADFS server or paste the static metadata XML into Zivver SSO settings using these steps.
The ADFS metadata XML is out of date
Applies only if using the static metadata XML.
If Manually is selected on the SSO page, the metadata may have become invalid due to changes in the Zivver relying party trust or ADFS configuration, including certificate renewal.
Fix: Update the static metadata XML in Zivver following these steps.
The ADFS login page does not appear
If you are not properly redirected to ADFS from Zivver, the login page may not appear after entering your email address.
The Relying Party Trust is disabled in ADFS
SSO is configured but not enabled in ADFS management.
Fix: Open the ADFS Management app and enable the Zivver relying party trust.
ADFS metadata issues
See this section for causes and solutions.
The ADFS server cannot be reached
Fix: Allow external network access to the ADFS server.
No valid certificate on the ADFS server
An invalid or missing SSL certificate results in browser errors instead of ADFS login.
Fix: Ensure a valid certificate exists, e.g., by renewing it. See this article.
Page can’t be found
IE11 may show “The page can’t be found” due to security settings.
Fix: Add https://*.zivver.com
as a trusted site in Internet Options.
White screen in mobile app
SSO works on app.zivver.com but not in the mobile app. Entering your email may show a white screen due to Windows Integrated Authentication not displaying correctly on mobile devices.
Cause: Global Primary Authentication is set to Windows Authentication, preventing Forms-based Authentication as secondary. This is a known ADFS issue. Verify by logging in at app.zivver.com as described in Check the error in Chrome.
Fix: Enable Windows Authentication for intranet and Forms Authentication for extranet. Users can then log in via the mobile app.
Redirect users to a login form instead of a Windows pop-up by editing web.config
under c:\inetpub\adfs\ls
.
Ensure Forms
is the first entry in <localAuthenticationTypes>
:
<localAuthenticationTypes> <add name="Forms" page="FormsSignIn.aspx" /> <add name="Integrated" page="auth/integrated/" /> <add name="TlsClient" page="auth/sslclient/" /> <add name="Basic" page="auth/basic/" /> </localAuthenticationTypes>
I cannot log in to ADFS
This section describes the possible causes and solutions if you cannot log in to ADFS. Describe the scope of the problem you are experiencing:
- The problem occurs only for some specific user(s). Click here, or read on for possible causes and fixes.
- The problem occurs for all users. Go here for possible causes and fixes.
Specific users cannot log in to ADFS
If some of your users cannot log in to ADFS, read the following causes and solutions:
Check the logs
If only specific user(s) cannot log in to ADFS, the cause may be that they entered the wrong password.
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 or disabled in Active Directory cannot log in via ADFS.
Fix: Enable the user account in AD to allow login via ADFS.
Duplicate UPN present in AD
If multiple objects (users) exist in AD with the same User Principal Name (UPN), they cannot log in via ADFS.
Fix: Search AD for the UPN of the affected user to find duplicates and remove or modify them.
No users can log in to ADFS
If none of your users can log in to ADFS, read the following causes and fixes:
Users are not able to log into ADFS using their email address
In most cases, the UPN is used for login, which may differ from the email address (e.g., @zivver.com
vs @zivver.local
).
Fix: Manually change the login name on the ADFS login page to log in.
User-friendly fix: To simplify the login process, apply one of the following options:
- Modify the ADFS
onload.js
so that the username field is empty by default:document.forms['loginForm'].UserName.value = ' '
- Modify the ADFS
onload.js
to automatically pre-fill the username field: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 may appear.
Many fixes in this section of the guide address specific errors that can occur when trying to log in via SSO in the browser. See Check the error in Chrome for instructions on determining the error.
Below are the causes for this problem, as well as related fixes.
ADFS metadata problem
The ADFS metadata contains information necessary for SSO to work. See this section for the causes and solutions.
Error messages
Do you get an error after logging in to ADFS? Review these errors and fixes. If the error is not listed or the solution does not solve the issue, contact Zivver support.
- Error: {“error”: “SAML Response is not valid before: …”}
- Error: {“error”: “SAML response was not properly signed. Make sure to sign at least the SAML response or the assertion(s).”}
- Error: {“warn”: “Response wasn’t properly signed (resp:false, unenc:true, end:false) for …”}
- Error: urn:oasis:names:tc:SAML:2.0:status:Requester
- Error: urn:oasis:names:tc:SAML:2.0:status:Responder
- {“error”: “The IdP Sent us the status code ‘urn:oasis:names:tc:SAML:2.0:status:Responder’. The second-level status code was: ‘urn:oasis:names:tc:SAML:2.0:status:RequestDenied’. Check if ‘[unknown user]’ is allowed to use single sign-on with ZIVVER in your IdP’s settings.”}
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.
Before performing the steps below, check if any errors are displayed while logging in via SSO using Chrome. See Check the error in Chrome.
After logging in, I get a notification to enter my password
After redirection to Zivver, enter your Zivver password. The notification also states that this is a one-time occurrence, necessary to enable SSO for the account.
This problem has several possible causes and corresponding solutions:
User account was created before configuring SSO
The user already had an account created (or invited to the organization) before SSO was configured and enabled.
Fix: Enter the Zivver password when the notification appears. This only needs to be done once. After entering the password, the account is matched to the account in the IdP. From now on, login via SSO is possible.
ZivverAccountKey attribute mismatch between SSO and the Synctool
The ZivverAccountKey attribute differs between the Synctool and the SSO configuration. For example, Synctool uses ObjectGUID, while ADFS uses ObjectSID.
Fix: Reconfigure ADFS or the Synctool so that the attribute for the ZivverAccountKey is the same. For example, both can use ObjectGUID. Then run the Synctool again to synchronize the correct ZivverAccountKey. Make sure Update the password/accountkey for all users in local data is enabled under Syncing > Synchronization Options in the Synctool. Manually run the Synctool with this option only once, then turn it off for future automatic syncs.
Synctool was run with SSO disabled
The Synctool was executed while SSO was disabled.
Fix: If users know their Zivver password, enter it to fix the problem. If not, run the Synctool again and ensure Update the password/accountkey for all users in local data is enabled under Syncing > Synchronization Options in the Synctool. Manually run it once, then turn off for future 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. Possible causes are detailed below.
Synctool was run without SSO
The Synctool ran before activating SSO in Zivver. Examples why this might happen: SSO is not fully configured yet, or SSO was set up but not enabled in the SSO Settings page.
Alternatively: The Synctool ran with the option Users log in via SSO disabled. In this case, Synctool assigns a temporary password that users must change on first login.
Fix: Remove all accounts using the Synctool and re-create them. Ensure Users log in via SSO is enabled under Target (Zivver) when running Synctool to create the accounts.
SSO works, but it does not log me in automatically in the Office plugin
If SSO is working, but users are not logged in automatically in the plugin, required registry keys may not have been set up properly. Deploy these keys for each user to enable automatic login via SSO.
Fix: Read how to enable automatic login to the Office plugin with SSO for instructions.
Still experiencing issues?
Are you still experiencing issues after following the guide, or is your problem not listed here? 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? Contact support with the following information:
- ADFS configuration
- How is AD FS set up?
- Are multiple servers used, for example?
- User scope
- How many users are experiencing the problem?
- What are the email addresses of the affected users?
- Product scope
- Which products are affected?
- Does the problem occur in multiple products?
For example, some specific products like the Office plugin, WebApp, OWA, or all products?
- Network location
- From which location on the network does the problem occur?
For example, from inside or outside the company network, or both?
- From which location on the network does the problem occur?
- Steps to reproduce
- Where in the login process does the problem happen exactly?
- What are the steps to reproduce the problem?
- Security measures
- Are there any security measures in the company network that may cause the problem?
For example, a firewall or proxy?
- Are there any security measures in the company network that may cause the problem?
- Recent changes
- Have there been any recent changes to the network or working environment that may have caused an issue?
- Logging information
- Search the ADFS log in Event Viewer for the corresponding error and include this with your email.
Attach this information to a support request.
Contact support