Résolution des problèmes

Problème

La passerelle hébergée sur ESXi n’affiche pas de bouton « Approuver » dans Sophos Central après le déploiement.

Actions à mener

1. Vérifiez si votre passerelle peut se connecter à ces URL. Si ce n’est pas le cas, autorisez-les. Utiliser le port 443 sauf indication contraire.

   • sophos.jfrog.io
   • \*.amazonaws.com
   • production.cloudflare.docker.com
   • \*.docker.io
   • \*.sophos.com
   • login.microsoftonline.com
   • graph.microsoft.com
   • ztna.apu.sophos.com (Port 22)
   • sentry.io
   • \*.okta.com (Si vous utilisez Okta en tant que fournisseur d’identité)

2. Assurez-vous que la dernière version du firmware est installée sur ESXi.

3. Assurez-vous que l’heure est correctement définie (GMT 0) sur ESXi.

4. Assurez-vous que le CD-ROM est joint. Si ce n’est pas le cas, éteignez la machine virtuelle et reconnectez-la. Si cela échoue, recréez la VM de la passerelle.

5. Exécutez une sonde TCP sur l’interface interne 6443 pour vous assurer que K3S est en cours d’exécution.

6. Si votre passerelle se trouve derrière le pare-feu Sophos, connectez-vous au pare-feu, rendez-vous dans Diagnostics > Capture de paquets et activez la capture de paquets, ou configurez le filtrage Web pour voir quelles requêtes échouent. Vous pouvez également le faire sur un pare-feu tiers.

Problème

Lorsque vous ajoutez une ressource à ZTNA, aucun groupe d’utilisateurs ne peut y accéder.

Actions à mener

Vérifiez que votre service d’annuaire (Microsoft Entra ID (Azure AD) ou Active Directory) possède des groupes d’utilisateurs et qu’ils sont synchronisés dans Sophos Central.

Problème

Lorsque vous ouvrez la page Modifier la passerelle, vous ne voyez pas les certificats que vous avez téléchargés lorsque vous avez ajouté la passerelle.

Actions à mener

Ceci est normal. Il est impossible d’afficher les certificats actuels.

Problème

La création de ressources sans agent ZTNA échoue. Le message affiché est : « Domaine non validé ». En effet, les ressources sont ajoutées avec le nom de domaine complet (FQDN) de la passerelle au lieu du nom de domaine.

Actions à mener

Lorsque vous créez des ressources, utilisez le nom de domaine et non le nom de domaine complet (FQDN) de la passerelle. Par exemple, utilisez test123.local au lieu de ztna.test123.local.

Problème

Si l’utilisateur AD sur site appartient uniquement au groupe principal sur le serveur AD, la vérification du groupe sur le serveur ZTNA échoue et l’utilisateur ne peut pas accéder aux ressources.

Actions à mener

Ajoutez l’utilisateur à d’autres groupes AD et configurez ces groupes pour permettre l’accès aux ressources sur ZTNA.

Problème

Le serveur AD principal et la passerelle ZTNA ne se connectent pas.

Actions à mener

Vérifiez que votre serveur AD principal est accessible depuis la passerelle ZTNA et que vous avez configuré correctement son nom d’hôte, son adresse IP et son port.

Problème

Les paramètres de votre serveur AD principal ne sont pas corrects.

Actions à mener

1. Vérifiez que les paramètres du DN de liaison et du Mot de passe de liaison sont corrects.
2. Vérifiez que le port LDAP est activé par TLS. Habituellement, le port 389 est utilisé pour établir des connexions LDAP non sécurisées et le port 636 est utilisé pour établir des connexions LDAP sécurisées.

Problème

Cette erreur peut être causée par une faute de frappe dans le DN de base, des paramètres avancés mal configurés, des paramètres de test incorrects ou des paramètres de serveur AD principal incorrects.

Actions à mener

