Sophos Firewall Per-Connection AD SSO für Multi-User-Hosts einrichten

Mehrere Benutzer arbeiten auf demselben Remote Desktop Session Host, doch die Sophos Firewall sieht bei allen Verbindungen nur eine Server-IP. Per-Connection AD SSO löst genau diesen Sonderfall für Webtraffic: Der Direct Web Proxy authentifiziert jede HTTP- und HTTPS-Verbindung separat mit Kerberos oder NTLM.

Die Grenze ist ebenso wichtig wie die Funktion. Nur Verbindungen, die der Browser oder die Anwendung ausdrücklich an den Proxy sendet, erhalten eine Benutzeridentität. DNS, RDP, SMB und anderer Non-Proxy-Traffic derselben Server-IP bleiben unauthentifiziert. Wenn auch diese Protokolle benutzerbezogen kontrolliert werden müssen, passt SATC für Remote Desktop Services besser.

⚠️ Sobald eine IP-Adresse unter Multi-user hosts eingetragen ist, verwendet sie keine anderen IP-basierten Authentifizierungsmethoden mehr. STAS, Captive Portal, Clientless User und transparentes AD SSO fallen für diese IP weg. Deshalb zuerst mit genau einem Pilotserver testen und den bisherigen Authentifizierungspfad dokumentieren.

Per-Connection AD SSO in neun Schritten

Entscheiden, ob wirklich nur HTTP und HTTPS über einen expliziten Proxy benutzerbezogen verarbeitet werden sollen.
Active Directory, Gruppenimport, DNS, Zeit und Domain Join der Firewall prüfen.
Einen auflösbaren Firewall-FQDN und einen passenden HTTP-SPN für Kerberos vorbereiten.
AD SSO und Web proxy nur für die benötigte Quellzone oder den Pilothost erlauben.
Den RDS-Server als exaktes IP-Hostobjekt anlegen.
Unter Authentication > Web authentication Per-Connection AD SSO für diesen Host aktivieren.
Browser und proxyfähige Anwendungen auf den Firewall-FQDN und Port 3128 konfigurieren.
Eine eigene, geloggte Hostregel vor konkurrierenden Benutzerregeln platzieren und Match known users deaktiviert lassen.
Zwei parallele RDS-Sitzungen, unterschiedliche Web-Policy-Ergebnisse und Non-Proxy-Traffic getrennt prüfen.

Per-Connection AD SSO, STAS oder SATC?

Alle drei Verfahren liefern Benutzerkontext, lösen aber unterschiedliche Aufgaben.

STAS passt zu normalen Windows-Clients, wenn eine Client-IP typischerweise genau einem Benutzer gehört. Die Firewall erhält eine Benutzer-IP-Zuordnung aus den Windows-Anmeldeereignissen.
Per-Connection AD SSO passt zu Multi-User-Hosts, wenn nur explizit proxied HTTP- und HTTPS-Verbindungen unterschieden werden müssen. Auf dem RDS-Server ist kein SATC-Agent nötig, alle Anwendungen müssen den Direct Web Proxy aber zuverlässig verwenden.
SATC passt zu RDS- oder Citrix-Systemen, wenn auch andere Verbindungstypen aus den einzelnen Benutzersitzungen eine Identität benötigen. Dafür ist Sophos Server Protection auf dem Session Host erforderlich.

Klassisches STAS auf Sophos Firewall kann mehrere Benutzer hinter derselben RDS-IP nicht unterscheiden. Per-Connection AD SSO und SATC sind deshalb keine bequemeren Varianten von STAS, sondern eigene Betriebsmodelle. Falls eine Anwendung keinen expliziten Proxy unterstützt oder Non-Web-Protokolle benutzerbezogen geregelt werden sollen, hier stoppen und SATC prüfen.

Beispiel und austauschbare Werte

Der Ablauf verwendet dieses Beispiel:

Multi-User-Host: RDS01
IP-Adresse: 10.20.30.40
Firewall-FQDN und Proxyziel: fw01.corp.example
Direct-Web-Proxy-Port: 3128
AD-Gruppen: RDS-Web-Standard und RDS-Web-Restricted
je ein Pilotkonto pro Gruppe mit absichtlich unterschiedlichen Web-Policy-Ergebnissen

10.20.30.40 wird durch die feste, auf der Firewall sichtbare IP des Pilotservers ersetzt. Hinter dieser Adresse dürfen nicht zusätzlich andere Systeme per NAT erscheinen. fw01.corp.example ist ein Dokumentationsname und muss durch den echten, intern auflösbaren Firewall-FQDN ersetzt werden. Der Hostanteil sollte höchstens 15 Zeichen lang und klein geschrieben sein, damit Hostname, NetBIOS-Name, AD-Computerobjekt und SPN zusammenpassen.

Port 3128 ist der Standard für den Direct Web Proxy. Wird in der eigenen Umgebung ein anderer Listening Port verwendet, müssen Firewall, PAC-Datei oder GPO, Browser und Tests denselben Wert verwenden. Die Beispielgruppen dienen nur zur verständlichen Abnahme; Gruppennamen und Web Policies müssen zur eigenen Berechtigungsstruktur passen.

Voraussetzungen vorbereiten

Active Directory und Domain Join prüfen

Die Firewall benötigt einen funktionierenden Active-Directory-Server, importierte Gruppen und einen erfolgreichen Domain Join. Active Directory mit Sophos Firewall verbinden erklärt LDAPS, Suchbasis, Gruppenimport und die allgemeinen AD-SSO-Voraussetzungen.

Für die normale LDAP-Abfrage reicht ein Konto mit Leserechten. Der Domain Join und das Erstellen des SPN benötigen dagegen ein Domain-Admin-Konto oder ein Konto mit sauber delegierten Rechten. Das hinterlegte Konto muss auch einen späteren Rejoin erlauben, weil HA, weitere AD-Server oder Upgrades diesen erneut auslösen können. Ein uneingeschränktes Domain-Admin-Konto sollte dafür nicht unnötig dauerhaft verwendet werden.

Unter Authentication > Services > Firewall authentication methods den vorgesehenen AD-Server auswählen und in die richtige Reihenfolge bringen. Bei mehreren Servern prüft die Firewall sie von oben nach unten. Test connection am AD-Server bestätigt nur Zugangsdaten und Erreichbarkeit, nicht die spätere Kerberos- oder NTLM-Anmeldung im Browser.

FQDN, DNS, SPN und Zeit kontrollieren

Kerberos funktioniert nur, wenn die Clients den Firewall-FQDN als Proxyziel verwenden. Eine Proxy-IP-Adresse reicht dafür nicht. Auf einem Windows-Pilotclient helfen diese lesenden Prüfungen:

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

Der HTTP-SPN, ausgeschrieben Service Principal Name, bindet den Proxy-FQDN an das AD-Computerobjekt der Firewall. setspn -Q sollte genau eine passende Zuordnung liefern. Kein Treffer oder mehrere Treffer müssen vor dem Rollout geklärt werden.

Die DNS-Antwort muss zur vorgesehenen Firewall passen. Client, Domain Controller sowie Firewall benötigen ausserdem eine zum Kerberos-Verfahren passende Zeit. Die Befehle ändern nichts. SPN, Domain Join oder Zeitkonfiguration nicht auf Verdacht korrigieren, sondern zuerst den tatsächlichen Fehler belegen.

Proxyfähigkeit und Ausnahmen erfassen

Jeder Browser und jede Anwendung, deren Webtraffic einen Benutzer erhalten soll, muss den expliziten Proxy verwenden und integrierte Windows-Authentifizierung unterstützen. Vor dem Rollout mindestens prüfen:

Browser in jeder unterstützten RDS-Sitzung
Anwendungen mit eigenem HTTP-Stack
Windows- und Software-Updates
Dienste, die im Systemkontext statt in einer Benutzersitzung laufen
Ziele, die in der PAC-Datei oder Proxy-Bypass-Liste stehen

