Synchronise Active Directory with Sophos Central

Sophos Central can import users and groups from an on-premises Active Directory. These identities are used for policy assignment and device association, among other purposes. However, an uncontrolled synchronisation can create unnecessary accounts, duplicate objects or unexpected deletions.

Microsoft Entra ID is synchronised through a separate connector. Instructions are available in Synchronise Microsoft Entra ID with Sophos Central.

Define the source model before installation

Central can manage up to 25 directory sources per tenant. A Central Enterprise structure is intended for more sources. Users and email addresses must remain unique within a Central tenant. The same domain must not supply users through multiple AD, Entra ID, or Google Directory sources at the same time.

For a trial, Sophos also limits the number of Directory Objects that can be created or used, including users, devices, and groups. An incomplete test import is therefore not automatically a filtering error. Review the trial scope, expected object count, and licence status together before a pilot.

Multiple child domains can be selected within a forest, and a tenant can also synchronise multiple forests. Sophos nevertheless recommends connecting each forest to only one Central tenant. If the same forest is imported into multiple tenants, or if multiple forests contain the same users or email addresses, successive runs update the same apparent identities alternately from each source. Central does not merge these records, so names, attributes, and group assignments can become inconsistent.

A supported mixed model, by contrast, is useful: AD synchronises computers and computer groups, while Entra ID supplies users and user groups for the same domain. Shared Mailboxes in a Microsoft 365 group require Entra ID or Google Directory. AD Sync can import a normal Shared Mailbox outside a Microsoft 365 group.

Shared Mailboxes and Public Folders in the same domain as the users require AD Sync Utility together with Sync users and user groups. Microsoft 365 group mailboxes aren’t imported through AD Sync. A Shared Mailbox without a delegate isn’t synchronised either. If an inactive user mailbox with mail delegation to an active mailbox remains in place, AD Sync doesn’t delete it and can continue to manage it in Central as a Shared Mailbox.

Run only one production AD Sync client for the same domain or subdomain. Multiple AD devices must also not have the same DNS hostname, because Central then can’t match them unambiguously. When changing servers, stop the old schedule before the new instance starts production synchronisation.

If the Self Service Portal will be used for Sophos Email, Device Encryption, or Mobile, enable user access before the first Directory Sync. This gives new and existing users the intended invitation. The procedure is described in Set up Sophos Central Self Service Portal access.

AD Sync limits and cross-domain groups

AD Sync does not merge data from multiple forests or Directory Services into a master record. The same user or email address must therefore not occur in more than one synchronised forest. Duplicate users, email addresses, or groups can be updated alternately with data from their respective source during each run and can even change the Directory Owner shown in Central. Users and email addresses remain unique per tenant; users in the same domain must not be synchronised from both AD and Entra ID or supplied to multiple Central Admin Accounts in parallel.

For a group with members from several domains, Central imports only users from the domain to which the group belongs. Preview and Sync can show all members, but users from the other domain aren’t added to the group during production synchronisation. Test this behaviour for Universal Groups and child domains with one test member per domain.

Users and user groups are synchronised together or turned off together. The same applies to devices and device groups. A maximum of 1'000 filters is supported per Directory Object, and additional LDAP filters can be no longer than 5'000 characters. Domain labels longer than 63 characters or starting or ending in - or _ aren’t supported.

Microsoft 365 group mailboxes require Entra ID. AD Sync doesn’t support a Shared Mailbox without a delegate, multiple production AD Sync clients for the same domain or subdomain, or multiple AD devices with an identical DNS hostname. An inactive mailbox delegated to an active mailbox, however, can remain as a Shared Mailbox. Treat these limits as design decisions before the first run, not as problems to bypass later with broader filters.

Clean up inactive AD objects before syncing

Where possible, review and remove or disable inactive user accounts and devices directly in Active Directory. They not only increase the Central inventory but also remain a security risk in the source. Cleanup also reduces the sync file transferred to Sophos Central and can speed up the run.

