Sophos Protected Browser : résoudre les problèmes d’accès et de connexion

Ce runbook aide à cerner les problèmes d’accès à Protected Browser et aux ressources RDP/SSH ZTNA sans agent. Dans Sophos Central, ouvrir Meine Produkte > Protected Browser et commencer par le symptôme visible. Corriger uniquement la cause confirmée lors des contrôles. Des modifications générales du DNS, de l’annuaire des utilisateurs ou de ZTNA compliquent le diagnostic.

Procédure rapide : Si l’ajout ou la modification d’une ressource échoue dès le départ, vérifier les adresses email de tous les membres du groupe d’utilisateurs concerné. Si une ressource existante est inaccessible sans message d’erreur précis, tester d’abord le portail utilisateur ZTNA, puis la résolution DNS du FQDN de la passerelle ZTNA. Pour « Netzwerk nicht erreichbar » ou « Verbindung konnte nicht hergestellt werden », comparer directement le fournisseur d’identité configuré dans ZTNA avec la méthode de connexion de la session Protected Browser. Si la connexion à Protected Browser échoue, vérifier l’accès à Self Service Portal et l’unicité de l’adresse email parmi les tenants. Traiter séparément le message « Hostschlüsselüberprüfung fehlgeschlagen ».

Prérequis et limites d’intervention sûres

Ces contrôles nécessitent un environnement Protected Browser et ZTNA déjà configuré, ainsi qu’un utilisateur affecté clairement identifié. L’absence de menus ou d’autorisations ne permet pas de conclure à un problème précis de licence ou de rôle. Dans ce cas, transmettre le contrôle à l’administrateur Sophos Central responsable.

Le contrôle de l’utilisateur dans Sophos Central nécessite un accès à Meine Umgebung > Benutzer und Gruppen > Benutzer. Pour le test de connectivité, il faut connaître le FQDN de la passerelle ZTNA réellement configurée et le type de passerelle : Sophos Cloud Gateway ou passerelle locale. Dans la commande, remplacer l’espace réservé par le FQDN de la passerelle ZTNA, et non par le nom d’une ressource RDP/SSH cible.

Pendant le diagnostic, ne modifier qu’une seule valeur à la fois, puis refaire le test avec le même utilisateur et le même appareil. Si un prérequis n’est pas clair ou si la gestion des utilisateurs est inaccessible, arrêter le diagnostic et transmettre le cas à l’administrateur Sophos Central, du service d’annuaire ou ZTNA responsable.

Résolution des problèmes par symptôme

Échec de l’ajout ou de la modification d’une ressource RDP/SSH sans agent

Cause probable : Au moins un membre du groupe d’utilisateurs concerné ne possède pas d’adresse email valide. Cela peut affecter aussi bien une ressource ZTNA qu’une ressource RDP/SSH dans un groupe d’applications Protected Browser.

Contrôle :

1. Ouvrir Meine Umgebung > Benutzer und Gruppen > Benutzer.
2. Dans la colonne E-Mail, contrôler tous les utilisateurs du groupe qui doit être affecté à la ressource ou au groupe d’applications.

Résultat attendu : Chaque utilisateur du groupe concerné possède une adresse email valide. Une entrée vide confirme l’état d’erreur.

Action sûre : Ajouter l’adresse manquante dans le service d’annuaire faisant autorité. L’ajouter directement dans Sophos Central uniquement pour les utilisateurs créés manuellement dans Sophos Central. Ne pas modifier les adresses existantes par simple supposition.

Nouvelle validation : Réessayer d’ajouter ou de modifier la même ressource sans changer le groupe. Si l’opération échoue encore alors que la colonne E-Mail est entièrement renseignée, cette cause n’est pas confirmée. Au lieu de modifier d’autres données d’identité, consigner le type de ressource, le groupe, l’heure et le message visible, puis faire remonter le cas.

Ressource RDP/SSH sans agent inaccessible via Protected Browser

Cause probable : L’appareil ne parvient pas à résoudre correctement le FQDN de la passerelle ZTNA. Le premier point de distinction reste toutefois le portail utilisateur ZTNA : si celui-ci est déjà inaccessible via Protected Browser, le problème se situe avant la ressource RDP/SSH individuelle.

Contrôle :

