Skip to content
Avanet

Connect a Generic LDAP Server to Sophos Firewall

Sophos Firewall

Sophos Firewall can authenticate users through the LDAP server server type based on directory attributes and group memberships. In practice, four steps are required: prepare a local group, connect the LDAP server, select it under Authentication > Services for the required service, and test login and authorization with real accounts.

OpenLDAP, 389 Directory Server, and FreeIPA are typical candidates for a generic LDAP connection, but they are not interchangeable products. Attributes, returned group values, and account expiration differ by schema. This guide therefore provides an adaptable example; you must verify the values on the actual user object. Google Secure LDAP is covered below as a separate variant documented by Sophos.

For Windows Active Directory with LDAPS, group import or AD SSO, Connect Active Directory to Sophos Firewall is a better fit. RADIUS via Microsoft NPS or an MFA gateway is covered in Set up a Sophos Firewall RADIUS server. If you need to replace the native eDirectory server type before SFOS 23, you can find the complete migration process at Migrate eDirectory before SFOS 23.

Prepare the values and rollback plan

Required:

  • WebAdmin access to Sophos Firewall;
  • network connectivity from the firewall to the LDAP server over the port configured on the server;
  • a Bind account with read rights to the required directory area;
  • Bind DN and Base DN, for example cn=svc-sophos,ou=service,dc=example,dc=net and ou=people,dc=example,dc=net;
  • the login, display name, email address, group and, if applicable, account expiry attributes;
  • if certificate validation is enabled, a resolvable server name and the appropriate CA trust chain.

The usual starting values are port 389 for STARTTLS and 636 for SSL/TLS. These are not fixed SFOS requirements: a directory can use a different port, but it must match Connection security and the server configuration.

⚠️ The Bind account does not require administrative write permissions. Limit its read permissions to the subtree and attributes that the firewall needs for user queries.

Before switching under Authentication > Services, document the selected servers, their order, and inheritance options for each affected method. Also record the previous Default group under Firewall authentication methods. This allows you to undo the change without hastily deleting new objects.

Distinguish between Bind DN, Base DN, and attributes

A DN runs from the specific object to the directory root. cn=svc-sophos,ou=service,dc=example,dc=net denotes the bind account in the example. The Base DN, on the other hand, specifies the starting point of the user search, such as ou=people,dc=example,dc=net.

A Base DN that is too narrow will not find all required users. 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; if the DN is already complete, the option normally remains disabled. The behavior of the LDAP server in use is what matters.

The attributes also come from the directory schema. uid, cn, mail, and memberOf are examples, not universal requirements. Sophos recommends memberOf as the Group name attribute, but uses GID in its own general configuration example. You must therefore verify the returned value, local group mapping, and multiple memberships with real test users.

Select encryption and certificates

Plaintext sends user credentials unencrypted and is not a good production configuration. SSL/TLS encrypts the connection from the start; STARTTLS upgrades an initially unencrypted LDAP connection to TLS.

When using Validate server certificate, enter under Server IP/domain the name specified in the server certificate and resolvable by the firewall. Sophos refers to it as a CNAME in the SFOS 22 help, while the same field description elsewhere just mentions a server IP. The certificate name is therefore the safe choice for a controlled TLS rollout. If the firewall cannot resolve it, an entry can be created under Network > DNS > DNS host entry. TTL, reverse lookup, and resolver testing are explained in Set up DNS host entries on Sophos Firewall.

Validate server certificate checks the certificate of the remote LDAP server. The optional Client certificate specifies a certificate that the firewall uses to establish a secure connection to the LDAP service; Google Secure LDAP explicitly requires the certificate generated by Google. For TLS errors, fix the name, DNS, time, validity and trust chain first instead of turning off the server certificate check as the first step.

Configure LDAP group and server

Prepare local group

  1. Open Authentication > Groups and select Add.
  2. Enter a unique Group name, for example LDAP-Benutzer.
  3. Select the Group type for the intended authentication method. Normal requires user login; Clientless controls access based on an IP address.
  4. Set required user, remote access and sign-in policies and save with Save.