LDAP filters can prevent inactive users from reaching Central and also reduce the sync file. However, they don’t remove the risk of an inactive AD account that still exists. The operating process therefore combines a defensible inactivity period, owner approval, source cleanup, and a subsequent preview run. Review devices separately for age, last domain contact, and protection status before removing a computer account.

Manage Directory Sources in Central

The central overview is under Global Settings > Platform > Directory service. An appropriate Central administration role is required to set up and manage a source. Depending on the required source, the page provides Add Active Directory, Add Microsoft Entra ID, and Add directory service for Google. Download the current setup software for on-premises AD from here; authorise Entra ID and Google through their respective cloud connectors.

For each entry, the source list shows its name, type, domain, schedule, and status. Check warnings or errors not only in this overview but also under Alerts and Reports > Logs > General Logs > Events. A green source status alone isn’t sufficient if the last run is out of date or the expected object count is wrong.

Select the name to open the details. For AD, check in particular the number of users, groups, devices, device groups, Public Folders, and Shared Mailboxes, as well as the hostname, client version, domain, status, and time of the last sync. For Entra ID and Google, focus on user and group counts, status, last run, and schedule. Compare these values with a known reference set after initial setup and after every filter or source change.

Depending on the source type, the details also allow changes to configuration and filters, purging of synchronised data, and deletion of the source. These are different actions: Purge removes directory data imported from this source, while Delete also removes the Directory Source. For AD, first stop sync options and running clients; for Entra ID and Google, use their respective filter, purge, and delete dialogs. Before either action, export affected users, groups, devices, policies, and mailboxes and read the consequences stated in Central. Purge or Delete isn’t a non-binding connection test and must not be confirmed without a rollback plan.

A source’s name and description can be changed only after it has been disabled with Turn off. After saving, enable it again with Turn on and verify it. Turning it off interrupts updates, so don’t do this during an unreviewed directory change. Once production synchronisation has been enabled for a source, that step can’t simply be reversed. For a manual run, open the source and select Synchronize, then review the status, time, and object changes.

Plan Self Service and Shared Mailboxes before syncing

If a user will use the Self Service Portal, enable User Access before the first Directory Sync. This allows Central to send invitations as intended. Enabling access later doesn’t automatically correct every previously missed delivery, so test pilot users, mail delivery, and portal access before the broad import.

Shared Mailboxes in Central don’t necessarily have complete user attributes. Delegated users receive Self Service access for their assigned Shared Mailbox and, depending on the licensed product, can see features such as Emergency Inbox and Quarantine Summary. A delegate can therefore receive summaries for their own mailbox and additionally for the Shared Mailbox. Test delegations and delivery addresses in practice after the sync rather than accepting them solely on the basis of the object count.

A Shared Mailbox within a Microsoft 365 group can’t be synchronised through on-premises AD; use Microsoft Entra ID or Google Directory. AD Sync can import a normal Shared Mailbox outside a Microsoft 365 group. Before a later migration to Entra ID, inventory which mailbox comes from which object type. Otherwise, continued AD synchronisation after the source change can remove mailboxes or leave them at an outdated state.

Before the first sync

First define which directory is authoritative for which users and groups. The same people should not be created manually and imported from both AD and Entra ID at the same time.

For the first run, use a small test OU containing representative users and groups. Check:

• email addresses and User Principal Names,
• nested groups and memberships,
• disabled or obsolete accounts,
• service and technical accounts,
• naming conflicts with existing Central objects.

Every user to be synchronised requires a unique email address. Many Central workflows use it as an identity and delivery target; with Sophos Email, a message to an address without an assigned user can even be undeliverable. The firewall or proxy must also be able to reach the domains and ports documented for Central. A successful LDAP test alone doesn’t confirm this cloud path.

Install AD Sync Utility

Download the current synchronisation software directly from Sophos Central and install it on a permanently available Windows system. The system requires network access to the domain controller and the required Sophos services.