Traffic, der den Proxy umgeht, bleibt erwartungsgemäss ohne Benutzer-ID. Für notwendige Maschinenverbindungen eine eigene, eng begrenzte Regel ohne Benutzerbezug planen. Eine breite Any-Regel würde die Sicherheitswirkung der Benutzer- und Web-Policies verwässern.

Per-Connection AD SSO konfigurieren

1. Firewall-FQDN und AD SSO vorbereiten

Unter Administration > Admin and user settings den vorgesehenen Firewall-FQDN eintragen. Danach unter Authentication > Web authentication bei If Active Directory (AD) SSO is configured die Option Kerberos & NTLM wählen. NTLM ist als Fallback technisch unterstützt, für grössere Installationen sollte Kerberos aber zuverlässig funktionieren, weil Per-Connection AD SSO sehr viele zusätzliche Authentifizierungsanfragen erzeugen kann.

Im Log Viewer unter Authentication müssen nach der AD-SSO-Initialisierung diese Erfolgsmeldungen erscheinen:

Kerberos authentication initialized successfully
NTLM authentication channel established successfully

Die Firewall bietet die Verfahren erst an, wenn beide Kanäle funktionieren. Cannot initialize Kerberos authentication oder Cannot establish NTLM authentication channel sind Stop-Signale, keine Aufforderung zu einem blinden Service-Neustart.

2. Device Access eng freigeben

Unter Administration > Device access müssen AD SSO und Web proxy für den vorgesehenen Quellpfad erlaubt sein. Bei einer festen Pilot-IP ist eine gezielte Local service ACL exception rule meist enger als eine Freigabe für die ganze LAN-Zone. Eine zusätzliche Accept-Exception schränkt eine bereits aktive Zonenfreigabe jedoch nicht ein; für ein wirklich enges Design muss die breite Freigabe aus bleiben. Den vollständigen Aufbau erklärt Device Access und Local Service ACL.

Web-Proxy-Zugriff hat eine wichtige Nebenwirkung: Ein zugelassener Host kann HTTP- und HTTPS-Dienste der Firewall über den Proxy erreichen, selbst wenn deren Zone in der normalen Local-Service-Matrix nicht freigegeben ist. WebAdmin, User Portal und andere lokale Ziele deshalb mit dem Pilothost negativ testen. Ist diese Exposition im eigenen Netz nicht akzeptabel, das Design nicht produktiv aktivieren.

Unter Web > General settings den tatsächlichen Web proxy listening port und die erlaubten Zielports prüfen. Den Standard 3128 nur ändern, wenn PAC-Datei, GPO und alle verwalteten Anwendungen konsistent angepasst werden können.

3. Multi-User-Host anlegen

Unter folgendem Pfad ein neues Hostobjekt erstellen:

Hosts and services > IP host > Add

Für das Beispiel werden diese Werte verwendet:

Name: RDS01
IP version: IPv4
Type: IP
IP address: 10.20.30.40

Für den ersten Test keine ganze Range und kein Subnetz eintragen. Sonst verlieren möglicherweise viele Systeme gleichzeitig ihre bisherige IP-basierte Authentifizierung. Mehrere später freigegebene Hosts können nach erfolgreicher Einzelabnahme kontrolliert in einer Hostgruppe zusammengefasst werden.

4. Per-Connection AD SSO aktivieren

Zu diesem Bereich wechseln:

Authentication > Web authentication > Authentication settings for direct web proxy

Dann:

Use per-connection AD SSO authentication for multi-user hosts aktivieren.
Unter Multi-user hosts das Objekt RDS01 hinzufügen.
Mit Apply speichern.

Ab diesem Moment sind STAS, Captive Portal, Clientless User und transparentes AD SSO für 10.20.30.40 nicht mehr verfügbar. Deshalb die Änderung im Wartungsfenster durchführen und eine bestehende RDS-Sitzung nicht als alleinigen Test verwenden.