The group is later used as the Default group. It does not grant or block traffic by itself; its policies and the rules of the relevant service determine access. User-specific policies take precedence over group policies. The complete group logic, including a pilot rollout, user overrides, and the Main Group, is explained in Manage Sophos Firewall user groups safely.

Configure the connection and bind

  1. Open Authentication > Servers and select Add.
  2. Select LDAP server as Server type.
  3. Assign a unique Server name, for example LDAP-Firma.
  4. Enter the server IP or domain name under Server IP/domain. For Validate server certificate, use the resolvable name from the server certificate.
  5. Select the Version 2 or 3 supported by the server. Google Secure LDAP requires version 3.
  6. Set Connection security and Port together. Use SSL/TLS or STARTTLS in production.
  7. Disable Anonymous login and enter the read-only account’s Bind DN and Password.
  8. Only switch on Append base DN if the server should add the base DN during bind.
  9. If the connection is secure, decide consciously whether Validate server certificate is activated. For standard LDAP servers, enabling validation after correctly configuring the name, DNS, and trust chain is the safe production choice. Google Secure LDAP follows the special case described below. Select a required Client certificate from the list.

Set search base and attributes

  1. Enter the starting point of the user search under Base DN. Get base DN can retrieve the search base offered by the server.
  2. Set the attribute with the login name as Authentication attribute, often uid or mail.
  3. Enter Display name attribute and Email address attribute to match the user object, for example cn and mail.
  4. Enter the group attribute returned on the user object under Group name attribute. memberOf is Sophos’ recommendation, but must match the schema and return format.
  5. Enter the Expiry date attribute that matches the schema. If no such attribute exists, check before rollout whether the form accepts an empty value and how accounts without expiration are handled.
  6. Run Test connection and save with Save.

According to Sophos, Test connection checks the connection and bind credentials. The test neither proves that the base DN includes all users nor that a group or service authorization applies correctly. A real login is required for this.

API automation only when moving from SFOS 22 to SFOS 23: The LDAP API reference changes the documented rows under Status Message Information: for Add LDAP server, from 200/500/502/503 to 200/400/401/403/409/500; for Edit LDAP server, from 200/500/503 to 200/400/401/403/404/500. 409 appears only for Add, 404 only for Edit. The presentation symbols also change from Message.LDAP* to Message.CP*. These documentation rows and symbols do not guarantee actual wire codes or messages or establish a fixed mapping from 502/503 to 409/404. For API automation, review the reference for your version and validate actual target-firewall responses before adopting a mapping. This is a separate API check; the GUI Test connection check and a real login remain necessary.

Enable LDAP for the required services

  1. Open Authentication > Services.
  2. Under Firewall authentication methods, move the LDAP server to Selected authentication servers. Place it first if it should respond as the primary server.
  3. Select the prepared group LDAP-Benutzer as Default group and click Apply.
  4. Select the server separately for all methods actually used: User portal authentication methods, VPN portal authentication methods, VPN (IPsec/dial-in/L2TP/PPTP) authentication methods, Administrator authentication methods and SSL VPN authentication methods.
  5. Use inheritance options such as Set authentication methods same as firewall, Same as firewall or Same as VPN only if the derived server list is intended.

A maximum of 20 servers can be selected for each authentication method. If there are multiple servers, the firewall queries them in the displayed order. The administrator method does not apply to the Super Administrator. For L2TP and PPTP, Sophos documents only PAP with LDAP; because of the protocol and these now-obsolete VPN technologies, this combination should not be introduced without careful review.

Set up Google Secure LDAP

Before configuring the firewall, create an LDAP client in the Google Admin Console under Apps > LDAP. Limit its Access permissions, download the certificate and private key, and generate separate credentials. The password is no longer visible after the dialog is closed. If the username or password is incorrect or no longer available, generate new access credentials in the Google Admin Console and then update Bind DN and Password in the firewall’s LDAP server configuration.

