Aller au contenu
Avanet

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

Sophos Firewall peut authentifier les utilisateurs via le type de serveur LDAP server en fonction des attributs d’annuaire et des appartenances à des groupes. En pratique, quatre étapes sont nécessaires : préparer un groupe local, connecter le serveur LDAP, le sélectionner sous Authentication > Services pour le service souhaité, puis vérifier la connexion et les autorisations avec de vrais comptes de test.

OpenLDAP, 389 Directory Server ou FreeIPA sont des candidats typiques pour une connexion LDAP générique, mais ne sont pas des produits interchangeables. Les attributs, les valeurs de groupe renvoyées et l’expiration des comptes diffèrent selon le schéma. Ce guide fournit donc un exemple adaptable ; les valeurs doivent être vérifiées sur l’objet utilisateur réel. Google Secure LDAP est décrit plus bas comme une variante distincte documentée par Sophos.

Pour Windows Active Directory avec LDAPS, importation de groupe ou AD SSO, Connecter Active Directory au pare-feu Sophos est une meilleure solution. RADIUS via Microsoft NPS ou une passerelle MFA est traité dans Configurer un serveur RADIUS sur Sophos Firewall. Si vous devez remplacer le type de serveur eDirectory natif avant SFOS 23, vous pouvez trouver le processus de migration complet dans Migrer eDirectory avant SFOS 23.

Préparer les valeurs et le retour arrière

Prérequis :

  • Accès WebAdmin à Sophos Firewall ;
  • accessibilité du serveur LDAP depuis le pare-feu sur le port configuré sur le serveur ;
  • un compte Bind avec des droits de lecture sur la zone de répertoire requise ;
  • le DN de liaison et le DN de base, par exemple cn=svc-sophos,ou=service,dc=example,dc=net et ou=people,dc=example,dc=net ;
  • les attributs de login, d’affichage, d’adresse email, de groupe et, le cas échéant, d’expiration du compte ;
  • si la validation du certificat est activée, un nom de serveur résoluble et la chaîne de confiance CA appropriée.

Les valeurs de départ habituelles sont le port 389 pour STARTTLS et 636 pour SSL/TLS. Il ne s’agit pas d’exigences fixes de SFOS : un répertoire peut utiliser un port différent, qui doit correspondre à Connection security et à la configuration du serveur.

⚠️ Le compte Bind ne nécessite pas d’autorisations administratives en écriture. Limitez ses droits de lecture à la sous-arborescence et aux attributs dont le pare-feu a besoin pour les requêtes des utilisateurs.

Avant de passer sous Authentication > Services, documentez les serveurs sélectionnés, leur ordre et les options d’héritage pour chaque méthode concernée. Enregistrez également le Default group précédent sous Firewall authentication methods. Cela vous permet d’annuler la modification sans supprimer hâtivement de nouveaux objets.

Distinguer le DN de liaison, le DN de base et les attributs

Un DN s’étend de l’objet spécifique à la racine du répertoire. cn=svc-sophos,ou=service,dc=example,dc=net désigne le compte de liaison dans l’exemple. Le DN de base, quant à lui, spécifie le point de départ de la recherche d’utilisateur, tel que ou=people,dc=example,dc=net.

Un DN de base trop étroit ne trouvera pas tous les utilisateurs dont vous avez besoin. Une base de recherche inutilement large peut ralentir les recherches et inclure des éléments indésirables. Append base DN ajoute le DN de base à un DN de liaison incomplet lors de la liaison ; Si le DN est déjà complet, l’option reste généralement désactivée. Le comportement du serveur LDAP utilisé est déterminant.

Les attributs proviennent également du schéma d’annuaire. uid, cn, mail et memberOf sont des exemples et non des spécifications universelles. Sophos recommande memberOf comme Group name attribute, mais utilise GID dans son propre exemple de configuration générale. Par conséquent, la valeur de retour, le mappage de groupe local et les appartenances multiples doivent être vérifiés auprès de vrais utilisateurs de test.

Choisir le chiffrement et les certificats

