To setup Dome9 SSO with ADFS perform the following steps:
In Dome9, click Administration > Account Settings.
- Click the SSO tab.
- Click the Edit button to edit the SSO configuration.
- In the Account ID field, enter a string of your choosing which is a company name identifier (no spaces).
Note: The Account ID string will be appended onto the Dome9 SSO Login Page URL. For example, an Account ID of contoso will have a URL of: https://secure.dome9.com/sso/contoso
In the Issuer field, enter an Issuer URI string. This is required to be a URI of the identity provider as configured in ADFS and is case sensitive.
Common example: http://<myadfs.domain.com>/adfs/services/trust
Other environmental considerations:
-A valid URI may be HTTP or HTTPS
-A valid URI may also end with /trust/mex or /trust
In the Idp endpoint url field, enter the trusted URL of your ADFS. (The web address of your ADFS server)
In the X.509 Certificate field, copy and paste the public key of your AD FS Token-signing certificate. It should be exported in Base-64 encoded X.509 format.
Before beginning to configure your ADFS environment, copy the following Service Provider Metadata XML and save it to file. Replace <yourcompanyname> to match the string configured in step 4. If needed, you may update the property values of validUntil and cacheDuration.
Template for Service Provider Metadata XML:
<?xml version="1.0"?> <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" validUntil="2017-09-03T06:43:37Z" cacheDuration="PT604800S" entityID="https://secure.dome9.com"> <md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> <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://secure.dome9.com/sso/saml/<yourcompanyname>" index="1" /> </md:SPSSODescriptor> </md:EntityDescriptor>
In ADFS, Add a new Relying Party Trust (Claims aware) and follow the steps in the wizard
Import the Service Provider Metadata XML file from Step 9 by clicking Browse.
- Click the Next button.
In the Display name field, enter Relying Party for Dome9.
Click Next until the end of the wizard.
Click the Next button and edit the Claim rules.
Click Add Rule.
Select Send LDAP Attributes as Claims and then click Next.
In the Claims rule name field, enter Get Email.
In the Attribute store drop-down, select Active Directory.
In the Mapping of LDAP attributes... section, map E-Mail-Addresses to E-mail Address as seen in the image below.
Click the Add Rule button again.
Select Transform an Incoming Claim and then click Next.
In the Claim rule name field, enter Convert Email to NameID
In the Incoming claim type drop-down, select E-Mail Address.
In the Outgoing claim type drow-down, select Name ID.
In the Outgoing name ID format drop-down, select Email.
Click Finish.Note: The Relying Party Trust defaults to a secure hash algorithm of SHA256. The Token-signing certificate (found in ADFS > Services > Certificates) should have a matching Signature hash algorithm.
Optional - Setup Just-in-time (JIT) provisioning for the account
In order to setup JIT provisioning with Dome9 and your AD FS environment you will perform three major steps:
- Enable JIT Provisioning in Dome9
- Create a Dome9 role
- Create an AD Group and configure the Dome9 Relying Party Trust
Enable JIT Provisioning in your Dome9 account
- In Dome9, click Administration > Account Settings.
- Click the SSO tab.
- Click the Edit button.
- With the SSO configuration, click to check Allow under Just-in-time provisioning for the account.
- Leave the Attribute name in SAML for just-in-time role as the default value of memberOf.
- Click Save.
Create a Dome9 Role
- In Dome9, Click Administration > Roles.
- Click Add Role.
- Create Role: In the Name field, enter a role name. (e.g. dome9-jit-readonly). The description is optional.
- Click Create.
- Edit the permissions and click Save.
Create an AD Group and configure the Dome9 Relying Party Trust
- Create an Active Directory security group for JIT provisioning to Dome9 (e.g. dome9-jit-readonly) in your domain environment. Add the domain users to the new group who will be logging into Dome9.
- Edit the AD FS Claim Issuance Policy for Relying Party for Dome9 and click Add Rule.
- Click the Claim rule template drop-down and select Send Group Membership as a Claim.
- Click Next.
- In the Claim rule name field, Enter Get Group.
- Click Browse and find the AD group you created earlier (e.g. dome9-jit-readonly)
- Click the Outgoing claim type drop-down and select Group.
- In the Outgoing claim value field, enter the Dome9 role name that was created above.
- Click Finish.
- Ensure the rule Get Group is last on the list.
If the SSO login still does not work use see below for troubleshooting tips.
Most of the issues are caused due to the wrong configuration.
In order to troubleshoot those issues need to navigate to the Audit trail on Dome9 Console (Audit Trail (v1)).
If the Audit trail contains an SSO Login failed audit it means that most of the configuration is good but maybe failing because of specific configuration errors.
If there is no SSO Login audit it means that the SAML request is not configured to target a valid ADFS environment.
The description will alert on the cause of the failure.
If you see the either of the two Dome9 audit log messages above please verify the following:
- Ensure the Token-signing certificate is SHA256.
- Ensure the Token-signing certificate public key is entered in the Dome9 SSO configuration in Base-64 encoded X.509 format.
- Ensure your Issuer field is correct.
If the Issuer URI field is incorrect your browser will not forward to your ADFS login page, but instead forward you to the standard Dome9 login page. Hence, need to adjust the Issuer field on Dome9 SSO configuration.
- The second audit log entry on response token is invalid, need to validate the certificate is valid, not encrypted and that it wasn't expired.
This Audit mentions that the user that tried to log in using SSO does not exist on Dome9 system.
Usually, this indicates that Relying Party Trust was not created correctly or the associated claim rules were not configured correctly in the Claims Issuance Policy. This could also indicate that the metadata file contains the wrong Account Identifier.
For more assistance contact Dome9 Support.