5. Direct Web Proxy verteilen

Den Browser- oder Systemproxy per GPO, PAC-Datei oder verwalteter Anwendung auf diesen Wert setzen:

fw01.corp.example:3128

Für Kerberos muss exakt der FQDN verwendet werden, der zum SPN passt. Eine IP-Adresse als Proxyziel, eine nicht auflösbare Kurzform oder ein anderer Alias führt häufig zu NTLM-Fallback oder einer Anmeldeabfrage. Bypass-Einträge bewusst klein halten und dokumentieren, weil jede umgangene Verbindung keine Per-Connection-Identität erhält.

Die allgemeine Listener-, PAC-, Regel- und Rollback-Konfiguration steht unter Direct Web Proxy mit PAC-Datei einrichten. Dieser Artikel ergänzt den Aufbau nur um die Multi-User-Authentifizierung.

6. Eigene Firewallregel einordnen

Unter Rules and policies > Firewall rules eine eigene, klar benannte Outbound-Regel für RDS01 erstellen. Sie muss vor Regeln stehen, die denselben Host mit Match known users erfassen.

Der sichere Rahmen:

Source zones: tatsächliche RDS-Zone, zum Beispiel LAN
Source networks and devices: nur RDS01
Destination zones: WAN
Destination networks: nur die benötigten Ziele oder bewusst Any
Services: eigener TCP-Service für 3128 oder den tatsächlich konfigurierten Proxy-Listening-Port; Any nur bewusst
Log firewall traffic: aktiv
Match known users: deaktiviert
Web filtering > Web policy: vorbereitete benutzer- oder gruppenabhängige Policy auswählen

Web Policies können Benutzer und Gruppen innerhalb des Proxyverkehrs unterscheiden, wirken aber erst, wenn sie der Firewallregel zugeordnet sind. Diese Unterscheidung gehört in die Web Policy, nicht in Match known users dieser Hostregel. Nach dem Auswählen oder Ändern der Web Policy den Schalter nochmals kontrollieren, weil eine Benutzerabhängigkeit ihn wieder aktivieren kann.

Für DNS, Updates und andere notwendige Non-Proxy-Verbindungen eine separate Maschinenregel erstellen. Keine pauschale WAN-zu-LAN-Regel ergänzen; das von Sophos gezeigte Inbound-Beispiel ist für normalen RDS-Webzugriff nicht nötig und wäre ohne eigenen Veröffentlichungszweck unnötige Angriffsfläche. Aufbau, Reihenfolge und Logging erklärt Firewall-Regeln richtig erstellen.

Mit zwei RDS-Benutzern abnehmen

Ein einzelner erfolgreicher Browseraufruf beweist nur, dass irgendein Proxytraffic funktioniert. Die eigentliche Abnahme benötigt zwei parallele Sitzungen.

Zwei AD-Pilotkonten unterschiedlichen Web-Policy-Gruppen zuordnen.
Zwei neue RDS-Sitzungen auf RDS01 öffnen.
In beiden Sitzungen die effektive Proxykonfiguration prüfen.
Je einen erlaubten und einen bewusst unterschiedlich bewerteten HTTP- oder HTTPS-Aufruf auslösen.
Unter Current activities > Live users beide Benutzer mit Client Type Multi-host client prüfen.
Unter Log viewer > Authentication Benutzer und Log Comp für Kerberos oder NTLM kontrollieren.
Im Web- und Firewall-Log Benutzer, Policy, Rule ID, Aktion und Zeitpunkt vergleichen.
Einen notwendigen Non-Proxy-Test auslösen und bestätigen, dass er nicht fälschlich eine Benutzeridentität erhält.
Vom Pilothost aus erfassen, welche lokalen HTTP- und HTTPS-Dienste der Firewall über den Proxy erreichbar sind. Ist ein im Sicherheitsdesign unzulässiger Dienst erreichbar, den Rollout stoppen und erst mit einer belegten zusätzlichen Schutzmassnahme fortsetzen.

