Skip to content
Avanet

Deploy the Sophos ITDR Sensor for on-premises Active Directory

Sophos ITDR

The Sophos ITDR Sensor connects an on-premises Active Directory environment to Sophos ITDR. You install it on a supported Active Directory server, where it uses a read-only service account to read the selected domains. After the initial full synchronization, it sends only incremental changes to the Sophos Cloud.

Follow this secure deployment sequence:

  1. Prepare the server, resources, service account, and outbound connections.
  2. Create the integration under Identity > Settings > Integrations.
  3. Securely capture the API credentials, which are displayed only once.
  4. Install the sensor and configure LDAP, domains, filters, and the schedule.
  5. Start the initial full synchronization.
  6. Confirm Health: Healthy, Status: Enabled, and the expected directory data.

Prerequisites and limitations

Before you deploy the sensor, you need:

  • administrative access to Sophos Fusion with the Sophos Fusion Administrator role;
  • an Active Directory server running one of the supported versions:
    • Windows Server 2016,
    • Windows Server 2019,
    • Windows Server 2022,
    • Windows Server 2025;
  • Microsoft .NET Framework 4.8 Runtime on that server; the sensor does not require the Developer Pack;
  • at least 2 GB RAM; Sophos recommends at least a dual-core processor;
  • the names of every AD domain you intend to monitor, such as CORP.LOCAL and CHILD.CORP.LOCAL;
  • a read-only AD service account;
  • two separate outbound network paths: DNS on port 53 to the internal DNS resolver, and HTTPS over TCP port 443 to the S3 destination names and wildcards listed below.

The sensor is currently available only in English. The on-premises AD integration works independently of a Microsoft Entra ID integration. Without Entra ID, however, visibility and posture assessments are limited to the on-premises AD environment.

The sensor supplies data for Exposure Management and Active Directory identity posture assessments. It does not capture sign-in events or extend MFA enforcement to on-premises systems. It is also separate from the Sophos Central Directory Sync product.

The sensor collects these AD object types:

  • users and groups,
  • computers,
  • Group Policy Objects (GPOs),
  • Service Principals,
  • Certificate Server Templates,
  • Domain Policies,
  • Organizational Units (OUs).

Prepare the server and service account

Choose a supported AD server with sufficient spare resources. Before installation, confirm that .NET Framework 4.8 Runtime is installed. An older .NET version, or an SDK installed for another purpose, does not meet this requirement.

Create a dedicated read-only AD service account for the sensor. Do not use a personal administrator account, and do not grant the service account write permissions or Domain Admin privileges preemptively. Keep its username and password separate from the Client ID and Client Secret. The AD service account authenticates LDAP access, while the client credentials identify the sensor to Sophos ITDR.

Document the following in advance:

  • the sensor host and Windows Server version,
  • the installed .NET Framework version,
  • all intended AD domains,
  • the read-only service account in use, but not its password,
  • the approved outbound destinations,
  • the planned installation and validation window.

Create the integration in Sophos Fusion

  1. In Sophos Fusion, open Identity > Settings > Integrations.
  2. On the On-Premise Active Directory card, select Set Up.
  3. Complete both fields:
    • Name the directory service: Enter a unique display name, such as Production AD.
    • Active Directory domains to monitor: Enter a comma-separated list of AD domain names, such as CORP.LOCAL, CHILD.CORP.LOCAL.
  4. Select Next. Credential generation can take several minutes.
  5. In API Credential Summary, verify every displayed field:
    • Name: the display name you entered,
    • Domains: the specified AD domains,
    • Client ID: the automatically generated sensor ID,
    • Client Secret: the automatically generated sensor secret.
  6. Select Download client secret, or copy Client ID and Client Secret with their respective Copy icons.

Save the values immediately in an approved secrets store. When copying them, make sure you do not introduce leading or trailing spaces. After installation, remove temporary plaintext copies and clear clipboard contents according to your internal process. Never include the secret in screenshots or support documentation.