Google may change the Admin Console interface and its setup steps. Before starting, check the current Google documentation on creating LDAP clients, downloading the certificate, and generating access credentials.

Then switch on the client under Service status with ON for everyone and save with SAVE. This service status activates the client but does not replace the previously set Access permissions.

Before importing the certificate, check under Administration > Time that the firewall is obtaining the correct time via NTP. According to Sophos, an incorrectly set manual clock can cause the import of certificates to fail. Then select the format CER (.cer) under Certificates > Certificates > Add and import both Certificate and Private key from the Google download. The certificate may appear untrusted because it is self-signed by Google; Sophos confirms that Google LDAP still works. This indication applies to the client certificate, not to validation of the LDAP server certificate.

The following values apply to 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 or retrieve 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 for Google LDAP group creation. The official Google instructions do not explicitly set Validate server certificate in their list of values. Without an SFOS 22 lab test, this should not be interpreted as a firm instruction to enable or disable the option; decide according to the general TLS procedure and your own trust chain.

Verify login and group assignment

An acceptance test covers connection, identity, and authorization:

  1. Test connection must confirm the connection and bind credentials.
  2. Under Authentication > Services check server list, order and inheritance of each method used. The Default group belongs to Firewall authentication methods.
  3. Log in to the intended service with a pilot user. When you log in for the first time, the firewall creates the externally authenticated user locally.
  4. Under Authentication > Users, verify that the user and group appear as expected.
  5. Carry out a positive test for each relevant directory group. Additionally check with a user without a suitable local group assignment whether the expected Default group applies.
  6. Verify not only the login but also the intended policy or test rule. Then use an incorrect password as a negative test.
  7. For user login, authorization and accounting check access_server.log; for VPN portal problems additionally vpnportal.log.
  8. If an expiration attribute is used, include a test account with known expiration status.

If the schema values are unclear, an administrator can query the user object read-only from a Linux administration system or directly from 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)' '*' '+'

This optional diagnostic path is not an SFOS command and does not belong in the Advanced Shell. The example assumes LDAPS and trust in the server CA on the executing system; STARTTLS requires a correspondingly adapted call. -W prompts for the bind password interactively. Adapt the filter (uid=max.muster) to the configured Authentication attribute. '*' and '+' can output many normal and operational attributes with personal data. Anonymize the output before attaching it to a ticket or sharing it.

Isolate errors by symptom

  • No connection: Check routing, DNS, port and Connection security. Then check Bind DN, password and Anonymous login.
  • TLS or certificate error: Check the name from the server certificate, DNS resolution, firewall time, validity and CA chain. Do not deactivate the certificate check as the first step.
  • Test connection works, but the user is not found: Compare Base DN, Authentication attribute and the login name entered.
  • Login works, the group is wrong: Check Group name attribute and its real return value, local group mapping and Default group. memberOf is a recommendation, but not a guaranteed mapping for every schema.
  • Server is created but is not used: Check selection, order and inheritance for the affected service under Authentication > Services.
  • Google Secure LDAP does not bind: Check version 3, port 636, disabled Anonymous login, disabled Append base DN, the client service status, the credentials, and the Google client certificate individually.
  • Search is slow or returns unwanted accounts: Limit base DN to the required subtree.
  • Login works, the expected policy does not: Check user override, group policy, group mapping and the responsible firewall or VPN rule separately. The full diagnostic model shows Troubleshoot authentication failures systematically.

Roll back safely

In the event of a failed rollout, first restore the previously documented server selection, order, and inheritance for each affected method. Also restore the previous Default group under Firewall authentication methods. Carry out a positive and a negative test using the previous authentication method and check the relevant logs.

Only delete the new LDAP server and group when they are no longer used in any service or policy. Do not clean up automatically created LDAP users with Purge AD users: The SFOS 22 help documents this function only for Active Directory. If such users must be removed, confirm the supported procedure for your configuration with Sophos Support beforehand.