Single Sign-On (SSO) Management for Enterprise Accounts¶

Note

This feature is coming soon -- please speak to your DomainTools representative.

To enable Single-Sign On (SSO) for your DomainTools enterprise account, follow these two steps (outlined in detail below):

Configure your Identity Provider (IdP) to use DomainTools as a SAML Service Provider (SP).
Configure your DomainTools Group Management account so that the DomainTools SAML Service Provider (SP) can connect to and trust your Identity Provider (IdP).

Configure Your Identity Provider¶

Supported Identity Providers¶

DomainTools supports and provides configuration information (below) for the these Single Sign-On Identity Providers:

SSO Identity Provider	Availability	Suggested Documentation
Microsoft Entra ID	Supported	What is SSO?, How to Enable SSO in Entra
Okta	Supported	Add a SAML Identity Provider
SAML (other)	Supported	SAML 2.0 spec
IBM Security Verify	Coming soon
JumpCloud	Coming soon
Ping Identity	Coming soon

The DomainTools Enterprise Support Team enterprisesupport@domaintools.com works with our customers to build and maintain the required configuration on customer and DomainTools systems.

Configure Microsoft Entra ID as an Identity Provider for DomainTools¶

Note

This section on Entra ID is in early draft form. Consult with your DomainTools representative for more information.

Step 1: Register a New Application¶

Navigate from Home > [Company Name] > Register an application
Select New registration

Step 2: Create Your Own Application¶

Navigate from Home > [Company Name] > Register an application > App registrations > Register an application > Enterprise applications | All applications > Browse Microsoft Entra Gallery
Select Create your own application

Step 3: Single Sign-On¶

Navigate from Home > [Company Name] > Register an application > App registrations > Register an application > Enterprise applications | All applications > Browse Microsoft Entra Gallery > [Application Name]
In the following sections:
- 3. SAML Certificates
  - Download the Certificate (Raw) (filename will be [Application Name].cer)
- 4. Set up [Application Name]
  - Login URL = Your SSO Url
  - Microsoft Entra Identifier = Your Issuer URL

Step 4: DomainTools SSO Configuration¶

Edit your DomainTools SSO configuration:
- SSO Url (step 4: Login URL)
- Issuer URL (step 4: Microsoft Entra Identifier)
- Certificate (step 3: SAML Certificate)
- Email Domains: If your employees use email addresses like alice@acmecorp.com and bob@acme-support.com, you would enter acmecorp.com and acme-support.com.
Save your configuration to get the ACS URL and the Audience URL

Step 5: Basic SAML Configuration¶

Visit 1. Basic SAML Configuration
- Select Edit and fill in:
  - Identifier (Entity ID) = Audience URL
  - Reply URL (Assertion Consumer Service URL) = ACS Url
Save 1. Basic SAML Configuration

Step 6: Log out of DomainTools¶

Step 7: Assess¶

Now, when attempting to log into DomainTools, you should be redirected to Microsoft Entra. If not, log in via password and check that the provided configuration is correct in DomainTools and the ACS/Audience URLs in Entra are correct. Contact enterprisesupport@domaintools.com if redirection is successful but authenticating with Entra fails to restore password-authentication.

Next, configure your DomainTools SSO Service Provider.

Configure Okta as an Identity Provider for DomainTools¶

Step 1: Create App Integration¶

In your Okta Admin Console, select Applications -> Applications --> Create App Integration.

The Group Management page — The group management page.

Step 2: Select SAML 2.0 as the sign-in method¶

Step 3: Create SAML Integration in General Settings¶

Enter "DomainTools" as the App name.
Optional: Upload the DomainTools logo as the App Integration Logo

Step 4: Configure SAML Settings¶