1. Vérifiez que les paramètres Utilisateur et Groupe d’utilisateurs sont corrects.
2. Vérifiez que l’utilisateur que vous avez testé existe sur le serveur AD.
3. Vérifiez si le champ de l’email de l’utilisateur sur le serveur AD principal contient une adresse email valide. Si l’adresse email saisie pour un utilisateur est vide ou non valide, le test de connexion échoue.
4. Si vous avez saisi une adresse email pour votre utilisateur dans les paramètres avancés, testez la connexion avec l’adresse email plutôt qu’avec le nom d’utilisateur.
5. Vérifiez que votre serveur AD principal est accessible depuis la passerelle ZTNA et que vous avez configuré correctement son nom d’hôte, son adresse IP et son port.
6. Assurez-vous que vos utilisateurs sont membres d’un autre groupe d’utilisateurs en plus du groupe d’utilisateurs principal sur le serveur AD principal.

Problème

La vérification de l’état d’intégrité du serveur AD principal échoue lorsque les utilisateurs tentent d’accéder à une appli.

Actions à mener

1. Vérifiez que l’utilisateur existe sur le serveur AD.
2. Si vous avez utilisé les paramètres de configuration avancée par défaut lorsque vous avez configuré AD sur site en tant que fournisseur d’identité, connectez-vous avec votre nom d’utilisateur sans ajouter le nom de domaine.

Actions à mener

Vérifiez que votre serveur AD principal est accessible depuis la passerelle ZTNA et que vous avez configuré correctement son nom d’hôte, son adresse IP et son port.

Actions à mener

Vérifiez que les paramètres Utilisateur et Groupe d’utilisateurs sont corrects.

Actions à mener

Vérifiez si les valeurs de messagerie, de nom et d’ID que vous avez définies dans la configuration avancée sont également définies sur le serveur AD.

Problème

La passerelle ZTNA ne peut pas se connecter au serveur SMTP.

Actions à mener

Si vous ne recevez pas de code de confirmation pour l’authentification multifacteur, vérifiez la configuration de votre serveur SMTP.

Problème

Lorsque vous ouvrez Sophos Endpoint sur un appareil géré par Sophos Central, la page État affiche « Zero Trust Network Access : non configuré »

Actions à mener

Accédez à Appareils > Ordinateurs (ou Serveurs). Vérifiez si l’agent ZTNA est installé sur l’appareil. S’il est installé, vous verrez une coche verte. Si ce n’est pas le cas, vous verrez un signe « plus ». Cliquez dessus pour installer ZTNA.

Problème

Lorsque vous ouvrez Sophos Endpoint sur un appareil géré par Sophos Central, la page État affiche « Zero Trust Network Access : erreur ». Cela indique un problème de connexion.

Actions à mener

1. Vérifiez qu’une stratégie ZTNA a été configurée dans Sophos Central.

2. Vérifiez que le FQDN de la passerelle peut être résolu.

3. Vérifiez si la configuration de l’adaptateur TAP Sophos a échoué.

4. Désactivez l’interface réseau IPv6 sur l’agent. Le tunnel sera alors établi.

Problème

Les utilisateurs d’un groupe d’utilisateurs Microsoft Entra ID (Azure AD) qui avaient précédemment accès à une appli ne peuvent plus y accéder.

Cause

Si vous modifiez le nom d’un groupe d’utilisateurs Microsoft Entra ID (Azure AD) qui a été autorisé à accéder à une appli, la liste des Groupes d’utilisateurs assignés dans ZTNA n’est pas mise à jour et ne reflète pas la modification. Les utilisateurs ne pourront pas accéder à l’appli.

Actions à mener

1. Allez dans Zero Trust Network Access > Ressources et accès

   

2. Sur la page Ressources et accès, recherchez l’appli puis cliquez dessus pour modifier ses informations.

   

3. Dans la boîte de dialogue Modifier la ressource, procédez de la manière suivante :

   1. Accédez à la section Assigner des groupes d’utilisateurs.
   2. Dans Groupes d’utilisateurs disponibles, cochez la case se trouvant à côté du groupe d’utilisateurs renommé.
   3. Déplacez le groupe vers Groupes d’utilisateurs assignés et cochez la case se trouvant à côté.
   4. Cliquez sur Enregistrer.

   

