Connect Active Directory to Sophos Firewall

Active Directory is still the central source for users, groups and authentication in many Sophos Firewall environments. The firewall uses the AD connection for user-based rules, Remote Access VPN, Captive Portal, User Portal, reporting and Single Sign-On scenarios.

This article explains how to add an Active Directory server to Sophos Firewall, which fields really matter and how to validate the connection afterwards. For new Remote Access designs, also decide whether classic AD, RADIUS or Microsoft Entra ID SSO for Sophos Connect and VPN Portal is the better fit.

If Active Directory is the target for an existing eDirectory environment, first plan the controlled eDirectory migration, including group validation, per-service cutover and rollback.

The following Sophos Techvids video shows the basic process as a visual supplement. It was created with SFOS v21; the logic is still helpful, but individual screens may look slightly different in SFOS 22.

The practical process consists of four parts. A successful connection test is only the beginning; VPN, portal, user rules and SSO must be validated separately.

1. Add server: Enter the domain controller, NetBIOS domain, search base and service account correctly.
2. Protect the connection: Plan LDAPS, certificate validation and internal DNS resolution deliberately.
3. Import groups: Import only the required AD groups and understand Main Group.
4. Test usage: Check login, MFA, VPN, User Portal, Captive Portal, SSO and Log Viewer.

Overview

Sophos Firewall can use several authentication sources. Active Directory makes sense when users and groups are already managed in a local Windows domain and the firewall should use these identities directly.

Typical use cases:

• user and group synchronisation from local Active Directory
• firewall rules with user or group criteria
• Remote Access VPN with AD users
• User Portal or Captive Portal with domain accounts
• reporting by user instead of only by IP address
• Active Directory SSO with NTLM or Kerberos

An AD connection does not automatically solve every authentication question. One must distinguish whether the firewall only queries users through LDAP/LDAPS, whether groups are imported, whether SSO is used or whether Remote Access also needs MFA. For MFA basics, see Enable MFA for Sophos Firewall WebAdmin, VPN Portal and Remote Access.

Important decisions before setup

Clarify these points before adding the server:

• Connection: Use LDAPS with SSL/TLS on port 636 where possible.
• Service account: Use a dedicated AD account with read permissions instead of Domain Admin.
• Search base: Search only the required OUs, not the whole domain blindly.
• Display attribute: Choose sAMAccountName, userPrincipalName or displayName deliberately.
• Groups: Import only groups that are really needed for firewall, VPN or portal use.
• MFA: Protect Remote Access and portals additionally with MFA.
• Server order: Set the query order deliberately when using several AD servers.
• Operation: Check auth logs, group import, certificates and password expiry regularly.

Also establish the route and source path from the firewall to the domain controller. LDAPS requires TCP 636, while STARTTLS uses TCP 389; internal DNS and the complete valid certificate chain must work from the actual firewall path. Before changing the integration, create and download an encrypted configuration backup under Backup and firmware > Backup and restore, and store its password safely.

⚠️ The connection between firewall and authentication server should be encrypted. Unencrypted LDAP on port 389 can work in labs, but is not a good permanent solution for production environments.

Older Windows Server versions are also supported for AD integration, but in current environments Windows Server 2016, 2019, 2022 and 2025 are the most relevant. Since SFOS 21.5 MR1, Active Directory SSO with Windows Server 2025 is possible for NTLM and Kerberos. SFOS 22 contains updated Samba components for Kerberos and NTLM authentication and removes older encryption methods. After firewall or domain-controller upgrades, AD SSO, group import and Remote Access should therefore be tested deliberately.

Important: Strict enforcement of LDAP Channel Binding and LDAP Signing is currently not supported by Sophos Firewall. If domain controllers enforce very strict LDAP security settings, test the AD connection in a maintenance window before changing production.

Add Active Directory server

The configuration is done in the Sophos Firewall WebAdmin:

Authentication > Servers

Use Add to create a new authentication server and select Active Directory as the Server Type.

Active Directory configuration fields

The numbering in the screenshot is deliberate: the most important fields are explained from top to bottom. Depending on the SFOS version, the order can look slightly different. In newer versions, Validate server certificate is also shown when certificate validation for LDAPS should be enabled.

1. Server type: Use Active Directory for a classic Windows domain. Other server types such as RADIUS, LDAP or Microsoft Entra ID are different integration types and should not be mixed.
2. Server name: Internal display name on the firewall. The name has no effect on DNS or AD, but should be unique, for example AD-ZH-DC01 or AD-HQ-LDAPS. With several domain controllers, a clean name helps later in Log Viewer and troubleshooting.
3. Server IP/domain: IP address or DNS name of the domain controller. A DNS name is cleaner if certificate, internal DNS resolution and failover fit. An IP address is easier to debug, but binds the firewall directly to one domain controller.
4. Port: Port for the LDAP connection. For production, 636 with SSL/TLS is the preferred option. 389 is used for unencrypted LDAP or STARTTLS, but should not be the permanent solution when user authentication is used in production.
5. NetBIOS domain: Short NetBIOS name of the AD domain, for example AVANET. This value is not the DNS domain name. Incorrect NetBIOS values often lead to users existing but not being found or mapped cleanly.
6. ADS user name: Username of the account used for AD queries. Sophos uses the short username administrator in its example. For production, Avanet recommends a dedicated service account that can search, read, and query group membership rather than a Domain Admin account. Sophos does not state that short name, DOMAIN\user, and UPN are universally interchangeable, so use and record the format tested in your own directory.
7. Password: Password of the service account. If this password expires or is changed, user queries, group import, VPN logins or portal logins suddenly stop working. The account should therefore be documented and monitored.
8. Connection security: Defines whether and how the connection is protected. For LDAPS, use SSL/TLS with port 636. STARTTLS normally uses port 389, but requires the domain controller to provide STARTTLS cleanly. Plaintext is unencrypted and should only be used for tests.
9. Display name attribute: Directory attribute shown as the user’s name on the firewall. Match it to your directory schema and verify it with a test user; the general Sophos AD procedure does not define several interchangeable defaults. For Microsoft Entra Domain Services, Sophos explicitly uses DisplayName.
10. Email address attribute: Attribute for the email address. Usually this is mail. The field only helps when email addresses are actually maintained in AD. Otherwise user information is empty or inconsistent.
11. Domain name: DNS name of the AD domain, for example ad.example.com. This value is not the NetBIOS name. It must match the domain, search base and domain controller used.
12. Search queries: Search base for user and group queries. Enter Distinguished Names such as DC=ad,DC=example,DC=com or more specifically OU=Users,OU=Company,DC=ad,DC=example,DC=com. A targeted OU limits the visible user scope and keeps imports manageable.