Erst wenn beide Benutzer gleichzeitig korrekt unterschieden werden, die beabsichtigten Web-Policy-Ergebnisse eintreten und der Non-Proxy-Pfad verstanden ist, weitere RDS-Hosts aufnehmen. Für die allgemeine Regelabnahme hilft Sophos Firewall-Regeln kontrolliert testen.

Troubleshooting

Der Proxy ist nicht erreichbar

FQDN-Auflösung, Port, PAC-/GPO-Ergebnis, Quellzone und die Freigaben Web proxy sowie AD SSO prüfen. Ein erfolgreicher AD-Server-Test beweist den Proxyzugriff nicht. Bei SD-WAN-Routen muss der Proxy-Port oder Any zum Servicematch passen; die Firewall erzeugt die externe Proxyverbindung selbst, deshalb gelten nicht alle Client-Merkmale wie bei normalem geroutetem Traffic.

Der Browser fragt nach Anmeldedaten oder verwendet NTLM

Proxyziel, DNS, HTTP-SPN, Browserzone und integrierte Authentifizierung prüfen. Kerberos benötigt den passenden FQDN, nicht die Firewall-IP. NTLM-Fallback ist ein Symptom, das zuerst erklärt werden sollte, kein Grund für einen vorsorglichen NTLM-only-Rollout.

Beide Sitzungen erscheinen als derselbe Benutzer

Prüfen, ob beide Browser wirklich den expliziten Proxy verwenden und ob eine Anwendung Verbindungen ausserhalb der jeweiligen Benutzersitzung erzeugt. Auch ein vorgeschalteter Proxy oder NAT kann das gewünschte Verbindungsmodell verändern. In Live Users muss der Typ Multi-host client erscheinen; eine normale IP-basierte Zuordnung ist für diesen Host ein falscher Pfad.

Benutzer ist sichtbar, aber die Web Policy greift nicht

AD-Gruppe, Main Group, Web-Policy-Reihenfolge, Firewallregel und Logeintrag gemeinsam prüfen. Match known users muss in der speziellen Hostregel aus bleiben. Eine sichtbare Authentifizierung beweist noch nicht, dass der Request die erwartete Web Policy oder Firewall Rule ID verwendet.

Nicht-Web-Traffic zeigt keinen Benutzer

Das ist erwartetes Verhalten. Per-Connection AD SSO identifiziert nur HTTP und HTTPS über den Direct Web Proxy. Für erforderlichen Maschinenverkehr gilt eine Regel ohne Benutzerbezug. Wenn RDP, SMB, Datenbank- oder anderer Non-Proxy-Traffic pro Sitzung unterschieden werden muss, zu SATC wechseln.

Nach Upgrade oder HA-Failover funktioniert SSO nicht mehr

AD SSO kann nach einem Upgrade, beim Einsatz mehrerer AD-Server oder in HA einen erneuten Domain Join benötigen. Das delegierte Join-Konto muss deshalb weiterhin gültig sein. Nach einem kontrollierten Failover mit einer neuen Proxyverbindung und beiden Pilotkonten testen; bestehende Proxyverbindungen oder Kerberos-Tickets nicht als unterbrechungsfrei fortgesetzt voraussetzen. In jedem HA-Modus speichert jeder Node nur die Logs des Traffics, den er selbst verarbeitet hat. Für ein Ereignis deshalb den zu diesem Zeitpunkt aktiven beziehungsweise verarbeitenden Node prüfen.

Relevante Logs lesen

In der Advanced Shell sind diese Dateien relevant:

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

nasm.log zeigt NTLM-, Kerberos- und mögliche KVNO-Probleme. access_server.log hilft bei Authentifizierung und Autorisierung, awarrenhttp.log beim Web Proxy. awarrenhttp_access.log entsteht nur mit temporär aktiviertem Debug und gehört nicht zum normalen ersten Schritt. Vor Service-Neustarts oder Debug-Ausweitung zuerst Zeitfenster, Benutzer, Ziel, Regel und die vorhandenen Logs sichern.