Problème

Vous avez ajouté un utilisateur à un groupe d’utilisateurs autorisé pour une appli, mais l’utilisateur reçoit un message d’erreur 403 Accès Refusé.

Actions à mener

Si l’utilisateur a été ajouté récemment, demandez-lui de réessayer ultérieurement. Les modifications des groupes d’utilisateurs peuvent prendre jusqu’à 24 heures pour être appliquées.

Sinon, s’il s’agit d’une appli Web, dites à l’utilisateur d’essayer à nouveau depuis son navigateur en mode Incognito ou privé.

Problème

Vous avez supprimé un utilisateur d’un groupe d’utilisateurs autorisé pour une appli, mais celui-ci peut toujours y accéder.

Actions à mener

Vérifiez à nouveau plus tard. Les modifications apportées au groupe d’utilisateurs autorisé peuvent prendre jusqu’à une heure.

Problème

Lorsque l’utilisateur tente d’accéder à une appli configurée pour un accès sans agent, il voit une erreur 404 Introuvable.

Actions à mener

Dans vos paramètres de gestion DNS, procédez de la manière suivante :

1. Vérifiez que l’appli qui pointe vers le FQDN de la passerelle dispose d’un enregistrement CNAME.

2. Assurez-vous qu’il n’y ait pas d’enregistrement CNAME pour les appli accessibles via un agent ZTNA.

Problème

L’utilisateur voit une erreur 403 Accès refusé lorsqu’il tente d’accéder à une appli sans agent.

Actions à mener

1. Vérifiez que vous avez activé toutes les autorisations d’API requises pour votre fournisseur d’identité.

   Pour Azure, vous avez besoin des autorisations Microsoft Graph API suivantes :

   • Directory.Read.All (Délégué)
   • Directory.Read.All (Application)
   • Group.Read.All (Délégué)
   • openID (Délégué)
   • profile (Délégué)
   • User.Read (Délégué)
   • User.Read.All (Délégué)

   Vous avez également besoin actuellement d’une autorisation API Microsoft Entra ID (Azure AD) : Directory.ReadWrite.All (Application). Voir Enregistrer l’appli ZTNA.

   Pour Okta :

   • okta.groups.read
   • okta.idps.read (uniquement si vous utilisez AD Sync)

2. Vérifiez que la stratégie ZTNA autorise l’accès à l’appli.

3. Vérifiez que l’utilisateur se trouve dans un groupe d’utilisateurs assigné à appli.

4. Vérifiez que votre réseau est connecté à celui du fournisseur d’identité :

   Pour Azure :

   • login.microsoftonline.com
   • graph.microsoft.com

   Pour Okta :

   • *.okta.com

Problème

L’utilisateur voit une erreur de requête en amont lorsqu’il tente d’accéder à une appli sans agent.

Actions à mener

1. Vérifiez que l’application est accessible à partir du réseau sur lequel la passerelle ZTNA est activée.

2. Vérifiez que l’application est toujours en cours d’exécution.

3. Si le nom de domaine complet ou l’adresse IP interne est affiché, assurez-vous qu’il ait une résolution avec l’appli.

4. Si vous utilisez un serveur DNS privé, vérifiez qu’il est en cours d’exécution et effectuez la résolution vers le FQDN externe de l’application.

5. Vérifiez que les numéros de port spécifiés pour l’appli sont corrects.

Problème

L’utilisateur est authentifié mais ne peut pas accéder à l’appli.

Actions à mener

1. Recherchez les erreurs dans les journaux SNTP.

2. Vérifiez que les certificats sont valides dans heartbeat.xml.

Problème

L’utilisateur pouvait auparavant accéder à une appli, mais ne peut plus le faire.

Actions à mener

1. Recherchez les erreurs dans les journaux SNTP.

2. Vérifiez que les certificats sont valides dans heartbeat.xml

3. Vérifiez si ZTNA affiche un état d’intégrité « rouge » dans l’interface utilisateur Sophos Endpoint.

