Troubleshooting & FAQs

Resource for answering common questions and resolving errors.

During installation, the SSO Connect service hangs and doesn't start.
Please ensure that you have a compatible Java version installed.  See the System Requirements page for supported Java versions.  Please note you may need to uninstall all existing Java installations before installing a compatible version.
How to make changes to my SSO Connect configuration to update the SSL certificate or IdP metadata?
Follow the steps outlined on the Updating the SSO Connect Configuration page of this guide.
We use ADFS, and our SSO Connect is down.
ADFS signing certificates typically are only valid for a year.  ADFS may automatically rotate to the most current certificate.   This breaks the trust between Keeper SSO Connect and ADFS.   A new FederationMetadata.xml file will need to be generated and uploaded to the Keeper SSO Connect to ensure operation  (https://docs.keeper.io/sso-connect-guide/identity-provider-setup/ad-fs-configuration#obtain-federation-metadata-xml).   We strongly recommend setting a reminder before the expiration of the certificate so this step can be performed to maintain operation.
What information needs to be secured on the SSO Connect server?
There is a "data" folder created when SSO Connect starts up.  This data folder is located in C:\ProgramData\Keeper SSO Connect\ on windows, and in the installation folder on Linux.
Inside the data directory there are several files. It is critical that access to this data folder is restricted.  You can add an extra layer of security by utilizing an HSM (Hardware Security Module) as described in this document. When an HSM is available, an encryption key is generated for each SSO Connect instance and stored securely in the HSM. The encryption key is used to encrypt the property files in the data/ folder.
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.
If you are hosted in  the.eu domain, usekeepersecurity.eu instead ofkeepersecurity.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.
When I set up an HA SSO Connect server, or recover my SSO Connect server configuration from the cloud sync, the private IP address is not there.
This is by design.   The Private IP is unique to the local instance of the SSO Connect.  If the Private IP from "Server1" was sync'd and when "Server2" authenticated and sync'd the SSO Connect Config, it would have the incorrect IP from "Server1".  For this reason the Private IP of the 1st (on any other) SSO Connect server is not retained.
The SSO Connect service will be in a "Stopped" status if the Private IP address is needed and not configured.
When users authenticate via SSO they receive an error stating "invalid SAML response".
If nothing has changed in the IdP or within Keeper SSO Connect, the most likely culprit is the clock on the SSO Connect has changed and the system time is off by greater than 2 minutes.  Older versions of SSO Connect will display this message when the time is off, but the latest version of SSO Connect will specifically give the error:  "SAML Validation error: System time is off by > 2 min".   It is recommended to have the SSO Connect Server clock to sync with NTP.

Another potential cause of this error is if the metadata from the IdP is different than what is on the SSO Connect which causes the SAML certificates to be out of sync and there for untrusted.
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.  For the first issue, move the user into the SSO Enabled node and have them try again.  For the second issue, verify the SSO account uses the same email address as the invited user. If they are different, a new account with the email address from the IdP will be created.
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, separated by Node.  The Keeper Admin Console also has a role policy which can allow SSO users to also create a Master Password for logging in offline.
How do I convert a federated user to a local user or put another way,  disable SSO access and have the user log in natively (username/master password)?
In the admin console, move the user from the SSO enabled node to a node not under the enforcements of the SSO provisioning.
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.
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.
If using Duo for 2FA, have user disable their 2FA prior to the email change. (Admin may have to change the role to temporarily allow no 2FA on the account).  This because if the email changes outside of Keeper and the vault is still associated with the old email, it may not correspond to what is in Duo.
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.
After I install SSO Connect, the configuration page comes up with a "Can't reach this page" at http://127.0.0.1:8080/config/.
If JRE has been installed and the server has been rebooted, this error is most like caused by a competing service like IIS listening to the port 8080.  To alleviate the competition IIS can be uninstalled if not needed, or the port that SSO Connect uses for the configuration page can be changed. 
Stop the SSO Connect service if running
Edit the instance.properties file located at:
C:\ProgramData\Keeper SSO Connect\data\
Change the port of the admin_port.  (i.e. 8081)
Restart the SSO Connect service and relaunch the admin page on the newly defined port. (i.e. http://127.0.0.1:8081/config/).
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
What's the process for upgrading SSO Connect to the latest version?
See the "Upgrading SSO Connect" section of this document.
When my users log out of Keeper it logs them out of all SAML connected applications and the IdP.
To disable Single Logout (SLO), edit the IdP metadata file to remove the line found in the metadata that gets inputed into the Keeper SSO Connect Server: 

<md:SingleLogoutServiceBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://your-sso_connect:8443/sso-connect/saml/slo"/>
<?xml version="1.0" encoding="UTF-8"?>
<md:EntityDescriptor entityID="https://your-sso_connect:8443/sso-connect" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata">
    <md:SPSSODescriptor AuthnRequestsSigned="true"
        WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
        <md:KeyDescriptor>
            <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                <ds:KeyName>Keeper SSO Connect</ds:KeyName>
                <ds:X509Data>
                    <ds:X509Certificate>MIIEHTCCAwWgAwIBAgIUOL886JdcXafub9E19hjGwnXAqZkwDQYJKoZIhvcNAQELBQAwgZ0xCzAJ
BgNVBAYTAlVTMREwDwYDVQQIDAhJbGxpbm9pczEQMA4GA1UEBwwHQ2hpY2FnbzEPMA0GA1UECgwG
S2VlcGVyMQ4wDAYDVQQLDAVTYWxlczEXMBUGA1UEAwwONzQuMTIzLjIzMC4yMTIxLzAtBgkqhkiG
9w0BCQEWIGpwYWRpbGxhK2RlbW9Aa2VlcGVyc2VjdXJpdHkuY29tMB4XDTE5MDYwNjIzMTc1NFoX
DTI5MDYwNTIzMTc1NFowgZ0xCzAJBgNVBAYTAlVTMREwDwYDVQQIDAhJbGxpbm9pczEQMA4GA1UE
BwwHQ2hpY2FnbzEPMA0GA1UECgwGS2VlcGVyMQ4wDAYDVQQLDAVTYWxlczEXMBUGA1UEAwwONzQu
MTIzLjIzMC4yMTIxLzAtBgkqhkiG9w0BCQEWIGpwYWRpbGxhK2RlbW9Aa2VlcGVyc2VjdXJpdHku
Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsI2mf2YO+cWOrJkF49JMt9ptQAlW
/dGH3xJe5iXSkNSRbaHSy28yMq/5tQt0PijqiIMrNA2OAp08LKFlHdLxx+J9QS3TsJ02P2zlOOTR
Io5D5vhdZp4Ncoq7bIorNelWwXuCYN4VCeGb2Wpv0t1vUXJt+RdqMtTo5mhDv0BBMaQPAqJHcMJy
a3Ll6s97+/N8zpikwM8EK7DoN3PL9BpWBPaV7vGp/op8ZF2teH0jdbaVNzWZJFccI39OY7gw/Wt8
BAFdty00XEKgUrjOwN4rCZO1y2vrMvhF9rCXEqOQ1rCtIjf+PLiRf3JrGkZw9FwY4Q1Wvtx7sO3z
/7DCHm6ZXQIDAQABo1MwUTAdBgNVHQ4EFgQU6rASWeedslRXXQ/pacXDogAg+lQwHwYDVR0jBBgw
FoAU6rASWeedslRXXQ/pacXDogAg+lQwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQsFAAOC
AQEAoZTerl+qGg8nmwgaKLpLeGxvSIxTSybAALjAymIs520U4imyuZqsPz9EKlWRWJI7e4z8kHFh
PPyAYuxC/kVqKAg/GQ50KPZDdOd3jOuykpI4wgCvyB739/KOlGAbsQ7R5Ga0ttsFAJIoBkXAlf7e
HaeZCpm31EFdP64AS4R4xjYJ5P/EtVYkpsJy5BnwhfGXza4x79NEn2+xc5fBze9bjC0NoYT5kJo4
ndKalRnY/S51yznQ7mPeYJ8lweJxnXfh5n/AVvr+07dUH7PeLy0ZlMPkVrE3vQJO9eZFlrNiW5w9
nnw2XVkoGfvYLuPcjHUpRA6Ib7zpBVuhMr9qDZyDaB==</ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </md:KeyDescriptor>
        
//REMOVE --> <md:SingleLogoutService
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://your-sso_connect:8443/sso-connect/saml/slo"/>
        
        <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>
        <md:AssertionConsumerService
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
            Location="https://your-sso_connect:8443/sso-connect/saml/sso"
            index="0" isDefault="true"/>
    </md:SPSSODescriptor>
</md:EntityDescriptor>
​
And re-import the file to the SSO Connect server.
​

Service Management

Appendix - Creating Certificates

Last updated 4 days ago

Troubleshooting & FAQs

During installation, the SSO Connect service hangs and doesn't start.

How to make changes to my SSO Connect configuration to update the SSL certificate or IdP metadata?

We use ADFS, and our SSO Connect is down.

What information needs to be secured on the SSO Connect server?

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

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

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

When I set up an HA SSO Connect server, or recover my SSO Connect server configuration from the cloud sync, the private IP address is not there.

When users authenticate via SSO they receive an error stating "invalid SAML response".

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

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

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”}

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

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

How do I convert a federated user to a local user or put another way, disable SSO access and have the user log in natively (username/master password)?

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

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

After I install SSO Connect, the configuration page comes up with a "Can't reach this page" at http://127.0.0.1:8080/config/.

What's the process for upgrading SSO Connect to the latest version?

When my users log out of Keeper it logs them out of all SAML connected applications and the IdP.