Configurer Per-Connection AD SSO sur Sophos Firewall pour les hôtes multi-utilisateurs

Plusieurs utilisateurs travaillent sur le même Remote Desktop Session Host, mais Sophos Firewall ne voit qu’une seule IP de serveur pour toutes les connexions. Per-Connection AD SSO résout précisément ce cas particulier pour le trafic web : le Direct Web Proxy authentifie séparément chaque connexion HTTP et HTTPS avec Kerberos ou NTLM.

Cette fonction ne se limite pas à Windows RDS : un serveur Linux multi-utilisateur peut également utiliser ce modèle de connexion, à condition que ses clients prennent en charge le Direct Web Proxy et Kerberos ou NTLM. Cet exemple présente un pilote Windows RDS ; les commandes Windows et le déploiement par GPO ne constituent pas un guide pour Linux. Les hôtes qui ne figurent pas dans la liste Multi-user hosts conservent leur authentification basée sur l’IP telle qu’elle était configurée.

La limite est aussi importante que la fonction. Seules les connexions que le navigateur ou l’application envoie explicitement au proxy reçoivent une identité utilisateur. DNS, RDP, SMB et les autres trafics sans proxy provenant de la même IP de serveur restent non authentifiés. Si ces protocoles doivent également être contrôlés par utilisateur, SATC pour Remote Desktop Services est mieux adapté.

⚠️ Dès qu’une adresse IP est ajoutée sous Multi-user hosts, elle n’utilise plus les autres méthodes d’authentification basées sur l’IP. STAS, Captive Portal, Clientless User et l’AD SSO transparent ne s’appliquent plus à cette IP. Il faut donc commencer par tester avec un seul serveur pilote et documenter au préalable le chemin d’authentification existant.

Per-Connection AD SSO en neuf étapes

1. Déterminer si seuls HTTP et HTTPS doivent réellement être traités par utilisateur via un proxy explicite.
2. Vérifier Active Directory, l’importation des groupes, le DNS, l’heure et la jonction du pare-feu au domaine.
3. Préparer un FQDN de pare-feu résolvable et un SPN HTTP correspondant pour Kerberos.
4. Évaluer d’abord la portée et l’impact sur la sécurité, puis activer AD SSO pour la zone LAN requise sous Administration > Device access et cliquer sur Apply. Limiter séparément Web proxy à l’hôte pilote par une exception ACL ciblée, si elle est prise en charge ; une exception Accept ne réduit pas une autorisation de zone. Si l’autorisation requise est inacceptable, arrêter le déploiement et obtenir une conception prise en charge et de portée limitée.
5. Créer le serveur RDS sous la forme d’un objet hôte IP contenant son adresse exacte.
6. Activer Per-Connection AD SSO pour cet hôte sous Authentication > Web authentication.
7. Configurer les navigateurs et les applications compatibles avec un proxy pour utiliser le FQDN du pare-feu et le port 3128.
8. Placer une règle dédiée à l’hôte, avec journalisation, avant les règles utilisateur concurrentes et laisser Match known users désactivé.
9. Vérifier séparément deux sessions RDS simultanées, des résultats différents de politiques web et le trafic sans proxy.

Per-Connection AD SSO, STAS ou SATC ?

Les trois méthodes fournissent un contexte utilisateur, mais répondent à des besoins différents.

• STAS convient aux clients Windows classiques lorsque l’IP d’un client correspond généralement à un seul utilisateur. Le pare-feu reçoit une association utilisateur-IP à partir des événements de connexion Windows.
• Per-Connection AD SSO convient aux hôtes multi-utilisateurs lorsque seules les connexions HTTP et HTTPS passant par un proxy explicite doivent être distinguées. Aucun agent SATC n’est nécessaire sur le serveur RDS, mais toutes les applications doivent utiliser le Direct Web Proxy de manière fiable.
• SATC convient aux systèmes Windows RDS pris en charge lorsque d’autres types de connexions issus des différentes sessions utilisateur ont également besoin d’une identité. Sophos Server Protection est alors requis sur le Session Host. Le guide Sophos actuel ne confirme pas la prise en charge d’un nouveau déploiement Citrix ; pour les installations Citrix existantes, il convient de consulter Sophos Support avant toute modification.