The current Active Directory Synchronization Setup Software runs only on a 64-bit Windows system and requires .NET Framework 4.6.2. Sophos lists Windows 7, 8.1, 10, and 11, as well as Windows Server 2008 R2, 2012, 2012 R2, 2016, 2019, 2022, and 2025. Sophos lists Windows Server 2008 R2 through 2025 as domain controllers. This vendor compatibility doesn’t replace the Microsoft lifecycle: use a currently supported and patched server operating system for a new production installation, not Windows 7 or an end-of-life Windows Server release.

For Central access, use API Credentials with the Service Principal Active Directory Sync role rather than general Super Admin credentials.

The AD service account receives only the permissions required to read the selected forests and directory objects. Document password expiry, service startup and ownership. A personal administrator account is unsuitable.

The utility can’t process a domain if a single label in its name is longer than 63 characters or starts or ends with - or _. Check this limit before installation because a shortened display name or different UPN doesn’t fix an invalid AD domain name.

Sophos has tested up to 30'000 AD objects. Above 40'000 user records, the interface may respond more slowly. Larger environments therefore require particularly strict filtering and tests with realistic runtimes.

During every synchronisation run, the utility checks whether a newer version is available and normally performs subsequent upgrades automatically. Early AD Sync versions no longer support current Central authentication and can fail completely if this automatic upgrade doesn’t work. In that case, download the current installer under Global Settings > Platform > Directory service and run it over the existing installation. Then create new API Credentials with the Service Principal Active Directory Sync role and enter them in the utility as the Client ID and Client Secret. Each production sync instance needs a traceable technical identity, documented ownership, and its own secret rotation.

At startup, verify the Client ID and Client Secret with Validate credentials. If the utility must communicate through a proxy, enable Configure proxy manually and enter the proxy address. If the proxy requires authentication, also configure Enable proxy authentication, the proxy user, and the proxy password. Only a successful second credential test confirms that both the API credentials and the proxy path work.

This proxy form belongs to Active Directory Synchronization Setup 4.0. A trial tenant may instead still receive the older Sophos Central AD Sync Utility 3.5.4, which has no UI for proxy details. By default, its service runs as Local Service and often fails at an authenticating proxy with Failed active directory synchronization, a System.Net.Http.HttpRequestException, and CommandLib.HttpRequestCommand+HttpStatusException. An alternative service account used for this purpose requires Log on as a service, interactive and batch sign-in, read access to the affected OUs, and full control over C:\ProgramData\Sophos\Sophos Cloud AD Sync. Reconfigure the old utility after every change of this service account. Use the current 4.0 software for production environments wherever possible.

For LDAP access, use a read-only account for the entire selected forest. Keep Use LDAP over an SSL connection enabled wherever possible. LDAPS usually uses TCP 636 and unencrypted LDAP TCP 389. Because of LDAP Signing and Channel Binding, port 389 isn’t a dependable workaround in current Active Directory environments. For LDAPS, the domain controller requires a valid certificate trusted by the sync system.

If the specific LDAP environment demonstrably doesn’t support SSL, Use Secure LDAP can be turned off and the port changed to the appropriate unencrypted LDAP service. This is a documented fallback, not a best practice. Credentials and directory data are then not protected by TLS in transit, so treat segmentation, the network path, and a timely move to LDAPS as risks.

What the utility expects in the forest

For a complete forest, AD Sync reads rootDomainNamingContext with the Distinguished Name of the forest root domain and defaultNamingContext with the Distinguished Name of the server in use at the root of the directory tree. Under CN=Partitions,CN=Configuration,<rootDomainNamingContext>, the utility expects entries with netBiosName, dnsRoot, and nCName for the relevant naming contexts. The value of nCName determines the additional search areas unless it is a parent Distinguished Name of the server specified in the setup form.

If one of these attributes is missing or the service account can’t read the Configuration partition, a login test can succeed while forest discovery or the later sync still fails. In that case, verify the values with LDP.exe under the same service account before changing filters or Central objects.

Filter OUs and objects

Filters limit the scope of synchronisation. Include only the OUs, users and groups that Sophos Central actually requires. A broad import from the root is rarely appropriate.

