Microsoft AD FS
How to configure Keeper SSO Connect Cloud with Microsoft AD FS for seamless and secure SAML 2.0 authentication.
Please complete the steps in the Admin Console Configuration section first.
Microsoft AD FS
Obtain Federation Metadata XML
Inside the AD FS Management application, locate the Federation Metadata xml file. This can be found by clicking on AD FS > Service > Endpoints then locate the URL path in the "Metadata" section. The path is typically /FederationMetadata/2007-06/FederationMetadata.xml as seen below:
Download the Metadata
To download the metadata file, this can typically be found by loading the URL in the browser on the server. For example: https://localhost/FederationMetadata/2007-06/FederationMetadata.xml Download this file and save to the computer.
Import Federation Metadata
From the Keeper Admin Console SSO Cloud configuration screen, select "ADFS" as the IdP type and import the Federation Metadata file saved in the previous step.
Export Keeper Metadata
Go back to the Provisioning screen and click on View.
Next download the Keeper metadata file so it can be imported during the Relying Part Trust Wizard. Navigate to the view screen of the Keeper SSO Connect Cloud™ provisioning.
Click the "Export Metadata" button to download the config.xml file. This will be used in a few steps ahead.
Finish AD FS Configuration
Important: Keeper's Cloud SSO SP Certificate is only valid for a year. On an annual basis, you will need to download the latest Keeper SP Cert from the Admin Console and upload this into the Relying Trust Party settings in AD FS.
Keeper notifies all affected customers when the certificate expiration is coming soon.
Create Relying Trust Party
Create Keeper SSO Connect as a Relying Party Trust:
Import Keeper Metadata
Import the Keeper Metadata file that was exported previously from Keeper SSO Connect Cloud view screen by completing the Relying Party Trust Wizard as seen in the steps below.
Select "Claims aware" in the Welcome screen and then select the metadata file saved from Keeper.
To prevent a logout error, change the SAML Logout Endpoints on the Relying Party Trust to: https://<YourADFSserverDomain>/adfs/ls/?wa=wsignout1.0
Create Claim Issuance Policy Rules
To map attributes between AD FS and Keeper, you need to create a Claim Issuance Policy with Send LDAP Attributes as Claims and map the LDAP attributes to Keeper Connect attributes.
Important: Ensure that 3 attributes ("First", "Last" and "Email") are configured with the exact spelling as seen above.
For Logout support we need to add two more Claim Issuance Policy rules:
To copy the syntax to add in the claims rule, copy the following text and paste it into the custom rule:
Incoming claim type: http://mycompany/internal/sessionid Outgoing claim type: Name ID Outgoing name ID format: Transient Identifier
SAML Signing Configuration
a. Open Powershell as Administrator on the AD FS server. b. Identify your SSO Connect Relying Party Trust "Identifier" string which you can obtain by running:
Running this command will generate a long list of output, you are looking for the SSO Connect section and the "Identifier" string. This string will look something like: https://keepersecurity.com/api/rest/sso/saml/459561502484
c. Run the below command, replacing <Identifier> with the string found in step (b).
If you run Get-ADFSRelyingPartyTrust again, you'll see that the SamlResponseSignature section is set to "MessageAndAssertion".
Restart AD FS services
From the services manager, restart AD FS service.
SAML assertion signing must be configured properly on your AD FS environment. If signing has not been configured, you will need to set this up, then exchange metadata again between AD FS and Keeper SSO Connect after the re-configuration.
Troubleshooting
If you need to disable certificate validation on the IdP for testing purposes or for internal PKI certificates, you can use the below Powershell commands. Replace <Identifier> with the string found in the "SAML Signing Configuration" instructions above.
Note: Any changes made to signing configuration may require exchange of XML metadata between IdP and SSO Connect.
Move existing users/initial admin to SSO authentication
Users created in the root node (top level) will need to be migrated to the sub node that the SSO integration was configured on. If users remain in the root node, they will be prompted for the master password when accessing the vault and/or admin console.
An admin can not move themselves to the SSO enabled node. It requires another admin to perform this action.
After the user is moved to the SSO enabled node, they need to log into the Keeper vault initially by selecting the "Enterprise SSO" pull down and inputting in the Enterprise Domain configured on the SSO integration. The user may get prompted to confirm by entering in the master password.
Once the user has authenticated with SSO, they only need to use their email address moving forward to initiate SSO authentication.
They won't have to enter the Enterprise Domain. If typing in the email address and clicking Next does not route the user to the desired SSO, ensure that just-in-time provisioning is enabled in the Keeper SSO configuration and ensure that your email domain is reserved by Keeper. More information regarding routing and domain reservation can be found here.
Last updated