La méthode classique STAS sur Sophos Firewall ne peut pas distinguer plusieurs utilisateurs derrière la même IP RDS. Per-Connection AD SSO et SATC ne sont donc pas des variantes plus pratiques de STAS, mais des modèles de fonctionnement distincts. SATC n’associe lui aussi que les processus liés à un utilisateur ; les connexions générées par les services système nécessitent toujours une règle dédiée sans Match known users. Si une application ne prend pas en charge un proxy explicite ou si des protocoles non web doivent être régis par utilisateur, arrêter ici et examiner SATC.

Exemple et valeurs à remplacer

La procédure utilise l’exemple suivant :

• Hôte multi-utilisateur : RDS01
• Adresse IP : 10.20.30.40
• FQDN du pare-feu et destination du proxy : fw01.corp.example
• Port du Direct Web Proxy : 3128
• Groupes AD : RDS-Web-Standard et RDS-Web-Restricted
• Un compte pilote par groupe, avec des résultats de politiques web volontairement différents

Remplacer 10.20.30.40 par l’IP fixe du serveur pilote telle qu’elle est visible par le pare-feu. Aucun autre système ne doit apparaître derrière cette adresse via NAT. fw01.corp.example est un nom utilisé pour la documentation et doit être remplacé par le véritable FQDN du pare-feu, résolvable en interne. La partie correspondant au nom d’hôte doit comporter au maximum 15 caractères et être écrite en minuscules, afin que le nom d’hôte, le nom NetBIOS, l’objet ordinateur AD et le SPN concordent.

Le port 3128 est le port par défaut du Direct Web Proxy. Si l’environnement utilise un autre port d’écoute, le pare-feu, le fichier PAC ou la GPO, les navigateurs et les tests doivent tous utiliser la même valeur. Les groupes d’exemple servent uniquement à rendre la validation compréhensible ; les noms de groupes et les politiques web doivent correspondre à votre propre structure d’autorisations.

Préparer les prérequis

Vérifier Active Directory et la jonction au domaine

Le pare-feu nécessite un serveur Active Directory fonctionnel, des groupes importés et une jonction au domaine réussie. Connecter Active Directory à Sophos Firewall explique LDAPS, la base de recherche, l’importation des groupes et les prérequis généraux d’AD SSO.

Si le serveur AD n’est pas encore configuré, sélectionner le type Active Directory sous Authentication > Servers > Add. Renseigner le nom du serveur, l’IP ou le FQDN accessible du DC, le domaine NetBIOS, le domaine AD et la base de recherche de votre environnement. Pour corp.example, la base de recherche est dc=corp,dc=example. Chiffrer la connexion avec SSL/TLS sur le port 636 ou STARTTLS sur le port 389, et préparer la vérification du certificat conformément à la procédure AD liée. Renseigner le compte de lecture/jonction disposant des droits décrits ci-dessous, exécuter Test connection et enregistrer avec Save. Ne pas remplacer un serveur AD déjà utilisé uniquement pour le pilote, ni modifier ses identifiants sans vérification. Si le domaine impose une liaison de canal LDAP stricte ou la signature LDAP, clarifier la compatibilité dans la procédure AD avant le déploiement ; l’aide Sophos relative aux serveurs AD mentionne une restriction à ce sujet. Ne désactiver aucune exigence de protection à l’échelle du domaine pour résoudre un problème.

Lors de l’importation des groupes, la sélection d’une unité d’organisation (OU) sélectionne automatiquement tous les groupes qu’elle contient. Attach to all the Groups attribue les politiques communes sélectionnées à chaque groupe importé par l’assistant. Avant de terminer, vérifier donc la liste de groupes élargie par la sélection de l’OU et la portée de ces politiques ; ne conserver que les groupes réellement nécessaires et les attributions de politiques prévues.

Pour le pilote, ouvrir Import pour le serveur AD sous Authentication > Servers > Manage, démarrer l’Import group wizard avec Start et sélectionner la Base DN appropriée. Pour le domaine d’exemple corp.example, elle est dc=corp,dc=example ; remplacer les composants du domaine, pas la syntaxe LDAP. Sélectionner RDS-Web-Standard et RDS-Web-Restricted, vérifier l’attribution des politiques communes et le récapitulatif, terminer l’assistant et le fermer avec Close. Vérifier ensuite sous Authentication > Groups que les deux groupes sont bien présents. Une jonction au domaine réussie ne suffit pas à importer les groupes nécessaires aux politiques.

