Sophos Firewall : migrer eDirectory avant SFOS 23

SFOS 23.0 ne prend plus en charge le serveur d’authentification eDirectory natif. Si une configuration de serveur eDirectory native reste sur le pare-feu, la mise à niveau du firmware vers SFOS 23.0 ou une version ultérieure échoue. Avant la mise à niveau, un serveur d’authentification pris en charge doit donc fonctionner et la configuration native du serveur eDirectory et du SSO doit être entièrement supprimée.

eDirectory fonctionne encore dans SFOS 22.0 MR2. Il faut profiter de cette période pour réaliser une exploitation parallèle contrôlée : ajouter la nouvelle source, vérifier les utilisateurs et les groupes avec des comptes réels, basculer les services d’authentification de manière contrôlée, puis supprimer eDirectory uniquement lorsque le retour arrière n’est plus nécessaire. Les services Entra ID SSO couplés doivent être traités ensemble. La présentation de MR2 replace les autres modifications de cette version dans leur contexte.

Procédure rapide

Inventorier toutes les dépendances eDirectory dans les serveurs, groupes, services, règles, VPN et SSO.
Préparer une sauvegarde récente, un administrateur local et un accès console documenté.
Choisir comme cible, selon l’usage, LDAP générique, Active Directory, RADIUS ou Microsoft Entra ID SSO.
Ajouter le nouveau serveur d’authentification en parallèle et vérifier la connexion, les utilisateurs et les groupes.
Réaffecter explicitement les groupes et les politiques à la nouvelle source.
Sous Authentication > Services, basculer les services de manière contrôlée et les tester avec des comptes réels ; traiter ensemble les services Entra ID SSO couplés.
Uniquement après la validation complète, supprimer toutes les configurations natives du serveur eDirectory et du SSO, créer une nouvelle sauvegarde, puis lancer la mise à niveau vers SFOS 23.

Il ne s’agit volontairement pas d’une bascule à l’aide d’un seul bouton. Le pare-feu utilise les serveurs d’authentification par service et selon un ordre défini. De plus, les autorisations dépendent souvent de groupes qui peuvent porter le même nom après la migration sans posséder automatiquement la même affectation ni produire le même effet.

Ce qui dépend actuellement d’eDirectory

Avant la première modification, il faut déterminer précisément où eDirectory est réellement utilisé. L’inventaire doit au minimum couvrir les domaines suivants :

Sous Authentication > Servers se trouvent les serveurs eDirectory et, le cas échéant, plusieurs cibles de répertoire.
Sous Authentication > Services, chaque service définit les serveurs interrogés et leur ordre.
Sous Authentication > Groups, les politiques de groupe, le Default Group et l’ordre des groupes peuvent déterminer les droits effectifs d’un utilisateur. Avec Active Directory, il faut également tenir compte du Main Group et des autres appartenances.
Les règles de pare-feu, les politiques Web et Application ainsi que le Traffic Shaping peuvent faire référence à des utilisateurs ou des groupes.
VPN Portal, SSL VPN, Remote Access IPsec, User Portal et Captive Portal possèdent leurs propres chemins d’authentification et d’autorisation.
La MFA et les connexions administratives peuvent dépendre des groupes et de l’ordre d’authentification.
Les rapports basés sur les utilisateurs et l’identification transparente des utilisateurs nécessitent toujours une association fiable entre l’utilisateur et la connexion.

Une capture d’écran de l’ordre actuel des serveurs, services et groupes est souvent plus utile qu’une simple liste de noms. Il faut également noter au moins un utilisateur de test positif et un utilisateur de test négatif pour chaque groupe important. On peut ainsi vérifier non seulement qui obtient l’accès, mais également qui est correctement refusé.

Choisir la méthode cible adaptée

Il n’existe pas de remplacement universel à l’identique pour tous les environnements eDirectory. Une entreprise peut continuer d’utiliser le répertoire existant via LDAP, migrer les identités vers un autre répertoire ou combiner plusieurs méthodes d’authentification selon le service.