Only users matched by at least one Search query can appear for this AD server under Current activities > Live users. If an expected user is missing despite a successful Test connection, first verify that the Base DN and OU scope include the user’s actual directory object. Do not widen the search base to the entire domain as a precaution.

If several domain controllers exist, decide deliberately whether the firewall should address one specific DC or whether a stable internal DNS name points to a suitable AD infrastructure. DNS resolution, certificate, routing and firewall rules must fit together.

AD automation when moving from SFOS 22 to SFOS 23: The API documentation for adding and editing an AD server uses narrower table labels in SFOS 23 than in SFOS 22: ServerIpDomain/ServerAddress becomes ServerAddress, ServerName/NetBIOSDomain becomes NetBIOSDomain, and ADSUsername/Administrator/Username becomes ADSUsername/Administrator. However, the XML example continues to use the elements ServerAddress, NetBIOSDomain, and ADSUsername unchanged in both versions. This demonstrates a change in documentation labels, not that the firewall rejects older aliases or that the WebAdmin fields explained above have been renamed. The internally inconsistent example is not a verified, directly executable API template.

The connection security labels also remain distinct: Plaintext is the WebAdmin label; the API documentation lists Simple, SSL, and StartTLS as the values for ConnectionSecurity. GUI labels must not be used as API values without verification.

The documented status/message tables for Add and Edit also differ between SFOS 22 and SFOS 23. These tables alone do not guarantee actual response codes or returned message text, HTTP transport status, or safe retries. When migrating AD automation, response interpretation must therefore be checked against the API documentation for the version in use and actual captured responses, rather than carrying over old error mappings unchanged. Afterwards, verify the saved AD configuration and a normal test user’s login to the intended service.

Safely retire the old AD server: The documented API operation Delete Active Directory server identifies the saved authentication server entry on the firewall by its exact ServerName, not by the domain controller’s IP address or an AD user. Purge AD users, by contrast, cleans up AD user entries on the firewall and is not a substitute for removing a server. The fact that the Delete table lists ServerName as optional establishes neither that deletion without a target is safe nor that bulk deletion is supported. No delete request is therefore generated or executed if the target is missing or unclear; the documentation provides neither a verified, executable request envelope nor the behaviour when the target is omitted. As a conservative operational precaution, before an approved retirement, document the exact object name and its settings, ensure usable local administrator access and a configuration backup are available, and check the affected services and intended server order under Authentication > Services. First validate the replacement login path with a normal user and their group permissions; do not rely on automatic fallback when credentials are rejected. Afterwards, read back the saved server list and check login and group authorisation for every affected service. If the response is unclear, establish the actual state first rather than blindly retrying the deletion. The Delete table continues to list 200 and 500 in SFOS 22 and 23, but the JavaScript message identifiers change between versions. These documentation values are neither HTTP status codes nor proof of the operation’s effect; no returned message text or runtime behaviour can be inferred from the unresolved JavaScript references. This operational guidance is limited to what the documentation establishes; no deletion or restore test was performed here.

Validate server certificate

Current SFOS versions can additionally enable Validate server certificate. This is useful for LDAPS because the firewall then not only encrypts the connection, but also checks whether it trusts the domain controller certificate.

These points must be correct:

1. Upload the domain controller’s server certificate under Certificates > Certificates > Add > Upload certificate. A CA-only import belongs under Certificates > Certificate authorities; do not conflate the two lists.
2. As specified by Sophos, enter the CNAME in Server IP/domain; this DNS name must be included in the server certificate’s Subject Alternative Name.
3. The firewall can resolve the CNAME internally.
4. Date and time on the firewall and domain controller are correct.

If internal DNS resolution does not resolve a CNAME or the domain-controller name cleanly, a DNS Host Entry under Network > DNS > DNS host entry can help.

NetBIOS domain and domain name

Sophos Firewall needs both the NetBIOS domain and the domain name. These values must match the AD domain exactly.

The NetBIOS domain can be found, for example, in Active Directory Users and Computers through the properties of the domain.

The domain name is the DNS name of the domain, for example ad.example.com.

Typical mistakes here:

• NetBIOS name and DNS domain name are confused.
• The domain controller entered belongs to another domain.
• The firewall cannot resolve the DNS name of the domain controller.
• A network firewall or Windows Firewall blocks the connection between firewall and domain controller.

Service account and password

A dedicated service account should be used for Active Directory access. A Domain Admin account is not required for normal LDAP queries and increases risk unnecessarily.

Useful requirements:

• dedicated account for the firewall, for example svc-sophos-fw-ldap
• only the required read permissions
• documented owner for password changes
• long, unique password
• no interactive logon if AD policies can enforce this cleanly
• monitoring or reminder before password expiry