Pour une requête LDAP normale, un compte disposant de droits de lecture suffit. La jonction au domaine et la création du SPN nécessitent en revanche un compte administrateur du domaine ou un compte avec des droits correctement délégués. Le compte configuré doit également permettre une nouvelle jonction ultérieure, car la HA, l’ajout de serveurs AD ou les mises à niveau peuvent la déclencher à nouveau. Il convient de ne pas utiliser durablement, sans nécessité, un compte administrateur du domaine sans restriction.

Sous Authentication > Services > Firewall authentication methods, sélectionner le serveur AD prévu et le placer dans le bon ordre. S’il y a plusieurs serveurs, le pare-feu les examine de haut en bas. Test connection sur le serveur AD confirme uniquement les identifiants et l’accessibilité, pas l’authentification Kerberos ou NTLM ultérieure dans le navigateur.

Dans la même section, choisir délibérément la Default group et enregistrer avec Apply. Si le groupe AD nécessaire n’est pas importé, un utilisateur correctement authentifié peut se retrouver dans le groupe par défaut au lieu de recevoir la politique de groupe souhaitée. Les utilisateurs situés dans une OU sans appartenir à un groupe de l’annuaire peuvent apparaître dans l’Open group. En cas d’appartenance à plusieurs groupes, le premier groupe correspondant peut déterminer la politique ; il faut donc contrôler non seulement l’importation, mais aussi l’ordre et l’association effective. Pour le pilote, ne pas utiliser un groupe par défaut doté d’autorisations étendues pour compenser une importation manquante. Lors de la première nouvelle connexion, vérifier l’association réelle au groupe sous Authentication > Users ; un objet utilisateur n’est pas nécessairement visible avant cette connexion.

Contrôler le FQDN, le DNS, le SPN et l’heure

Kerberos ne fonctionne que si les clients utilisent le FQDN du pare-feu comme destination du proxy. Une adresse IP de proxy ne suffit pas. Sur un client pilote Windows, les vérifications en lecture seule suivantes sont utiles :

Resolve-DnsName fw01.corp.example
setspn -Q HTTP/fw01.corp.example
w32tm /query /status

Le SPN HTTP, dont le nom complet est Service Principal Name, associe le FQDN du proxy à l’objet ordinateur AD du pare-feu. setspn -Q doit retourner exactement une association correspondante. L’absence de résultat ou la présence de plusieurs résultats doit être clarifiée avant le déploiement.

Le suffixe DNS configuré dans le champ du nom d’hôte n’est pas automatiquement le suffixe AD : lors de la jonction au domaine, le pare-feu construit le nom d’ordinateur AD et le SPN à partir de son nom NetBIOS et du domaine AD. Si le domaine DNS et le domaine AD diffèrent, comparer le FQDN enregistré sur l’objet ordinateur AD avec la destination prévue du proxy. L’exemple suppose qu’un SPN correspondant existe pour fw01.corp.example ; la simple saisie de ce nom sous Admin and user settings ne le prouve pas. Clarifier d’abord conjointement le DNS et le SPN pour la destination réelle du proxy, puis déployer la configuration du proxy. Ne pas créer de SPN supplémentaires au hasard.

La réponse DNS doit correspondre au pare-feu prévu. Le client, le contrôleur de domaine et le pare-feu doivent également avoir une heure compatible avec le fonctionnement de Kerberos. Les commandes ne modifient rien. Ne pas corriger le SPN, la jonction au domaine ou la configuration horaire sur la base d’une supposition ; établir d’abord l’erreur réelle.

Recenser la compatibilité proxy et les exceptions

Chaque navigateur et chaque application dont le trafic web doit recevoir une identité utilisateur doit utiliser le proxy explicite et prendre en charge Kerberos ou NTLM ; dans l’exemple Windows RDS, cela passe par l’authentification Windows intégrée. Avant le déploiement, vérifier au minimum :

• Les navigateurs dans chaque session RDS prise en charge
• Les applications disposant de leur propre pile HTTP
• Les mises à jour Windows et logicielles
• Les services exécutés dans le contexte système plutôt que dans une session utilisateur
• Les destinations figurant dans le fichier PAC ou la liste de contournement du proxy

Le trafic qui contourne le proxy reste, comme prévu, sans identité utilisateur. Pour les connexions machine nécessaires, prévoir une règle dédiée, strictement limitée et sans référence à un utilisateur. Une règle Any trop large affaiblirait l’efficacité des politiques utilisateur et web.

Configurer Per-Connection AD SSO

