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

Avec le type de serveur LDAP server, Sophos Firewall authentifie les utilisateurs provenant d’OpenLDAP, de 389 Directory Server, de FreeIPA, de Google Secure LDAP et d’autres répertoires LDAP. La procédure complète comporte quatre parties : créer un groupe local, connecter le serveur LDAP de manière sécurisée, activer le serveur sous Authentication > Services, puis vérifier l’authentification et l’affectation au groupe avec un utilisateur réel.

Pour un environnement Windows Active Directory avec LDAPS, importation de groupes ou AD SSO, l’article Connecter Active Directory à Sophos Firewall est plus adapté. L’authentification RADIUS via Microsoft NPS ou une passerelle MFA est décrite dans Configurer un serveur RADIUS sur Sophos Firewall.

Pour remplacer le type de serveur eDirectory natif avant SFOS 23, la procédure Migrer eDirectory avant SFOS 23 présente l’inventaire complet, le choix de la cible, le fonctionnement parallèle et le retour arrière.

Prérequis

accès WebAdmin à Sophos Firewall
accessibilité du serveur LDAP depuis le pare-feu, généralement via le port 389 pour STARTTLS ou 636 pour SSL/TLS
compte de liaison disposant d’un accès en lecture à la partie nécessaire du répertoire
Bind DN et Base DN, par exemple cn=svc-sophos,ou=service,dc=example,dc=net et ou=people,dc=example,dc=net
attributs utilisateur effectivement employés, tels que uid, cn, mail et un attribut de groupe
chaîne de confiance CA appropriée et résolution DNS fonctionnelle lorsque le certificat est validé

⚠️ Un compte de liaison ne doit disposer que de droits de lecture sur le sous-arbre nécessaire. Il ne sert pas à effectuer des modifications administratives dans le répertoire, mais uniquement à authentifier auprès du serveur LDAP les requêtes utilisateur du pare-feu.

Ajouter le serveur LDAP

Préparer le groupe LDAP local

Ouvrir Authentication > Groups et sélectionner Add.
Créer un groupe clairement nommé, par exemple Utilisateurs-LDAP.
Définir l’accès, les quotas de temps et les autres stratégies de groupe en fonction de l’usage prévu, puis enregistrer.

Ce groupe sera ensuite utilisé comme Default group. Il n’interdit pas automatiquement l’accès : les stratégies attribuées au groupe et les règles du service concerné déterminent ce qui est autorisé.

La logique générale des groupes avec un Default Group restrictif, les exceptions utilisateur, le pilote et le retour arrière est décrite dans Gérer les groupes d’utilisateurs Sophos Firewall en sécurité ; l’affectation propre à LDAP découle ensuite de l’attribut de groupe et du schéma de l’annuaire.

Configurer la connexion et la liaison

Ouvrir Authentication > Servers et sélectionner Add.
Sélectionner LDAP server comme Server type.
Saisir un Server name explicite, par exemple LDAP-Entreprise.
Sous Server IP/domain, saisir le nom DNS du serveur LDAP. Lorsque la validation du certificat est active, il doit correspondre à un nom figurant dans le certificat du serveur.
Utiliser Version 3, sauf si le répertoire exige une autre version. Google Secure LDAP ne prend en charge que la version 3.
Pour un environnement de production, sélectionner SSL/TLS ou STARTTLS ainsi que le port correspondant.
Désactiver Anonymous login et saisir le Bind DN et le Password du compte de lecture.
Activer Append base DN uniquement si le serveur LDAP attend que la Base DN soit ajoutée lors de la liaison.
Activer Validate server certificate dès que le nom, le DNS et la confiance CA sont correctement configurés. Un Client certificate n’est nécessaire que si le service LDAP exige une authentification mutuelle par certificat.

Saisir la base de recherche et les attributs

Sous Base DN, saisir le point de départ de la recherche d’utilisateurs, par exemple ou=people,dc=example,dc=net. Get base DN peut récupérer la base de recherche proposée par le serveur.
Définir Authentication attribute sur l’attribut de connexion, généralement uid ou mail.
Renseigner Display name attribute et Email address attribute conformément à l’objet utilisateur, par exemple cn et mail.
Sous Group name attribute, saisir l’attribut à partir duquel le pare-feu reçoit les informations de groupe de l’utilisateur. Sophos recommande memberOf, mais la valeur correcte dépend du schéma du répertoire.
Si le répertoire fournit une date d’expiration de compte, saisir l’Expiry date attribute correspondant.
Exécuter Test connection, puis enregistrer avec Save.