Before importing, use the preview to check which objects would be added, changed, or removed. Deletions in particular must not be approved without review. The Preview or Pending Changes view may display UTF-16 or double-byte characters incorrectly, showing ???, for example. The data is nevertheless transferred to Sophos Central and displayed there. Therefore, additionally verify names in languages such as Chinese, Japanese, or Korean directly in Active Directory and in Central after a controlled pilot sync.

Sophos describes this preview issue as a limitation that is to be fixed in a future version of AD Sync Utility. Until the deployed version demonstrably corrects it, checks in the source directory and after the sync remain necessary.

Base DN and LDAP filter serve different purposes. Base DN limits the search to selected OUs; OU membership can’t be expressed reliably as a normal LDAP filter alone. The LDAP filter limits attributes or group membership within that search space. Maintain both per domain because child domains don’t inherit the parent domain setting. User and group filters also work independently.

On the AD Filters tab, configure Search Bases and LDAP Query Filters separately for each domain and, where required, separately for users and groups. A Search Base for a Finance OU can look like this:

OU=Finance,DC=myCompany,DC=com

A user filter for members of a group can look like this:

memberOf=CN=testGroup,DC=myCompany,DC=com

Without an additional group filter, Central continues to discover every group to which these users belong. To restrict group selection to this one group as well, add a group filter such as CN=testGroup. A filter change can move previously synchronised users and groups out of scope and delete them in Central, so always run a complete preview.

Sophos uses these filters as the starting point:

Benutzer: (&(objectCategory=person)(objectClass=user)(!sAMAccountType=805306370)(!userAccountControl:1.2.840.113556.1.4.803:=2))
Gruppen:  (&(objectCategory=group)(objectClass=group))

The user filter selects people with the user class but excludes computer objects through sAMAccountType=805306370 and disabled accounts through the corresponding userAccountControl bit. Combine additional filters per domain with these base conditions and test them first with LDP.exe.

Sophos limits the configuration to 1'000 filters per Directory Object and 5'000 characters per additional LDAP filter. Users can be synchronised only together with user groups, and devices only together with device groups. For cross-domain groups, the preview shows all members, but Central imports only users from the domain to which the group belongs. Test such groups explicitly before production synchronisation.

Verify the expected result with Microsoft LDP.exe: AD Sync’s Search Base corresponds to Base DN, and its LDAP expression corresponds to Filter. This distinguishes an omission by Sophos from an object already absent in the directory query. Some attribute comparisons can be case-sensitive.

Use filters based on lastLogon or lastLogonTimestamp cautiously. Although lastLogon is usually more current, it isn’t replicated between domain controllers; obtaining a reliable value would therefore require querying every domain controller. lastLogonTimestamp is replicated but may be outdated. Sophos recommends removing inactive accounts and devices at the source instead of relying solely on a time filter.

If lastLogonTimestamp is nevertheless used as a transitional filter, first define a UTC cutoff and convert it to Windows FILETIME with a trusted LDAP or Active Directory FILETIME converter. The Sophos example cutoff of 1 December 2020 at 00:01 produces 132581431640000000. In the Custom Filters field under Active Directory Synchronization Setup > AD Filters, enter the additional LDAP expression:

(lastLogonTimestamp>=132581431640000000)

Don’t reuse the example value unchanged. Choose the actual cutoff deliberately, convert it correctly, and document it together with the time zone and change approval. Then run Preview and Sync, review included and excluded users, and only then approve the production run.

AD Sync creates only groups with more than one member. An empty group or a group with exactly one member therefore doesn’t appear as the expected Central object. Duplicate users or email addresses across several forests aren’t merged, so an object’s source can change between runs. Where possible, synchronise each forest with only one Central tenant.

Exclude disabled user accounts is enabled by default. It must remain enabled to synchronise Shared Mailboxes. If disabled, Central can create duplicate mailbox objects for Shared Mailboxes. Regardless of this option, clean up ordinary disabled user accounts at the source rather than reintroducing them through a broader sync.

The data type switches have specific dependencies:

• Sync users and user groups synchronises both together and also includes normal Shared Mailboxes. If it is turned off, neither Shared Mailboxes nor Public Folders can be synchronised through this AD source.
• Sync public folders additionally requires Sync users and user groups because Public Folders are treated as mailbox objects.
• For devices, Sync devices and Sync organizational units are enabled together during normal operation. During initial setup, only the OUs can be imported first so that policies are ready before the devices.
• If only Sync organizational units is later turned off, the devices remain active but the existing OUs appear as Custom Groups. If only OU synchronisation remains active, devices are no longer assigned to the Central groups.

Without prepared OU groups, newly synchronised devices initially receive the Default Policies. After the OU pilot, enable both device switches together and verify both the assignment and the policy actually applied.

For very large groups, the AD attribute member also matters. From 1'500 entries, Active Directory uses range retrieval such as member;range=0-1499 and leaves the simple member attribute empty. A group already containing more than 1'500 objects before the first sync can consequently be missing or show an incorrect member count in Central. Keep such groups below 1'500 user objects where possible and verify them with LDP.exe.

User matching and email aliases

Central matches AD users with existing users through the domain login in the format DOMAIN\user or through the mail attribute. The display name comes from Display name, and additional email aliases from proxyAddresses. On a match, the existing Central object becomes directory-managed; without a match, a new user is created. Preview and Sync shows matches under Users to Modify and new objects under Users to Add.

An object synchronised by another Directory Service isn’t created as a second new user on a match, but it can receive an additional email address from AD. A manually created user and an AD user with the same name can, however, remain as two separate objects if their login and email don’t match. The display name alone isn’t a matching key.

In Preview and Sync, review matches under Users to Modify and new identities under Users to Add individually. Reject an incorrect assignment instead of accepting the entire proposal with Approve Changes and Continue. The directory icon also shows when a manual user changes to an AD-managed object.

If a user is removed from AD, Central’s behaviour depends on the user’s dependencies. Administrators and users with an assigned device or login remain as normal Central users. A user without a device, login, or privileged role, by contrast, can be removed automatically. For the same protective reason, changes to a Central administrator’s email aren’t imported blindly from AD. Therefore, review administration roles and device associations separately before offboarding.

To change the primary email address of a directory-managed administrator or remove their remaining Central object after deletion from AD, revoke the administration role in a controlled manner before the next sync. The required role can be assigned again after synchronisation. Always retain a second functioning Super Admin as a recovery path during this procedure.

Incorrect name caused by overlapping logins

If user A also has user B’s device login by mistake, AD Sync can initially assign both logins to A and later rename the existing record to B when B is processed. Under Logins for the affected Central user, remove all foreign assignments and then synchronise again. Don’t simply rewrite names while the incorrect login remains.

A role cannot be assigned to an AD user

First search for the email address under My Environment > Users & Groups > Users. For duplicates, document the logins of the objects that won’t be used, remove them there through Edit logins, and add them to the correct user. Only then save the role and verify that the setup email is sent. If the email address remains blocked across the tenant, don’t continue deleting objects; resolve the conflict through the support process.

Interpret nested groups correctly

The user page can show parent nested groups as linked groups in addition to the direct AD group. This doesn’t automatically mean that the user is a direct member of every group shown. For permission and policy analysis, review direct AD membership, nesting, and the Central policy actually applied separately.

Associate a Mac login with the synchronised user

AD Sync imports a login as NETBIOSDOMAIN\user, while a Mac often reports it as MACNAME\user. Central can therefore create a second user object automatically. After checking the affected devices, clean up this object and assign MACNAME\user to the AD-synchronised user. For a larger rollout, test the Sophos domain override instead of relying on manual remediation.

Synchronise computers and OU groups

Device discovery supports Windows computers and servers. Sophos matches a protected device to the AD object using its FQDN and hostname, then moves it into the synchronised OU group. A computer previously assigned to a group manually can therefore return to the AD structure during the next sync.

Central creates a new device or group object if it doesn’t yet know an entry with the same AD ObjectGUID. If the name of a new AD group conflicts with an existing group, Central uses the Distinguished Name for the new group. Multiple AD records with the same DN aren’t supported.

