Connecter un serveur LDAP générique à Sophos Firewall

Active Directory est le serveur d’authentification le plus courant sur Sophos Firewall, mais ce n’est pas le seul. Qui exploite OpenLDAP, 389 Directory Server, FreeIPA, Google Secure LDAP ou un autre annuaire LDAP pur peut relier Sophos Firewall de la même manière comme client LDAP. Le type de serveur s’appelle volontairement LDAP server, et non Active Directory, même si Active Directory est lui-même techniquement un annuaire LDAP.

Cet article traite spécifiquement du cas générique : un service d’annuaire sans les champs spécifiques à AD comme les noms de domaine ou Kerberos. Pour les environnements Active Directory avec LDAPS, import de groupes et AD SSO, voir plutôt Connecter Active Directory à Sophos Firewall. Pour l’authentification basée sur RADIUS, par exemple via Microsoft NPS ou une passerelle MFA, Configurer un serveur RADIUS Sophos Firewall est l’article approprié.

Quand un serveur LDAP générique convient

Un serveur LDAP sur Sophos Firewall est pertinent lorsque :

• les utilisateurs et groupes se trouvent dans un annuaire qui n’est pas Active Directory, par exemple OpenLDAP, 389 Directory Server ou FreeIPA,
• un annuaire cloud propose une interface LDAP, par exemple Google Secure LDAP ou un proxy LDAP devant Entra ID ou Okta,
• plusieurs systèmes s’authentifient déjà contre le même annuaire LDAP et le firewall doit utiliser la même source,
• il ne faut ni Kerberos ni NTLM, une simple authentification par bind suffit.

Si un Windows Server avec Active Directory Domain Services est utilisé à la place, le type de serveur AD spécialisé est en général le meilleur choix, car il couvre proprement des champs supplémentaires comme les noms de domaine. Le type de serveur LDAP générique fonctionne aussi avec Active Directory, mais couvre moins d’automatismes spécifiques à AD.

Prérequis

• Accès au WebAdmin de Sophos Firewall.
• Joignabilité du serveur LDAP depuis le firewall, généralement le port 389 (Plaintext/StartTLS) ou 636 (LDAPS).
• Un compte de bind avec droits de lecture sur le sous-arbre concerné, spécifié comme Distinguished Name (DN).
• Le Base DN sous lequel les utilisateurs sont recherchés, par exemple ou=people,dc=firma,dc=local.
• Connaissance de l’attribut qui sert de nom de connexion, souvent uid, sAMAccountName ou mail.
• En cas de connexion chiffrée : le certificat serveur ou la chaîne de certificats, si le firewall doit le valider.

⚠️ Un compte de bind ne devrait avoir que des droits de lecture sur le sous-arbre nécessaire. Il n’est pas utilisé pour des modifications administratives dans l’annuaire, mais uniquement pour authentifier les requêtes utilisateur du firewall auprès du serveur LDAP.

Créer le serveur LDAP

1. Ouvrir Authentication > Servers.
2. Sélectionner Add et choisir LDAP server comme Server type.
3. Sous Server name, donner un nom unique, par exemple LDAP_Firma_Intern.
4. Sous Server IP/domain, saisir l’adresse IP ou le nom DNS du serveur LDAP.
5. Sous Version, choisir la version LDAP prise en charge par le serveur, généralement Version 3.
6. Sous Connection security, choisir entre Plaintext, SSL/TLS ou STARTTLS.
7. Sous Port, définir le port approprié si le port standard n’est pas utilisé.
8. Désactiver Anonymous login si le serveur n’autorise pas les requêtes de bind anonymes.
9. Sous Bind DN, saisir le compte technique comme Distinguished Name, par exemple cn=svc-sophos,ou=service,dc=firma,dc=local.
10. Saisir le Password correspondant.
11. Sous Base DN, saisir le périmètre de recherche des utilisateurs, par exemple ou=people,dc=firma,dc=local.
12. Sous Authentication attribute, saisir le champ qui sert de nom de connexion, souvent uid.
13. Définir éventuellement Display name attribute et Email address attribute, par exemple cn et mail.
14. Définir éventuellement Group name attribute si les appartenances aux groupes doivent être évaluées.
15. Exécuter Test connection et vérifier le résultat.
16. Sélectionner Save.

Les champs en un coup d’oeil :

Un Test connection réussi prouve seulement que le serveur, le port, le compte de bind et la base de recherche sont fondamentalement joignables. Il faut ensuite vérifier avec un véritable utilisateur de test si les bons utilisateurs sont trouvés et si les groupes sont correctement associés.

Bien choisir le chiffrement

Pour les environnements productifs, la connexion entre le firewall et le serveur LDAP devrait être chiffrée, soit via LDAPS sur le port 636, soit via STARTTLS sur le port classique 389. Le LDAP en clair envoie les mots de passe de bind et parfois des données utilisateur sans chiffrement et ne devrait être utilisé que dans des scénarios de test internes strictement contrôlés.

Avec Validate server certificate, le firewall vérifie si le certificat présenté par le serveur LDAP est digne de confiance. Avec des certificats autosignés, comme ceux utilisés par exemple par Google Secure LDAP, le certificat peut être marqué comme non fiable bien que la connexion fonctionne. Dans ce cas, il faut décider consciemment si la vérification du certificat est adaptée ou si le certificat est importé dans le firewall.

Exemple : Google Secure LDAP

Google Secure LDAP montre bien comment un annuaire cloud est connecté via LDAP générique :

• Server IP/domain : ldap.google.com
• Port : 636
• Version : 3
• Connection security : SSL/TLS
• Bind DN et Password : identifiants issus des LDAP Client Credentials générés dans la Google Admin Console.
• Certificat : le certificat client émis par Google avec sa clé privée est déposé sur le firewall.
• Attributs : uid pour la connexion, cn pour le nom affiché, mail pour l’adresse e-mail, memberOf pour les groupes.