1. Préparer le FQDN du pare-feu et AD SSO

Sous Administration > Admin and user settings, saisir le FQDN prévu du pare-feu et enregistrer avec Apply. Ensuite, sous Authentication > Web authentication, sélectionner Kerberos & NTLM dans If Active Directory (AD) SSO is configured et enregistrer également avec Apply. NTLM est techniquement pris en charge comme solution de repli ; Kerberos est plus rapide et plus sûr et doit fonctionner de manière fiable dans le pilote. Comme chaque connexion proxy peut déclencher une authentification, observer également les erreurs d’authentification, les temps de réponse et la charge du pare-feu et d’AD sous un trafic représentatif avant un déploiement plus large. Ne pas en déduire un multiplicateur de charge fixe ni une capacité utilisateur garantie.

Si les terminaux ne sont pas correctement configurés pour Kerberos ou si le navigateur ne prend pas en charge l’authentification Kerberos, NTLMv2 est automatiquement utilisé comme solution de repli. Contrairement à Kerberos, NTLMv2 ne nécessite pas de FQDN comme destination du proxy. Ce repli de compatibilité ne garantit toutefois pas une authentification réussie : les canaux d’authentification décrits ci-dessous doivent être initialisés, et le chemin d’authentification réel doit être vérifié avec les comptes pilotes.

Dans le Log Viewer, sous Authentication, les messages de réussite suivants doivent apparaître après l’initialisation d’AD SSO :

• Kerberos authentication initialized successfully
• NTLM authentication channel established successfully

Le pare-feu ne propose ces méthodes que lorsque les deux canaux fonctionnent. Cannot initialize Kerberos authentication ou Cannot establish NTLM authentication channel sont des signaux d’arrêt, pas une invitation à redémarrer un service à l’aveugle.

2. Limiter strictement les autorisations Device Access

Sophos exige l’activation d’AD SSO pour la zone LAN requise sous Administration > Device access, suivie d’Apply, comme prérequis à Kerberos/NTLM. Évaluer d’abord la portée de cette autorisation et son impact sur la sécurité ; ne pas ouvrir toute la zone LAN sans cette analyse. Désactiver AD SSO dans toutes les zones empêche Kerberos/NTLM ; une exception ACL AD SSO limitée à un hôte ne remplace pas ce prérequis. Ajouter une exception Accept ne réduit pas une autorisation de zone existante. Si l’autorisation requise est inacceptable, arrêter le déploiement et obtenir auprès du responsable des ACL ou de Sophos Support une conception prise en charge et de portée limitée pour le build installé. Séparément, limiter l’accès source à Web proxy à l’hôte pilote avec une Local service ACL exception rule ciblée, si elle est prise en charge. Une exception Accept ne réduit pas une autorisation Web proxy déjà active pour toute la zone ; cette autorisation étendue ne doit pas rester active pour un accès réellement limité à l’hôte. N’autoriser aucune autre zone ni aucun service inutile. Device Access et Local Service ACL explique la configuration complète.

L’accès au proxy web a un effet secondaire important : un hôte autorisé peut atteindre les services HTTP et HTTPS du pare-feu via le proxy, même si leur zone n’est pas autorisée dans la matrice normale des services locaux. Effectuer donc des tests négatifs de WebAdmin, User Portal et des autres destinations locales depuis l’hôte pilote. Si cette exposition n’est pas acceptable dans votre réseau, ne pas activer cette conception en production.

Sous Web > General settings, vérifier le Web proxy listening port réellement utilisé et les ports de destination autorisés. Ne modifier la valeur par défaut 3128 que si le fichier PAC, la GPO et toutes les applications gérées peuvent être adaptés de façon cohérente.

3. Créer l’hôte multi-utilisateur

Créer un nouvel objet hôte à l’emplacement suivant :

Hosts and services > IP host > Add

L’exemple utilise les valeurs suivantes :

1. Name: RDS01
2. IP version: IPv4
3. Type: IP
4. IP address: 10.20.30.40

Enregistrer avec Save et vérifier que l’objet contient l’IP exacte du pilote avant de le sélectionner dans la liste des hôtes multi-utilisateurs.

Pour le premier test, ne pas saisir une plage entière ni un sous-réseau. De nombreux systèmes pourraient sinon perdre simultanément leur authentification existante basée sur l’IP. Après une validation individuelle réussie, plusieurs hôtes autorisés ultérieurement peuvent être regroupés de manière contrôlée dans un groupe d’hôtes.

