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 Funktion ist nicht auf Windows RDS beschränkt: Auch ein Multi-User-Linux-Server kann dieses Verbindungsmodell verwenden, sofern seine Clients den Direct Web Proxy und Kerberos oder NTLM unterstützen. Dieses Beispiel führt durch einen Windows-RDS-Piloten; die Windows-Befehle und GPO-Verteilung sind keine Linux-Anleitung. Hosts ausserhalb der Multi-user hosts-Liste behalten ihre bisher konfigurierte IP-basierte Authentifizierung.

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

1. Entscheiden, ob wirklich nur HTTP und HTTPS über einen expliziten Proxy benutzerbezogen verarbeitet werden sollen.
2. Active Directory, Gruppenimport, DNS, Zeit und Domain Join der Firewall prüfen.
3. Einen auflösbaren Firewall-FQDN und einen passenden HTTP-SPN für Kerberos vorbereiten.
4. Zuerst Umfang und Sicherheitsauswirkungen prüfen; dann AD SSO für die erforderliche LAN-Zone unter Administration > Device access aktivieren und Apply wählen. Web proxy separat per gezielter ACL-Exception auf den Pilothost begrenzen, sofern unterstützt; eine Accept-Exception verengt keine Zonenfreigabe. Ist die erforderliche Zonenfreigabe nicht akzeptabel, Rollout stoppen und ein unterstütztes, begrenztes Design abklären.
5. Den RDS-Server als exaktes IP-Hostobjekt anlegen.
6. Unter Authentication > Web authentication Per-Connection AD SSO für diesen Host aktivieren.
7. Browser und proxyfähige Anwendungen auf den Firewall-FQDN und Port 3128 konfigurieren.
8. Eine eigene, geloggte Hostregel vor konkurrierenden Benutzerregeln platzieren und Match known users deaktiviert lassen.
9. 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 unterstützten Windows-RDS-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. Die aktuelle Sophos-Anleitung belegt keinen neuen Citrix-Rollout; bestehende Citrix-Installationen sollte man vor Änderungen mit Sophos Support abklären.

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. Auch SATC ordnet nur benutzerbasierte Prozesse zu; von Systemdiensten erzeugte Verbindungen benötigen weiterhin eine eigene Regel ohne Match known users. 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.

Falls der AD-Server noch nicht eingerichtet ist, unter Authentication > Servers > Add den Typ Active Directory wählen. Servername, die erreichbare DC-IP oder den DC-FQDN, NetBIOS-Domäne, AD-Domäne und die Suchbasis der eigenen Umgebung eintragen. Für corp.example ist die Suchbasis dc=corp,dc=example. Die Verbindung mit SSL/TLS auf Port 636 oder STARTTLS auf Port 389 verschlüsseln und die Zertifikatsprüfung gemäss dem verlinkten AD-Ablauf vorbereiten. Das Lese-/Join-Konto mit den unten beschriebenen Rechten hinterlegen, Test connection ausführen und mit Save speichern. Einen bereits verwendeten AD-Server nicht allein für den Piloten ersetzen oder dessen Zugangsdaten ungeprüft ändern. Falls die Domäne strikte LDAP-Kanalbindung oder LDAP-Signierung erzwingt, vor dem Rollout die Kompatibilität im AD-Ablauf klären; die Sophos-AD-Server-Hilfe nennt dafür eine Einschränkung. Keine domänenweite Schutzanforderung zur Fehlerbehebung abschalten.

Beim Gruppenimport wählt eine Organisationseinheit (OU) automatisch alle darin enthaltenen Gruppen aus. Attach to all the Groups weist die ausgewählten gemeinsamen Policies jeder vom Assistenten importierten Gruppe zu. Vor dem Abschluss deshalb die durch die OU-Auswahl erweiterte Gruppenliste und den Geltungsbereich dieser Policies prüfen; nur die tatsächlich benötigten Gruppen und beabsichtigten Policy-Zuweisungen übernehmen.

Für den Piloten unter Authentication > Servers > Manage beim AD-Server Import öffnen, im Import group wizard mit Start beginnen und die passende Base DN wählen. Für die Beispieldomäne corp.example lautet sie dc=corp,dc=example; ersetzt werden die Domänenbestandteile, nicht die LDAP-Syntax. RDS-Web-Standard und RDS-Web-Restricted auswählen, die gemeinsame Policy-Zuweisung und die Zusammenfassung prüfen, den Assistenten abschliessen und mit Close schliessen. Danach unter Authentication > Groups nachsehen, ob beide Gruppen wirklich vorhanden sind. Ein erfolgreicher Domain Join allein importiert die benötigten Policy-Gruppen nicht.

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.

