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.

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.

Classification

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.

⚠️ 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 service account with which the firewall performs AD queries. Use a dedicated account with read permissions, not a Domain Admin. Depending on the environment, the short logon name, DOMAIN\user or a UPN such as svc-firewall-ldap@example.local can work.
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. Simple is unencrypted and should only be used for tests.
9. Display name attribute: AD attribute that the firewall uses as the display name. Common values are sAMAccountName, userPrincipalName, displayName or name. For operations and troubleshooting, a unique attribute is more important than a nice-looking name.
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 example.local or 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=example,DC=local or more specifically OU=Users,OU=Company,DC=example,DC=local. The narrower the search base, the clearer and more performant the import remains.

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.

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. The issuing CA of the domain-controller certificate is known on the firewall under Certificates > Certificates.
2. The value in Server IP/domain matches the certificate name or a Subject Alternative Name of the certificate.
3. If a CNAME is used, the firewall can resolve this name 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 example.local or 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 environments, LDAPS should be preferred. The domain controller needs a suitable certificate and the firewall must trust the issuing CA.

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 issuing CA is known on the firewall if validation is required.
• Time and date on firewall and domain controller are correct.

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.

Display attribute and email attribute

The display attribute determines how users are shown in Sophos Firewall. Typical values are:

• sAMAccountName
• userPrincipalName
• displayName
• name

sAMAccountName is often robust and short in classic AD environments. userPrincipalName is closer to modern login names and cloud identities. displayName is easy for people to read, but not always unique enough for operations and troubleshooting.

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=example,DC=local

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

OU=Users,OU=Company,DC=example,DC=local

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.

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.

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 a user is not found in any imported AD group, the user lands in the Default Group. This Default Group is visible under Authentication > Services in the Firewall Authentication Methods. By default, this is often the Open group.

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

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

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. The firewall validates users in the order configured in WebAdmin. This is not a replacement for a cleanly 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.

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.

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.

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.

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

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.
2. Under Administration > Admin and user settings, set the Redirection Location so clients can resolve the name and trust the target. In transparent Kerberos scenarios, this name must match the SPN. On a Windows client, setspn -Q HTTP/* helps check existing HTTP SPNs.
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.

If Use web authentication for unknown users must authenticate HTTPS traffic in transparent mode, the firewall can decrypt the connection for the authentication process. 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.

The account question matters. For normal LDAP queries, a Domain User with read permissions is often enough. For AD SSO, however, the firewall must join the domain and create a computer object or SPN. This requires either a Domain Admin account or an account with properly delegated domain-join rights. In HA environments, with several AD servers or after upgrades, the firewall may need to rejoin. For that reason, do not join once with a Domain Admin account and then switch to a weaker account if that account cannot perform the later rejoin.

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 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/* 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.

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.

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.
• 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