Conserver eDirectory via LDAP générique

Si eDirectory reste en place, Sophos Firewall peut l’interroger pour les connexions utilisateur au moyen du type de serveur pris en charge LDAP server. Cette méthode ne modifie pas automatiquement l’arborescence du répertoire, mais exige une nouvelle configuration LDAP avec une Base DN ainsi que des attributs de connexion et de groupe adaptés.

La limite est importante : le SSO eDirectory natif n’est plus disponible à partir de SFOS 23. Le serveur LDAP générique assure la vérification de la connexion, mais pas l’identification transparente des utilisateurs. Les utilisateurs auparavant identifiés automatiquement ont donc besoin d’un nouveau processus SSO ou de connexion. La description complète des champs se trouve dans Connecter un serveur LDAP générique à Sophos Firewall.

Active Directory

Active Directory convient lorsque les utilisateurs existent déjà dans un domaine Windows ou sont volontairement migrés vers celui-ci. Il faut alors importer les groupes, vérifier de nouveau le Main Group et les politiques, puis construire séparément l’identification transparente des utilisateurs souhaitée. Connecter Active Directory à Sophos Firewall explique LDAPS, l’importation des groupes et les tests des services.

STAS transmet de manière transparente au pare-feu les connexions au domaine Windows, mais ne convertit pas l’ancienne configuration eDirectory SSO. Si ce chemin d’identité est nécessaire, il faut le planifier comme une migration distincte à l’aide de STAS pour Sophos Firewall.

RADIUS

RADIUS convient lorsqu’un service d’authentification central ou une passerelle MFA existe déjà. Le serveur RADIUS doit fournir au pare-feu les informations nécessaires au service concerné ; le modèle de groupes d’un répertoire n’est pas repris automatiquement. La méthode MFA doit être compatible avec le service : VPN Portal, par exemple, ne prend pas en charge la MFA RADIUS basée sur un challenge. Le Shared Secret, l’attribut de groupe, les délais d’attente et les autres limites sont traités dans Configurer un serveur RADIUS sur Sophos Firewall.

Microsoft Entra ID SSO

Microsoft Entra ID SSO peut convenir aux scénarios documentés de portail, d’administration et de Remote Access. Il ne remplace cependant pas toutes les demandes de nom d’utilisateur et de mot de passe et ne fournit pas d’identification transparente des utilisateurs du LAN. Pour Remote Access, les services associés doivent être coordonnés : VPN Portal et SSL VPN utilisent le même serveur Entra ; avec un fichier de provisioning, cette exigence s’applique également à IPsec. Les Redirect URIs, groupes, Conditional Access et services pris en charge sont décrits dans Microsoft Entra ID SSO pour Sophos Connect et VPN Portal.

L’architecture cible peut être mixte. LDAP peut, par exemple, continuer provisoirement à authentifier les utilisateurs provenant de l’eDirectory existant, tandis que Remote Access sera migré ultérieurement et de manière ciblée vers RADIUS ou Entra ID SSO. L’essentiel est que chaque service utilisé dispose d’un chemin cible testé avant la suppression d’eDirectory.

Sécuriser avant la première modification

Avant la bascule, les éléments suivants doivent être disponibles :

Une sauvegarde Sophos Firewall récente et chiffrée.
Un administrateur local dont la connexion ne dépend ni d’eDirectory ni de la nouvelle source externe. Sous Authentication > Services, Local doit rester sélectionné dans Administrator authentication methods.
Un accès console ou un autre accès d’urgence documenté au pare-feu.
Des captures d’écran ou un inventaire écrit de l’ordre des serveurs, services et groupes.
Au moins un compte de test pour chaque groupe important, ainsi qu’un compte qui ne doit pas obtenir l’accès.
Une fenêtre de maintenance, un décideur responsable et un critère de retour arrière clair.