Selon Sophos, Test connection vérifie la connexion et les identifiants. Seule une authentification réelle permet de savoir si la Base DN couvre tous les utilisateurs nécessaires et si les groupes sont correctement attribués.

Choisir le bon chiffrement

Le protocole LDAP en clair transmet les identifiants sans chiffrement et convient tout au plus à un test isolé. En production, la connexion doit être protégée par SSL/TLS, généralement sur le port 636, ou par STARTTLS, généralement sur le port 389.

Il faut distinguer deux rôles de certificat :

Validate server certificate vérifie l’identité du serveur LDAP distant. Server IP/domain doit correspondre à un nom DNS valide dans le certificat, c’est-à-dire au Common Name ou à un Subject Alternative Name. Si le pare-feu ne peut pas résoudre ce nom, ajouter une entrée DNS appropriée sous Network > DNS > DNS host entry. Configurer et tester les DNS Host Entries sur Sophos Firewall explique le TTL, la résolution inverse et le test du résolveur. L’autorité de certification émettrice doit également être approuvée.
Client certificate identifie le pare-feu auprès d’un service LDAP qui exige une authentification mutuelle par certificat. Ce certificat ne remplace pas la validation du certificat du serveur.

En cas d’erreur TLS, corriger d’abord le nom du serveur, la résolution DNS, la validité et la chaîne de certification. La désactivation de la validation du certificat du serveur ne doit pas être la solution par défaut.

Saisir correctement le Bind DN et la Base DN

La cause d’erreur la plus fréquente avec un nouveau serveur LDAP est une syntaxe DN mal écrite ou mal comprise.

Un DN va de l’objet spécifique jusqu’à la racine du répertoire, par exemple cn=svc-sophos,ou=service,dc=example,dc=net.
La Base DN commence à l’endroit où doit débuter la recherche d’utilisateurs. Si les utilisateurs se trouvent dans plusieurs unités d’organisation, elle doit être placée assez haut dans l’arborescence pour tous les inclure.
Une Base DN trop étroite ne renvoie aucun utilisateur correspondant, même si le serveur est accessible. Une base de recherche inutilement large peut ralentir les recherches et inclure des objets indésirables.
Append base DN ajoute la Base DN à un Bind DN incomplet lors de la liaison. Avec un DN déjà complet, l’option reste normalement désactivée ; le comportement du serveur LDAP fait foi.

Activer les groupes et les services

Group name attribute n’est pas un réglage universel pour toutes les structures de groupes LDAP. Lors de la connexion, le pare-feu lit l’attribut configuré dans l’objet utilisateur et utilise les informations de groupe renvoyées pour l’affectation. Sophos recommande memberOf, et Google Secure LDAP utilise cette valeur. OpenLDAP, 389-ds ou FreeIPA peuvent toutefois exiger une autre valeur selon le schéma, l’overlay et l’objet utilisateur.

Il ne faut pas déduire l’attribut utilisateur du seul type de groupe groupOfNames ou posixGroup. Ce qui compte, c’est ce que l’objet utilisateur réel renvoie et si le groupe correspondant est correctement représenté sur le pare-feu. Si le pare-feu ne trouve aucune affectation de groupe correspondante, l’utilisateur est placé dans le Default group configuré.

Activer ensuite le serveur :

Ouvrir Authentication > Services.
Sous Firewall authentication methods, sélectionner le serveur LDAP et le déplacer à la position souhaitée dans Selected authentication servers. Le pare-feu interroge plusieurs serveurs dans cet ordre.
Sélectionner le groupe Utilisateurs-LDAP créé précédemment comme Default group, puis cliquer sur Apply.
Si les utilisateurs doivent se connecter au User Portal, au VPN Portal, via SSL VPN, à un autre service VPN ou en tant qu’administrateurs, sélectionner également le serveur LDAP sous la méthode d’authentification correspondante.