1. Sur le même appareil et avec le même utilisateur, essayer d’ouvrir le portail utilisateur ZTNA via Protected Browser.
2. Si le portail est inaccessible, exécuter une requête DNS sur l’appareil concerné :

nslookup <ZTNA-Gateway-FQDN>

Remplacer <ZTNA-Gateway-FQDN> par le nom de passerelle réellement configuré. nslookup est un test en lecture seule qui ne modifie aucune configuration.

Résultat attendu : Avec une Sophos Cloud Gateway, le nom de la passerelle est résolu en adresse du proxy de passerelle. Avec une passerelle locale, il est résolu en adresse de la passerelle ZTNA configurée sur le serveur DNS de l’organisation. Comparer la réponse avec la cible réellement configurée pour le modèle de passerelle concerné. En cas d’échec de la résolution, la configuration DNS doit être contrôlée. Une réponse différente ne confirme une erreur que si elle ne correspond pas à la cible configurée. Si la cible attendue est inconnue, ne pas modifier le DNS et transmettre le contrôle au responsable DNS/ZTNA.

Action sûre : Corriger la configuration DNS selon la procédure DNS/ZTNA prévue. La zone et la cible correctes dépendent du modèle de passerelle ; aucune modification DNS générale ne doit donc être effectuée ici.

Nouvelle validation : Après confirmation par le responsable DNS/ZTNA d’une correction effectuée selon la procédure prévue, exécuter de nouveau la même requête nslookup. Ouvrir ensuite le portail utilisateur ZTNA, puis seulement après la ressource RDP/SSH d’origine. Si la réponse DNS est conforme et le portail accessible, mais que la ressource reste inaccessible, consigner ces deux contrôles positifs et faire remonter l’examen ZTNA propre à la ressource.

« Netzwerk nicht erreichbar » ou « Verbindung konnte nicht hergestellt werden »

Cause probable : ZTNA utilise un fournisseur d’identité tel qu’Okta ou Entra ID, mais l’utilisateur est connecté à Protected Browser avec son Sophos ID ou comme utilisateur local. Les messages indiqués peuvent alors apparaître lors de l’accès à une application SSH ou RDP derrière la passerelle ZTNA.

Contrôle : Déterminer quel fournisseur d’identité est configuré dans ZTNA et le comparer à la méthode de connexion de la session Protected Browser actuelle.

Résultat attendu : La cause est confirmée si ZTNA utilise un fournisseur d’identité, mais que la session Protected Browser n’a pas été authentifiée par ce fournisseur.

Action sûre : Fermer la session concernée et connecter l’utilisateur à Protected Browser par l’intermédiaire du fournisseur d’identité configuré dans ZTNA. Ne pas changer le fournisseur d’identité ZTNA pour contourner une seule erreur de connexion.

Nouvelle validation : Dans la session nouvellement authentifiée, ouvrir la même application SSH ou RDP. Si le message persiste malgré des méthodes de connexion concordantes, consigner le fournisseur d’identité, l’utilisateur, la ressource et l’heure, puis transmettre le cas au responsable ZTNA.

Impossible pour l’utilisateur de se connecter à Protected Browser

Deux causes indépendantes doivent être contrôlées ici. Ne pas les corriger simultanément afin de pouvoir identifier la cause effective.

Absence d’accès à Self Service Portal

Contrôle : Ouvrir Meine Umgebung > Benutzer und Gruppen > Benutzer et contrôler la colonne Rolle de l’utilisateur concerné. Il est également possible de sélectionner le nom d’utilisateur et de vérifier le texte sous la photo de profil.

Résultat attendu : Lorsque l’accès à Sophos Central Self Service Portal est disponible, SelfService apparaît dans la colonne Rolle ou sous la photo de profil.

Action sûre : Si SelfService est absent, transmettre l’attribution de l’accès à Self Service Portal à l’administrateur Sophos Central responsable.

Nouvelle validation : Confirmer d’abord l’affichage de SelfService, puis renouveler la connexion avec ce même utilisateur.

Adresse email associée à plusieurs comptes Sophos Central

Contrôle : Déterminer si l’adresse email de l’utilisateur concerné est attribuée à plusieurs comptes Sophos Central.

