Customers can log in to Jive using the "non-employee" option, the admin login option, or via the API. All of which require a Jive username and password. The user may run into issues like:
- Being asked to log in each time they click a link to a document from an email or search results.
- Getting locked frequently and requiring a password reset.
- Getting an error message when trying to log in. E.g. "System Error We're sorry but a serious error has occurred in the system".
- Getting a 401 Unauthorized Error
This article helps troubleshoot such authentication issues.
Note: This article does not handle Single Sign-On (SSO) or LDAP-related authentication issues. Please see the below links for some articles relevant to SSO and LDAP:
The first step for troubleshooting any authentication issues should involve:
- Clear cookies and browsing data (instructions for Chrome, and Edge).
- Try logging in using an Incognito/Private Window
- Try using a different browser
Try Logging in via API and Front End
If you are having trouble logging in via the Jive "non-employee" or "admin" options, try logging in via the API as well.
- Create a GET request to the above endpoint, replacing the "customer.jiveon.com" part with the URL of your instance.
- Enter your username and password in the basic authentication section.
- Press "Send"
- If it is successful you will see a 200 OK message. If you see any other message, please make a note of it for further troubleshooting purposes.
If you are facing issues logging in via the API, please do the reverse. Try logging in via the Jive non-employee option using the affected API user.
Look for Errors in Logs, HAR Files, HTML Elements, and Browser Console
SBS Logs (for Hosted & On-Prem), and Kibana (for Cloud - Agent Access Only) should be the first place to look for any error messages. Sometimes there are error messages in the browser console. Sometimes the error message is hidden and cannot easily be seen. In such cases, it helps to inspect the HTML elements in the browser. You can also record a HAR file while you reproduce the error.
Note the date and time (and timezone) of when the error occurred, so you can look in the logs around that time.
Check for Outage
An error message like "System Error - We're sorry but a serious error has occurred in the system" may indicate a system outage.
You can check for any documented outages here: https://status.jivesoftware.com/
You can create a vanilla test instance and check if you can authenticate on that instance.
Steps for creating vanilla test instances:
You can contact us with as many of the below details as possible:
- Instance URL
- User Names of Affected Users
- Error message
- Screenshots of the error
- Summary of the troubleshooting that you have done so far
- Any log files you have collected
- The exact time when the error occurred
Check if User is Active in Jive
Active users are defined as Enabled Users that are also Visible, are not External users and have logged in at some point in the last 30 days.
This can be checked through Admin Console > System > Settings > Search > User Search
Try Resetting Passwords
Refer to How to Reset another User’s Password for the steps to reset the password of the user who is facing issues logging in.
Check User Decay
User Decay is a process that, by default, disables users that have not been active for one year. This is configurable and can be set to any number of months.
If this task is enabled, it may be a reason why certain users are getting disabled. To verify, follow the below steps:
- Open the Jive Admin Console
- Navigate to System > Management > System Properties
- Search for "user.decay.task.enabled".
- If you don't find this property, or if its value is set to TRUE, it means that decay is enabled. You can troubleshoot decay further in this case.
- If you find that the above property is set to FALSE, it means decay is disabled and is not the reason for users getting disabled or locked.
Check Changes to User Profile in the Audit Log
Jive keeps an audit log of activities, including changes to users and their profiles. The DB table "jiveauditlog" is used to record this activity. You can query this table to see what changes have been made to the profiles of the affected users recently.
This is kept in the SBS database. For cloud and hosted installations, you can use MagicQuery to run the query. For On-Prem installations, you will have to ask the customer to run the query on your behalf using their database access tool of choice (psql, Oracle SQL Developer etc.).
The below query will return recent activity on a user called "firstname.lastname@example.org":
SELECT *,to_timestamp(timestamp/1000) FROM jiveauditlog WHERE details ILIKE '%email@example.com%' ORDER BY timestamp DESC limit 30
Look for things like a particular user doing frequent changes to other users' profiles.
Eg. in ticket 2177297, the agent found that a user with ID 2020 is changing the affected users' profiles on a regular basis.
For example, the below query gave more information on the activities of user 2020.
SELECT *,to_timestamp(timestamp/1000) FROM jiveauditlog WHERE userid = 2020 ORDER BY timestamp DESC limit 30
The agent was then able to inform the customer of this, and the customer was able to understand that there was an issue at their end which was causing the problem.
Check Advanced User Sync (Boomi)
It is possible that the API user does not exist in the CSV file used for Boomi Sync. Review the file for inconsistencies.
Agents should follow the steps in Advanced User Sync (Boomi).
Monitor Password Hash for Changes
It is possible to get the password hash and monitor it for changes regularly to find out if the password has changed.
SELECT userid, passwordhash, username, email, to_timestamp(modificationdate/1000) as modified, to_timestamp(creationdate/1000) as created, to_timestamp(lastloggedin/1000) as lastlogin from jiveuser where userid = 14937
Check "Keep me Logged In"
When a user logs in to Jive, using the non-employee option, there is a check box saying "Keep me logged in". If this is not checked, the user might get logged out when a session expires, requiring them to log in again when trying to open a document or a jive link.
You should ask the customer to check this box while logging in, and then try to reproduce the problem.
Troubleshoot Vanity URLs
A vanity URL is a domain name (community.mydomain.com) purchased and maintained by the customer which replaces the default site URL that was provided to the customer by Jive (customer.hosted.jivesoftware.com or community.jiveon.com).
One cause of authentication issues is that vanity URLs are not properly configured or the customer is using the wrong URL. Look for the below on a customer instance:
- What URL does the user use to log in? Is it a Jive-provided URL like https://customer.jiveon.com?
- What URL is in the emailed links that the user is clicking? Is it a vanity URL like https://community.mydomain.com ?
If there is a mismatch like the one above, you can ask the customer to log in using the vanity URL and then check again. You can read more about Vanity URLs here.
Verify with Customer and Close the Ticket
Once you have found the root cause of the issue on a test instance, and you have found a fix for it, apply that fix on the customer instance as well. If the fix is something that the customer can apply themselves, it may suffice to demonstrate the root cause and fix to the customer over a video call.