L’accès WebAdmin doit être basculé en dernier. Il faut auparavant vérifier que Local reste sélectionné et que la connexion locale fonctionne dans une fenêtre de navigation privée. Un accès indépendant reste ainsi disponible si la nouvelle authentification externe ou la résolution de ses groupes ne fonctionne pas comme prévu.

Construire le serveur cible en parallèle

Le nouveau serveur est d’abord ajouté en complément. Pendant la configuration initiale du serveur, la sélection eDirectory existante reste inchangée ; une seule méthode d’authentification contrôlable est modifiée pour le test pilote.

Exemple : connecter eDirectory comme serveur LDAP générique

Sous Authentication > Servers > Add, une configuration pilote peut par exemple se présenter comme suit :

Server type : LDAP server
Server name : EDIR-LDAP-PILOT
Server IP/domain : edir01.example.net
Version : 3
Connection security : SSL/TLS
Port : 636
Bind DN : cn=sfos-bind,ou=service,o=Example
Base DN : ou=users,o=Example
Authentication attribute : par exemple uid, après vérification de l’objet utilisateur
Group name attribute : par exemple groupMembership, après vérification de l’objet utilisateur
Validate server certificate : activé après avoir configuré l’autorité de certification émettrice comme fiable sur le pare-feu

edir01.example.net, le Bind DN et la Base DN sont des exemples qui doivent être adaptés à l’arborescence du répertoire concerné. Lorsque la validation du certificat est activée, le FQDN configuré doit correspondre au certificat du serveur et être résolvable par le pare-feu. Le compte de liaison doit uniquement disposer de droits de lecture sur la partie nécessaire du répertoire.

Les attributs de connexion et de groupe adaptés sont déterminés à partir de l’objet utilisateur réel. Dans un environnement eDirectory, cn ou uid peuvent par exemple servir à la connexion et groupMembership aux groupes. Il s’agit de valeurs à vérifier et non de prescriptions universelles.

Depuis un système d’administration Linux, on peut vérifier un objet utilisateur en lecture seule :

LDAPTLS_CACERT='/secure/path/edir-ca.pem' \
ldapsearch -LLL -x \
  -H 'ldaps://edir01.example.net:636' \
  -D 'cn=sfos-bind,ou=service,o=Example' -W \
  -b 'ou=users,o=Example' -s sub \
  '(|(cn=max.muster)(uid=max.muster))' \
  dn objectClass cn uid mail groupMembership

Cette commande ne doit pas être exécutée dans l’Advanced Shell de Sophos Firewall. L’option -W demande le mot de passe de liaison de manière interactive afin qu’il ne soit pas enregistré dans l’historique du shell. Le chemin indiqué dans LDAPTLS_CACERT, le FQDN, les DN, le filtre et les attributs demandés doivent être adaptés à l’environnement. Si le client OpenLDAP local fait déjà confiance à l’autorité de certification par l’intermédiaire de son Trust Store ou de ldap.conf, LDAPTLS_CACERT peut être omis. Dans le cas contraire, la variable doit pointer vers un bundle CA au format PEM accessible en lecture.

Une sortie possible peut se présenter comme suit :

dn: cn=Max Muster,ou=users,o=Example
cn: Max Muster
uid: max.muster
mail: max.muster@example.net
groupMembership: cn=VPN-Mitarbeitende,ou=groups,o=Example

Il s’agit d’un exemple de lecture et non d’une promesse concernant le schéma eDirectory. Si groupMembership est absent ou si le répertoire renvoie d’autres valeurs, il faut déterminer l’attribut réel et adapter la configuration du pare-feu. Il faut ensuite vérifier séparément Test connection, une connexion utilisateur réelle et le groupe obtenu.

Reconfigurer les groupes et les politiques