If the service account password expires or is changed, the firewall can no longer query users and groups. Later this often appears as a VPN, portal or user-rule problem, even though the real cause is the AD connection.

Connection security and LDAPS

For production, prefer LDAPS. The domain controller needs a suitable server certificate. With Validate server certificate enabled, follow the Sophos server-certificate import above; import any separately required CA certificate as a Certificate Authority.

Check:

• Port 636 is reachable from the firewall interface to the domain controller.
• The domain-controller certificate is valid.
• The certificate name matches the DNS name used.
• The server certificate and, where required, its issuing CA are in their respective certificate lists.
• Time and date on firewall and domain controller are correct.

An important product limit remains: SFOS 22 currently doesn’t support strict enforcement of LDAP channel binding and LDAP signing. LDAPS with certificate validation protects the connection, but it doesn’t prove compliance with an AD security policy that mandates channel binding or signing. If the organization requires this enforcement, validate the integration against the specific AD policy before rollout and don’t approve it based on a successful Test connection alone.

For certificate topics, CA distribution also matters. For distributing the Sophos Firewall CA to clients, see Distribute Sophos Firewall CA certificate for HTTPS Scanning. For LDAPS, however, the CA of the domain controller or internal PKI is decisive.

Connect Microsoft Entra Domain Services

A managed Microsoft Entra Domain Services domain can be connected as an Active Directory server. Sophos lists WebAdmin, Captive Portal, User Portal, Client Authentication Agent, and Remote Access SSL VPN for this integration. This isn’t direct Entra ID SSO, and that list does not establish VPN Portal support.

For production, enable Secure LDAP and allow port 636 from the selected firewall path to the managed domain. The server certificate needs the Server Authentication extended key usage. Instead of exposing LDAPS publicly, use a private Azure or IPsec path when possible and restrict the Network Security Group to the required source address.

The official Sophos example uses the public Secure LDAP IP, SSL/TLS, port 636, DisplayName, mail, and clears Validate server certificate. Sophos separately recommends a private Azure or IPsec path for better security. Certificate validation with a matching name and trusted chain is an Avanet hardening recommendation that must be tested locally, not part of the official example. Entra users must first sign in and change their passwords so Kerberos and NTLM hashes can be generated and synchronized; the bind account must belong to the configured Entra Domain Services administrator group.

Prepare the managed domain and certificate

Before changing production, have the Azure owner confirm the Entra ID tenant, managed-domain DNS name, VNet/private route, administrator group, synchronization scope and required privileges. Use a secured Windows, macOS or Linux endpoint with OpenSSL installed; the following shell example is for Linux/macOS, not the SFOS console. Record the existing certificate, LDAP settings, NSG rules and service order, and keep a tested local administrator available.

⚠️ HISTORICAL minimal example, NOT an upload-ready certificate: The retained command sequence below explains CA, LDAP key/CSR, serverAuth, and PKCS#12. It sets only the Extended Key Usage, but neither the required Key Usage nor a wildcard DNS name. Its output must not be uploaded directly in the next Azure step. First obtain a suitable certificate from the approved PKI or plan an explicitly approved self-signed test case and verify all the criteria below. A self-signed example does not constitute production approval.

For Secure LDAP, the certificate must have the following properties:

• Domain name: A wildcard for the actual managed DNS domain in the Subject or DNS Subject Alternative Name (SAN), for example *.ad.example.com for ad.example.com. Replace the entire example domain name; a single LDAP hostname is insufficient because Microsoft operates the managed domain controllers with changing names. For subsequent firewall validation, the endpoint name used must also match the certificate.
• Key Usage: digitalSignature and keyEncipherment, plus the Extended Key Usage serverAuth for Server Authentication. The EKU alone does not replace these two Key Usage requirements.
• Validity and trust: The certificate must already be valid and cover at least the next 3 to 6 months. Plan renewal in good time. The accessing systems must trust the issuer and the required chain; for an internal CA or a self-signed test certificate, distribute the public trust certificates specifically to the systems that need them, never the server or CA private key.
• Upload package: A password-protected .pfx containing the LDAP private key that matches the server certificate and the required public chain certificates, but no CA private key. The PFX export format must also meet the import requirements described below.

For the historical example, work in a new directory accessible only to its owner, do not overwrite anything, and set umask 077. Create entra-eku.conf in a text editor:

[client_server_ssl]
extendedKeyUsage = serverAuth

Run the following commands there only to follow the historical minimal example; answer certificate prompts according to the approved naming plan, and do not copy example customer identities. Even with correctly answered prompts, this command sequence does not automatically add the missing certificate extensions:

umask 077
openssl genrsa -out entra-ca.key 4096
openssl req -x509 -new -key entra-ca.key -days 365 -out entra-ca.pem
openssl genrsa -out entra-ldap.key 4096
openssl req -new -key entra-ldap.key -out entra-ldap.csr
openssl x509 -req -extensions client_server_ssl -extfile entra-eku.conf -in entra-ldap.csr -CA entra-ca.pem -CAkey entra-ca.key -CAcreateserial -out entra-ldap.crt -days 365
openssl pkcs12 -export -out entra-ldap.pfx -inkey entra-ldap.key -in entra-ldap.crt -certfile entra-ca.pem
openssl x509 -in entra-ldap.crt -noout -text
openssl pkcs12 -in entra-ldap.pfx -info -noout