Cet exemple peut être transposé à d’autres fournisseurs LDAP avec une structure similaire. Ce qui compte toujours, c’est de savoir quel attribut le fournisseur remplit réellement pour le nom de connexion, le nom affiché, l’e-mail et l’appartenance aux groupes.

Bien saisir le Bind DN et le Base DN

La source d’erreur la plus fréquente lors de la création d’un nouveau serveur LDAP est une syntaxe DN mal écrite ou mal comprise.

Règles importantes :

• Un DN s’écrit de la partie la plus spécifique à la plus générale, par exemple cn=svc-sophos,ou=service,dc=firma,dc=local.
• Le Base DN pour la recherche des utilisateurs doit être le sous-arbre où se trouvent réellement les objets utilisateur concernés, pas forcément la racine de l’annuaire.
• Si les utilisateurs se trouvent dans plusieurs unités organisationnelles, le Base DN doit être choisi assez haut dans l’arbre pour inclure tous les conteneurs concernés.
• Append base DN détermine si le Base DN est en plus ajouté au Bind DN. Cela dépend du serveur et devrait être testé spécifiquement en cas de problème.

Si le Base DN est choisi trop étroitement, le firewall peut signaler un test de connexion réussi, mais ne trouve ensuite aucun utilisateur. Si le Base DN est choisi trop largement, la recherche peut durer inutilement longtemps ou inclure des objets indésirables.

Associer groupes et attributs

Pour les règles de firewall, les Web Policies ou les autorisations VPN par groupe, le Group name attribute est déterminant. Il détermine quel attribut LDAP le firewall interprète comme appartenance à un groupe.

Schémas typiques :

• Les annuaires avec un schéma classique groupOfNames ou posixGroup utilisent souvent un attribut comme memberOf ou évaluent l’appartenance aux groupes via des références inverses.
• Les annuaires cloud avec proxy LDAP, par exemple Google Secure LDAP, fournissent souvent les groupes directement dans l’attribut memberOf de l’objet utilisateur.
• Si le schéma n’est pas clair, un navigateur LDAP ou un outil en ligne de commande comme ldapsearch aide à examiner une fois complètement l’objet utilisateur avant de configurer le firewall.

Après la configuration, il faut tester au moins un utilisateur de chaque groupe concerné. Une seule connexion réussie ne prouve pas que l’association des groupes fonctionne correctement pour tous les groupes.

Activer le serveur LDAP pour les services

Un serveur LDAP créé n’authentifie encore personne de lui-même. Il doit en plus être associé sous Authentication > Services au service souhaité, par exemple VPN Portal, SSL VPN, Captive Portal ou connexion admin.

Déroulement pratique :

1. Ouvrir Authentication > Services.
2. Sélectionner le service concerné, par exemple Firewall authentication methods ou VPN.
3. Ajouter le serveur LDAP nouvellement créé comme source d’authentification.
4. Vérifier l’ordre si plusieurs serveurs sont utilisés en parallèle.
5. Vérifier le service prévu avec un utilisateur de test.

Si plusieurs serveurs d’authentification sont actifs en même temps, par exemple LDAP et utilisateurs locaux, l’ordre devrait être choisi consciemment. Le firewall interroge les serveurs dans l’ordre saisi.

Tester et valider la connexion

Après l’enregistrement, la configuration devrait être testée à plusieurs niveaux :

1. Test connection dans l’écran du serveur : confirme la joignabilité, le compte de bind et le Base DN.
2. Connecter un utilisateur de test au service cible : confirme que l’authentification fonctionne réellement.
3. Vérifier l’appartenance aux groupes : confirme que le Group name attribute est correctement évalué.
4. Tester un mauvais utilisateur ou un mauvais mot de passe : confirme que les connexions échouées sont proprement rejetées.
5. Vérifier le Log Viewer : montre si les requêtes d’authentification arrivent et sont traitées comme prévu.

Un utilisateur de test qui se connecte avec succès mais n’est pas associé au groupe attendu indique généralement un Group name attribute incorrect ou un schéma de groupes inattendu.

Erreurs typiques

• Syntaxe DN incorrecte : Bind DN ou Base DN sont inversés, mal écrits ou utilisent de mauvais séparateurs. Vérifier la syntaxe par rapport au schéma de l’annuaire.
• Base DN choisi trop étroitement : le test de connexion réussit, mais les utilisateurs réels ne sont pas trouvés. Placer le Base DN plus haut dans l’arbre de l’annuaire.
• Mauvais port ou mauvais chiffrement : LDAPS sur le port 389 ou Plaintext sur le port 636 ne fonctionne pas. Le port et la Connection security doivent correspondre.
• Certificat non fiable : avec des certificats autosignés, le firewall peut classer la connexion comme non fiable. Importer consciemment le certificat ou adapter spécifiquement la validation.
• Anonymous login actif alors que le serveur le refuse : le bind échoue. Désactiver Anonymous login et saisir Bind DN/Password.
• Attribut de groupe ne correspondant pas au schéma : la connexion fonctionne, mais les policies de groupe ne s’appliquent pas. Vérifier l’attribut par rapport au schéma LDAP réel, par exemple avec ldapsearch.
• Serveur LDAP non associé sous Authentication > Services : le serveur est créé mais n’est utilisé par aucun service. Rattraper l’association sous Authentication > Services.
• Plusieurs serveurs d’authentification dans le mauvais ordre : un autre serveur répond en premier et provoque un comportement inattendu. Vérifier l’ordre sous Authentication > Services.

FAQ