For matching, both FQDN and hostname must match. If a Central device exists with the domain and hostname but different stored details, the sync updates this information and moves the device into the appropriate AD group. If two devices have the same FQDN, the previously associated device object is disconnected and the new record is linked. Therefore, clean up duplicate hostnames before synchronisation instead of treating the resulting reassignment as random device loss.

OUs are synchronised before devices so policies can first be prepared on the intended groups. Synchronised devices and groups can’t be reorganised permanently in Central contrary to the AD structure. A hierarchy deeper than 40 levels is merged at level 40.

Synchronised devices and groups can be moved or deleted in Central but can’t be edited like local objects. Such manual changes aren’t permanent: the next sync restores the AD structure or recreates the object. If a protected device is deleted in AD, Central moves it to an unstructured group during the next run and removes its AD-managed designation. Changes to names, operating system details, or the OU structure are also imported during the next sync, including moving and removing groups.

Policies on manually created groups are retained. However, AD-managed devices are moved from these groups into the synchronised group and initially receive the Default Policies there unless an appropriate policy was assigned beforehand. A policy on a top-level group is inherited by a nested group as long as no separate policy assignment exists there. Therefore, synchronise OUs first, assign policies, and only then import the devices.

Sophos currently doesn’t provide an API for AD-synchronised Directory Devices and Device Groups. Automations must therefore not assume that this structure can be managed completely through the API like normal Central groups.

Under My Environment > Unmanaged devices, computers and servers known from AD appear in separate views without a Sophos agent. The required protection packages are available under My Environment > Installers. However, this inventory view doesn’t install protection; every expected device remains in the rollout or exception process until the agent is installed or a documented exception is approved.

Schedule and monitoring

The sync schedule must match the organisation’s rate of change. After every run, check the status, errors and object changes. A successfully started service does not prove that all objects were synchronised correctly.

Resolve warnings about credentials, connectivity, missing attributes or object conflicts promptly. Operations require a named owner and a deputy.

On the first run and after every filter change, start Preview and Sync manually. Review the preview for new, changed, and deleted objects and only then confirm it with Approve Changes and Continue. A manual run can take up to 15 minutes. To allow only controlled manual runs, select Never. Only sync when manually initiated in the schedule.

Runtime logs are stored under:

C:\ProgramData\Sophos\Sophos Cloud AD Sync\Logs\

They rotate across seven daily files. Copy or rename a required log before its next rotation. A medium-severity email alert often contains only the summary; find the concrete cause in the log for the same time window.

When replacing the AD Sync server, never run an uncontrolled second instance at the same time. First stop the schedule on the previous server. Then configure the current utility on the new server, compare the existing filter configuration, and verify it with Preview and Sync. Only after a successful manual run should the schedule be enabled there and the old installation removed.

Deletion and rebuilding

Removing an object from the source directory or excluding it through a filter can affect the corresponding Central object and its policy assignments. Before a bulk change, read and document the actions announced in the interface.

Deleting the sync configuration or synchronised data is not a normal troubleshooting step. First check device associations, group memberships and possible duplicates. Rebuilding without analysis can reproduce the same problems.

Before selecting Purge data, stop all running or copied AD Sync instances and check the filters, otherwise the data will reappear. Purge cannot be undone. Managed devices and their associated users, and administrators, are not removed even when they originally came from AD.

Purge synchronised AD data

The executable procedure starts under Global Settings > Platform > Directory service. Open the name of the AD source, stop it with Turn off, and select Purge data. In the dialog, deliberately select the data scope to remove:

• Users and user groups also removes the synchronised Shared Mailboxes and Public Folders.
• Devices and device groups removes the synchronised device and group inventory, except for the protected objects identified by Sophos.

After confirming that the action is irreversible, select Purge data again. Central deletes the selected inventory and doesn’t synchronise that data type again from the stopped source. If all AD data was removed, users, devices, and groups must subsequently be managed manually or through a new, clearly separated source. Microsoft Entra ID can take over users and user groups, for example.

Before the purge, locate and stop all copies of AD Sync Utility and their schedules. Filters alone don’t prevent the data from returning if a second instance continues to synchronise. Afterwards, review the remaining administrators and the managed devices and their assigned users, because Central doesn’t delete these exceptions.