Résultat attendu : L’adresse ne doit pas être associée à plusieurs comptes Sophos Central.

Action sûre : Demander à l’administrateur de tenant ou d’identités responsable de corriger l’attribution. Ne supprimer aucun utilisateur et ne modifier aucune adresse de production sans tenant cible confirmé.

Nouvelle validation : Après confirmation de l’attribution unique, renouveler la connexion à Protected Browser. En cas de nouvel échec, consigner SelfService, l’attribution de l’adresse email, l’heure et le message visible pour la remontée du cas.

SSH signale « Hostschlüsselüberprüfung fehlgeschlagen »

Cause probable : La clé enregistrée dans le client SSH ne correspond plus à celle de l’hôte. Cela peut se produire après un changement légitime, comme une réinstallation, mais le même message peut aussi signaler une modification inattendue.

Contrôle : Obtenir l’empreinte attendue de la clé d’hôte auprès du responsable du système, par un canal indépendant et fiable, puis la comparer à l’empreinte de l’hôte cible correct. Ne se fier ni à la connexion SSH en échec ni à la nouvelle clé proposée lors de cette connexion. Si l’empreinte attendue n’a pas été confirmée indépendamment, si elle ne correspond pas ou si le changement reste inexpliqué, s’arrêter à ce stade et faire remonter l’événement comme incident de sécurité.

Résultat attendu : L’hôte cible, le changement de clé légitime et l’empreinte attendue sont confirmés indépendamment et sans ambiguïté.

Action sûre : Avant toute suppression, déterminer quelles entrées la fonction proposée par le client SSH supprime. Sophos cite Bekannte Hosts löschen comme exemple, sans confirmer que cette fonction supprime uniquement l’hôte concerné. Si l’étendue de la suppression est inconnue ou si l’empreinte attendue ne peut pas être confirmée indépendamment, ne procéder à aucune réinitialisation et faire remonter le cas. Supprimer la clé enregistrée uniquement lorsque l’étendue est claire et l’empreinte confirmée. Lors de la connexion suivante, accepter seulement la clé dont l’empreinte correspond à la confirmation indépendante.

Nouvelle validation : Rétablir la connexion. La vérification de la clé d’hôte doit réussir avec la clé nouvellement acceptée. Si le message réapparaît ou si la clé change de nouveau de manière inattendue, ne pas supprimer des entrées à répétition ; faire remonter le cas avec le nom d’hôte, l’heure et le client SSH.

Retour arrière, remontée et limites opérationnelles

Il n’existe aucun rollback universel pour ces problèmes. Pour revenir en arrière en toute sécurité, ne pas effectuer de modifications générales et consigner la valeur initiale de toute attribution d’utilisateur modifiée de manière ciblée. En l’absence de résultat, s’arrêter au point de remontée correspondant. La suppression des clés d’hôte SSH connues ne constitue pas une réinitialisation générale et n’est acceptable qu’avec une empreinte confirmée indépendamment et une étendue de suppression connue.

Pour une remontée interne ou auprès du support, consigner au minimum le symptôme, l’utilisateur, l’appareil, le type de ressource, le modèle de passerelle, le FQDN de la passerelle ZTNA, l’heure et le résultat du contrôle directement associé. Les identifiants, clés privées et tokens ne doivent pas figurer dans le ticket.

Répéter uniquement le contrôle correspondant à l’action réellement exécutée ou au transfert confirmé : nouvel ajout ou nouvelle modification de la ressource après correction d’une adresse email ; connexion après confirmation de l’accès à Self Service Portal ou d’une attribution de compte unique ; ouverture de la ressource après connexion via le fournisseur d’identité configuré ; ou connexion SSH après la réinitialisation contrôlée de la clé d’hôte. Après transfert au responsable DNS/ZTNA, ne retester nslookup, le portail utilisateur et la ressource d’origine qu’une fois la correction selon sa procédure confirmée par ce responsable.

Délimitation par rapport aux autres guides

Ce runbook traite uniquement les symptômes de Protected Browser décrits ici. La configuration de Protected Browser ou de l’extension, ainsi que la configuration générale de DNS et ZTNA, relèvent des guides de configuration correspondants. Lorsqu’une telle configuration est nécessaire, transmettre le cas à l’administrateur responsable.