Enter a unique export password interactively and store it in the approved secret store, never in a command, ticket, or log. The .pfx contains the LDAP private key, not the CA private key. The keys generated above are stored unencrypted on the working drive; umask 077 restricts file permissions but does not replace encryption. Use a secured, encrypted drive, protect the keys and package, securely transfer only the approved package, and remove working copies in accordance with the key-handling policy. The last two commands are inspection steps that do not output private keys, not approval to upload. The commands and Azure upload were not tested against a tenant or appliance here.

Check certificate properties before export

Inspect the server certificate actually intended for use with openssl x509 -in entra-ldap.crt -noout -text; replace the filename with the certificate approved by the PKI rather than using the minimal example’s output without verification. The output must show the managed wildcard domain name, Digital Signature, Key Encipherment, TLS Web Server Authentication, issuer, and Not Before and Not After values that meet the requirements. Also have the associated trust chain and the match with the intended private key verified. This text output alone proves neither chain trust at the firewall endpoint nor successful Azure acceptance. If a property is missing or the trust chain remains unresolved, stop and obtain a suitable certificate with the PKI/Azure owner; do not upload the minimal example.

Export the PFX in a compatible, protected format

The retained command above, openssl pkcs12 -export, does not explicitly select a compatible export format. OpenSSL 3 defaults to AES-256-CBC/PBKDF2 and a SHA256 MAC; Microsoft requires TripleDES-SHA1 for this Entra import. The historical output entra-ldap.pfx is therefore not an approved upload package. Renaming a package or entering the correct password does not resolve this format conflict. This compatibility encoding applies exclusively to the PFX container; it is not a recommendation for weak TLS, certificate-signature, or key algorithms.

A documented alternate export path is Windows certificate export on a secured Windows system that offers TripleDES-SHA1; on Windows Server, this option is available starting with Windows Server 2016. The separately approved server certificate must already be in that system’s personal certificate store with its matching, exportable private key. Do not import private keys merely to distribute trust to clients.

1. As an authorized administrator, open mmc and select File > Add/Remove Snap-in > Certificates > Computer account > Local computer. Under Certificates (Local Computer) > Personal > Certificates, identify the approved certificate by name and thumbprint, not an arbitrary certificate with the same name.
2. Select All Tasks > Export, then Yes, export the private key and Personal Information Exchange - PKCS #12 (.PFX). Enable Include all certificates in the certification path if possible. The CA certificates are public chain components; the CA private key is not exported.
3. On the security page, select Password, set the encryption to TripleDES-SHA1, and enter and confirm a unique password in the dialog. Save it in a protected location under a new name, such as entra-ldap-upload.pfx; do not overwrite the historical example file. If the option is unavailable or the private key is not exportable, stop and have the PKI owner arrange a compatible export rather than proceeding with defaults.
4. Inspect the completed package on a secured system with openssl pkcs12 -in entra-ldap-upload.pfx -info -noout; enter the password only interactively. Expect a SHA1 MAC and TripleDES/3DES for the encrypted key and certificate components, typically shown by OpenSSL as pbeWithSHA1And3-KeyTripleDES-CBC. AES/PBKDF2 or a SHA256 MAC do not match this export profile. If the installed OpenSSL version or provider policy prevents inspection, do not disable safeguards indiscriminately; instead, have the PKI owner inspect the package with an approved inspection tool. -noout prevents certificates and private keys from being output; passwords, PFX files, and private keys must not be included in inspection logs.

Only after the certificate criteria, matching private key, chain, export profile, and secure handover have been checked and documented may the approved entra-ldap-upload.pfx be used in the following step. This preparation is supported by documentation; no Windows export, tenant, or appliance test was performed here.

Configure Secure LDAP and discover the endpoint

1. Have the Azure owner provision the managed domain with the agreed DNS/VNet/admin settings; wait for Microsoft Entra Domain Services > Running. Under Synchronization, choose All or Scoped deliberately and Save synchronization scope. Ensure intended users are included and the password-hash synchronization described above has completed.
2. Only after the certificate and PFX checks have passed, open the domain’s Secure LDAP, enable it, and upload only the approved upload package, not the historical example file, under .PFX file with secure LDAP certificate. Enter the export password under Password to decrypt .PFX file, then select Save. The public source example also enables Allow secure LDAP access over the internet; this is not required for a private path. Enable it only for explicitly approved public access, with the NSG allowing TCP 636 exclusively from the firewall’s actual public source IP.
3. Under Properties, record IP addresses, Secure LDAP external IP addresses and Admin group. Under Microsoft Entra ID > Users, confirm that the bind account belongs to that Admin group. For private routing, verify the selected managed-domain endpoint, DNS and source path rather than substituting a tenant IP for a domain controller.

Map the Entra server and validate usage

In Authentication > Servers > Add, use Server type: Active Directory and a unique Server name. Set Server IP/domain to the chosen managed-domain LDAP endpoint, Connection security: SSL/TLS, Port: 636, and the managed domain’s NetBIOS domain. ADS user name is the verified Admin-group member; enter its password securely. Use Display name attribute: DisplayName, Email address attribute: mail, the managed DNS Domain name, and Search queries as LDAP DNs covering only the required synchronized objects. The existing validation qualification above applies: clearing Validate server certificate is the retained example, not Avanet’s production hardening standard.

Run Test connection, then Save. Import required groups through Authentication > Servers > Import, check them under Authentication > Groups, and apply the server to the intended supported services under Authentication > Services without silently changing other server orders. Test a normal synchronized user’s login and group authorization for each selected service. If connection fails, check Running, synchronization/password hashes, endpoint/source route, NSG TCP 636, PFX password/expiry/EKU, bind-group membership and search DN. Do not fix it by exposing LDAP broadly or permanently disabling validation. If acceptance fails, restore the recorded certificate/LDAP/NSG/service settings in the maintenance window and retest the previous path; do not delete the managed domain. Keep a renewal and rollback owner.