Problème

Le fournisseur d’identité doit inviter l’utilisateur à se connecter la première fois qu’il tente d’accéder à une appli. Si ce n’est pas le cas, l’utilisateur ne peut pas accéder à l’appli.

Actions à mener

Vérifiez que le appareil de l’utilisateur est en mesure de contacter la passerelle ZTNA.

Problème

L’utilisateur doit voir une fenêtre contextuelle qui l’invite à se connecter lorsqu’il tente d’accéder à une appli nécessitant l’agent ZTNA. Si ce n’est pas le cas, il ne pourra pas accéder à appli.

Actions à mener

1. Recherchez les erreurs dans les journaux SNTP.

2. Vérifiez les paramètres DNS. Le serveur DNS ne doit pas avoir d’enregistrement CNAME correspondant à l’appli.

3. Vérifiez que le processus de l’agent ZTNA est en cours d’exécution.

Problème

L’utilisateur peut accéder à une appli, mais les liens vers d’autres applis ne fonctionnent pas.

Actions à mener

Ajoutez les autres applis à ZTNA comme décrit dans Ajouter les ressources. Ceci permet à ZTNA d’accorder l’accès à l’utilisateur lorsqu’il clique sur les liens.

Problème

L’utilisateur voit l’écran de connexion et est authentifié, mais n’est pas redirigé vers l’appli à laquelle il a tenté d’accéder.

Actions à mener

1. Vérifiez que vous avez spécifié la bonne URI de redirection dans les paramètres du fournisseur d’identité (IdP).

   • Si le fournisseur d’identité est Microsoft Entra ID (Azure AD), vous avez spécifié l’URI de redirection lors de l’enregistrement de l’appli ZTNA. Voir Enregistrer l’appli ZTNA.
   • Si Okta est le fournisseur d’identité, vous avez spécifié l’URI de redirection de connexion lorsque vous avez créé une intégration d’appli dans Okta. Voir les instructions d’Okta sur Configurer un fournisseur d’identité.

2. Si Okta est le fournisseur d’identité, vérifiez que vous avez saisi « Groups claim expression » avec la bonne majuscule. Cette expression est sensible aux majuscules.

Problème

L’utilisateur voit une erreur 403 Accès refusé lorsqu’il tente d’accéder à une ressource interne, par exemple, un serveur Web interne.

Actions à mener

1. Assurez-vous que l’utilisateur fait partie d’un groupe d’utilisateurs mappé à la ressource.
2. Assurez-vous que la configuration du groupe est correcte dans les paramètres du service d’annuaire. Par exemple, dans Microsoft Entra ID (Azure AD), assurez-vous que vos groupes d’utilisateurs importés sont sécurisés.
3. Assurez-vous d’activer la stratégie ZTNA dans Sophos Central.

Problème

L’utilisateur ne peut pas voir de applis dans le portail utilisateur ZTNA.

Actions à mener

1. Assurez-vous que vos groupes d’utilisateurs importés sont sécurisés.

2. Allez dans Ressources et accès et cliquez sur une appli pour modifier ses paramètres.

3. Vérifiez que l’utilisateur se trouve dans les groupes d’utilisateurs assignés au applis dont il a besoin. Les utilisateurs ne peuvent voir que les applis auxquels ils sont autorisés à accéder.

4. Vérifiez que l’administrateur a sélectionné Afficher la ressource dans le portail utilisateur lorsqu’il a ajouté l’appli.

Problème

L’utilisateur tente d’accéder au portail utilisateur ZTNA et l’écran de connexion du fournisseur d’identité s’affiche. Une fois connecté, il n’est pas renvoyé au portail utilisateur.

Actions à mener

Vérifiez que vous avez spécifié la bonne URI de redirection dans les paramètres du fournisseur d’identité (IdP).

Si le fournisseur d’identité est Microsoft Entra ID (Azure AD), vous avez spécifié l’URI de redirection lorsque vous avez enregistré l’appli ZTNA. Voir Configurer le service d’annuaire.