Move from AD to Microsoft Entra ID

Sophos supports moving user and group synchronisation for a domain from AD to Entra ID. A suitable AD and Entra source for the same domain must already exist, and users in both sources must match reliably. Unmatched AD users may be removed from Central during the migration.

Entra ID does not synchronise computers or computer groups. If these are still required, AD remains active for devices while Entra ID supplies users and user groups for the same domain. Public Folders and existing Shared Mailbox assignments have further restrictions and are checked separately before migration.

The migration starts with an export and comparison list, not by immediately switching the source. If users match between AD and Entra ID, Central updates the existing object and retains associated mailboxes. Unmatched users can be removed together with their mailbox assignment; new Entra users are created as new objects. Unmatched user groups remain in place but are no longer updated.

Shared Mailboxes and Public Folders require particular attention. Central retains existing AD Shared Mailboxes with their last AD data but no longer updates them through AD. New Entra Shared Mailboxes can appear in addition. Public Folders also remain at their last state. If the old on-premises AD synchronisation continues to be used for these objects after migration, differing object types can unexpectedly remove Shared Mailboxes.

Afterwards, review users, groups, policies, device assignments, Shared Mailboxes, Public Folders, and duplicates. If AD remains active for devices, continue to operate Sync devices and Sync organizational units together there.

Prerequisites and migration decision

AD and Entra ID must represent the same domain. Before migration, compare users by unique email addresses and other matching identity attributes so that Central updates existing accounts instead of deleting and recreating them. Fully prepare the Entra connector and its app permissions before turning off the AD source.

Public Folders, computers, and computer groups continue to come only from AD. Therefore, decide for each domain whether Entra ID alone is sufficient or whether AD must continue to operate in parallel for devices and OU structures. Additionally, classify Shared Mailboxes as AD, Entra, or Microsoft 365 group objects.

Use Microsoft Entra ID only

This approach is suitable if Central no longer needs to update devices, device groups, or Public Folders from on-premises AD.

1. Complete a final AD sync and validate users, groups, mailboxes, and errors.
2. Under Global Settings > Platform > Directory service, open the AD source and disable it with Turn off.
3. Use Add Microsoft Entra ID to configure the Entra source for the same domain and grant the required app permissions.
4. Start Entra synchronisation and compare users, groups, and Shared Mailboxes with the export and comparison list.
5. Only after acceptance, uninstall the local AD Sync Setup Software and revoke its API Credentials after a documented review.

Turning off the old source is a controlled migration, not a troubleshooting reset. If unexpected deletions occur, don’t continue synchronising by repeatedly turning the source off and on; analyse the matching report first.

Use Microsoft Entra ID and AD in parallel

This model uses Entra ID for users, user groups, and modern Shared Mailboxes, while AD supplies devices and device groups.

1. Run the existing AD sync completely and validate the starting inventory.
2. In AD Sync Utility, restrict the selection to Sync devices and Sync organizational units; users and user groups will no longer be supplied from AD.
3. Temporarily disable the AD source in Central with Turn off.
4. Add Microsoft Entra ID for the same domain, synchronise, and validate users, groups, and Shared Mailboxes.
5. Enable the AD source again with Turn on, synchronise it manually, and verify that devices and device groups continue to be updated without reimporting users from AD.

Give both sources separate owners, schedules, and acceptance figures. A green status for both connectors still doesn’t prove that their object scopes are cleanly separated.

Effects on users, groups, mailboxes, and devices

For matching users, Entra ID updates the existing Central object; associated mailbox information is retained. An AD user without a matching Entra record can be removed from Central together with their mailbox assignment. New Entra users are created as new Central users with the available mailbox data.

Matching user groups are updated. AD groups without an Entra counterpart remain visible in Central but receive no further updates from AD. New Entra groups are created. These remaining groups aren’t proof that synchronisation still works; therefore, review policy assignments and memberships separately.