Une connexion réussie ne suffit pas si l’utilisateur est ensuite placé dans le mauvais groupe. Supposons que l’ancien groupe VPN-Mitarbeitende soit autorisé à utiliser SSL VPN et à accéder à des applications internes par l’intermédiaire d’une règle basée sur les utilisateurs. Après la migration, il faut au minimum répondre aux questions suivantes :

L’utilisateur de test apparaît-il sous Authentication > Users avec le groupe effectif attendu ? Avec Active Directory, le Main Group et les autres appartenances doivent être contrôlés séparément.
Le nouveau groupe est-il présent et correctement ordonné sous Authentication > Groups ?
La configuration SSL VPN ou IPsec fait-elle référence au nouveau groupe effectif ?
L’utilisateur correspond-il toujours à la règle de pare-feu prévue et non à une règle plus générale ?
La politique MFA souhaitée s’applique-t-elle toujours ?

Des noms de groupes identiques provenant de deux sources ne garantissent ni la même appartenance ni la même priorité de groupe effective. Avec Active Directory, l’ordre des groupes et le Main Group peuvent influencer le VPN, la MFA et d’autres politiques. Les principes sont décrits dans Activer la MFA pour Sophos Firewall.

Basculer service par service

Sous Authentication > Services, les serveurs d’authentification sont sélectionnés par service. Tout ne doit donc pas être basculé simultanément. Les services Entra ID SSO couplés doivent toutefois être planifiés comme un chemin commun et validés ensemble.

Commencer par choisir un service contrôlable et un utilisateur pilote.
Sélectionner le nouveau serveur pour ce service et définir consciemment sa position dans l’ordre des serveurs.
Appliquer la modification et tester une connexion correcte ainsi qu’une connexion volontairement incorrecte.
Contrôler l’utilisateur, le groupe, l’entrée de journal et la politique réellement appliquée.
Ne basculer le service suivant qu’après cette vérification.

Il faut commencer par un service pilote choisi explicitement et facile à contrôler. Viennent ensuite les domaines réellement utilisés, tels que Firewall authentication methods, User portal authentication methods, VPN portal authentication methods, SSL VPN authentication methods et Remote Access IPsec. Avec Entra ID SSO, les services Remote Access couplés décrits précédemment sont basculés de manière coordonnée. En raison du risque de verrouillage, Administrator authentication methods intervient en dernier. La présentation des portails Sophos Firewall explique quels portails fonctionnent séparément et doivent être accessibles.

Lorsque le même nom d’utilisateur existe sur l’ancien et le nouveau serveur, l’ordre des serveurs peut masquer une mauvaise affectation de groupe. Pour effectuer un test contrôlé, il est possible de sélectionner temporairement uniquement le nouveau serveur pour le service pilote choisi. La connexion réelle et Authentication > Users indiquent ensuite si la nouvelle source fournit l’utilisateur avec le groupe attendu.

Valider avec des connexions réelles

Test connection confirme l’accessibilité et les identifiants du serveur. La vérification ne se termine toutefois que lorsque le service réel et l’autorisation qui lui est associée fonctionnent.

Pour chaque groupe pertinent, la validation doit au minimum démontrer les points suivants :

Un utilisateur autorisé peut se connecter au portail ou au service VPN prévu.
Un utilisateur non autorisé est refusé ou reçoit uniquement la politique restreinte prévue.
Sous Authentication > Users, l’utilisateur et le groupe sont corrects.
Le Log Viewer affiche un événement d’authentification compréhensible.
Les politiques de pare-feu, Web et VPN correspondent à la règle attendue.
Les cibles internes sont accessibles par le chemin de trafic prévu.
La MFA et les rôles administratifs se comportent comme prévu.

La procédure Tester les règles de pare-feu et utiliser le Log Viewer permet de vérifier quelle Rule ID s’applique à un utilisateur et à son trafic. L’identification transparente des utilisateurs ou le SSO doit être testé séparément ; une connexion LDAP réussie ne valide pas ce chemin.

Retour arrière pendant la phase pilote