Si Okta est le fournisseur d’identité, vous avez spécifié l’URI de redirection de connexion lorsque vous avez créé une intégration d’appli dans Okta. Voir les instructions d’Okta sur Configurer un fournisseur d’identité.

Problème

Une fois l’agent ZTNA installé, si vous utilisez nslookup pour effectuer une recherche DNS, il échoue parfois.

Actions à mener

Indiquez la carte réseau à utiliser pour la recherche.

L’installation de l’agent ZTNA modifie l’adaptateur TAP par défaut. Si vous utilisez nslookup pour effectuer une recherche DNS, il utilise maintenant l’adaptateur TAP ZTNA par défaut. Les recherches d’applis qui ne sont pas derrière la passerelle ZTNA échoueront.

Pour éviter ce problème, ajoutez l’adaptateur approprié à votre commande nslookup. Par exemple :

nslookup <FQDN-to-be-resolved><DNS-Server>

Actions à mener

Vérifiez que le fichier ISO téléchargé depuis Sophos Central est joint.

Actions à mener

Vérifiez la configuration de l’interface réseau. Si vous devez modifier les paramètres réseau de la passerelle, créez une nouvelle instance de la passerelle sur Sophos Central et téléchargez un nouveau fichier ISO.

Actions à mener

Vérifiez la configuration de l’interface réseau. Si vous devez modifier les paramètres réseau de la passerelle, créez une nouvelle instance de la passerelle sur Sophos Central et téléchargez un nouveau fichier ISO.

Actions à mener

Vérifiez la configuration de votre serveur DNS et assurez-vous que ntp.ubuntu.com peut être résolu.

Actions à mener

Vérifiez la configuration de votre serveur DNS et assurez-vous que sophos.jfrog.io peut être résolu.

Actions à mener

Vérifiez la configuration de l’interface réseau. Si ntp.ubuntu.com est inaccessible, les services ZTNA ne démarreront pas.

Actions à mener

Assurez-vous que toutes les URL mentionnées dans les conditions requises de ZTNA sont autorisées : Sites Web autorisés.

Actions à mener

Le démarrage du service après le démarrage de la passerelle peut prendre jusqu’à 10 minutes. Suivez les étapes ci-dessous si le service ne démarre pas après 10 minutes.

Assurez-vous que l’heure de la passerelle est synchronisée avec celle de Kubernetes. Assurez-vous également que le fuseau horaire est UTC.

Assurez-vous que la passerelle est connectée à Internet.

Si vous configurez votre cluster de passerelles en mode DHCP, assurez-vous que les adresses IP de vos passerelles n’ont pas changé.

Si la plate-forme de passerelle est VMware ESXi, assurez-vous que le CD-ROM est connecté à l’instance de la machine virtuelle lorsque vous la démarrez.

Assurez-vous qu’au moins la moitié des nœuds de votre cluster de passerelle sont actifs.

Si le service ne démarre toujours pas, contactez le support Sophos pour obtenir de l’aide.

Actions à mener

Contactez le support Sophos pour obtenir plus d’assistance.

Actions à mener

Contactez le support Sophos pour obtenir plus d’assistance.

Actions à mener

Vérifiez la connectivité à Sophos Central.

Actions à mener

Vérifiez que la passerelle a bien été enregistrée et vérifiez la connectivité à Sophos Central.

Actions à mener

Approuvez la passerelle sur Sophos Central.

Actions à mener

Vérifiez l’ISO mappé lors du démarrage de la passerelle. Assurez-vous que la dernière version ISO est utilisée et redéployez la passerelle.

Actions à mener

Vérifiez que les paramètres du pare-feu sont mis à jour pour vous assurer que l’URL dynamique affichée est résolue.

Actions à mener

Vérifiez la connectivité à Sophos Central.

Actions à mener

Vérifiez les paramètres sur la plate-forme de passerelle. Un décalage horaire entraîne des problèmes de connectivité.

Actions à mener

Vérifiez les paramètres sur la plate-forme de passerelle. Un décalage horaire entraîne des problèmes de connectivité.