Plaintext envoie les informations d’identification de l’utilisateur non chiffrées et ne constitue pas une bonne configuration de production. SSL/TLS chiffre la connexion dès le départ ; STARTTLS met à niveau une connexion LDAP initialement non chiffrée vers TLS.

Pour Validate server certificate, le nom spécifié dans le certificat de serveur et résolvable par le pare-feu doit être sous Server IP/domain. Sophos l’appelle CNAME dans l’aide SFOS 22, tandis que la même description de champ ailleurs mentionne simplement l’adresse IP d’un serveur. Le nom du certificat est donc le choix sûr pour un déploiement TLS contrôlé. Si le pare-feu ne peut pas le résoudre, une entrée peut être créée sous Network > DNS > DNS host entry. Le TTL, la recherche inversée et le test du résolveur sont expliqués dans Configurer les entrées d’hôte DNS sur Sophos Firewall.

Validate server certificate vérifie le certificat du serveur LDAP distant. Le Client certificate facultatif spécifie un certificat que le pare-feu utilise pour établir une connexion sécurisée au service LDAP ; Google Secure LDAP nécessite explicitement le certificat généré par Google. Pour les erreurs TLS, corrigez d’abord le nom, le DNS, l’heure, la validité et la chaîne de confiance au lieu de désactiver la vérification du certificat du serveur dans un premier temps.

Configurer le groupe et le serveur LDAP

Préparer le groupe local

  1. Ouvrez Authentication > Groups et sélectionnez Add.
  2. Entrez un Group name unique, par exemple LDAP-Benutzer.
  3. Sélectionnez le Group type adapté au mode de connexion prévu. Normal nécessite une connexion utilisateur ; Clientless contrôle l’accès en fonction d’une adresse IP.
  4. Définissez les politiques d’utilisateur, d’accès à distance et de connexion requises et enregistrez-les avec Save.

Le groupe sera ensuite utilisé comme Default group. Il n’autorise ni ne bloque le trafic à lui seul : ses stratégies et les règles du service concerné déterminent l’accès. Les stratégies propres à un utilisateur sont prioritaires sur celles du groupe. La logique complète des groupes, avec phase pilote, exceptions propres aux utilisateurs et Main Group, est décrite dans Gérer les groupes d’utilisateurs Sophos Firewall en toute sécurité.

Configurer la connexion et la liaison

  1. Ouvrez Authentication > Servers et sélectionnez Add.
  2. Sélectionnez LDAP server comme Server type.
  3. Attribuez un Server name unique, par exemple LDAP-Firma.
  4. Saisissez l’adresse IP du serveur ou le nom de domaine sous Server IP/domain. Pour Validate server certificate, utilisez le nom résoluble du certificat du serveur.
  5. Sélectionnez la Version 2 ou 3 prise en charge par le serveur. Google Secure LDAP nécessite la version 3.
  6. Réglez Connection security et Port ensemble. Pour un environnement de production, utilisez SSL/TLS ou STARTTLS.
  7. Désactivez Anonymous login et saisissez Bind DN et Password du compte de lecture.
  8. Activez Append base DN uniquement si le serveur doit ajouter le DN de base lors de la liaison.
  9. Si la connexion est sécurisée, décidez explicitement d’activer ou non Validate server certificate. Pour les serveurs LDAP standard, l’activation de la validation après la configuration correcte du nom, du DNS et de la chaîne de confiance constitue le choix sûr en production. Google Secure LDAP suit le cas particulier décrit ci-dessous. Sélectionnez un Client certificate requis dans la liste.

Définir la base de recherche et les attributs

  1. Saisissez le point de départ de la recherche d’utilisateur sous Base DN. Get base DN permet d’obtenir la base de recherche proposée par le serveur.
  2. Définissez l’attribut avec le nom de connexion comme Authentication attribute, souvent uid ou mail.
  3. Renseignez Display name attribute et Email address attribute en fonction de l’objet utilisateur, par exemple cn et mail.
  4. Saisissez l’attribut de groupe renvoyé sur l’objet utilisateur sous Group name attribute. memberOf est la recommandation de Sophos, mais doit correspondre au schéma et au format de retour.
  5. Saisissez le Expiry date attribute qui correspond au schéma. Si aucun attribut de ce type n’existe, vérifiez avant le déploiement si le formulaire accepte une valeur vide et comment les comptes sans expiration sont gérés.
  6. Exécutez Test connection et enregistrez avec Save.

