Aller au contenu
Avanet

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

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 groupes ou AD SSO, Connecter Active Directory à Sophos Firewall est un guide plus adapté. 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 de liaison avec des droits de lecture sur la partie requise de l’annuaire ;
  • 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 du nom de connexion, du nom d’affichage, de l’adresse e-mail, du groupe et, le cas échéant, de l’expiration du compte ;
  • si la validation du certificat est activée, un nom de serveur résoluble et la chaîne de confiance appropriée de l’autorité de certification.

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 annuaire peut utiliser un port différent, qui doit correspondre à Connection security et à la configuration du serveur.

⚠️ Le compte de liaison 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 modifier la configuration sous Authentication > Services, documentez les serveurs sélectionnés, leur ordre et les options d’héritage pour chaque méthode concernée. Sous Firewall authentication methods, notez également la valeur actuelle de Default group. Cela vous permet d’annuler la modification sans supprimer hâtivement de nouveaux objets. Pendant les modifications, gardez à disposition un accès administrateur local préalablement testé pour pouvoir rétablir l’accès.

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

Un DN décrit le chemin allant de l’objet spécifique à la racine de l’annuaire. 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’utilisateurs, par exemple ou=people,dc=example,dc=net.

Un DN de base trop restreint ne permet pas de trouver tous les utilisateurs nécessaires. Une base de recherche inutilement large peut ralentir les recherches et inclure des objets 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 renvoyée, la correspondance avec les groupes locaux et les appartenances multiples doivent être vérifiées avec 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.

Lorsque Validate server certificate est activé, le champ Server IP/domain doit contenir le nom indiqué dans le certificat du serveur, que le pare-feu doit pouvoir résoudre. 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 figurant dans le 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.

Pour Surfing quota et Access time, choisissez délibérément les limites nécessaires. Sophos utilise Unlimited internet access et Allowed all the time dans son exemple pédagogique ; il s’agit de stratégies données à titre d’exemple, et non de prérequis pour LDAP. Pour un accès pilote restreint, la durée d’utilisation réellement nécessaire et la plage horaire autorisée sont plus adaptées. Ne conservez les valeurs par défaut des autres champs que si elles correspondent à votre propre politique d’accès.

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. Pour les stratégies utilisateur et les VPN d’accès à distance autres que SSL VPN, les paramètres propres à l’utilisateur sont prioritaires sur les stratégies de groupe. Cette règle de priorité ne s’applique pas au SSL VPN d’accès à distance : un utilisateur peut accéder aux ressources de toutes les stratégies de tunnel complet et de tunnel fractionné qui s’appliquent à lui ou à ses groupes. Une stratégie utilisateur plus restrictive n’annule donc pas automatiquement les autorisations plus larges des groupes SSL VPN. Cela ne garantit pas que tous les schémas LDAP représentent les appartenances multiples de la même manière ; l’affectation aux groupes et les ressources réellement accessibles doivent être vérifiées pendant la phase pilote. La logique complète des groupes, avec phase pilote, exceptions propres aux utilisateurs et groupe principal, 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. Pour Server type, sélectionnez LDAP server.
  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 figurant dans le 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 disposant des droits de lecture.
  8. Activez Append base DN uniquement si le pare-feu doit ajouter le DN de base à un DN de liaison incomplet 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. Si un certificat client est nécessaire, sélectionnez-le dans la liste Client certificate.

Définir la base de recherche et les attributs

  1. Saisissez le point de départ de la recherche d’utilisateurs sous Base DN. Get base DN permet d’obtenir la base de recherche proposée par le serveur.
  2. Définissez l’attribut contenant 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é par 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. Renseignez Expiry date attribute avec l’attribut correspondant 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.

Display name attribute et Email address attribute sont des champs facultatifs pour un serveur LDAP générique. Le nom d’affichage facilite l’identification de l’objet utilisateur local ; l’attribut d’adresse e-mail fournit l’adresse correspondante. En revanche, l’attribut d’adresse e-mail est requis pour la création de groupes Google LDAP. Un Expiry date attribute désigne l’expiration du compte, et non la durée d’une session VPN. Sophos indique Date dans son exemple pédagogique général et expiry pour Google ; le nom d’attribut approprié dépend du schéma concerné.

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.

Uniquement pour l’automatisation par API lors du passage de SFOS 22 à SFOS 23 : La référence de l’API LDAP modifie les lignes documentées sous Status Message Information : pour Add LDAP server, de 200/500/502/503 à 200/400/401/403/409/500 ; pour Edit LDAP server, de 200/500/503 à 200/400/401/403/404/500. 409 figure uniquement pour Add, et 404 uniquement pour Edit. Les symboles de présentation passent également de Message.LDAP* à Message.CP*. Ces lignes et symboles documentaires ne garantissent pas les codes ou messages réellement transmis et n’établissent aucune correspondance fixe de 502/503 à 409/404. Pour l’automatisation par API, consultez la référence de votre version et validez les réponses réelles du pare-feu cible avant d’adopter une correspondance. Cette vérification de l’API est distincte ; le contrôle Test connection dans l’interface graphique et une véritable authentification restent nécessaires.

