Troubleshooting & FAQs

How do we link users directly to the sign-in screen?

If you would like to send users a hyperlink directly to the SSO Login screen of the Web Vault, you can use the following format:

https://keepersecurity.com/vault/#provider_name/xxxxx

Replace xxxxx with the name of the Enterprise Domain that has been assigned in the Admin Console. NOTE: If you are hosted in our .eu domain, use keepersecurity.eu instead of keepersecurity.com.

Why don't you just bind the SSO service to all interfaces rather than require me to provide an IP?

• The reason is that some customers have multi-homed servers and they do not want to bind to all interfaces for a number of reasons.

If an internal IP is required, why does SSO connect let me leave it blank?

• The internal IP is not required. You can leave it blank if the hostname resolves via DNS to

  the same external IP or even internal IP for Intranet. We have customers who use SSO strictly

  internally and the FQDN resolves to the internal IP. So that field can be left blank. It

  depends on your setup.

Why can’t my non-SSO users change their master password?

• When SSO Connect is enabled on a node, all the users in the node and sub-nodes are under an

  enforcement to prevent the changing of their master password. This is done to prevent SSO users

  from bypassing authentication through the IdP.

If a user is transitioned to SSO login, but desires to change their master password, they will need to be relocated to a node that doesn’t have the SSO enforcement.

If use of a master password in conjunction with SSO authentication is desired, follow the steps outlined in the Enterprise guide for vault offline access: https://docs.keeper.io/enterprise-guide/vault-offline-access​

I have invited a user; why can’t they create their vault via SSO Connect?

• When logging in for the first time the on-boarding process needs to occur on either the Web

  or the Desktop application. The Browser Extensions do not facilitate the on-boarding process

  of a new user, but will allow existing users to authenticate.

I am receiving the following error when a new user tries to connect for the first time: {“result_code”: ”does_not_exist”, ”message”: ”This user does not exist”}

• There are two possible reasons for this error. The invited user is not in an SSO Enabled node within the Admin Console or the email address in the IdP doesn’t match the email address of the invited user. Try moving the user into the SSO Enabled node. If after verifying the user is in the correct node, try changing the SSO provisioning method from invited users to dynamic users. If the account gets created, it is most likely an email address mis-match.

I'm getting an error on Linux about writing to /tmp. How do I resolve?

• On a Linux system /tmp must have exec privileges. If /tmp does not have exec privileges, execution of java -jar SSOConnect.jar

  may show an exception similar to: java.lang.UnsatisfiedLinkError: /tmp/sqlite...

  To resolve this, ensure that you have exec permission on /tmp with the command chmod a+x /tmp.

Can users login in both ways: via SSO and natively?

• Enterprises can have some users configured to natively login and other users configured to

  use SSO, but once a user has been transitioned to SSO, they will only be able to access their

  vault via SSO.

I can login via SSO into Keeper using Chrome, Firefox, and the Desktop application, but I can’t connect with IE. Why?

• IE has difficulty handling cross-domain redirects due to their multiple security zones. IE requires security zone settings to be configured in order to work properly with SSO. These security zone settings can be pushed out by the admin or manually configured if allowed. See the section on Trusted Sites Policy for settings.

If my email address changes, and I authenticate with SSO, what do I need to do within Keeper?

• Changing emails is a tricky business as both the IdP and Keeper need to identify the same user based on their email address. So if email changes in one, but not the other, authentication will not work. It has to be a coordinated effort on both fronts.

• From the Keeper side, only the user can change their email address. This requires the user to be moved from the SSO enabled node to another node (like the root level node) that does not have SSO enforcements.

• After the move, the user must perform an account recovery (logging in natively with an incorrect password) clicking the ‘Forgot Password’ link. The user will receive an account recovery code to the email address listed on their Keeper account. After inputting the code, the user will be required to have the security question and answer configured at the inception of the vault creation process. This will allow them to create a new master password.

• Now the user can log in natively with their email and newly created master password. To change their email address in Keeper, click on More > Settings > General > Change Email Address. Once it is changed on the Keeper account the SSO IdP will need to be changed.

• After both sides are converted, the admin will relocate the user back into the SSO enabled node and the end user can authenticate following the SSO login path. During that process they will need to enter their master password one last time to convert their account to an SSO login.

Where are the Keeper SSO Connect log files located?

• On Microsoft Server installations, the log files reside within a hidden system directory. This directory can be access by typing the following path into the File Explorer:

C:\ProgramData\Keeper SSO Connect\logs

• On Linux distributions, the logs are located with the sso_connect folder and varies depending on the base installation path:

/<base_path>/sso_connect/logs

​