Selon Sophos, Test connection vérifie la connexion et les identifiants de liaison. Le test ne prouve ni que le DN de base inclut tous les utilisateurs ni qu’une autorisation de groupe ou de service s’applique correctement. Pour cela, une véritable connexion est requise.

Activer LDAP pour les services requis

  1. Ouvrez Authentication > Services.
  2. Sous Firewall authentication methods, déplacez le serveur LDAP vers Selected authentication servers. S’il doit répondre en premier, mettez-le en première position.
  3. Sélectionnez le groupe préparé LDAP-Benutzer comme Default group et cliquez sur Apply.
  4. Sélectionnez le serveur séparément pour toutes les méthodes réellement utilisées : User portal authentication methods, VPN portal authentication methods, VPN (IPsec/dial-in/L2TP/PPTP) authentication methods, Administrator authentication methods et SSL VPN authentication methods.
  5. Utilisez les options d’héritage telles que Set authentication methods same as firewall, Same as firewall ou Same as VPN uniquement si la liste de serveurs dérivée est prévue.

Un maximum de 20 serveurs peuvent être sélectionnés par méthode d’authentification. S’il existe plusieurs serveurs, le pare-feu les interrogera dans l’ordre indiqué. La méthode d’authentification des administrateurs ne s’applique pas au Super Administrateur. Pour L2TP et PPTP, Sophos documente uniquement PAP pour LDAP ; cette combinaison ne doit pas être réintroduite sans vérification en raison du protocole et des procédures VPN désormais obsolètes.

Configurer le LDAP sécurisé de Google

Avant de configurer le pare-feu, créez un client LDAP dans la console d’administration Google sous Apps > LDAP. Ses Access permissions sont limités, le certificat et sa clé privée sont téléchargés et des données d’accès séparées sont générées. Le mot de passe n’est plus visible après la fermeture de la boîte de dialogue.

Activez ensuite le client sous Service status avec ON for everyone et enregistrez avec SAVE. Cet état de service active le client mais ne remplace pas les Access permissions définies précédemment.

Avant d’importer le certificat, vérifiez sous Administration > Time si le pare-feu obtient l’heure correcte via NTP. Selon Sophos, une horloge manuelle mal réglée peut entraîner l’échec de l’importation des certificats. Sélectionnez ensuite le format CER (.cer) sous Certificates > Certificates > Add et importez Certificate et Private key à partir du téléchargement Google. Le certificat peut sembler peu fiable car Google le signe lui-même ; Sophos confirme que Google LDAP fonctionne toujours. Cette indication concerne le certificat client et non la vérification du certificat du serveur LDAP.

Les valeurs suivantes s’appliquent au 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 Google LDAP générés
  • Append base DN : désactivé
  • Client certificate : le certificat Google importé
  • Base DN : saisir ou 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 la création de groupes Google LDAP. Les instructions officielles de Google ne définissent pas explicitement Validate server certificate dans leur liste de valeurs. En l’absence de test en laboratoire sous SFOS 22, il ne faut en déduire aucune consigne ferme d’activation ou de désactivation ; choisissez cette option selon la procédure TLS générale et votre propre chaîne de confiance.

Vérifier l’authentification et l’affectation aux groupes

