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 ce cas particulier pour le trafic web : le Direct Web Proxy authentifie séparément chaque connexion HTTP et HTTPS avec Kerberos ou NTLM.

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 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 les flux HTTP et HTTPS envoyés via un proxy explicite doivent être traités par utilisateur.
2. Vérifier Active Directory, l’importation des groupes, DNS, l’heure et le Domain Join du pare-feu.
3. Préparer un FQDN de pare-feu résolvable et un HTTP SPN correspondant pour Kerberos.
4. Autoriser AD SSO et Web proxy uniquement pour la zone source ou l’hôte pilote nécessaires.
5. Créer le serveur RDS comme objet IP host exact.
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. Tester séparément deux sessions RDS simultanées, des résultats de Web Policy différents 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 lorsqu’une IP cliente correspond généralement à un seul utilisateur. Le pare-feu reçoit une association entre utilisateur et IP à partir des événements de connexion Windows.
• Per-Connection AD SSO convient aux hôtes multi-utilisateurs lorsqu’il suffit de distinguer les connexions HTTP et HTTPS envoyées explicitement au proxy. 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 RDS ou Citrix lorsque d’autres types de connexion issus de chaque session utilisateur nécessitent également une identité. Sophos Server Protection est alors requis sur le Session Host.

Le STAS classique 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 d’exploitation distincts. Si une application ne prend pas en charge un proxy explicite ou si des protocoles non web doivent être contrôlés par utilisateur, il faut s’arrêter ici et évaluer SATC.

Exemple et valeurs à remplacer

Ce guide utilise l’exemple suivant :

• Hôte multi-utilisateurs : RDS01
• Adresse IP : 10.20.30.40
• FQDN du pare-feu et cible 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 Web Policy volontairement différents

Il faut remplacer 10.20.30.40 par l’IP fixe du serveur pilote telle que le pare-feu la voit. Aucun autre système ne doit apparaître derrière cette adresse via NAT. fw01.corp.example est un nom de documentation à remplacer par le véritable FQDN du pare-feu, résolvable en interne. La partie hôte devrait comporter au maximum 15 caractères et être écrite en minuscules afin que le hostname, le nom NetBIOS, l’objet ordinateur AD et le SPN correspondent.

Le port 3128 est la valeur par défaut du Direct Web Proxy. Si l’environnement utilise un autre listening port, le pare-feu, le fichier PAC ou la GPO, le navigateur et les tests doivent tous utiliser la même valeur. Les groupes de l’exemple servent uniquement à clarifier la validation ; leurs noms et les Web Policies doivent correspondre à la structure d’autorisations réelle.

Préparer les prérequis

Vérifier Active Directory et le Domain Join

Le pare-feu nécessite un serveur Active Directory fonctionnel, des groupes importés et un Domain Join réussi. 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.

Un compte disposant de droits de lecture suffit pour une requête LDAP normale. En revanche, le Domain Join et la création du SPN nécessitent un compte Domain Admin ou un compte doté de droits correctement délégués. Le compte enregistré doit également permettre un rejoin ultérieur, car HA, des serveurs AD supplémentaires ou des mises à niveau peuvent le déclencher de nouveau. Il ne faut pas conserver inutilement un compte Domain Admin sans restriction à cette fin.

Sous Authentication > Services > Firewall authentication methods, sélectionner le serveur AD prévu et le placer dans le bon ordre. Avec plusieurs serveurs, le pare-feu les vérifie de haut en bas. Test connection sur le serveur AD confirme uniquement les identifiants et l’accessibilité, pas la future connexion Kerberos ou NTLM dans le navigateur.

Vérifier le FQDN, DNS, le SPN et l’heure

Kerberos fonctionne uniquement lorsque les clients utilisent le FQDN du pare-feu comme cible du proxy. Une adresse IP de proxy ne suffit pas. Sur un client Windows pilote, les contrôles en lecture seule suivants sont utiles :

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

Le HTTP SPN, ou 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 plusieurs résultats doivent être clarifiés avant le déploiement.

La réponse DNS doit correspondre au pare-feu prévu. Le client, le contrôleur de domaine et le pare-feu doivent également utiliser une heure compatible avec Kerberos. Ces commandes ne modifient rien. Il ne faut pas corriger le SPN, le Domain Join ou la configuration horaire sur une simple supposition, mais d’abord prouver 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 l’authentification Windows intégrée. Avant le déploiement, vérifier au minimum :

• les navigateurs de 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 ID utilisateur. Pour les connexions machine nécessaires, prévoir une règle distincte, étroitement limitée et sans référence utilisateur. Une règle large avec Any réduirait l’effet de sécurité des règles utilisateur et des Web Policies.

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. Ensuite, sous Authentication > Web authentication, sélectionner Kerberos & NTLM pour If Active Directory (AD) SSO is configured. NTLM est techniquement pris en charge comme fallback, mais Kerberos doit fonctionner de manière fiable dans les installations importantes, car Per-Connection AD SSO peut générer de nombreuses requêtes d’authentification supplémentaires.

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