Avant tout ajout ou toute modification LDAP automatisés : Les références de l’API pour SFOS 22 et 23 sont contradictoires concernant IntegrationType : l’exemple indique LooseIntegration/TightIntegration et associe à DisplayNameAttribute, EmailAddressAttribute, GroupNameAttribute et ExpiryDateAttribute le commentaire Only For Tight Integration ; le tableau des paramètres décrit les deux modes, mais n’autorise que la valeur 1. N’en déduisez ni la prise en charge de l’un ou l’autre mode, ni la signification de 1, ni la possibilité d’omettre des attributs conditionnels. L’exemple ne constitue pas une charge utile prête à être envoyée ; ses valeurs textuelles pour les options d’activation et la sécurité de la connexion ne correspondent pas non plus aux codages des tableaux. Avant toute modification, vérifiez le schéma ou la référence de l’API de la version cible et contrôlez en lecture seule la configuration réelle de la cible ainsi qu’une réponse API associée. Si la correspondance reste incertaine, n’exécutez aucune automatisation fondée sur celle-ci ; utilisez plutôt la procédure vérifiée dans l’interface graphique ou clarifiez les exigences de l’API auprès du support Sophos. Les étapes dans l’interface graphique décrites ci-dessus restent distinctes de cette vérification ; Test connection ainsi que des tests réels de l’identité, des groupes, de l’expiration du compte le cas échéant et de chaque service utilisé restent nécessaires.

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. Pour Default group, sélectionnez le groupe préparé LDAP-Benutzer 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 résultante est bien celle souhaitée.

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 mise en place sans vérification en raison du protocole et des technologies VPN désormais obsolètes.

Pour les connexions administrateur, procédez également comme suit : Lors de sa première connexion, un utilisateur authentifié en externe via LDAP est d’abord créé comme utilisateur standard, même s’il possède un rôle d’administrateur dans l’annuaire. Connectez-vous d’abord avec le compte prévu à un service autorisé, comme le portail utilisateur ou le portail VPN. Ensuite, avec l’accès administrateur local existant, modifiez l’utilisateur créé sous Authentication > Users, définissez User type sur Administrator, sélectionnez un Profile limité aux droits nécessaires et enregistrez avec Save. La sélection du serveur sous Administrator authentication methods ne suffit pas à elle seule. Vérifiez ensuite la connexion à WebAdmin ainsi que les opérations d’administration autorisées et non autorisées avec ce compte ; conservez l’accès local de récupération préalablement testé.

Configurer Google Secure LDAP

Avant de configurer le pare-feu, créez un client LDAP dans la console d’administration Google sous Apps > LDAP. Limitez ses Access permissions, téléchargez le certificat avec sa clé privée et générez des identifiants distincts. Le mot de passe n’est plus visible après la fermeture de la boîte de dialogue. Si le nom d’utilisateur ou le mot de passe est incorrect ou n’est plus disponible, générez de nouveaux identifiants d’accès dans la console d’administration Google, puis mettez à jour Bind DN et Password dans la configuration du serveur LDAP du pare-feu.

Google peut modifier l’interface et les étapes de la console d’administration. Avant de commencer, consultez donc la documentation Google actuelle sur la création de clients LDAP, le téléchargement du certificat et la génération d’identifiants d’accès. La page Google Secure LDAP explique si le service est disponible pour votre édition de Google ; les autorisations d’accès doivent correspondre au périmètre d’utilisateurs et de groupes prévu.

La procédure documentée par Sophos dans la console d’administration Google peut être suivie ainsi :

  1. Sous Apps > LDAP, commencez avec ADD CLIENT, saisissez un nom de client LDAP et une Description, puis sélectionnez CONTINUE. Un nom unique tel que Sophos-Firewall-Pilot facilite l’identification ultérieure.
  2. Limitez les Access permissions au périmètre d’utilisateurs et de groupes nécessaire, puis confirmez avec ADD LDAP CLIENT.
  3. Sélectionnez Download certificate. Le ZIP contient le fichier de certificat .cer et la clé privée .key. Extrayez les deux fichiers dans un dossier de travail protégé et notez leur emplacement pour l’importation suivante. La clé privée ne doit pas être placée dans des tickets ou des partages non protégés.
  4. Poursuivez avec CONTINUE TO CLIENT DETAILS, ouvrez la carte Authentication et sélectionnez GENERATE NEW CREDENTIALS. Consignez Username et Password de manière sécurisée avant de sélectionner CLOSE ; ces valeurs seront ensuite utilisées comme Bind DN et Password, et non les identifiants d’un administrateur Google.