Set a reminder well before the API credentials expire after 36 months. There is no documented procedure for changing or renewing them. Contact Sophos Support before they expire to confirm the supported process.

Install and configure the sensor

  1. Select Download ITDR Sensor to download the installer.
  2. Transfer it to the designated Windows Server through your approved software distribution channel.
  3. Run the installer and follow the Setup Wizard.
  4. When prompted, enter the Client ID and Client Secret from API Credential Summary, then select Next.
  5. Configure the LDAP settings. Where possible, select LDAP over SSL, which Sophos recommends for secure communication.
  6. Under Service Account, enter the username and password for the read-only AD account, then select Next.
  7. Under Domains, select only the domains that belong to this integration, then select Next.
  8. Keep the default settings under AD Filters. They collect all required object types. Do not introduce restrictions during initial acceptance testing.
  9. Under Sync Schedule, keep the default 1 hour interval and select Finish.
  10. In the communication status window that opens next, select Sync Now to start the initial full synchronization.

The initial synchronization can take several minutes, depending on the size of the Active Directory environment. The sensor then monitors for changes and, by default, sends only incremental updates every hour. You can configure the interval in the sensor, but Sophos recommends the default one-hour interval for timely updates.

Allow outbound network access

If outbound connections are blocked by default, create two separate rules for the sensor:

  1. DNS on port 53: Allow traffic from the sensor host only to the approved or configured internal DNS resolver. Follow the DNS protocol requirements for your environment. Do not allow access to an arbitrary public resolver, and do not allow port 53 to the S3 destinations.
  2. HTTPS over TCP port 443: Allow traffic from the sensor host only to the following pre-signed S3 destination names and wildcards. Use the FQDN or wildcard syntax supported by your firewall or security product.

The documented pre-signed S3 destinations are:

tf-presigned-url-eu-west-1-prod-*-bucket.s3.eu-west-1.amazonaws.com
tf-presigned-url-eu-central-1-prod-*-bucket.s3.eu-central-1.amazonaws.com
tf-presigned-url-us-east-2-prod-*-bucket.s3.us-east-2.amazonaws.com
tf-presigned-url-us-west-2-prod-*-bucket.s3.us-west-2.amazonaws.com
tf-presigned-url-ca-central-1-prod-*-bucket.s3.ca-central-1.amazonaws.com
tf-presigned-url-ap-southeast-2-prod-*-bucket.s3.ap-southeast-2.amazonaws.com
tf-presigned-url-ap-northeast-1-prod-*-bucket.s3.ap-northeast-1.amazonaws.com
tf-presigned-url-ap-south-1-prod-*-bucket.s3.ap-south-1.amazonaws.com
tf-presigned-url-sa-east-1-prod-*-bucket.s3.sa-east-1.amazonaws.com
tf-presigned-url-me-central-1-prod-*-bucket.s3.me-central-1.amazonaws.com

The following wildcards are also documented:

*.s3.eu-west-1.amazonaws.com
*.s3.eu-central-1.amazonaws.com
*.s3.us-east-2.amazonaws.com
*.s3.us-west-2.amazonaws.com
*.s3.ca-central-1.amazonaws.com
*.s3.ap-southeast-2.amazonaws.com
*.s3.ap-northeast-1.amazonaws.com
*.s3.ap-south-1.amazonaws.com
*.s3.sa-east-1.amazonaws.com
*.s3.me-central-1.amazonaws.com

Add the S3 destinations above to the relevant firewall or security policy only as HTTPS destinations for TCP port 443. Do not replace the hostnames with fixed IP addresses. Restrict the rule to the sensor host and document which destinations the policy covers. The separate DNS rule on port 53 terminates at the internal DNS resolver, not at the S3 destinations.

Validate synchronization and health

After setup, validate sensor operation, its status in Sophos Fusion, both network paths, and the directory content that was actually synchronized.

1. Communication and synchronization

  • Sync Now started without a visible communication error.
  • The initial full synchronization was given enough time to complete.
  • Subsequent changes are transferred incrementally at the default one-hour interval.