Existing Shared Mailboxes and Public Folders previously supplied by AD remain at their last AD state but are no longer updated. Such Shared Mailboxes remain visible under Mailboxes but may have no assigned users after the migration. New Entra Shared Mailboxes can appear both as a user object and under Mailboxes, and they can also arrive without the delegate assignment known from AD. Therefore, validate delegated access and quarantine summaries again. If the old AD synchronisation continues uncontrolled after migration, differing object types can remove existing Shared Mailboxes.

In the Entra-only model, existing AD devices and device groups initially remain in Central but are no longer updated from the directory. In the parallel model, AD continues to synchronise these objects. Entra ID itself doesn’t supply computers, computer groups, or Public Folders. Explicitly document this effect in the migration decision so that a static inventory isn’t mistaken for current synchronisation.

Move existing endpoints to a new AD domain

If only the AD domain changes while the computer name and SID remain the same, the Sophos agent doesn’t need to be reinstalled. Its machine_id remains unchanged. First change the AD Sync configuration to the new domain under Global Settings > Platform > Directory service, validate the credentials, and synchronise users, groups, OUs, and devices. Only then should the endpoints check in with Central.

Because of the new FQDN, Central removes the old AD assignment and searches for the matching device object in the new domain. On a match, the same endpoint object is linked again and, if OU synchronisation is active, moved to the correct group. User logins, by contrast, change from OLDDOMAIN\jsmith to NEWDOMAIN\jsmith, for example, and can create duplicates.

The acceptance check covers the new domain, OU group, applied policies, and user assignment. Only then remove obsolete device, user, group, or Directory objects from the old domain.

Common problems

User appears twice

Compare the sources, email address, UPN and existing manually created objects. Do not hastily delete either object while devices or policies are still associated with it.

New group is missing

Check OU and group filters, nested membership, the last successful synchronisation and directory attributes.

0000208D, NO_OBJECT, or “The object does not exist”

This error typically occurs when a Custom Filter still references an OU that has since been removed from Active Directory. The error message doesn’t name the deleted OU. Under Define Filters, therefore check every AD filter against the current directory structure and remove only references to objects that no longer exist. Then run another preview and review the planned deletions.

0xFFFE or 0xFFFF in Preview and Sync

If Active Directory contains characters with the invalid hexadecimal values 0xFFFE or 0xFFFF, the manual run can stop at Preview and Sync. First locate the affected source attribute and correct it at the source. If that isn’t possible in the short term, Sophos names Sync on Schedule - automatic (within next 2-3 minutes) as a targeted workaround because this run skips the preview. This isn’t a permanent correction: immediately afterwards, verify the scope, result, new and removed objects in Central, and the log.

endpoint_user_sessions.user_match_id while deleting a login

Error syncing record: Error deleting login together with a foreign-key reference to endpoint_user_sessions.user_match_id can occur when AD has removed or disabled a user but Central can’t delete the associated login because a session still references it. The remaining sync continues and can finish successfully. If the entry recurs, document the user, login, and time and ask Sophos Support to clean up Central; a full purge or rebuild is disproportionate.

Synchronisation remains out of date

Check the Windows service, service account, password, DNS, proxy, firewall rules and Central sync status. Include sync logs and timestamps in a support ticket.

Since AD Sync Client 5.x, the Audit Log shows the registered client GUID rather than the API credential Client ID as Modified by for directory changes. This applies to create, update, and delete actions. Correlate the GUID with the sync instance, schedule, and log time before treating it as an unknown actor.

LDAP credentials are requested repeatedly

NeedADCredsException together with The LDAP server is unavailable does not necessarily mean a wrong password. Check the domain controller, account format DOMAIN\username, read permissions, and selected port. LDAPS normally uses TCP 636, and the domain controller must actually present a trusted certificate there. A listening port alone does not prove a working TLS configuration.

Escalation to Sophos Support

A reproducible support case contains the error description, tenant and licence, exact period, AD Sync version, all logs, relevant screenshots, and the sync system’s public IP at collection time. Partner cases also need the correct MSP customer assignment. Enable Remote Assistance only for the specific case and after internal approval.

Frequently asked questions