Tant que le pare-feu utilise encore SFOS 22.0 MR2 et qu’eDirectory n’a pas été supprimé, l’ancienne configuration reste disponible comme retour arrière contrôlé. Si un pilote échoue, il faut rétablir toutes les valeurs modifiées pour celui-ci : sélection et ordre des serveurs sous Authentication > Services, Default Group et ordre des groupes, ainsi que les membres VPN, références MFA et références de politiques concernés. Il faut ensuite vérifier de nouveau la connexion, le groupe et la politique.

La sauvegarde protège la configuration du pare-feu, mais ne constitue pas une migration automatique des identités. La sauvegarde et l’importation de configuration ne convertissent ni ne migrent la configuration eDirectory qu’elles contiennent. Une telle sauvegarde ne constitue donc pas un retour arrière eDirectory fonctionnel après la mise à niveau.

Supprimer eDirectory et autoriser SFOS 23

eDirectory ne doit être supprimé qu’après une période d’observation définie au préalable. Pendant cette période, chaque chemin de connexion utilisé en production, chaque groupe important, les connexions VPN utilisées et les procédures administratives doivent avoir fonctionné sans erreur au moins une fois par l’intermédiaire de la nouvelle source dans des conditions réalistes ; les erreurs d’authentification, de groupe ou de politique non résolues empêchent l’autorisation de suppression.

Pour terminer :

Vérifier qu’eDirectory n’est plus sélectionné dans aucune méthode d’authentification.
Comparer une dernière fois les dépendances de groupes, VPN, politiques, MFA, administration et SSO avec l’inventaire.
Supprimer du pare-feu toutes les configurations natives de serveur eDirectory et d’eDirectory SSO. Un nouveau LDAP server générique qui interroge le même répertoire reste en place.
Vérifier sous Authentication > Servers, Authentication > Services et dans l’inventaire qu’il ne reste aucune configuration ou dépendance eDirectory native.
Créer une nouvelle sauvegarde chiffrée de la configuration nettoyée.
Consulter la procédure générale Mise à jour du firmware Sophos Firewall : préparation et bonnes pratiques, ainsi que les Release Notes, informations de mise à niveau et Known Issues actuelles de SFOS 23. Lancer ensuite seulement la mise à niveau.

Sophos confirme l’échec de la mise à niveau lorsqu’une configuration native de serveur eDirectory est présente et la nécessité de la supprimer avant SFOS 23. Avant la mise à niveau en production, il faut également consulter les Release Notes, informations de mise à niveau et Known Issues définitives de SFOS 23 afin de détecter d’autres détails éventuels.

Difficultés typiques

Test connection réussit, mais l’utilisateur est placé dans le mauvais groupe : vérifier la Base DN, les attributs de connexion et de groupe sur l’objet utilisateur réel ainsi que l’ordre des groupes.
Le pilote semble fonctionner, mais pourrait encore utiliser eDirectory : sélectionner temporairement uniquement le nouveau serveur pour le service pilote contrôlé, puis vérifier l’utilisateur, le groupe et la politique.
User Portal fonctionne, mais pas le VPN : vérifier séparément la méthode d’authentification et le groupe d’autorisation de chaque portail et service VPN.
La connexion LDAP fonctionne, mais pas l’identification transparente : le SSO eDirectory natif n’est plus disponible à partir de SFOS 23. LDAP générique vérifie la connexion, mais ne fournit pas l’identification transparente des utilisateurs.
Une autre règle de pare-feu s’applique après la modification des groupes : comparer le groupe effectif, l’ordre des groupes et les références directes à des utilisateurs ou groupes dans les politiques. Avec Active Directory, vérifier également le Main Group et les autres appartenances.
La sauvegarde est prévue comme retour arrière eDirectory ultérieur : sous SFOS 23, la configuration eDirectory qu’elle contient n’est pas migrée ; le retour arrière doit fonctionner avant la mise à niveau.