Configurer Google Secure LDAP

Avant de configurer le pare-feu, créer un client LDAP dans la console d’administration Google. Définir ses droits d’accès, télécharger le certificat avec sa clé privée et générer des identifiants distincts. Le mot de passe ne s’affiche plus après la fermeture de la boîte de dialogue Google.

Importer le certificat client Google avec son certificat et sa clé privée sous Certificates > Certificates > Add. Sophos Firewall peut l’afficher comme non approuvé parce qu’il est autosigné par Google, mais il fonctionne néanmoins pour l’authentification du client. Cet affichage ne concerne pas la validation du certificat du serveur.

Utiliser les valeurs suivantes pour le serveur LDAP :

Server IP/domain : ldap.google.com
Version : 3
Connection security : SSL/TLS
Port : 636
Anonymous login : désactivé
Bind DN et Password : les identifiants LDAP Google générés
Append base DN : désactivé
Client certificate : le certificat Google importé
Base DN : la saisir ou la récupérer avec Get base DN
Authentication attribute : UID
Display name attribute : CN
Email address attribute : mail
Group name attribute : memberOf
Expiry date attribute : expiry

mail est requis pour créer des groupes LDAP Google. Après l’enregistrement, suivre les mêmes étapes que pour un répertoire local : définir le groupe LDAP local, activer le serveur sous Authentication > Services, puis tester une connexion réelle et son affectation au groupe.

Vérifier la connexion et l’affectation aux groupes

Une validation fiable comprend plusieurs niveaux :

Test connection confirme la connexion et les identifiants de liaison.
Un utilisateur se connecte au service prévu, par exemple au VPN Portal ou au Captive Portal.
Sous Authentication > Users, vérifier que l’utilisateur et le groupe apparaissent comme prévu.
Si plusieurs groupes LDAP sont utilisés, tester au moins un utilisateur de chaque groupe concerné. Une stratégie ou une règle de test confirme que la connexion et l’autorisation du groupe correspondant fonctionnent.
Un mot de passe incorrect est refusé et le Log viewer affiche une erreur d’authentification compréhensible.

Si le schéma n’est pas clair, un administrateur peut examiner l’objet utilisateur en lecture seule depuis un système d’administration Linux ou depuis le serveur LDAP :

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 demande le mot de passe de liaison de manière interactive afin qu’il ne soit pas enregistré dans l’historique du shell. '*' affiche les attributs normaux et '+' les attributs opérationnels ; adapter le filtre de recherche si un autre attribut de connexion est utilisé. Cette commande ne doit pas être exécutée dans l’Advanced Shell de Sophos Firewall. Il faut vérifier que l’objet utilisateur renvoie réellement les attributs et les valeurs de groupe attendus. La sortie peut contenir des données personnelles du répertoire et doit être anonymisée avant d’être jointe à un ticket ou partagée.

Erreurs courantes

Aucune connexion : Vérifier le routage, le DNS, le port et Connection security. Contrôler ensuite le Bind DN, le mot de passe et Anonymous login.
Erreur TLS ou de certificat : Vérifier les noms DNS du certificat du serveur, la résolution DNS, la validité et la chaîne de certification. Ne pas désactiver la validation du certificat du serveur comme première mesure.
Test connection fonctionne, mais l’utilisateur est introuvable : La Base DN est souvent trop étroite ou Authentication attribute ne correspond pas au nom de connexion.
La connexion fonctionne, mais l’utilisateur est placé dans le Default group : Vérifier le Group name attribute sur l’objet utilisateur réel, le mappage des groupes locaux et l’ordre des groupes. memberOf est un exemple fréquent, mais n’est pas garanti pour tous les schémas.
Google Secure LDAP ne se lie pas : Vérifier la version 3, le port 636, Anonymous login désactivé, Append base DN désactivé, les identifiants et le certificat client Google.
Le serveur est configuré mais n’est pas utilisé : Vérifier l’affectation, l’ordre et le Default group sous Authentication > Services.
La recherche est lente ou renvoie des comptes indésirables : Limiter la Base DN au sous-arbre nécessaire.
Un autre serveur d’authentification répond en premier : Corriger l’ordre des serveurs sélectionnés pour le service concerné.