Connect a Generic LDAP Server to Sophos Firewall

Active Directory is the most common authentication server on Sophos Firewall, but it’s not the only one. If you run OpenLDAP, 389 Directory Server, FreeIPA, Google Secure LDAP, or any other pure LDAP directory, you can connect Sophos Firewall to it just as easily as an LDAP client. The server type is deliberately called LDAP Server, not Active Directory, even though Active Directory is itself technically an LDAP directory.

This article covers the generic case specifically: a directory service without AD-specific fields such as domain names or Kerberos. For Active Directory environments with LDAPS, group import, and AD SSO, see Connect Active Directory to Sophos Firewall instead. For RADIUS-based authentication, for example via Microsoft NPS or an MFA gateway, Set Up a RADIUS Server on Sophos Firewall is the right article.

When a generic LDAP server makes sense

An LDAP server on Sophos Firewall makes sense when:

• Users and groups live in a directory that isn’t Active Directory, for example OpenLDAP, 389 Directory Server, or FreeIPA.
• A cloud-based directory offers an LDAP interface, for example Google Secure LDAP or an LDAP proxy in front of Entra ID or Okta.
• Multiple systems already authenticate against the same LDAP directory and the firewall should use the same source.
• You don’t need Kerberos or NTLM, and simple bind authentication is enough.

If you’re running a Windows Server with Active Directory Domain Services, the specialized AD server type is usually the better choice, because it maps additional fields such as domain names cleanly. The generic LDAP server type also works against Active Directory, but doesn’t map AD-specific automation as well.

Prerequisites

• Access to the Sophos Firewall WebAdmin.
• Reachability of the LDAP server from the firewall, usually port 389 (plaintext/StartTLS) or 636 (LDAPS).
• A bind account with read access to the relevant subtree, specified as a Distinguished Name (DN).
• The Base DN under which users are searched, for example ou=people,dc=company,dc=local.
• Knowledge of the attribute used as the sign-in name, often uid, sAMAccountName, or mail.
• For an encrypted connection: the server certificate or certificate chain, if the firewall should validate it.

⚠️ A bind account should only have read access to the required subtree. It isn’t used for administrative changes in the directory, only to authenticate the firewall’s user lookups against the LDAP server.

Adding an LDAP server

1. Open Authentication > Servers.
2. Select Add and choose LDAP server as the Server type.
3. Under Server name, enter a unique name, for example LDAP_Company_Internal.
4. Under Server IP/domain, enter the IP address or DNS name of the LDAP server.
5. Under Version, select the LDAP version supported by the server, usually Version 3.
6. Under Connection security, choose between Plaintext, SSL/TLS, or STARTTLS.
7. Under Port, set the correct port if you’re not using the default.
8. Turn off Anonymous login if the server doesn’t allow anonymous bind requests.
9. Under Bind DN, enter the technical account as a Distinguished Name, for example cn=svc-sophos,ou=service,dc=company,dc=local.
10. Enter the matching Password.
11. Under Base DN, enter the search scope for users, for example ou=people,dc=company,dc=local.
12. Under Authentication attribute, enter the field used as the sign-in name, often uid.
13. Optionally set Display name attribute and Email address attribute, for example cn and mail.
14. Optionally set Group name attribute if group memberships should be evaluated.
15. Run Test connection and check the result.
16. Select Save.

Fields at a glance:

A successful Test connection only proves that the server, port, bind account, and search base are basically reachable. Whether the right users are found and groups are mapped correctly must be checked afterward with a real test user.

Choosing encryption correctly

For production environments, the connection between the firewall and the LDAP server should be encrypted, either via LDAPS on port 636 or via STARTTLS on the classic port 389. Plaintext LDAP sends bind passwords and, in some cases, user data unencrypted, and should only be used in tightly secured, internal test scenarios.

With Validate server certificate, the firewall checks whether the certificate presented by the LDAP server is trustworthy. With self-signed certificates, as used for example by Google Secure LDAP, the certificate may be marked untrusted even though the connection works. In this case, you need to deliberately decide whether to adjust certificate validation or import the certificate into the firewall.

Example: Google Secure LDAP

Google Secure LDAP is a good example of how a cloud-based directory is connected via generic LDAP:

• Server IP/domain: ldap.google.com
• Port: 636
• Version: 3
• Connection security: SSL/TLS
• Bind DN and Password: credentials generated in the Google Admin console as LDAP client credentials.
• Certificate: the client certificate issued by Google, along with its private key, is uploaded to the firewall.
• Attributes: uid for sign-in, cn for the display name, mail for the email address, memberOf for groups.

This example can be applied to other LDAP providers with a similar structure. What matters is which attribute the provider actually populates for sign-in name, display name, email, and group membership.

Getting Bind DN and Base DN right

The most common source of errors with a new LDAP server is incorrectly written or misunderstood DN syntax.

Key rules:

• A DN is written from the most specific to the most general part, for example cn=svc-sophos,ou=service,dc=company,dc=local.
• The Base DN for the user search must be the subtree where the relevant user objects actually live, not necessarily the root of the directory.
• If users live in multiple organizational units, the base DN must be chosen high enough in the tree to include all relevant containers.
• Append base DN determines whether the base DN is additionally appended to the bind DN. This is server-dependent and should be tested deliberately if you run into problems.

If the base DN is chosen too narrowly, the firewall may report a successful connection test but later find no users. If the base DN is chosen too broadly, the search may take unnecessarily long or include unwanted objects.

Mapping groups and attributes

For firewall rules, web policies, or VPN permissions by group, the Group name attribute is crucial. It determines which LDAP attribute the firewall interprets as group membership.

Typical patterns:

• Directories with a classic groupOfNames or posixGroup schema often use an attribute like memberOf or evaluate group membership via back-references.
• Cloud directories with an LDAP proxy, for example Google Secure LDAP, often deliver groups directly in the memberOf attribute on the user object.
• If the schema is unclear, an LDAP browser or a command-line tool like ldapsearch helps to view the full user object once before configuring the firewall.

After setup, test at least one user from every relevant group. A single successful login doesn’t prove that group mapping works correctly for all groups.

Enabling the LDAP server for services

An LDAP server you’ve added doesn’t authenticate anyone by itself. It also needs to be assigned to the desired service under Authentication > Services, for example VPN Portal, SSL VPN, Captive Portal, or admin login.

Practical steps:

1. Open Authentication > Services.
2. Select the affected service, for example Firewall authentication methods or VPN.
3. Add the newly created LDAP server as an authentication source.
4. Check the order if multiple servers are used in parallel.
5. Test the intended service with a test user.

If multiple authentication servers are active at the same time, for example LDAP and local users, the order should be chosen deliberately. The firewall queries the servers in the order they’re listed.

Testing and validating the connection

After saving, the setup should be tested in several steps:

1. Test connection in the server dialog: confirms reachability, bind account, and base DN.
2. Sign in a test user at the target service: confirms that authentication actually works.
3. Check group membership: confirms that the group name attribute is evaluated correctly.
4. Test a wrong user or wrong password: confirms that failed logins are rejected cleanly.
5. Check Log Viewer: shows whether authentication requests arrive and are processed as expected.

A test user who signs in successfully but isn’t assigned to the expected group usually points to a wrong group name attribute or an unexpected group schema.

Common mistakes

• Incorrect DN syntax: Bind DN or base DN are swapped, misspelled, or use the wrong separators. Check syntax against the directory schema.
• Base DN chosen too narrowly: The connection test succeeds, but real users aren’t found. Set the base DN higher up in the directory tree.
• Wrong port or wrong encryption: LDAPS on port 389 or plaintext on port 636 doesn’t work. Port and connection security must match.
• Certificate not trustworthy: With self-signed certificates, the firewall may classify the connection as untrustworthy. Import the certificate deliberately or adjust validation specifically.
• Anonymous login enabled even though the server refuses it: Bind fails. Disable anonymous login and enter bind DN/password.
• Group attribute doesn’t match the schema: Login works, but group policies don’t apply. Check the attribute against the actual LDAP schema, for example with ldapsearch.
• LDAP server not assigned under Authentication > Services: The server is created but not used by any service. Add the assignment under Authentication > Services.
• Multiple authentication servers in the wrong order: A different server answers first and delivers unexpected behavior. Check the order under Authentication > Services.

FAQ