• Kerberos authentication initialized successfully
• NTLM authentication channel established successfully

Le pare-feu ne propose les 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 des invitations à redémarrer un service à l’aveugle.

2. Limiter étroitement Device Access

Sous Administration > Device access, AD SSO et Web proxy doivent être autorisés pour le chemin source prévu. Pour une IP pilote fixe, une Local service ACL exception rule ciblée est généralement plus restrictive qu’une autorisation accordée à toute la zone LAN. Une exception d’acceptation supplémentaire ne restreint toutefois pas une autorisation de zone déjà active ; pour un véritable périmètre limité, l’autorisation large doit rester désactivée. Device Access et Local Service ACL explique la configuration complète.

L’accès au Web Proxy 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 sa zone n’est pas autorisée dans la matrice Local Service normale. Il faut donc effectuer des tests négatifs depuis l’hôte pilote vers WebAdmin, User Portal et les autres cibles locales. Si cette exposition n’est pas acceptable dans la conception de sécurité du réseau, il ne faut pas activer ce modèle en production.

Sous Web > General settings, vérifier le Web proxy listening port réel 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 administrées peuvent être adaptés de manière cohérente.

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

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

Hosts and services > IP host > Add

Pour l’exemple, utiliser les valeurs suivantes :

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

Pour le premier test, ne pas saisir une plage complète ni un sous-réseau. De nombreux systèmes pourraient sinon perdre simultanément leur authentification IP existante. Après une validation individuelle réussie, plusieurs hôtes approuvés peuvent être regroupés de manière contrôlée dans un host group.

4. Activer Per-Connection AD SSO

Accéder à :

Authentication > Web authentication > Authentication settings for direct web proxy

Puis :

1. Activer Use per-connection AD SSO authentication for multi-user hosts.
2. Ajouter l’objet RDS01 sous Multi-user hosts.
3. Enregistrer avec Apply.

À partir de ce moment, STAS, Captive Portal, Clientless User et l’AD SSO transparent ne sont plus disponibles pour 10.20.30.40. Il faut donc effectuer la modification pendant une fenêtre de maintenance et ne pas utiliser une session RDS existante comme seul test.

5. Déployer le Direct Web Proxy

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

fw01.corp.example:3128

Kerberos nécessite exactement le FQDN correspondant au SPN. Une adresse IP comme cible du proxy, un nom court non résolvable ou un autre alias provoque souvent un fallback vers NTLM ou une demande d’identifiants. Les entrées de contournement doivent rester volontairement limitées et être documentées, car chaque connexion contournée ne reçoit aucune identité Per-Connection.

La configuration générale du listener, du PAC, de la règle et du retour arrière est décrite dans Configurer Direct Web Proxy avec un fichier PAC. Cet article ajoute uniquement l’authentification multi-utilisateurs.

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 et clairement nommée pour RDS01. Elle doit précéder les règles qui couvrent le même hôte avec Match known users.

Le cadre sécurisé est le suivant :

• Source zones: zone RDS réelle, par exemple LAN
• Source networks and devices: uniquement RDS01
• Destination zones: WAN
• Destination networks: uniquement les destinations nécessaires ou, en connaissance de cause, Any
• Services: un service TCP personnalisé pour 3128 ou le proxy listening port réellement configuré ; Any uniquement en connaissance de cause
• Log firewall traffic: activé
• Match known users: désactivé
• Web filtering > Web policy: sélectionner la stratégie préparée dépendant de l’utilisateur ou du groupe

Les Web Policies peuvent distinguer les utilisateurs et les groupes dans le trafic proxy, mais elles ne s’appliquent qu’après avoir été affectées à la règle de pare-feu. Cette distinction doit être définie dans la Web Policy, et non dans Match known users de cette règle d’hôte. Après avoir sélectionné ou modifié la Web Policy, vérifier de nouveau le commutateur, car une dépendance utilisateur peut le réactiver.

Créer une règle machine séparée pour DNS, les mises à jour et les autres connexions sans proxy nécessaires. 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 un accès web RDS normal et créerait une surface d’attaque inutile sans objectif de publication distinct. Créer correctement des règles de pare-feu explique la structure, l’ordre et la journalisation.

Valider avec deux utilisateurs RDS

Une seule requête réussie dans le navigateur prouve seulement qu’un trafic proxy fonctionne. La validation réelle nécessite deux sessions simultanées.

