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

Enterprise Support

DomainTools provides dedicated email support to Enterprise customers Monday-Friday 07:00-16:00 hrs Pacific / 14:00-23:00 hrs UTC. Support requests must be emailed to EnterpriseSupport@domaintools.com from an email address associated with an active DomainTools Enterprise account.

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¶

SSO relies on six key pieces of information split between you, the Identity Provider, and us, the Service Provider.

You provide metadata including...

An SSO Url. This is where SSO requests are sent when users attempt to sign in.
An SSO Binding. This specifies if requests sent to the SSO Url should be "Redirect" requests or "POST" requests.
An Issuer Url, sometimes called an Entity ID. This is a URL which uniquely identifies your Identity Provider.
One (or more) Certificate_s, specifically _Trust Certificates. These are used for securing SSO requests and responses.

We provide:

An ACS Url. This is where your Identity Provider will send SSO Responses.
An Audience Url. This is a URL which uniquely identifies us as a Service Provider.

In addition, DomainTools requires users to specify a list of approved email domains. When users attempt to log in, this informs us as to what Identity Provider we should use to identify the user.

Info

If you need our ACS Url and Audience Url in order to generate your SSO Url, reach out to DomainTools support and we can generate those values for you.

Warning

All Identity Providers must be configured to specify at least these three attributes in SSO Responses to identify authenticated users...

firstName
lastName
email

Supported Identity Providers¶

SSO builds on the SAML 2.0 specification, meaning any Identity Provider which adheres to the SAML spec should be supported.

However, DomainTools has documentation 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
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

Critical: User Assignment Required

After activating SSO, all users who need access to DomainTools must be explicitly assigned the DomainTools application within your Identity Provider console. Your users also require a DomainTools account created separately before they can authenticate and access 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.

Start Here: Configure Access¶

DomainTools manages the SSO configuration settings exclusively through the Group Admin page. To gain access to the required Settings option, we offer two flexible options based on your organization's security and procedural preferences:

1. Direct access for IdP Admin¶

The DomainTools Group Admin adds the individual responsible for IdP configuration (the IdP Admin) to the DomainTools Group. You must assign this individual the Admin or Moderator role.

Recommendation: You can grant this as temporary access, solely for the purpose of SSO implementation and initial testing. The DomainTools Group Admin can revoke the role once the setup is complete and successfully validated.

2. Transcribed Configuration¶

An existing DomainTools Group Admin, who already possesses the necessary access, acts as an intermediary. They will receive the essential IdP configuration details (metadata, certificates, endpoints) from your IdP Admin and then manually transcribe (copy/paste) those details into the DomainTools SSO configuration page.

Security Note: This option keeps the IdP Admin external to the DomainTools platform, relying on secure communication between your internal teams.

Activate Configuration Permission¶

Once you have decided which individual will perform the configuration (either the IdP Admin or an existing DomainTools Group Admin/Moderator), the following steps are required to activate their permission to the SSO setup page:

Notify DomainTools of the User: Inform the DomainTools support or account team of the individual(s) who require access to the SSO configuration page. You must provide their full user name and email address.
- Prerequisite: The user must already possess an active DomainTools account and be configured as a Group Moderator or Admin within your DomainTools Group.
DomainTools Activation: DomainTools will then enable this specific user's account with the necessary permissions to access the dedicated SSO configuration page.

Access the Group Settings Menu in Group Management¶

Navigate to https://research.domaintools.com/group-management/ and select the ⚙️ SETTINGS button
In the top-right, select Account > Group Admin > Settings

When filling out the SSO Configuration Settings form, you can select the What's this links below each field for help identifying the required value and how to find it in your Identity Provider's metadata.

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.

Configuration Activation

Your SSO configuration activates immediately when you select Submit. Login enforcement requires a separate step with Enterprise Support (see next section). Ensure all configuration is correct before submitting.

Enable SSO Login Enforcement¶

After you submit your SSO configuration, the SSO functionality is active, but login enforcement is not yet enabled. This allows you to test your configuration with specific accounts before requiring all users to authenticate through SSO.

To enable SSO enforcement:

Test your SSO configuration with designated test accounts using the steps in Testing Your SSO Configuration.
After you confirm your SSO configuration works correctly, contact Enterprise Support at EnterpriseSupport@domaintools.com to request SSO enforcement activation.
In your request, include:
- The email addresses of test accounts where you want enforcement enabled first
- Confirmation that you have successfully tested the SSO configuration
Enterprise Support will enable SSO login enforcement for your specified test accounts.
After you verify that enforcement works correctly on test accounts, contact Enterprise Support again to enable enforcement for your entire organization.

Why Enable Enforcement Separately

Enabling SSO enforcement separately from configuration prevents unintentionally forcing all users to set up multi-factor authentication (MFA) simultaneously. This phased approach lets you validate your SSO setup with a small group before rolling it out organization-wide.

Testing Your SSO Configuration¶

After completing your configuration, test your SSO setup before rolling it out to users.

Test the Redirect to Your Identity Provider¶

Open a private/incognito browser window or log out of DomainTools
Navigate to https://account.domaintools.com/log-in/
Enter an email address with one of your configured allowed domains
You should be automatically redirected to your Identity Provider's login page

If you are not redirected, verify your configuration in both DomainTools and your Identity Provider.

Test Authentication¶

After being redirected to your Identity Provider, authenticate with your credentials
You should be redirected back to DomainTools
You should be logged in to DomainTools

If authentication fails, see the Troubleshooting section below.

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.

HTTP 403 Error¶

A HTTP 403 error typically occurs when you attempt to log in at a legacy endpoint.

If you receive this error, navigate to a primary product page such as https://research.domaintools.com or https://account.domaintools.com/log-in/ instead of using sso.domaintools.com.

Circular Dependency: SSO URL and ACS URL¶

In some cases, your Identity Provider cannot generate an SSO URL until you provide DomainTools' ACS URL, but DomainTools cannot generate the ACS URL until you provide your IdP's SSO URL.

Workaround: Enter a temporary placeholder URL in either system to generate the required values, then update both systems with the correct URLs afterward.

Last modified: July 24, 2025