4. Activer Per-Connection AD SSO

Accéder à cette section :

Authentication > Web authentication > Authentication settings for direct web proxy

Puis :

1. Activer Use per-connection AD SSO authentication for multi-user hosts.
2. Sous Multi-user hosts, ajouter l’objet RDS01 avec Add new item.
3. Enregistrer avec Apply.

À partir de cet instant, STAS, Captive Portal, Clientless User et l’AD SSO transparent ne sont plus disponibles pour 10.20.30.40. Effectuer donc cette modification pendant une fenêtre de maintenance et ne pas utiliser une session RDS existante comme seul test.

Correspondance API facultative pour l’automatisation

Pour automatiser cette étape de l’interface graphique, la référence API de SFOS 22.0 et 23.0 décrit l’entité DirectWebProxyAuthentication. Elle établit la correspondance suivante avec le commutateur et la liste des hôtes multi-utilisateurs ; cette correspondance ne constitue pas une requête complète exécutable.

• DirectWebProxyAuthentication > PerConnectionAuth correspond au commutateur d’activation ou de désactivation de Per-Connection AD SSO. Le paramètre est documenté comme un SCALAR non obligatoire et n’autorise que Enable ou Disable. La notation avec une barre oblique dans l’exemple de la référence indique des alternatives, et non une troisième valeur autorisée.
• DirectWebProxyAuthentication > MultiUserHosts > Host décrit la liste des noms d’hôtes multi-utilisateurs, soit, dans l’exemple, le nom de l’objet hôte créé précédemment, RDS01, et non son adresse IP. Host est non obligatoire et documenté comme un ARRAY de type de données STRING. Plusieurs valeurs sont autorisées et, selon la référence, les doublons sont ignorés. La référence indique un maximum de 1500 caractères, sans préciser si cette limite s’applique à chaque valeur ou à l’ensemble de la liste.

Les colonnes des valeurs par défaut sont vides : cela ne permet de déduire ni une valeur par défaut documentée ni l’effet de l’omission de certains champs. La section consacrée à l’opération ne précise pas non plus si une liste transmise complète ou remplace les entrées existantes, ni comment supprimer des entrées. Il ne faut donc considérer ni l’omission ni une liste vide comme un moyen sûr de revenir à l’état antérieur ; les modalités exactes de mise à jour et de suppression doivent être clarifiées pour le build utilisé avant toute automatisation.

Le tableau des statuts contient 200 et 500. Ces valeurs de référence ne confirment ni le statut réel du transport HTTP ni le traitement correct des utilisateurs et des politiques. Les champs de message renvoient à du JavaScript ; la section de l’opération fournie ne donne aucun message de réponse littéral.

Même lors d’une modification ultérieure autorisée via l’API, les prérequis ci-dessus et le pilote strictement limité à un seul hôte restent applicables. Avant la modification, sauvegarder en sécurité les paramètres réellement en place et prévoir un accès d’administration indépendant. Ensuite, relire le commutateur et la liste complète des hôtes multi-utilisateurs sur le pare-feu précis qui a été modifié, puis les comparer à l’état souhaité ; effectuer ensuite les tests positifs et négatifs décrits ci-dessous pour le proxy, les utilisateurs, les politiques, le trafic sans proxy et les services locaux. Une réponse d’acceptation de la configuration ne remplace pas cette validation. Pour le retour arrière, restaurer l’état antérieur sauvegardé, sans en déduire une syntaxe de suppression API non étayée.

5. Déployer le Direct Web Proxy

Configurer le proxy du navigateur ou du système par GPO, fichier PAC ou application gérée avec la valeur suivante :

fw01.corp.example:3128

Pour Kerberos, il faut utiliser exactement le FQDN correspondant au SPN. Une adresse IP comme destination du proxy, un nom court non résolvable ou un autre alias entraîne souvent un repli vers NTLM ou une demande d’identifiants. Limiter délibérément les entrées de contournement et les documenter, car chaque connexion qui contourne le proxy ne reçoit aucune identité Per-Connection.

La configuration générale du port d’écoute, du PAC, des règles et du retour arrière est décrite dans Configurer le Direct Web Proxy avec un fichier PAC. Le présent article complète uniquement cette configuration avec l’authentification multi-utilisateur.

6. Positionner une règle de pare-feu dédiée