Im selben Bereich die Default group bewusst wählen und mit Apply speichern. Wenn die benötigte AD-Gruppe nicht importiert ist, kann ein erfolgreich authentifizierter Benutzer in der Standardgruppe landen statt die gewünschte Gruppen-Policy zu erhalten. Benutzer in einer OU ohne Mitgliedschaft in einer Verzeichnisgruppe können in der Open group erscheinen. Bei mehreren Gruppenmitgliedschaften kann die erste passende Gruppe die Policy bestimmen; deshalb nicht nur den Import, sondern auch Reihenfolge und tatsächliche Zuordnung kontrollieren. Für den Piloten deshalb keine weit berechtigte Standardgruppe als Ersatz für einen fehlenden Import verwenden. Bei der ersten neuen Anmeldung unter Authentication > Users die tatsächliche Gruppenzuordnung prüfen; ein Benutzerobjekt muss nicht schon vor dieser Anmeldung sichtbar sein.

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.

Der im Hostname-Feld konfigurierte DNS-Suffix ist nicht automatisch der AD-Suffix: Beim Domain Join bildet die Firewall den AD-Computernamen und den SPN aus ihrem NetBIOS-Namen und der AD-Domäne. Sind DNS-Domäne und AD-Domäne unterschiedlich, den auf dem AD-Computerobjekt registrierten FQDN mit dem geplanten Proxyziel vergleichen. Das Beispiel setzt einen passenden SPN für fw01.corp.example voraus; der blosse Eintrag dieses Namens unter Admin and user settings beweist ihn nicht. Erst DNS und SPN für das tatsächliche Proxyziel gemeinsam klären, danach die Proxykonfiguration verteilen. Keine zusätzlichen SPNs auf Verdacht anlegen.

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 Kerberos oder NTLM unterstützen; im Windows-RDS-Beispiel erfolgt dies über integrierte Windows-Authentifizierung. 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 und mit Apply speichern. Danach unter Authentication > Web authentication bei If Active Directory (AD) SSO is configured die Option Kerberos & NTLM wählen und ebenfalls mit Apply speichern. NTLM ist als Fallback technisch unterstützt; Kerberos ist schneller und sicherer und sollte im Piloten zuverlässig funktionieren. Da jede Proxyverbindung eine Authentifizierung auslösen kann, vor einem grösseren Rollout auch Anmeldefehler, Antwortzeiten und die Belastung von Firewall und AD unter repräsentativem Verkehr beobachten. Daraus keinen festen Lastmultiplikator oder eine garantierte Benutzerkapazität ableiten.

Sind die Endgeräte nicht passend für Kerberos konfiguriert oder unterstützt der Browser keine Kerberos-Authentifizierung, wird automatisch NTLMv2 als Fallback verwendet. Anders als Kerberos benötigt NTLMv2 keinen FQDN als Proxyziel. Dieser Kompatibilitätsfallback garantiert aber keine erfolgreiche Anmeldung: Die unten beschriebenen Authentifizierungskanäle müssen initialisiert sein, und der tatsächliche Anmeldepfad ist mit den Pilotkonten zu prüfen.

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

Sophos setzt für Kerberos/NTLM voraus, dass AD SSO für die erforderliche LAN-Zone unter Administration > Device access aktiviert und mit Apply übernommen wird. Vorher den Umfang der Zonenfreigabe und ihre Sicherheitsauswirkungen prüfen; die LAN-Zone nicht ungeprüft pauschal freigeben. Ist AD SSO in allen Zonen deaktiviert, funktionieren Kerberos/NTLM nicht. Eine auf einen Host begrenzte AD-SSO-ACL-Exception ersetzt diese Zonenvoraussetzung nicht. Auch eine zusätzliche Accept-Exception kann eine bestehende Zonenfreigabe nicht verengen. Ist die erforderliche Zonenfreigabe nicht akzeptabel, den Rollout stoppen und beim ACL-Verantwortlichen oder Sophos Support ein unterstütztes, eng begrenztes Design für den installierten Build einholen. Davon getrennt die Erreichbarkeit von Web proxy auf den Pilothost beschränken: Dafür eine gezielte Local service ACL exception rule verwenden, sofern der installierte Build dies unterstützt. Eine Accept-Exception verengt jedoch keine bereits aktive zonenweite Web-Proxy-Freigabe; diese darf für einen tatsächlich hostbegrenzten Proxyzugriff nicht bestehen bleiben. Keine unnötigen weiteren Zonen oder Dienste freigeben. 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:

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

Mit Save speichern und kontrollieren, dass das Objekt die exakte Pilot-IP enthält, bevor es in der Multi-User-Liste ausgewählt wird.

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:

1. Use per-connection AD SSO authentication for multi-user hosts aktivieren.
2. Unter Multi-user hosts mit Add new item das Objekt RDS01 hinzufügen.
3. 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.

Optionale API-Zuordnung für Automatisierung