Display attribute and email attribute

The display attribute determines how users are shown in Sophos Firewall. Directory attributes you may encounter and must verify locally include:

• sAMAccountName
• userPrincipalName
• displayName
• name

These values are not universally interchangeable. The directory schema, uniqueness, and result for a test user are decisive. Sophos documents DisplayName for Entra Domain Services; that does not define a general default for on-premises AD.

The attributes can be checked in Active Directory Users and Computers when Advanced Features is enabled.

The email attribute is usually mail. It is mainly relevant when the firewall should assign email-related information to users.

Search base and groups

The search base defines which part of Active Directory the firewall searches. For a whole domain, an example would be:

DC=ad,DC=example,DC=com

For a single OU, the path could look like this:

OU=Users,OU=Company,DC=ad,DC=example,DC=com

The Distinguished Name of an OU can be found in Active Directory Users and Computers in the attributes of the OU.

A broad search base often works, but makes the configuration less clear. For production environments, it is better to use:

• a dedicated OU or clear search base for relevant users
• separate AD groups for VPN, portals or firewall rules
• no random reuse of large department groups
• group import testing after changes
• regular removal of old or empty groups

Overly broad group imports can also put long-term pressure on the firewall’s internal user management. If many old users or groups exist and VPN Portal downloads later fail unexpectedly, check the Sophos Firewall User-ID limit.

Important for Remote Access: In SFOS 21.5 MR1, Sophos changed behaviour so L2TP and PPTP are no longer automatically enabled when groups are imported from Active Directory and Microsoft Entra ID. This reduces unwanted attack surface, but should be checked after upgrades if old Remote Access processes relied on it. Set up L2TP remote access on Sophos Firewall explains the explicit member assignment, main-group boundary, and validation.

Import groups and understand users

After adding the AD server, AD groups are not automatically fully present on the firewall. Groups are imported through the import assistant:

Authentication > Servers > Import

The process is:

1. Select the AD server and start Import.
2. Select the Base DN for the group search.
3. Select the required AD groups.
4. Check common group policies.
5. Review the selection and complete the import.
6. Check under Authentication > Groups whether the groups are present correctly.

If AD is intended to be the primary authentication method for this setup journey, go to Authentication > Services, select the configured AD server under Firewall authentication methods, move it to the first position in the selected-server list and click Apply. Then verify the imported groups under Authentication > Groups and have a test user sign in again to refresh group assignment. This first position applies to the primary-AD setup journey, not universally to every existing server order.

Users appear under Authentication > Users only after they sign in to a service, for example User Portal, VPN Portal, Captive Portal or Remote Access VPN. At each login, the firewall checks again which imported groups match the user and updates the mapping.

If none of a user’s AD groups exists on the firewall, the user receives the Default group configured under Authentication > Services. The product default is Open group. Still verify the effective value before rollout because it may have been changed and directly determines inherited settings.

In HA environments, import AD groups on the primary device. The same applies when cleaning up old AD users with Purge AD users.

For a complete operational workflow covering group policies, the Default Group, main group, user overrides, and function-specific multiple-group behavior, see Manage Sophos Firewall user groups and the main group correctly.

Main Group, group order and nested groups

An AD user can be in several groups. Sophos Firewall distinguishes between:

• Group: The first matching group in the firewall group list. This is the user’s Main Group.
• Other group memberships: Additional imported groups of which the user is also a member.
• Group order: Order under Authentication > Groups. This decides which group becomes the Main Group when several groups match.

This matters because not all functions evaluate multiple groups. Some functions only use the Main Group. If a user is in several AD groups, a different policy may apply than expected.

Change the group order here:

Authentication > Groups > Reorder

Nested AD groups are not supported. If a firewall policy should apply to a subgroup, that subgroup itself must be imported. Importing only the parent AD group is not enough.

The primary AD group of a user is also not treated like a normal group membership. This particularly affects the AD default group Domain Users. For firewall policies, use explicit security groups and add users directly to those groups.

Which functions support multiple groups

This distinction is especially important in operation.

Several AD groups can be considered for:

• Firewall rules: The order of firewall rules remains decisive.
• SSL/TLS inspection rules: The first matching inspection rule applies.
• Web policies: The firewall rule matches first, then the matching web-policy rule.
• IPS policies: The policy from the matching rule is applied.
• Application control policies: Evaluation happens through the matching firewall rule.
• SD-WAN routes: User or group criteria can consider several groups.
• Policy test: Helpful for checking group and policy matching.
• Remote access SSL VPN: Permissions from matching Full and Split Tunnel policies are considered. With Full Tunnel, Full Tunnel takes priority.
• Clientless SSL VPN: Permissions from matching groups are combined.

Only Main Group or explicit users are considered for:

• WAF rules
• Remote access IPsec VPN
• L2TP and PPTP
• Hotspots
• MFA, when MFA is applied specifically to groups
• Surfing quota, Access time, Network traffic and Traffic shaping
• Quarantine digest, MAC binding and Sign-in restriction

Sophos Firewall Access Time for users and groups shows how to verify the main group for time-dependent user access and distinguish user overrides.

The same main-group boundary applies to consumption-based time and data allowances. Surfing quota and network traffic quota on Sophos Firewall provides the complete workflow.

Practical example: A user is in VPN-Users and Firewall-Admins. Multiple membership can work for SSL VPN. For IPsec Remote Access or MFA group assignment, however, only the Main Group may count. For Remote Access and administrative access, deliberately test which group is set as Group in the user object.

Multiple Active Directory servers

Several AD servers can be configured. For Firewall authentication methods, the firewall proceeds to the next server only when the previous server is unreachable; rejected credentials do not trigger normal fallback. This order is neither load balancing nor a substitute for a well-planned AD design.