Sous Rules and policies > Firewall rules, créer une règle sortante dédiée à RDS01, avec un nom explicite. Elle doit précéder les règles qui ciblent le même hôte avec Match known users.

Pour cet exemple IPv4, sélectionner IPv4 > Add firewall rule > New firewall rule. Définir par exemple Rule name sur RDS01_DirectProxy_Outbound et Action sur Accept. Le nom est libre ; il doit permettre d’identifier l’hôte et la fonction. Vérifier la position avant les règles utilisateur concurrentes à partir de la liste complète des règles, et non du seul nom.

Le cadre sécurisé :

• Source zones: zone réelle de RDS, par exemple LAN
• Source networks and devices: uniquement RDS01
• Destination zones: WAN
• Destination networks: uniquement les destinations nécessaires ou, délibérément, Any
• Services: HTTP, HTTPS et un service TCP dédié pour 3128 ou le port d’écoute du proxy réellement configuré ; Any uniquement par choix délibéré. Sélectionner uniquement le port d’écoute ne constitue pas une sélection complète des services pour le proxy direct.
• Log firewall traffic: activé
• Match known users: désactivé
• Web filtering > Web policy: sélectionner la politique préparée, dépendante de l’utilisateur ou du groupe

Les politiques web peuvent distinguer les utilisateurs et les groupes dans le trafic proxy, mais elles ne s’appliquent que lorsqu’elles sont associées à la règle de pare-feu. Cette distinction relève de la politique web, pas de Match known users dans cette règle d’hôte. Après avoir sélectionné ou modifié la politique web, vérifier à nouveau ce commutateur, car une dépendance à l’utilisateur peut le réactiver.

Enregistrer avec Save, rouvrir la règle et contrôler Match known users, la journalisation, la politique web et la position. La règle d’hôte autorise le chemin de trafic prévu ; la politique web décide, à l’intérieur de ce chemin, des autorisations des utilisateurs et des groupes. Une identité correctement reconnue ne signifie donc pas automatiquement que l’autorisation est correcte.

Le guide général AD SSO décrit également des règles utilisateur avec Match known users activé. Ce n’est pas le modèle de règle applicable à l’IP multi-utilisateur définie ici : le guide spécifique Per-Connection exige explicitement une règle dédiée avec ce commutateur désactivé. Ne pas non plus reprendre les critères de correspondance des services d’une règle HTTP/HTTPS transparente : le port d’écoute du proxy décrit le chemin client-proxy, tandis qu’une connexion distincte proxy-destination utilise des services de destination tels que HTTP ou HTTPS. Confirmer dans le pilote la Rule ID réelle et le port approprié à partir des journaux. Un client IPv6 avec une destination IPv4 peut nécessiter deux règles ; cet exemple IPv4 ne constitue pas un guide Dual Stack complet.

Pour DNS, les mises à jour et les autres connexions nécessaires sans proxy, créer une règle machine distincte. Ne pas ajouter de règle générale WAN vers LAN ; l’exemple entrant présenté par Sophos n’est pas nécessaire pour l’accès web RDS normal et constituerait une surface d’attaque inutile sans objectif de publication propre. Créer correctement des règles de pare-feu explique la structure, l’ordre et la journalisation.

Si, indépendamment du proxy, un accès entrant justifié vers l’hôte multi-utilisateur existe, Match known users doit également être désactivé dans sa règle dédiée. Définir strictement la zone source et les hôtes sources autorisés, la zone de destination et RDS01, ainsi que les services réellement nécessaires, activer la journalisation et vérifier la position avant les règles utilisateur concurrentes. Il ne s’agit pas d’une invitation à exposer RDP publiquement ; aucune nouvelle règle entrante n’est créée pour l’accès web normal.

Valider avec deux utilisateurs RDS

Un seul accès réussi depuis un navigateur prouve uniquement qu’un certain trafic proxy fonctionne. La validation proprement dite nécessite deux sessions simultanées.

