Connect a Generic LDAP Server to 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 authorisation with real test 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 expiry 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 permissions for the required directory subtree;
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. Under Firewall authentication methods, also record the previous Default group. This allows you to undo the change without hastily deleting new objects. Keep a previously tested local administrator login available for recovery throughout the changes.

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 behaviour 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

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

Deliberately choose the required limits for Surfing quota and Access time. Sophos uses Unlimited internet access and Allowed all the time in its tutorial example; these are example policies, not prerequisites for LDAP. For restricted pilot access, the duration of use actually required and the permitted time window are more appropriate. Leave other fields at their defaults only if those defaults match your own access policy.

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. For user policies and remote access VPNs other than SSL VPN, user-specific settings take precedence over group policies. This precedence rule does not apply to remote access SSL VPN: a user can access the resources of all full-tunnel and split-tunnel policies that apply to the user or their groups. A more restrictive user policy therefore does not automatically override broader SSL VPN group permissions. This does not imply a general guarantee that every LDAP schema maps multiple memberships in the same way; group mapping and the resources actually accessible must be checked during the pilot. The complete group logic, including a pilot rollout, user-specific exceptions, and the main group, is explained in Manage Sophos Firewall user groups safely.

Configure the connection and bind

Open Authentication > Servers and select Add.
For Server type, select LDAP server.
Assign a unique Server name, for example LDAP-Firma.
Enter the server IP or domain name under Server IP/domain. For Validate server certificate, use the resolvable name from the server certificate.
Select the Version 2 or 3 supported by the server. Google Secure LDAP requires version 3.
Set Connection security and Port together. Use SSL/TLS or STARTTLS in production.
Disable Anonymous login and enter the read-only account’s Bind DN and Password.
Only enable Append base DN if the firewall should append the Base DN to an incomplete Bind DN during the bind.
For a secure connection, make a deliberate decision about whether to enable Validate server certificate. 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

Enter the starting point of the user search under Base DN. Get base DN can retrieve the search base offered by the server.
Set the attribute with the login name as Authentication attribute, often uid or mail.
Enter Display name attribute and Email address attribute to match the user object, for example cn and mail.
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.
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 expiry are handled.
Run Test connection and save with Save.

Display name attribute and Email address attribute are optional fields for a generic LDAP server. The display name makes the local user object easier to identify; the email attribute supplies the associated address. For Google LDAP group creation, however, the email attribute is required. An Expiry date attribute denotes account expiry, not the duration of a VPN session. Sophos specifies Date in its general tutorial example and expiry for Google; the appropriate attribute name depends on the relevant schema.

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 authorisation 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 the codes or messages actually transmitted 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.

Before any automated LDAP add/edit operation: The API references for SFOS 22 and 23 are contradictory for IntegrationType: the sample specifies LooseIntegration/TightIntegration and marks DisplayNameAttribute, EmailAddressAttribute, GroupNameAttribute and ExpiryDateAttribute with the comment Only For Tight Integration; the parameter table describes both modes but allows only 1. Do not infer from this that either mode is supported, what 1 means or whether conditional attributes may be omitted. The sample is not a ready-to-send payload; its text values for switches and connection security also do not match the encodings in the tables. Before making a change, check the schema or API reference for the target version and inspect the actual target configuration and a related API response on a read-only basis. If the mapping remains unclear, do not run automation based on it; instead, use the verified GUI procedure or clarify the API requirements with Sophos Support. The GUI steps described above remain separate from this; Test connection and real tests for identity, groups, account expiry where applicable, and every service used remain required.

Enable LDAP for the required services

Open Authentication > Services.
Under Firewall authentication methods, move the LDAP server to Selected authentication servers. Place it first if it should respond as the primary server.
For Default group, select the prepared group LDAP-Benutzer and click Apply.
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.
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.