Recommendations:

• Set server order deliberately under Authentication > Services.
• Document search base and domain cleanly for each server.
• Do not use conflicting groups with the same name in different sources.
• Plan DNS and AD configuration cleanly when using several UPNs or domains.
• Test failover not only with Test connection, but with a real user login.
• If an AD server fails, the error message shown to the user can look like an incorrect password.

If several UPNs belong to the same domain infrastructure, DNS entries and AD server configuration must match the respective domain. The important point is that search base, Domain Name and server resolution belong together.

For several UPN domains on the same domain server, Sophos describes this specific configuration: create a DNS entry for each domain pointing to that server’s IP address, and create a separate AD-server configuration on the firewall for each domain. Use the respective AD domain as the Search query in LDAP DN form, for example DC=ad,DC=example,DC=com for ad.example.com. Replace these values with your own domains and test sign-in and group assignment for each UPN domain. This is not a load-balancing or failover procedure for multiple domain controllers; with LDAPS, the server name used must still match certificate validation.

Test the connection

After saving, test the connection directly. The test checks whether the firewall reaches the server and whether the entered data basically works.

A successful test does not automatically mean user rules, SSO or VPN already work. At least these points should be checked afterwards:

1. AD users or groups are found correctly.
2. Test user can sign in at the intended location.
3. Group membership matches the desired firewall or VPN permission.
4. Log Viewer shows traceable authentication events.
5. Remote Access VPN, User Portal or Captive Portal works with a normal test user.
6. MFA is requested if it is planned for the use case.
7. The AD server is entered under Authentication > Services in the desired position of the Firewall Authentication Methods.

If it remains unclear whether the service selection, user identity, main group, quota, or only the later firewall rule fails, Systematically troubleshoot Sophos Firewall authentication errors separates these layers with a reproducible test case.

For Remote Access with Sophos Connect, the next suitable step is Configure Sophos Connect Client on Sophos Firewall.

Validate by use case

After the AD connection, do not only document a single connection test. Different functions use AD integration in different ways. Test each planned use case separately.

• Group import: Search for the relevant AD group and import it on the firewall. If something is wrong, the group is not found or contains unexpected users.
• User Portal: Test login with a normal AD user. A typical error symptom is a failed login even though the server test was successful.
• Remote Access VPN: Check VPN login, group permission, MFA and access to internal targets. In case of errors, the user may authenticate but receive no suitable policy or no access.
• User-based firewall rule: Generate test traffic and check Log Viewer for user, group and Rule ID. If mapping does not work, traffic appears only with an IP address or hits another rule.
• Captive Portal: Test browser login and subsequent traffic. Errors often show up as the login working, but the user not being mapped correctly afterwards.
• AD SSO or STAS: Check Live Users and Log Viewer after Windows login. In case of problems, the user remains unknown or is assigned to the wrong IP.

This separation saves time in operation. A successful LDAP test only proves that server, port, bind account and search base are basically reachable. It does not prove that VPN groups are mapped correctly, MFA applies or user traffic is evaluated with identity in firewall rules.

For user-based rules, always trigger a real traffic test and check in Log Viewer whether username, group, firewall Rule ID and action match the expectation. If only the IP address is visible, the cause is often SSO, STAS, Captive Portal or firewall-rule order. For STAS environments, Set up STAS on Sophos Firewall is the matching follow-up article.

If Sophos Endpoint already sends Security Heartbeat, Synchronized User ID Authentication can send a Windows 10 domain user to the firewall without an additional authentication agent. The workflow still requires matching AD validation and a real rule test.

Consider Active Directory SSO

Active Directory SSO is its own operating area. The pure AD server connection is a foundation, but SSO additionally needs suitable client, browser, DNS, Kerberos or NTLM conditions.

For Web Authentication, Sophos Firewall supports classic AD SSO with Kerberos and NTLM. Kerberos is cleaner and faster, but has stricter requirements for FQDN, DNS, SPN and browser trust. NTLM is more tolerant and can be the pragmatic fallback in old environments, but it should not silently become the only working method.

Sophos places browser-initiated NTLM behind General Authentication Client, Clientless single sign-on and Client-based single sign-on. NTLM is used as a fallback only when those assignments do not apply; if NTLM also fails, Captive Portal is shown. If a user appears with an unexpected method under Current activities > Live users, check the displayed Client type and existing identity sources before changing the SPN or Web Authentication.

The Kerberos & NTLM setting offers both methods to the browser, and the client decides which one to use. There is no Kerberos-only mode because the HTTP specification doesn’t support it. For transparent web traffic, the firewall redirects authentication to TCP port 8091.

When several users share the same RDS or terminal-server IP, the normal IP mapping is insufficient. For HTTP and HTTPS traffic sent exclusively through an explicit proxy, Per-Connection AD SSO for multi-user hosts explains the dedicated process and how it differs from SATC.

⚠️ Upgrade note for SFOS 22: After upgrading from SFOS 21.5 or earlier to SFOS 22.0 GA, AD SSO with Kerberos and NTLM can fail. Identity-based rules then no longer recognize the affected domain users, while other firewall traffic continues. Sophos fixed the issue in SFOS 22.0 MR1 Build 490. AD SSO should be tested with real user traffic before and immediately after the upgrade. Repair AD SSO after an SFOS 22 upgrade explains how to check nasm.log, run the targeted NASM cleanup and verify the result with real user traffic.

The AD SSO flow is therefore more than just Test connection on the AD server:

Sophos describes registering the firewall in the Windows domain as creating an object for the firewall on the primary domain controller. This context belongs to the domain join for AD SSO; LDAP/LDAPS directory queries alone do not automatically require that join. Keep the required join permissions separate from the LDAP bind account’s read permissions.

1. Set a hostname or FQDN under Administration > Admin and user settings. For Kerberos, use an FQDN, keep it lowercase and keep the host part to 15 characters or fewer so NetBIOS name, AD computer object and SPN do not drift apart.

   Example: The firewall is configured as fw01.edge.example.com, while the AD domain is corp.example.com. During the domain join, SFOS combines the NetBIOS hostname fw01 with the AD domain. The name known to AD is therefore fw01.corp.example.com, not automatically the configured firewall FQDN. The redirect name for transparent Kerberos must match the HTTP SPN registered in AD and resolve in DNS.

2. Under Administration > Admin and user settings, set the Redirection Location so clients can resolve and trust it. An account with AD read access can run this targeted read-only query on a Windows system:

   setspn -Q HTTP/fw01.corp.example.com
   

   Replace the example with the actual redirect FQDN. The output must identify the expected SPN on the expected computer object; no match or a different object must be resolved with the AD owner before rollout.

3. Save the AD server under Authentication > Servers and run Test connection. This test checks connectivity and credentials, but it does not prove that AD SSO works.

4. Under Authentication > Services, move the AD server to the required position in Firewall authentication methods. AD SSO uses the servers in this order and only falls back to the next server if the previous one is unreachable.

5. Under Administration > Device access, enable AD SSO for the required zones. Usually this is LAN or a clearly defined internal client network, not every zone.

6. Under Authentication > Web authentication, set If Active Directory (AD) SSO is configured to Kerberos & NTLM or deliberately to NTLM only.

7. In the relevant firewall rules, check whether Match known users and, for unknown web requests, Use web authentication for unknown users match the intended flow. A separate clearly named rule for HTTP and HTTPS is often easier to operate.

Under Authentication > Services, HTTP challenge redirect on intranet zone should remain enabled. If an internet-hosted website triggers an NTLM challenge, the firewall then handles the exchange through its local interface IP in the intranet zone. If the option is turned off, the browser can send credentials over the internet. This isn’t a harmless compatibility setting.

When Use web authentication for unknown users authenticates HTTPS traffic in transparent mode, the firewall decrypts the connection for authentication regardless of the firewall rule or SSL/TLS inspection rule settings. This must fit the TLS inspection and certificate design; otherwise AD SSO quickly looks like a browser, certificate or web-filter problem.

For validation, Log Viewer is decisive. Under Log viewer > Authentication, the start of the AD SSO connection should show messages such as Kerberos authentication initialized successfully and NTLM authentication channel established successfully. Messages such as Cannot initialize Kerberos authentication or Cannot establish NTLM authentication channel are problematic. The Log Comp column also shows whether a client uses Kerberos or NTLM.

Sophos Firewall only offers either method to the browser after both Kerberos and NTLM have initialized successfully on the firewall. A visible NTLM fallback is therefore no reason to skip the Kerberos check. DNS, SPN and system time must align; by default, the clocks involved in Kerberos must be no more than five minutes apart.

Keep the account roles separate. The LDAP bind account only needs the directory read permissions required for queries. The domain-join operation for AD SSO requires either a Domain Admin account or an account with properly delegated rights to create the computer object or SPN. In HA environments, with several AD servers or after upgrades, a new domain join may be required; ensure suitable join credentials are available without assuming that the LDAP bind account needs those elevated rights.

Since SFOS 21.5 MR1, Windows Server 2025 is supported for Active Directory SSO with NTLM and Kerberos. SFOS 22 also brings updated Samba components and removes older encryption methods. For administrators, this means:

• Test AD SSO deliberately after domain-controller upgrades.
• Check authentication and user mapping after SFOS upgrades.
• Document Kerberos/NTLM dependencies in older environments.
• Do not plan obsolete encryption as a permanent solution.
• Check DNS request routes for AD domains if the firewall cannot find AD service records through the normal resolver.
• Do not confuse SSO with Entra ID SSO for Sophos Connect.

If Entra ID SSO is planned for VPN or VPN Portal, use the separate article Set up Microsoft Entra ID SSO for Sophos Connect and VPN Portal. This is a different authentication model from classic local AD integration.

Troubleshooting

Connection test fails

First check reachability, port, routing and DNS. Then check connection security, certificate, service account and password.

Practical checks:

• Can the firewall reach the domain controller by IP?
• Is the DNS name resolved correctly?
• Is port 389 or 636 reachable?
• Does SSL/TLS really match the port and certificate?
• Is the service account active and not locked?
• Are Windows Firewall rules or LDAP signing requirements involved on the Windows side?

User is not found

The search base is often wrong or too narrow. Check the distinguishedName of the OU and make sure the user is really inside the search base. Spelling, umlauts, special characters and the chosen display attribute can also make searches harder.

Group is imported, but access does not work

Check the permission chain: AD group, imported firewall group, assigned VPN, portal or firewall rule, MFA and rule position. For Remote Access, the matching VPN configuration must also be linked to the group.

If the user is in several AD groups, also check the Main Group under Authentication > Users. MFA, Remote access IPsec VPN, WAF, Hotspots and several user-related settings in particular only consider the Main Group.

New AD users can’t sign in to the VPN portal

If an existing AD user can use the VPN portal but a newly created user with comparable permissions can’t, first compare the group assignment, Remote Access method and firmware version. Under Authentication > Users, Group shows the Main Group; additional imported groups appear under Other group memberships. SSL VPN can consider multiple group memberships, whereas IPsec Remote Access only considers the Main Group or an explicitly selected user.

For diagnosis:

1. Compare the affected new user with a working existing user.
2. Check the Main Group and Other group memberships.
3. Under Authentication > Services, check the VPN portal authentication methods; under Administration > Device access, check the allowed source zone; and in the Remote Access policy, check the user or group.
4. Record the SFOS version and build.

Sophos fixed NC-180824, an issue that prevented new AD users from a Secondary AD Group from signing in to the VPN portal. The fix is included in SFOS 22.0 MR2 Build 546, released on 14 July 2026. Sophos specifies neither the version in which the issue was introduced nor an official workaround. If the configuration and group logic are correct, update an affected older installation to SFOS 22.0 MR2 or later, then retest with an AD user signing in to the firewall for the first time whose VPN permission is granted exclusively through the affected Secondary Group in an SSL VPN policy.

⚠️ Don’t reorder groups on suspicion, prematurely purge users with Purge AD users, or recreate groups. Sophos doesn’t document these actions as solutions for NC-180824, and they can change other permissions.

New AD group does not appear automatically

New AD groups are not automatically synchronised to the firewall. Import the group again through the import assistant or create it manually as a matching group. Then a test user should sign in again so the firewall evaluates group memberships again.

User was deleted in AD, but remains visible on the firewall

AD users who have already signed in can remain visible on the firewall. If users were deleted in AD, remove them in AD first and then use Purge AD users on the firewall. In HA environments, do this on the primary device.

Login works, but user rule does not match

In this case, LDAP itself is usually not the problem. User mapping, SSO, rule position or logging are more likely. Log Viewer should show whether the traffic is evaluated with user identity or only with IP address. For rule analysis, see Test a firewall rule with Log Viewer, Policy Test and Packet Capture.

AD SSO falls back to Captive Portal or NTLM

If AD SSO does not work transparently, the redirection URL, SPN, DNS resolution or browser trust are usually involved. For Kerberos, the name to which the firewall redirects must belong to the matching HTTP SPN and must be resolvable by the client. For NTLM, the browser must treat the target name as trusted, otherwise it asks for credentials or falls back to the Captive Portal.

In practice, first check Administration > Admin and user settings, DNS resolution for the redirect name, setspn -Q HTTP/fw01.corp.example.com on a Windows client and Log viewer > Authentication. If only NTLM appears instead of Kerberos, this is often a sign of an SPN or browser-trust problem, not necessarily a broken AD server connection.

The certificate selected under Admin console and end-user interaction > Certificate must cover the redirect hostname or FQDN and be trusted by the endpoints. The firewall’s preinstalled self-signed certificate normally meets neither requirement for a newly configured name. Do not bypass a certificate warning; resolve it with a matching public or internal certificate.

For NTLM, trust can be restricted to the internal redirect name. On Windows, Microsoft Edge and Google Chrome inherit the setting from Internet Options > Security > Local intranet > Sites > Advanced. In Firefox, add the same FQDN to network.automatic-ntlm-auth.trusted-uris under about:config. Allow only the internal name that is actually used, not a broad domain or arbitrary websites.

Individual logins stop working after an upgrade

After SFOS or domain-controller upgrades, pay particular attention to SSO, Kerberos/NTLM, old encryption methods, certificates and group import. If only certain users are affected, also check special characters, spaces, UPN, group memberships and password status.

For authentication and service logs, see Sophos Firewall Troubleshooting: Services and Logs.

Connection does not work with certificate validation enabled

If Validate server certificate is enabled, certificate, CNAME, DNS resolution and CA trust must match. Common causes are a certificate with a different name, a missing internal CA on the firewall or a CNAME the firewall cannot resolve.

Roll back the change and operate safely

Record the server order, enabled services, groups, and certificate settings before making changes. If acceptance fails, first restore the previous order, encrypted connection method, and port. Plaintext on port 389 is only a short diagnostic isolation step and must never remain as a production rollback.

To reverse the complete configuration, restore the downloaded backup under Backup and firmware > Backup and restore. Restore replaces the current configuration, discards later changes, and restarts the firewall, so schedule a maintenance window. Booting the previous firmware partition also restores that partition’s configuration and closes sessions. Automatic firmware rollback only covers a failed configuration migration, not an AD SSO regression discovered during operation.

After any rollback, repeat Test connection, a normal service login, group authorization, and—when using SSO—a real user request with Log viewer > Authentication. In HA, import groups and run Purge AD users on the primary. Test a secondary DC only in an approved maintenance window by confirming the first server is genuinely unreachable and a login succeeds through the second.

Operational checklist

Before setup:

• Domain controller, port and DNS name defined.
• LDAPS and certificate chain checked.
• Dedicated service account created.
• Search base and relevant groups defined.
• MFA and Remote Access design clarified.

After setup:

• Connection test successful.
• AD server entered as the primary or appropriate Authentication Method.
• Test user and test group checked.
• AD groups imported through the import assistant.
• Main Group of a test user checked.
• For multiple groups: VPN portal login tested with an existing user and a user signing in to the firewall for the first time whose permission is granted exclusively through a Secondary Group in an SSL VPN policy.
• Remote Access, portal or user rule tested with a normal user.
• Log Viewer shows expected authentication events.
• For AD SSO, Kerberos/NTLM messages checked in the Authentication log.
• Password expiry of the service account documented.
• Upgrade test for AD SSO, group import and VPN processes planned.

In operation:

• Remove groups that are no longer needed.
• Import new AD groups actively; do not wait for automatic synchronisation.
• Check the service account regularly.
• Renew LDAPS certificates before expiry.
• Check group order after AD changes.
• Use named admins and MFA for administrative access.
• Do not treat authentication errors only as user problems; also check AD, network, certificates and firewall rules.

FAQ