Skip to content
Avanet

Connect a Generic LDAP Server to Sophos Firewall

Sophos Firewall

With the LDAP server server type, Sophos Firewall authenticates users from OpenLDAP, 389 Directory Server, FreeIPA, Google Secure LDAP, and other LDAP directories. The complete process has four parts: create a local group, connect the LDAP server securely, enable the server under Authentication > Services, and verify the login and group assignment with a real user.

For Windows Active Directory with LDAPS, group import, or AD SSO, Connect Active Directory to Sophos Firewall is a better fit. RADIUS through Microsoft NPS or an MFA gateway is covered in Set up a RADIUS server on Sophos Firewall.

If the native eDirectory server type must be replaced before SFOS 23, Migrate eDirectory before SFOS 23 provides the complete process for inventory, target selection, parallel operation and rollback.

Prerequisites

  • WebAdmin access to Sophos Firewall
  • reachability of the LDAP server from the firewall, usually over port 389 for STARTTLS or 636 for SSL/TLS
  • a bind account with read access to the required directory scope
  • the Bind DN and Base DN, for example cn=svc-sophos,ou=service,dc=example,dc=net and ou=people,dc=example,dc=net
  • the user attributes actually used, such as uid, cn, mail, and a group attribute
  • the correct CA trust chain and working DNS resolution when certificate validation is enabled

⚠️ A bind account should have read access only to the required subtree. It is not used for administrative changes in the directory, but only to authenticate the firewall’s user queries to the LDAP server.

Add the LDAP server

Prepare the local LDAP group

  1. Open Authentication > Groups and select Add.
  2. Create a clearly named group, for example LDAP-Users.
  3. Set access, time quotas, and other group policies to suit the intended use, then save.

This group is later used as the Default group. It does not automatically prevent access: the policies assigned to the group and the rules of the relevant service determine what is allowed.

The general group logic with a restrictive Default Group, user overrides, pilot, and rollback is described in Manage Sophos Firewall user groups safely; the LDAP-specific assignment then follows from the group attribute and directory schema.

Configure the connection and bind

  1. Open Authentication > Servers and select Add.
  2. Select LDAP server as the Server type.
  3. Enter a clear Server name, for example LDAP-Company.
  4. Under Server IP/domain, enter the LDAP server’s DNS name. When certificate validation is active, it must match a name in the server certificate.
  5. Use Version 3 unless the directory requires another version. Google Secure LDAP supports version 3 only.
  6. For production use, select SSL/TLS or STARTTLS and the corresponding port.
  7. Disable Anonymous login and enter the read account’s Bind DN and Password.
  8. Enable Append base DN only if the LDAP server expects the Base DN to be appended during the bind.
  9. Enable Validate server certificate once the name, DNS, and CA trust are configured correctly. A Client certificate is required only if the LDAP service requires mutual certificate authentication.

Enter the search base and attributes

  1. Under Base DN, enter the starting point for the user search, for example ou=people,dc=example,dc=net. Get base DN can retrieve the search base offered by the server.
  2. Set Authentication attribute to the login attribute, commonly uid or mail.
  3. Enter Display name attribute and Email address attribute to match the user object, for example cn and mail.
  4. Under Group name attribute, enter the attribute from which the firewall receives the user’s group information. Sophos recommends memberOf, but the correct value depends on the directory schema.
  5. If the directory provides an account expiry date, enter the appropriate Expiry date attribute.
  6. Run Test connection and save with Save.

According to Sophos, Test connection verifies the connection and credentials. Only a real login shows whether the Base DN includes all required users and whether groups are assigned correctly.

Choose the right encryption

Plaintext LDAP transmits credentials without encryption and is suitable only for an isolated test at most. In production, protect the connection with SSL/TLS, usually on port 636, or STARTTLS, usually on port 389.

Two certificate roles must be distinguished:

  • Validate server certificate verifies the identity of the remote LDAP server. Server IP/domain must match a valid DNS name in the certificate, either the Common Name or a Subject Alternative Name. If the firewall cannot resolve this name, add a suitable DNS entry under Network > DNS > DNS host entry. Configure and test DNS host entries on Sophos Firewall explains TTL, reverse lookup, and resolver testing. The issuing CA must also be trusted.
  • Client certificate identifies the firewall to an LDAP service that requires mutual certificate authentication. This certificate does not replace validation of the server certificate.

For a TLS error, first correct the server name, DNS resolution, validity, and CA chain. Disabling server certificate validation should not be the default solution.