Wer diesen GUI-Schritt automatisieren möchte, findet in der API-Referenz für SFOS 22.0 und 23.0 die Entität DirectWebProxyAuthentication. Sie ordnet den Schalter und die Multi-User-Liste wie folgt zu. Für eine ausführbare Anfrage sind Operationshülle und weitere erforderliche Felder zu ergänzen.

• DirectWebProxyAuthentication > PerConnectionAuth entspricht dem Ein-/Ausschalter für Per-Connection AD SSO. Der Parameter ist als nicht obligatorischer SCALAR dokumentiert und erlaubt ausschliesslich Enable oder Disable. Die Schreibweise mit Schrägstrich im Referenzbeispiel bezeichnet Alternativen, keinen dritten zulässigen Wert.
• DirectWebProxyAuthentication > MultiUserHosts > Host beschreibt die Liste der Multi-User-Hostnamen, also im Beispiel den Namen des zuvor angelegten Hostobjekts RDS01, nicht dessen IP-Adresse. Host ist nicht obligatorisch und als ARRAY mit Datentyp STRING dokumentiert. Mehrere Werte sind erlaubt, doppelte Werte werden laut Referenz ignoriert. Die Referenz nennt maximal 1500 Zeichen, erklärt aber nicht, ob dieses Limit je Wert oder für die gesamte Liste gilt.

Die Default-Spalten sind leer: Daraus ergibt sich weder ein dokumentierter Standardwert noch eine Aussage darüber, was ausgelassene Felder bewirken. Der Operationsabschnitt beschreibt auch nicht, ob eine übermittelte Liste bestehende Einträge ergänzt oder ersetzt und wie Einträge entfernt werden. Deshalb weder Auslassen noch eine leere Liste als sicheren Rückweg interpretieren; die konkreten Update- und Entfernungseigenschaften müssen vor einer Automatisierung für den eingesetzten Build geklärt werden.

Die Statustabelle enthält 200 und 500. Diese Referenzwerte bestätigen weder den tatsächlichen HTTP-Transportstatus noch eine erfolgreiche Benutzer- und Policyverarbeitung. Die Meldungsfelder verweisen auf JavaScript; der vorliegende Operationsabschnitt liefert keine wörtlichen Antwortmeldungen.

Auch bei einer späteren autorisierten API-Änderung gelten die obigen Voraussetzungen und der enge Einzelhost-Pilot. Vorher die tatsächlichen Einstellungen sicher sichern und einen unabhängigen Managementzugang bereithalten. Danach den Schalter und die vollständige Multi-User-Liste auf genau der geänderten Firewall erneut auslesen und mit dem beabsichtigten Zustand vergleichen; anschliessend die unten beschriebenen positiven und negativen Proxy-, Benutzer-, Policy-, Non-Proxy- und lokalen Diensttests durchführen. Eine akzeptierte Konfigurationsantwort ersetzt diese Abnahme nicht. Für den Rückweg den gesicherten Vorzustand wiederherstellen, ohne daraus eine unbelegte API-Löschsyntax abzuleiten.

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.

Für dieses IPv4-Beispiel IPv4 > Add firewall rule > New firewall rule wählen. Als Rule name beispielsweise RDS01_DirectProxy_Outbound und als Action Accept setzen. Der Name ist frei wählbar; er sollte Host und Zweck erkennen lassen. Die Position vor konkurrierenden Benutzerregeln anhand der vollständigen Regelliste prüfen, nicht nur anhand des Namens.

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: HTTP, HTTPS und eigener TCP-Service für 3128 beziehungsweise den tatsächlich konfigurierten Proxy-Listening-Port; Any nur bewusst. Nur den Listening Port auszuwählen ist keine vollständige Direct-Proxy-Serviceauswahl.
• 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.

Mit Save speichern, die Regel erneut öffnen und Match known users, Logging, Web Policy und Position kontrollieren. Die Hostregel erlaubt den vorgesehenen Verkehrsweg; die Web Policy entscheidet innerhalb dieses Wegs über Benutzer und Gruppen. Eine korrekt erkannte Identität bedeutet deshalb nicht automatisch die richtige Berechtigung.

Die allgemeine AD-SSO-Anleitung beschreibt auch Benutzerregeln mit Match known users an. Das ist nicht das Regelmodell für die hier eingetragene Multi-User-IP: Die spezifische Per-Connection-Anleitung verlangt ausdrücklich eine eigene Regel mit diesem Schalter aus. Auch das Servicematch nicht aus einer transparenten HTTP-/HTTPS-Regel übernehmen: Der Proxy-Listening-Port beschreibt den Client-zu-Proxy-Pfad, während eine separate Proxy-zu-Ziel-Verbindung Zielservices wie HTTP oder HTTPS verwendet. Die tatsächliche Rule ID und den passenden Port im Piloten anhand der Logs bestätigen. Ein IPv6-Client mit IPv4-Ziel kann zwei Regeln benötigen; dieses IPv4-Beispiel ist dafür keine vollständige Dual-Stack-Anleitung.

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.