1. Affecter deux comptes pilotes AD à des groupes de Web Policy différents.
2. Ouvrir deux nouvelles sessions RDS sur RDS01.
3. Vérifier la configuration proxy effective dans les deux sessions.
4. Déclencher une requête autorisée et une requête HTTP ou HTTPS volontairement évaluée différemment.
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 l’utilisateur et Log Comp pour Kerberos ou NTLM.
7. Comparer dans les journaux web et du pare-feu l’utilisateur, la policy, la Rule ID, l’action et l’heure.
8. Déclencher un test sans proxy nécessaire et confirmer qu’il ne reçoit pas à tort une identité utilisateur.
9. Depuis l’hôte pilote, relever 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 continuer qu’après avoir démontré une mesure de protection supplémentaire.

Ajouter d’autres hôtes RDS uniquement lorsque les deux utilisateurs sont correctement distingués en même temps, que les résultats prévus de la Web Policy apparaissent et que le chemin sans proxy est compris. Tester les règles Sophos Firewall de manière contrôlée aide à réaliser une validation générale des règles.

Dépannage

Le proxy n’est pas accessible

Vérifier la résolution du FQDN, le port, le résultat du fichier 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. Avec des routes SD-WAN, le port du proxy ou Any doit correspondre au 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 un trafic routé classique.

Le navigateur demande des identifiants ou utilise NTLM

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

Les deux sessions apparaissent comme le même utilisateur

Vérifier que les deux navigateurs utilisent réellement le proxy explicite et qu’aucune application ne crée de connexions hors de la session utilisateur concernée. Un proxy en amont ou NAT peut également modifier le modèle de connexion attendu. Live Users doit afficher le type Multi-host client ; une association IP normale constitue un mauvais chemin pour cet hôte.

L’utilisateur est visible, mais la Web Policy ne s’applique pas

Vérifier ensemble le groupe AD, le Main Group, l’ordre de la Web Policy, la règle de pare-feu et l’entrée de journal. Match known users doit rester désactivé dans la règle d’hôte dédiée. Une authentification visible ne prouve pas que la requête utilise la Web Policy ou la Firewall Rule ID attendue.

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 nécessaire utilise une règle sans référence utilisateur. Si RDP, SMB, une base de données ou un autre trafic sans proxy doit être distingué par session, il faut passer à SATC.

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

AD SSO peut nécessiter un nouveau Domain Join après une mise à niveau, lors de l’utilisation de plusieurs serveurs AD ou en HA. Le compte de join délégué doit donc rester valide. Après un basculement contrôlé, effectuer le test avec une nouvelle connexion proxy et les deux comptes pilotes ; ne pas supposer que les connexions proxy ou les tickets Kerberos existants se poursuivent sans interruption. Dans chaque mode HA, chaque nœud enregistre uniquement les journaux du trafic qu’il a lui-même traité. Il faut donc vérifier le nœud actif ou chargé du traitement au moment de l’événement.

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 montre les problèmes NTLM, Kerberos et les éventuelles erreurs KVNO. access_server.log aide pour l’authentification et l’autorisation, et awarrenhttp.log pour le Web Proxy. awarrenhttp_access.log n’est créé que lorsque le debug est temporairement activé et ne fait pas partie de la première étape normale. Avant de redémarrer des services ou d’étendre le debug, il faut d’abord conserver la période, l’utilisateur, la destination, la règle et les journaux existants.

Rollback

Un rollback propre restaure non seulement le proxy, mais aussi le modèle d’authentification précédent.

1. Documenter la liste multi-utilisateurs actuelle, les exceptions Device Access, les règles, la Web Policy 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 du proxy, le fichier PAC ou la configuration de l’application.
4. Restaurer l’ancienne association STAS, Clientless ou Captive Portal uniquement si elle avait été documentée et convient à cette IP.
5. Après vérification des autres dépendances, supprimer l’exception ACL pilote ou les autorisations temporaires de zone AD SSO et Web Proxy, ou les restaurer exactement dans leur état initial.
6. Désactiver ou supprimer les règles dédiées à l’hôte et aux machines dès que le chemin de remplacement est confirmé.
7. Refaire les tests avec de nouvelles sessions de navigateur et RDS et, en HA, dans les deux rôles d’exploitation.

Liste de contrôle

• Per-Connection AD SSO est prévu uniquement pour le trafic HTTP et HTTPS via un proxy explicite.
• L’hôte pilote possède une IP fixe et unique, sans autre système derrière lui.
• AD, les groupes, le Domain Join, le FQDN, DNS, le SPN et l’heure ont été vérifiés.
• AD SSO et Web Proxy sont autorisés uniquement pour le chemin source nécessaire.
• Les navigateurs et les applications utilisent fw01.corp.example:3128 ou les valeurs de remplacement propres à l’environnement.
• La règle d’hôte dédiée 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é remplacée par SATC.
• Deux utilisateurs simultanés, des stratégies 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 rejoin et de nouveaux tests.
• Le rollback de la liste multi-utilisateurs, du déploiement du proxy, de Device Access, des règles et de l’authentification précédente est documenté.

Questions fréquentes