1. Associer deux comptes pilotes AD à des groupes de politiques web différents.
2. Ouvrir deux nouvelles sessions RDS sur RDS01.
3. Vérifier la configuration effective du proxy dans les deux sessions.
4. Déclencher dans chacune un accès HTTP ou HTTPS autorisé et un accès dont le traitement doit volontairement différer.
5. Sous Current activities > Live users, vérifier les deux utilisateurs avec le Client Type Multi-host client.
6. Sous Log viewer > Authentication, contrôler les utilisateurs et Log Comp pour Kerberos ou NTLM.
7. Comparer l’utilisateur, la politique, la Rule ID, l’action et l’horodatage dans les journaux web et du pare-feu.
8. Déclencher un test nécessaire sans proxy et confirmer qu’il ne reçoit pas à tort une identité utilisateur.
9. Depuis l’hôte pilote, recenser les services HTTP et HTTPS locaux du pare-feu accessibles via le proxy. Si un service interdit par la conception de sécurité est accessible, arrêter le déploiement et ne le reprendre qu’après la mise en place d’une mesure de protection supplémentaire dont l’efficacité est démontrée.

Une comparaison pertinente utilise la même destination de test approuvée dans les deux sessions : un compte de RDS-Web-Standard peut l’ouvrir, tandis qu’un compte de RDS-Web-Restricted est bloqué par la politique web préparée. Consigner la date, l’heure, l’utilisateur, l’IP source, la Rule ID, la politique et le résultat. Accéder ensuite à une destination de contrôle que les deux groupes sont autorisés à utiliser. Cela permet de distinguer une restriction de groupe intentionnelle d’une panne générale du proxy ou du DNS. Les destinations de test proviennent de votre propre liste de tests approuvée ; ne pas bloquer un site web professionnel en production uniquement pour la validation.

N’ajouter d’autres hôtes RDS que lorsque les deux utilisateurs sont correctement distingués simultanément, que les résultats attendus des politiques web sont obtenus et que le chemin sans proxy est compris. Pour la validation générale des règles, consulter Tester les règles Sophos Firewall de manière contrôlée.

Dépannage

Le proxy est inaccessible

Vérifier la résolution du FQDN, le port, le résultat du PAC ou de la GPO, la zone source et les autorisations Web proxy et AD SSO. Un test réussi du serveur AD ne prouve pas l’accès au proxy. Pour les routes SD-WAN, le port du proxy ou Any doit correspondre au critère de service ; le pare-feu crée lui-même la connexion proxy externe, de sorte que toutes les caractéristiques du client ne s’appliquent pas comme pour du trafic routé normal.

Le navigateur demande des identifiants ou utilise NTLM

Vérifier la destination du proxy, le DNS, le SPN HTTP, la zone du navigateur et l’authentification intégrée. Kerberos nécessite le FQDN correspondant, pas l’IP du pare-feu. Le repli vers NTLM est un symptôme qu’il faut d’abord expliquer, pas une raison de déployer préventivement une configuration NTLM uniquement.

Les deux sessions apparaissent sous le même utilisateur

Vérifier que les deux navigateurs utilisent réellement le proxy explicite et qu’aucune application ne génère de connexions en dehors de la session utilisateur correspondante. Un proxy intermédiaire ou du NAT peut également modifier le modèle de connexion souhaité. Dans Live Users, le type Multi-host client doit apparaître ; une association normale basée sur l’IP représente un chemin incorrect pour cet hôte.

L’utilisateur est visible, mais la politique web ne s’applique pas

Vérifier conjointement le groupe AD, Main Group, l’ordre des politiques web, la règle de pare-feu et l’entrée du journal. Match known users doit rester désactivé dans la règle d’hôte spécifique. Une authentification visible ne prouve pas encore que la requête utilise la politique web ou la Firewall Rule ID attendue.

Si l’utilisateur pilote se trouve dans la Default group au lieu du groupe AD importé attendu, vérifier d’abord Authentication > Groups, la base de recherche et l’importation des groupes. Ne pas attribuer une politique de groupe par défaut plus permissive pour masquer l’erreur. Après une correction contrôlée, vérifier avec une nouvelle connexion que l’association et les deux tests de politiques sont corrects.

Le trafic non web n’affiche aucun utilisateur

C’est le comportement attendu. Per-Connection AD SSO identifie uniquement HTTP et HTTPS via le Direct Web Proxy. Le trafic machine requis relève d’une règle sans référence à un utilisateur. Si RDP, SMB, les connexions aux bases de données ou d’autres trafics sans proxy doivent être distingués par session, passer à SATC.

SSO ne fonctionne plus après une mise à niveau ou un basculement HA