Les identifiants Google ne remplacent pas le certificat client. Pour cette variante, Sophos Firewall nécessite à la fois le certificat avec sa clé privée et les identifiants de liaison générés.

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 mal réglée manuellement peut entraîner l’échec de l’importation des certificats. Sous Certificates > Certificates > Add, sélectionnez ensuite le format CER (.cer) et importez Certificate et Private key à partir du téléchargement Google. Le certificat peut apparaître comme non approuvé, car Google le signe lui-même ; Sophos confirme que Google LDAP fonctionne malgré cette indication. Cette indication concerne le certificat client et non la vérification du certificat du serveur LDAP.

Lors de l’importation, attribuez un nom de certificat unique. Avec Choose File, sélectionnez le fichier .cer extrait pour Certificate et le fichier .key correspondant pour Private key, validez chaque sélection avec Open, puis sélectionnez Save. Ce certificat ne peut être sélectionné sous Client certificate dans le serveur LDAP qu’après l’enregistrement.

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. Le guide Sophos pour Google Secure LDAP ne définit pas explicitement Validate server certificate dans sa liste de valeurs. Il ne faut en déduire aucune obligation d’activation ni de désactivation ; le choix de cette option dépend de la procédure TLS générale et de votre propre chaîne de confiance. L’affichage d’un certificat client Google comme non approuvé ne justifie pas la désactivation de la vérification du certificat du serveur distant.

Vérifiez la connexion Google avec Test connection et enregistrez le serveur avec Save. Préparez ensuite un groupe LDAP local comme décrit ci-dessus et sélectionnez le serveur Google sous Authentication > Services pour les services nécessaires. Avec Google également, la création du seul objet serveur ne rend encore aucun service utilisable ; la connexion pilote vérifie ensuite l’identité, le groupe et l’autorisation.

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 paramètre Default group se trouve sous Firewall authentication methods.
  3. Connectez-vous au service prévu avec un utilisateur pilote. Lors de la première connexion, 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. Pour SSL VPN, testez les ressources autorisées et bloquées en tenant compte des stratégies utilisateur et de groupe applicables ; ne déduisez pas les droits effectifs d’une seule stratégie utilisateur restrictive. 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)' '*' '+'

Cette méthode de diagnostic facultative n’est pas une commande SFOS et ne doit pas être exécutée dans l’Advanced Shell. L’exemple nécessite LDAPS et suppose que le système exécutant la commande fasse confiance à l’autorité de certification du serveur ; 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 champ Authentication attribute configuré. '*' et '+' peuvent renvoyer de nombreux attributs ordinaires et opérationnels contenant 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 Connection security. Vérifiez ensuite le DN de liaison, le mot de passe et Anonymous login.
  • Erreur TLS ou de certificat : Vérifiez le nom figurant dans le certificat du serveur, la résolution DNS, l’heure du pare-feu, la validité et la chaîne de confiance de l’autorité de certification. Ne désactivez pas la vérification du certificat comme première mesure.
  • Test connection fonctionne, mais l’utilisateur est introuvable : Comparez le DN de base, Authentication attribute et le nom de connexion saisi.
  • La connexion fonctionne, mais le groupe est incorrect : Vérifiez Group name attribute et sa valeur réellement renvoyée, la correspondance avec les groupes locaux et Default group. memberOf est une recommandation, mais pas une correspondance garantie 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 : Vérifiez séparément la version 3, le port 636, la désactivation de Anonymous login et de Append base DN, l’état du service du client, les identifiants et le certificat client Google.
  • La recherche est lente ou renvoie des comptes indésirables : Limitez le DN de base à la sous-arborescence requise.
  • La connexion fonctionne, mais pas la politique attendue : Vérifiez séparément les paramètres propres à l’utilisateur, la stratégie de groupe, la correspondance avec les groupes et la règle de pare-feu ou VPN concernée. Pour SSL VPN, prenez en compte toutes les stratégies utilisateur et de groupe applicables ainsi que les ressources réellement autorisées ; une stratégie utilisateur restrictive ne suffit pas à elle seule. Le modèle de diagnostic complet est présenté dans Résoudre systématiquement les échecs d’authentification.
  • La connexion au portail fonctionne, mais pas celle à WebAdmin : Sous Authentication > Users, vérifiez le rôle d’administrateur attribué manuellement et le Profile. Vérifiez ensuite la sélection du serveur sous Administrator authentication methods et les règles d’accès à l’équipement applicables. Ne renoncez pas à l’accès local de récupération avant d’avoir testé la nouvelle méthode.

Revenir en arrière en toute sécurité

En cas d’échec du déploiement, restaurez d’abord, pour chaque méthode concernée, la sélection des serveurs, leur ordre et les options d’héritage précédemment documentés. Sous Firewall authentication methods, restaurez également l’ancien Default group. Effectuez un test positif et un test 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.