2. Status in Sophos Fusion

Open Identity > Settings > Integrations. In Configured Integrations, the new integration must show these values:

  • Type: On-Prem Active Directory
  • Health: Healthy
  • Status: Enabled

3. Network path

Validate the two paths separately. From the sensor host, first test name resolution through the internal DNS resolver on port 53. Then confirm that the applicable policy allows HTTPS over TCP port 443 to the S3 destination names and wildcards listed above. Record the test time, sensor host, resolver or destination name tested, and the result. Do not record Client Secrets or passwords.

4. Spot-check the content

After the initial synchronization, compare several known objects from each included domain with the data shown in ITDR. For example, check an active user, a group, and a computer. Also confirm that no unintended domain was selected. Healthy and Enabled confirm the integration state, but they do not replace this content check.

Troubleshoot an Unhealthy status or missing data

Investigate only one suspected cause at a time. After each change, repeat the synchronization and status check.

Health is Unhealthy

Check the following in order:

  1. In Windows, confirm that the ITDR Sensor is shown as running. Use the available Windows interface rather than an undocumented service name or start command.
  2. Were the Client ID and Client Secret entered in full, with no extra spaces?
  3. Can the server resolve the S3 destination names through the internal DNS resolver on port 53? Port 53 terminates at the resolver, not at the S3 destinations. Do not switch to a public resolver.
  4. Does the outbound policy allow HTTPS over TCP port 443 from the sensor host to the S3 destination names and wildcards listed above?
  5. Do the sensor host, integration, and selected AD domains match the installation record?

If you did not save the Client Secret when it was displayed, you cannot retrieve it later. Do not attempt to reconstruct it or create additional credentials without guidance. Stop the setup attempt and ask Sophos Support how to replace the credentials through a supported process.

Health is Healthy but data is missing

  • Allow enough time for the initial full synchronization before treating missing data as an error.
  • Confirm that the missing domain was selected both in Active Directory domains to monitor and under Domains in the Setup Wizard.
  • Confirm that the read-only service account can read the affected objects. Do not increase its privileges preemptively.
  • Check whether the settings under AD Filters differ from the recommended defaults.
  • Start another Sync Now run, then compare the same sample of known objects.

If only recent changes are missing, remember that the default interval is one hour. Do not shorten the schedule as your first troubleshooting step. A manual run is a better way to distinguish a scheduling issue from an underlying read or communication failure.

Installation or communication continues to fail

Provide Sophos Support with only the following non-confidential information:

  • the integration display name and type,
  • the timestamp and affected synchronization run,
  • Health and Status from Configured Integrations,
  • the Windows Server version and confirmation that .NET Framework 4.8 Runtime is installed,
  • the selected domains and whether the default AD Filters settings are in use,
  • the results of the separate DNS-resolver and HTTPS-to-S3 tests,
  • the visible error message as text or in a sanitized screenshot.

Never provide the Client Secret or service account password. No authoritative log paths are documented. Do not submit files from assumed locations; instead, follow a specific request from Sophos Support.

Safely roll back changes

Before installation, document the existing firewall rules and the server’s baseline state. If the deployment affects server operation, do not expand the service account’s privileges or the firewall rules. Stop the setup, restore only the network policies changed during the maintenance window to their documented baseline, and verify normal AD operation again.

There is no documented sensor uninstall procedure, service name, log path, manual certificate process, or authoritative procedure for replacing or rotating the API credentials. There is also no documented statement about data retention after an integration is removed. Do not rely on assumed commands or paths. If you cancel the deployment, replace credentials, uninstall the sensor, or offboard the integration, ask Sophos Support to confirm the procedure supported for your version.

Do not remove a working integration as your first troubleshooting step. Retain a record of the baseline, without secrets, so that support staff and operations teams can trace the last known working state. Deployment is complete only after you have confirmed Healthy, Enabled, both network paths defined above, and the checked directory content.