AD SSO peut nécessiter une nouvelle jonction au domaine après une mise à niveau, lors de l’utilisation de plusieurs serveurs AD ou en HA. Le compte de jonction délégué doit donc rester valide. Après un basculement contrôlé, tester avec une nouvelle connexion proxy et les deux comptes pilotes ; ne pas supposer que les connexions proxy existantes ou les tickets Kerberos se poursuivent sans interruption. Dans chaque mode HA, chaque nœud ne conserve que les journaux du trafic qu’il a lui-même traité. Pour un événement, vérifier donc le nœud actif ou celui qui traitait le trafic à cet instant.

Lors d’une mise à niveau directe de SFOS 21.5 ou d’une version antérieure vers SFOS 22.0 GA Build 411, le problème connu NC-176853 peut également être en cause : AD SSO avec NTLM et Kerberos peut cesser de fonctionner immédiatement après la mise à niveau, de sorte que les politiques basées sur l’identité ne correspondent plus. Sophos indique SFOS 22.0 MR1 Build 490 comme version corrective. La procédure interne relative à KBA-000048429 décrit le diagnostic et la solution de contournement. La Known Issues List ne mentionne pas séparément Per-Connection AD SSO ; ce constat n’est donc pertinent que si le chemin AD SSO sous-jacent échoue après cette mise à niveau précise. Conserver le build du firmware, l’horodatage et les journaux, vérifier la KBA pour le build concerné et ne pas contourner le problème par des règles trop larges ou un changement d’authentification.

Lire les journaux pertinents

Dans l’Advanced Shell, les fichiers suivants sont pertinents :

cd /log
tail -n 200 nasm.log
tail -n 200 access_server.log
tail -n 200 awarrenhttp.log

nasm.log présente les problèmes NTLM, Kerberos et éventuellement KVNO. access_server.log aide pour l’authentification et l’autorisation, et awarrenhttp.log pour le proxy web. awarrenhttp_access.log n’est créé que lorsque la journalisation de débogage est temporairement activée et ne fait pas partie de la première étape normale. Avant de redémarrer des services ou d’étendre la journalisation de débogage, conserver d’abord la plage horaire, l’utilisateur, la destination, la règle et les journaux existants.

Retour arrière

Un retour arrière propre rétablit non seulement le proxy, mais aussi le modèle d’authentification antérieur.

1. Documenter la liste actuelle des hôtes multi-utilisateurs, les exceptions Device Access, les règles, la politique web et le déploiement du proxy.
2. Retirer RDS01 de Multi-user hosts et enregistrer avec Apply.
3. Annuler de manière contrôlée la GPO proxy, le fichier PAC ou la configuration de l’application.
4. Ne rétablir l’ancienne association STAS, Clientless ou Captive Portal que si elle était documentée au préalable et adaptée à cette IP.
5. Après vérification des autres dépendances, supprimer l’exception ACL du pilote ou les autorisations temporaires de zone pour AD SSO et le proxy web, ou les remettre exactement dans leur état antérieur.
6. Désactiver ou supprimer les règles spécifiques à l’hôte et aux machines dès que le chemin de remplacement est confirmé.
7. Tester à nouveau avec de nouvelles sessions de navigateur et RDS et, en HA, dans les deux rôles opérationnels.

Liste de contrôle

• Per-Connection AD SSO est destiné uniquement au trafic HTTP/HTTPS passant par un proxy explicite.
• L’hôte pilote possède une IP fixe et unique, sans autres systèmes derrière elle.
• AD, les groupes, la jonction au domaine, le FQDN, le DNS, le SPN et l’heure ont été vérifiés.
• Prérequis de zone AD SSO et impact sur la sécurité vérifiés ; zone LAN requise activée et Apply appliqué, accès Web proxy limité séparément à l’hôte pilote sans autorisation proxy étendue. Si l’autorisation de zone est inacceptable, arrêter le déploiement et obtenir une conception prise en charge et de portée limitée.
• Les navigateurs et les applications utilisent fw01.corp.example:3128 ou vos propres valeurs de remplacement.
• La règle d’hôte spécifique a la journalisation activée et Match known users désactivé.
• Le trafic sans proxy est prévu comme trafic machine, ou la conception a été modifiée pour utiliser SATC.
• Deux utilisateurs simultanés, des politiques différentes et l’accès d’administration ont fait l’objet de tests positifs et négatifs.
• Le basculement HA et les mises à niveau disposent d’une procédure documentée de nouvelle jonction et de nouveaux tests.
• Le retour arrière de la liste des hôtes multi-utilisateurs, du déploiement du proxy, de Device Access, des règles et de l’authentification antérieure est documenté.

Questions fréquentes