Enter the Single-Sign-On URL (e.g., https://sso.domaintools.com/sso/saml2/unique)
Enter the Audience URI (e.g., https://www.okta.com/saml2/service-provider/unique)
Both the SSO URL & Audience URI (SP Entity) can be retrieved once the configure your DomainTools SSO Service Provider section has been completed. For now enter dummy values and these can be edited later.
Set Name ID Format to EmailAddress.
Set Application username to Email.
Create 3 Attribute Statements for email, firstName, and lastName respectively.
Set Name format to Unspecified.
Incorrectly set or missing Attribute Statements may prevent successful SSO authentication.
Other settings can be left as default.

Name	Name format	Value
email	Unspecified	user.email
firstName	Unspecified	user.firstName
lastName	Unspecified	user.lastName

Step 5: Create SAML Integration - Feedback¶

Okta requires feedback on this page:
Select: I'm an Okta customer adding an internal app
Select: It's required to contact the vendor to enable SAML

Step 6: View SAML Setup Instructions¶

The next page will show the Sign On tab under the DomainTools App Integration you just created.
Click the View SAML setup instructions button under the SAML Setup section on the right hand side.

Step 7: Provide SAML Details to DomainTools¶

The following SAML details from this page are required to complete the configure your DomainTools SSO Service Provider section:
Identity Provider Single Sign-On URL
Identity Provider Issuer
x.509 Certificate

Step 8: Assign the DomainTools App Integration to Users and Groups¶

Return to the Applications page
Open the DomainTools App Integration you just created
Navigate to the Assignments tab
Use the Assign button to assign the application to your desired users and/or groups

Your users still require a DomainTools account, created separately, before they will be able to authenticate and access the products included in your subscription.

Complete SSO Authentication with Self-Serve Configuration¶

Next, configure your DomainTools SSO Service Provider.

How to Configure DomainTools as a SSO Service Provider¶

Configure DomainTools SSO After configuring your Identity Provider.

Do this First: Access the Group Settings Menu in Group Management¶

Navigate to https://research.domaintools.com/group-management/ and select the ⚙️ SETTINGS button

The `Certificate` Field¶

What is a Signing Certificate?¶

A Signing Certificate is a block of base-64 encoded text that acts as a digital signature, guaranteeing that login responses from your Identity Provider (IdP) are authentic and have not been tampered with.

It's the public half of a public/private key pair. Your IdP uses its private key to sign authentication responses, and our application uses this public certificate to verify that signature.

For example:

MIIDazCCA1OgAwIBAgIUR+AzgzLhPe...0Nu43FPPTjZ00Z00/i5j

Where to Find Your Signing Certificate¶

Your IdP provides this certificate. Obtain the Signing Certificate text from your IdP’s admin dashboard, your SAML metadata .xml file, or in a .pem or .cer file.

Either submit the Signing Certificate text, or paste in a .pem or .cer file.

Example from a Metadata File¶

In your SAML metadata .xml file, the certificate is the text inside the <ds:X509Certificate> tag. This tag is usually located within a <md:KeyDescriptor use="signing"> block.

<md:KeyDescriptor use="signing">
  <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ds:X509Data>
      <ds:X509Certificate>
        MIIDazCCA1OgAwIBAgIUR+AzgzLhPe...0Nu43FPPTjZ00Z00/i5j
      </ds:X509Certificate>
    </ds:X509Data>
  </ds:KeyInfo>
</md:KeyDescriptor>

Example from a Certificate File¶

If you have a .pem or .cer file, it will look like this. You can open the file in a plain text editor and copy the entire contents, including the BEGIN and END lines.

-----BEGIN CERTIFICATE-----
MIIDazCCA1OgAwIBAgIUR+AzgzLhPe...
...
...0Nu43FPPTjZ00Z00/i5j
-----END CERTIFICATE-----

The `SSO URL` Field¶

What is the SSO URL?¶

The Single Sign-On (SSO) URL is your organization's dedicated login page. It's the web address where we will send your users to have them sign in with their company credentials. For example:

https://identity.provider/login

Where to Find Your SSO URL¶

Your SSO URL is provided by your Identity Provider (e.g., Okta, Microsoft Entra ID, etc.) and is located in your SAML metadata file.

Locate the tag starting with <md:SingleSignOnService...>, and copy the entire URL from the Location="..." attribute inside that tag.

Finding Your SSO URL: An Example¶

Your SAML 2.0 metadata file (e.g., metadata.xml) will include a block of code like this. Copy the value for Location (within the quotation marks):

<md:SingleSignOnService
  Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
  Location="https://identity.provider/login"/>

The `Issuer URL` Field¶

What is an Issuer URL?¶

The Issuer URL, also known as the “Entity ID”, is the unique address for your organization's Identity Provider (IdP). It acts like a permanent ID card, ensuring our systems are communicating with the correct and trusted login service.

This URL must be publicly accessible and should point to your SAML metadata file. For example:

https://identity.provider/saml/metadata

Where to Find Your Issuer URL¶

Your Identity Provider supplies your Issuer URL. It's a fundamental piece of every SAML configuration and can typically be found in your IdP's admin dashboard, often labeled "Entity ID" or "Issuer".

Once you have your SAML metadata file, you can also find or verify it there.

Finding your Issuer URL: An Example¶

In your metadata .xml file, this URL is the value of the entityID attribute, located in the main <md:EntityDescriptor> tag near the top of the file:

<md:EntityDescriptor
    xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    validUntil="2027-01-20T19:04:25Z"
    cacheDuration="PT1485371065S"
    entityID="https://identity.provider/saml/metadata">

This file typically acts as a complete configuration sheet for your login service. It should also contain additional key values required for this setup:

The Signing Certificate, located in the <ds:X509Certificate> tag.
The SSO URL, located in the <SingleSignOnService> tag.

The `SSO Binding` Field¶

What is a SSO Binding?¶

The SSO Binding is a string of text that determine the HTTP method that will be used to send authentication requests to your SSO URL. For example:

urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect

It typically corresponds to one of two options:

HTTP-Redirect: Sends the request information in the URL itself (a GET request).
HTTP-POST: Sends the request information in the body of the request.

Your Identity Provider (IdP) dictates which method it supports. You must select the option that matches your IdP's configuration.

Where to Find the SSO Binding¶

This value is provided by your IdP and can be found in your SAML metadata file. It is located in the same tag as your SSO URL. For example:

<md:SingleSignOnService
  Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
  Location="https://identity.provider/login"/>

The `Allowed Email Domains` Field¶

What are Allowed Email Domains?¶

This field uses the domain name in users' email addresses to identify them as part of your organization and route them to your correct SSO login page.

Enter all the email domains that your employees use for their company accounts. When a user tries to log in, we will look at the domain in their email address to identify them as one of your users.

How to Enter Your Domains¶

List one or more domains, separated by commas (do not include the @ symbol).

For example: If your employees have email addresses like alice@acmecorp.com and bob@acme-support.com, you would enter:

acmecorp.com
acme-support.com

Why is this Required?¶

While not part of the core SAML specification, this routing information is essential for our system to act as a Federation Broker. It allows us to support multiple customers securely, ensuring that only users from your specified domains are directed to your organization's private login page.

Troubleshooting¶

HTTP 400 Error¶

A HTTP 400 error is often accompanied with the warning 400: Bad Request Error Code: GENERAL_NONSUCCESS.

The screenshot below shows a HTTP 400 error message that may be received when authentication via SSO is not successful.

HTTP 400 - General Nonsuccess — 400: Bad Request Error Code: GENERAL_NONSUCCESS.

The most common cause of such authentication failures is incorrect or missing Attribute Statements. They must be set exactly as detailed in the table (and displayed in the screenshot) under Step 4 in this guide, otherwise users will be unable to authenticate with SSO.

Another possible cause of the same error is incorrectly copy/pasting the Audience URI and/or SSO URL values during Step 4.

If users login directly through sso.domaintools.com instead of a product landing page, they will be redirected to the below screen:

In such cases, navigate to https://research.domaintools.com to access your subscription as normal.

Last modified: July 24, 2025