Besteht unabhängig vom Proxy ein begründeter eingehender Zugriff auf den Multi-User-Host, gilt auch für dessen eigene Regel Match known users aus. Quellzone und freigegebene Quellhosts, Zielzone und RDS01 sowie die tatsächlich benötigten Services eng festlegen, Logging aktivieren und die Position vor konkurrierenden Benutzerregeln prüfen. Das ist keine Aufforderung, RDP öffentlich bereitzustellen; für normalen Webzugriff wird keine neue Inbound-Regel angelegt.

Mit zwei RDS-Benutzern abnehmen

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

1. Zwei AD-Pilotkonten unterschiedlichen Web-Policy-Gruppen zuordnen.
2. Zwei neue RDS-Sitzungen auf RDS01 öffnen.
3. In beiden Sitzungen die effektive Proxykonfiguration prüfen.
4. Je einen erlaubten und einen bewusst unterschiedlich bewerteten HTTP- oder HTTPS-Aufruf auslösen.
5. Unter Current activities > Live users beide Benutzer mit Client Type Multi-host client prüfen.
6. Unter Log viewer > Authentication Benutzer und Log Comp für Kerberos oder NTLM kontrollieren.
7. Im Web- und Firewall-Log Benutzer, Policy, Rule ID, Aktion und Zeitpunkt vergleichen.
8. Einen notwendigen Non-Proxy-Test auslösen und bestätigen, dass er nicht fälschlich eine Benutzeridentität erhält.
9. 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.

Ein aussagekräftiger Vergleich verwendet in beiden Sitzungen dasselbe freigegebene Testziel: Ein Konto in RDS-Web-Standard darf es öffnen, eines in RDS-Web-Restricted wird durch die vorbereitete Web Policy blockiert. Datum, Uhrzeit, Benutzer, Quell-IP, Rule ID, Policy und Ergebnis festhalten. Danach ein Kontrollziel aufrufen, das beide Gruppen nutzen dürfen. So trennt man eine beabsichtigte Gruppenbeschränkung von einem generellen Proxy- oder DNS-Ausfall. Die Testziele stammen aus der eigenen freigegebenen Testliste; keine produktive Geschäftsseite nur für die Abnahme sperren.

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.

Steht der Pilotbenutzer in der Default group statt in der erwarteten importierten AD-Gruppe, zunächst Authentication > Groups, Suchbasis und Gruppenimport prüfen. Keine breitere Standardgruppen-Policy zum Kaschieren des Fehlers vergeben. Nach einer kontrollierten Korrektur mit einer neuen Anmeldung prüfen, ob Zuordnung und beide Policytests passen.

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.

Bei einem Upgrade von SFOS 21.5 oder älter direkt auf SFOS 22.0 GA Build 411 kommt zusätzlich Known Issue NC-176853 infrage: NTLM- und Kerberos-AD-SSO können unmittelbar nach dem Upgrade ausfallen, sodass identitätsbasierte Policies nicht matchen. Sophos führt SFOS 22.0 MR1 Build 490 als Fix-Version. Der interne Ablauf zu KBA-000048429 beschreibt Diagnose und Workaround. Die Known Issues List nennt Per-Connection AD SSO nicht separat; der Befund ist deshalb nur dann relevant, wenn der zugrunde liegende AD-SSO-Pfad nach genau diesem Upgrade ausfällt. Firmwarebuild, Zeitpunkt und Logs sichern, die KBA für den betroffenen Build prüfen und nicht mit breiten Regeln oder einem Authentifizierungswechsel überbrücken.

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.

1. Aktuelle Multi-User-Liste, Device-Access-Ausnahmen, Regeln, Web Policy und Proxyverteilung dokumentieren.
2. RDS01 aus Multi-user hosts entfernen und mit Apply speichern.
3. Proxy-GPO, PAC-Datei oder Anwendungskonfiguration kontrolliert zurücknehmen.
4. Frühere STAS-, Clientless- oder Captive-Portal-Zuordnung nur dann wiederherstellen, wenn sie vorher dokumentiert und für diese IP passend war.
5. 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.
6. Spezielle Host- und Maschinenregeln deaktivieren oder entfernen, sobald der Ersatzpfad bestätigt ist.
7. 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-Zonenvoraussetzung und Sicherheitsauswirkungen geprüft; erforderliche LAN-Zone aktiviert und mit Apply übernommen, Web-Proxy-Zugriff separat auf den Pilothost begrenzt, ohne breite Proxyfreigabe. Bei nicht akzeptabler Zonenfreigabe: Rollout stoppen und unterstütztes, begrenztes Design einholen.
• 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