Enter the Bind DN and Base DN correctly

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

  • A DN runs from the specific object to the directory root, for example cn=svc-sophos,ou=service,dc=example,dc=net.
  • The Base DN starts where the user search should begin. If users are stored in multiple organizational units, it must be high enough in the tree to include them.
  • A Base DN that is too narrow returns no matching users even though the server is reachable. An unnecessarily broad search base can slow searches and include unwanted objects.
  • Append base DN appends the Base DN to an incomplete Bind DN during the bind. With an already complete DN, the option normally remains disabled; the LDAP server’s behavior is authoritative.

Enable groups and services

Group name attribute is not a universal switch for every LDAP group structure. At login, the firewall reads the configured attribute from the user object and uses the returned group information for assignment. Sophos recommends memberOf, and Google Secure LDAP uses this value. Depending on the schema, overlay, and user object, OpenLDAP, 389-ds, or FreeIPA may require a different value.

Do not infer the user attribute solely from the groupOfNames or posixGroup group type. What matters is what the real user object actually returns and whether the corresponding group is mapped correctly on the firewall. If the firewall finds no matching group assignment, the user is placed in the configured Default group.

Then enable the server:

  1. Open Authentication > Services.
  2. Under Firewall authentication methods, select the LDAP server and move it to the desired position in Selected authentication servers. The firewall queries multiple servers in this order.
  3. Select the previously created LDAP-Users group as the Default group and click Apply.
  4. If users need to sign in to the User Portal, VPN Portal, SSL VPN, another VPN service, or as administrators, also select the LDAP server under the relevant authentication method.

Set up Google Secure LDAP

Before configuring the firewall, create an LDAP client in the Google Admin console. Define its access permissions, download the certificate with its private key, and generate separate credentials. The password is not displayed again after the Google dialog is closed.

Import the Google client certificate with its certificate and private key under Certificates > Certificates > Add. Sophos Firewall may display it as untrusted because it is self-signed by Google, but it still works for client authentication. This status does not concern validation of the server certificate.

Use these values for the LDAP server:

  • Server IP/domain: ldap.google.com
  • Version: 3
  • Connection security: SSL/TLS
  • Port: 636
  • Anonymous login: off
  • Bind DN and Password: the generated Google LDAP credentials
  • Append base DN: off
  • Client certificate: the imported Google certificate
  • Base DN: enter it or retrieve it with Get base DN
  • Authentication attribute: UID
  • Display name attribute: CN
  • Email address attribute: mail
  • Group name attribute: memberOf
  • Expiry date attribute: expiry

mail is required when creating Google LDAP groups. After saving, follow the same steps as for a local directory: set the local LDAP group, enable the server under Authentication > Services, and test a real login and its group assignment.

Verify the connection and group assignment

A reliable acceptance test covers several levels:

  1. Test connection confirms the connection and bind credentials.
  2. A user signs in to the intended service, such as the VPN Portal or Captive Portal.
  3. Under Authentication > Users, verify that the user and group appear as expected.
  4. If multiple LDAP groups are used, test at least one user from each relevant group. A policy or test rule confirms that both the login and the relevant group authorization work.
  5. An incorrect password is rejected, and the Log viewer shows a comprehensible authentication error.

If the schema is unclear, an administrator can inspect the user object read-only from a Linux administration system or the LDAP server:

ldapsearch -LLL -x -H ldaps://ldap.example.net:636 \
  -D 'cn=svc-sophos,ou=service,dc=example,dc=net' -W \
  -b 'ou=people,dc=example,dc=net' \
  '(uid=max.muster)' '*' '+'

-W prompts for the bind password interactively so it is not stored in the shell history. '*' displays regular attributes and '+' operational attributes; adjust the search filter accordingly when a different login attribute is used. Do not run this command in the Sophos Firewall Advanced Shell. What matters is whether the user object actually returns the expected attributes and group values. The output may contain personal directory data and must be anonymized before it is attached to a ticket or shared.

Common errors

  • No connection: Check routing, DNS, port, and Connection security. Then verify the Bind DN, password, and Anonymous login.
  • TLS or certificate error: Check DNS names in the server certificate, DNS resolution, validity, and the CA chain. Do not disable server certificate validation as the first measure.
  • Test connection works, but the user is not found: The Base DN is often too narrow, or Authentication attribute does not match the login name.
  • Login works, but the user is placed in the Default group: Check Group name attribute on the real user object, local group mapping, and group order. memberOf is a common example, but it is not guaranteed for every schema.
  • Google Secure LDAP does not bind: Check version 3, port 636, disabled Anonymous login, disabled Append base DN, credentials, and the Google client certificate.
  • The server is configured but not used: Check the assignment, order, and Default group under Authentication > Services.
  • Searches are slow or return unwanted accounts: Narrow the Base DN to the required subtree.
  • Another authentication server responds first: Correct the order of the selected servers for the affected service.