Additional steps for administrator logins: A user authenticated externally via LDAP is initially created as a standard user on first login, even if they have an administrator role in the directory. First, log in with the intended account to an enabled service such as the user portal or VPN portal. Then, using the existing local administrator login, edit the newly created user under Authentication > Users, set User type to Administrator, select a Profile limited to the required permissions, and save with Save. Selecting the server under Administrator authentication methods alone is not sufficient. Then test the WebAdmin login and both permitted and prohibited administrative actions with this account; continue to retain the tested local recovery login.

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 dialogue box 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 credentials. Google Secure LDAP explains whether the service is available for your Google edition; the access permissions must match the intended user and group scope.

The procedure documented by Sophos in the Google Admin Console can be followed as described below:

Under Apps > LDAP, start with ADD CLIENT, enter an LDAP client name and a Description, and select CONTINUE. A unique name such as Sophos-Firewall-Pilot makes subsequent identification easier.
Limit the Access permissions to the required user and group scope and confirm with ADD LDAP CLIENT.
Select Download certificate. The ZIP contains the certificate file .cer and the private key .key. Extract both files to a protected working folder and record the location for the subsequent import. The private key must not be included in tickets or stored on unprotected shares.
Proceed with CONTINUE TO CLIENT DETAILS, open the Authentication card and select GENERATE NEW CREDENTIALS. Securely record Username and Password before selecting CLOSE; these values are later used as Bind DN and Password, not the credentials of a Google administrator.

The Google credentials do not replace the client certificate. For this variant, Sophos Firewall requires both the certificate with its private key and the generated bind 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, under Certificates > Certificates > Add, select the format CER (.cer) 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.

Assign a unique certificate name during import. Use Choose File to select the extracted .cer for Certificate and the corresponding .key for Private key, confirm each selection with Open, and finally select Save. Only after saving can this certificate be selected under Client certificate in the LDAP server configuration.

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 Sophos instructions for Google Secure LDAP do not explicitly set Validate server certificate in their list of values. This cannot be taken as a requirement either to enable or to disable it; decide on the option according to the general TLS procedure and your own trust chain. An indication that a Google client certificate is untrusted is not a reason to disable validation of the remote server certificate.

Check the Google connection with Test connection and save the server with Save. Then prepare a local LDAP group as described above and select the Google server under Authentication > Services for the required services. For Google too, creating the server object alone does not make any service usable; the subsequent pilot login checks identity, group and authorisation.

An acceptance test covers connection, identity, and authorisation:

Test connection must confirm the connection and bind credentials.
Under Authentication > Services, check the server list, order and inheritance for each method used. The Default group belongs to Firewall authentication methods.
Log in to the intended service with a pilot user. On the first login, the firewall creates the externally authenticated user locally.
Under Authentication > Users, verify that the user and group appear as expected.
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.
Verify not only the login but also the intended policy or test rule. For SSL VPN, test permitted and blocked resources, taking the applicable user and group policies into account; do not infer effective permissions from a restrictive user policy alone. Then use an incorrect password as a negative test.
For user login, authorisation and accounting, check access_server.log; for VPN portal problems, additionally check vpnportal.log.
If an expiry attribute is used, include a test account with a known expiry status.

If the schema values are unclear, an administrator can make a read-only query of the user object 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 method 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 command. -W prompts for the bind password interactively. Adapt the filter (uid=max.muster) to the configured Authentication attribute. '*' and '+' can output many user and operational attributes containing personal data. Anonymise 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 actual returned 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-specific settings, group policy, group mapping and the relevant firewall or VPN rule separately. For SSL VPN, include all applicable user and group policies and the resources actually permitted; a restrictive user policy alone is not sufficient. The full diagnostic model is explained in Troubleshoot authentication failures systematically.
Portal login works, WebAdmin login does not: Under Authentication > Users, check the manually assigned administrator role and the Profile. Then check the server selection under Administrator authentication methods and the applicable device access rules. Do not give up the local recovery login before the new method has been tested.

Roll back safely

In the event of a failed rollout, first restore the previously documented server selection, order, and inheritance for each affected method. Under Firewall authentication methods, also restore the previous Default group. 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.