Rollback

Ein sauberer Rückweg stellt nicht nur den Proxy zurück, sondern auch das frühere Authentifizierungsmodell.

Aktuelle Multi-User-Liste, Device-Access-Ausnahmen, Regeln, Web Policy und Proxyverteilung dokumentieren.
RDS01 aus Multi-user hosts entfernen und mit Apply speichern.
Proxy-GPO, PAC-Datei oder Anwendungskonfiguration kontrolliert zurücknehmen.
Frühere STAS-, Clientless- oder Captive-Portal-Zuordnung nur dann wiederherstellen, wenn sie vorher dokumentiert und für diese IP passend war.
Die Pilot-ACL-Exception beziehungsweise temporäre AD-SSO- und Web-Proxy-Zonenfreigaben nach Prüfung anderer Abhängigkeiten entfernen oder exakt auf den Vorzustand setzen.
Spezielle Host- und Maschinenregeln deaktivieren oder entfernen, sobald der Ersatzpfad bestätigt ist.
Mit neuen Browser- und RDS-Sitzungen sowie bei HA auf beiden Betriebsrollen erneut testen.

Checkliste

Per-Connection AD SSO ist nur für expliziten HTTP-/HTTPS-Proxytraffic vorgesehen.
Der Pilothost besitzt eine feste, eindeutige IP ohne fremde Systeme dahinter.
AD, Gruppen, Domain Join, FQDN, DNS, SPN und Zeit sind geprüft.
AD SSO und Web Proxy sind nur für den benötigten Quellpfad freigegeben.
Browser und Anwendungen verwenden fw01.corp.example:3128 oder die eigenen Ersatzwerte.
Die spezielle Hostregel hat Logging an und Match known users aus.
Non-Proxy-Traffic ist als Maschinenverkehr geplant oder das Design wurde auf SATC geändert.
Zwei parallele Benutzer, unterschiedliche Policies und Managementzugriff wurden positiv und negativ getestet.
HA-Failover und Upgrades haben einen dokumentierten Rejoin- und Retest-Ablauf.
Rollback von Multi-User-Liste, Proxyverteilung, Device Access, Regeln und vorheriger Authentifizierung ist dokumentiert.

Häufige Fragen

Kann Per-Connection AD SSO SATC ersetzen?

Nur wenn ausschliesslich HTTP und HTTPS über den Direct Web Proxy benutzerbezogen ausgewertet werden müssen. SATC kann alle unterstützten Verbindungstypen aus den RDS-Benutzersitzungen zuordnen und ist deshalb nötig, wenn auch Non-Proxy-Traffic eine Benutzeridentität braucht.

Warum muss Match known users deaktiviert sein?

Die spezielle Firewallregel muss zuerst anhand der Multi-User-Host-IP greifen. Ist Match known users aktiv, kann die Firewall den Hostverkehr anhand einer bestehenden IP-Zuordnung, häufig eines administrativen Benutzers, verarbeiten und nachfolgende Regeln überspringen. Benutzer- und Gruppenunterschiede werden für dieses Design in der Web Policy ausgewertet.

Warum verwendet der Browser NTLM statt Kerberos?

Häufig passt das Proxyziel nicht zum HTTP-SPN, der Firewall-FQDN wird nicht korrekt aufgelöst oder der Browser vertraut dem Ziel nicht für integrierte Authentifizierung. Kerberos benötigt den FQDN als Proxyziel; mit einer IP-Adresse funktioniert es nicht.

Erhält auch RDP-, SMB- oder DNS-Traffic eine Benutzeridentität?

Nein. Per-Connection AD SSO gilt nur für HTTP- und HTTPS-Verbindungen über den Direct Web Proxy. Der übrige Traffic bleibt unauthentifiziert und benötigt eine passende Maschinenregel oder ein anderes Verfahren wie SATC.