La recette couvre la connexion, l’identité et l’autorisation :

  1. Test connection doit confirmer la connexion et les identifiants de liaison.
  2. Sous Authentication > Services, vérifiez la liste des serveurs, l’ordre et l’héritage de chaque méthode utilisée. Le Default group appartient au Firewall authentication methods.
  3. Connectez-vous au service prévu avec un utilisateur pilote. Lorsque vous vous connectez pour la première fois, le pare-feu crée localement l’utilisateur authentifié en externe.
  4. Sous Authentication > Users, vérifiez que l’utilisateur et le groupe apparaissent comme prévu.
  5. Effectuez un test positif pour chaque groupe d’annuaire concerné. Vérifiez également avec un utilisateur sans affectation de groupe local appropriée si le Default group attendu s’applique.
  6. Vérifiez non seulement l’authentification, mais également la politique ou la règle de test prévue. Utilisez ensuite un mot de passe incorrect comme test négatif.
  7. Pour l’authentification des utilisateurs, l’autorisation et la journalisation comptable, consultez access_server.log ; pour les problèmes du portail VPN, consultez également vpnportal.log.
  8. Si un attribut d’expiration est utilisé, incluez un compte de test avec un statut d’expiration connu.

Si les valeurs du schéma ne sont pas claires, un administrateur peut interroger l’objet utilisateur en lecture seule depuis un système d’administration Linux ou directement 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)' '*' '+'

Ce chemin de diagnostic facultatif n’est pas une commande SFOS et n’appartient pas à Advanced Shell. L’exemple suppose LDAPS et fait confiance à l’autorité de certification du serveur sur le système d’exécution ; STARTTLS nécessite un appel adapté en conséquence. -W demande le mot de passe de liaison de manière interactive. Adaptez le filtre (uid=max.muster) au Authentication attribute configuré. '*' et '+' peuvent générer de nombreux attributs normaux et opérationnels avec des données personnelles. Avant de joindre ou de transmettre la sortie, notamment dans un ticket, anonymisez-la.

Isoler les erreurs par symptôme

  • Aucune connexion : Vérifiez le routage, le DNS, le port et le Connection security. Vérifiez ensuite Bind DN, mot de passe et Anonymous login.
  • Erreur TLS ou certificat : Vérifiez le nom du certificat du serveur, la résolution DNS, l’heure du pare-feu, la validité et la chaîne d’autorité de certification. Ne désactivez pas la vérification du certificat dans un premier temps.
  • Test connection fonctionne, mais l’utilisateur est introuvable : Comparez le DN de base, Authentication attribute et le nom de connexion saisi.
  • La connexion fonctionne, le groupe est erroné : Vérifiez Group name attribute et sa valeur de retour réelle, le mappage de groupe local et Default group. memberOf est une recommandation, mais pas un mappage garanti pour chaque schéma.
  • Le serveur est créé mais n’est pas utilisé : Vérifiez la sélection, l’ordre et l’héritage du service concerné sous Authentication > Services.
  • La liaison à Google Secure LDAP échoue : Version 3, port 636, Anonymous login désactivé, Append base DN désactivé, vérifiez l’état du service client, les informations d’identification et le certificat client Google individuellement.
  • La recherche est lente ou renvoie des comptes indésirables : Limitez le DN de base au sous-arbre requis.
  • La connexion fonctionne, mais pas la politique attendue : Vérifiez séparément le remplacement de l’utilisateur, la stratégie de groupe, le mappage de groupe et la règle de pare-feu ou VPN responsable. Le modèle de diagnostic complet affiche Résoudre systématiquement les échecs d’authentification.

Revenir en arrière en toute sécurité

En cas d’échec du déploiement, restaurez d’abord la sélection, l’ordre et l’héritage du serveur précédemment documentés pour chaque méthode concernée. Restaurez également l’ancien Default group sous Firewall authentication methods. Effectuez un test positif et négatif en utilisant la méthode d’authentification précédente et vérifiez les journaux correspondants.

Supprimez le nouveau serveur et le nouveau groupe LDAP uniquement lorsqu’ils ne sont plus utilisés dans aucun service ou stratégie. Ne nettoyez pas les utilisateurs LDAP créés automatiquement avec Purge AD users : L’aide de SFOS 22 documente cette fonction uniquement pour Active Directory. Si ces utilisateurs doivent être supprimés, confirmez au préalable la procédure prise en charge pour votre propre configuration auprès du support Sophos.