Sophos Firewall RADIUS SSO mit Accounting einrichten

RADIUS SSO meldet einen Benutzer ohne zusätzliches Captive Portal an der Sophos Firewall an. Der Benutzer hat sich bereits an einem WLAN, Network Access Server oder einer anderen RADIUS-Gegenstelle authentifiziert. Danach erhält die Firewall ein RADIUS-Accounting-Paket mit Benutzername und Client-IP und kann diese Zuordnung für benutzerbasierte Regeln verwenden.

Der entscheidende Punkt ist nicht nur ein erfolgreicher 802.1X-Login. Die Firewall muss ein verwertbares Accounting-Start vom exakt eingetragenen Absender erhalten. Für Wi-Fi SSO verwendet Sophos die Framed-IP-Address aus diesem Startpaket. Fehlt die Client-IP, kennt die Firewall zwar möglicherweise den Benutzernamen, kann ihn aber keinem Datenverkehr zuordnen.

⚠️ RADIUS SSO ist nicht dasselbe wie Enable accounting am RADIUS-Serverobjekt. Unter Authentication > Servers bedeutet Enable accounting, dass die Firewall Accounting an einen RADIUS-Server sendet. Unter Authentication > Services > SSO using RADIUS accounting request empfängt die Firewall dagegen Accounting von einem RADIUS-Client und erzeugt daraus eine Benutzer-IP-Zuordnung.

Die aktuelle Sophos-Anleitung bestätigt diesen Ablauf für SFOS-verwaltete APX Access Points. Sie beschreibt keine allgemeine Freigabe für AP6 oder beliebige Drittanbieter-Controller. Bei einer anderen Plattform wird deshalb vor der produktiven Einführung mit dem Hersteller und gegebenenfalls Sophos Support geklärt, ob sie denselben Proxy- und Attributpfad unterstützt. Ein technisch passendes Testpaket allein erweitert den dokumentierten Supportumfang nicht.

Kurzablauf

1. Für den offiziell beschriebenen Ablauf APX mit 802.1X verwenden und den RADIUS-Accounting-Server als Proxy zur Firewall konfigurieren.
2. Den tatsächlichen Absender, die Zieladresse der Firewall, UDP-Port 1813 und ein starkes Shared Secret festlegen.
3. Unter Authentication > Services > SSO using RADIUS accounting request die Absender-IP und das Shared Secret eintragen.
4. Unter Administration > Device access den Dienst RADIUS SSO nur für diesen Absender und die richtige Firewall-Adresse erlauben.
5. Eine eng begrenzte Benutzerregel mit Match known users und Logging vorbereiten.
6. Einen echten Client verbinden und das Accounting-Paket auf der Firewall kontrollieren.
7. Unter Current activities > Live users den Clienttyp RADIUS SSO, den Benutzer und die richtige Client-IP prüfen.
8. Erst danach erlaubten und absichtlich nicht erlaubten Traffic mit der erwarteten Firewall Rule ID testen.

Wann RADIUS SSO passt

RADIUS SSO passt besonders zu 802.1X-WLANs oder Network-Access-Systemen, bei denen die Authentifizierung bereits ausserhalb der Firewall stattfindet. Die Firewall soll den Benutzer anschliessend ohne zweite Browseranmeldung erkennen.

Der Ablauf benötigt eine eindeutige Beziehung zwischen Benutzer und IPv4-Adresse. Typische Voraussetzungen sind:

• Der Client erhält eine IPv4-Adresse, die auch die Sophos Firewall als Traffic-Quelle sieht.
• Der Accounting-Absender kennt Benutzername und diese Client-IP.
• Das Accounting-Start erreicht eine Firewall-Adresse direkt und ohne unerwartete Quell-NAT-Änderung.
• Der RADIUS-Absender kann Framed-IP-Address im Startpaket liefern.
• Benutzer- oder Gruppenobjekte und die zugehörige Firewallregel sind bereits geplant.

RADIUS SSO ist kein Ersatz für STAS auf Sophos Firewall, wenn Windows-Anmeldeereignisse aus Active Directory die Identitätsquelle sind. Mehrere Benutzer hinter derselben RDS- oder Citrix-IP lassen sich auch mit RADIUS SSO nicht getrennt behandeln. Dafür passen je nach Traffic SATC für Remote Desktop Services oder Per-Connection AD SSO über den Direct Web Proxy.

Wann der Ablauf gestoppt wird

Nicht produktiv aktivieren, wenn einer dieser Punkte offen ist:

• Das Accounting-Paket enthält keinen Benutzernamen oder keine Framed-IP-Address.
• Die im Paket gemeldete Adresse unterscheidet sich von der Source-IP, welche die Firewall später im Nutztraffic sieht.
• Mehrere Benutzer teilen dieselbe Client-IP.
• Der reale Absender oder die Firewall-Zieladresse ist wegen NAT, HA oder Routing nicht eindeutig.
• Der RADIUS-Client kann nur ein ganzes, nicht vertrauenswürdiges Netz statt einer festen Quelladresse verwenden.
• Die bestehende Regelstrategie für unbekannte oder nicht mehr angemeldete Benutzer ist ungeklärt.

Accounting-Pfad verstehen

Bei klassischer RADIUS-Authentifizierung sendet die Firewall einen Access-Request an den RADIUS-Server. Bei RADIUS SSO ist die Richtung anders:

1. Ein Client authentifiziert sich am SFOS-verwalteten APX gegen den unter Wireless > Wireless settings ausgewählten RADIUS-Server.
2. Der APX sendet das Accounting über die Firewall an diesen Server. Der Server ist zusätzlich als Accounting-Proxy eingerichtet und leitet die Meldung an die Firewall zurück.
3. Die Sophos Firewall empfängt das weitergeleitete Paket auf ihrem RADIUS-SSO-Dienst.
4. Stimmen die Absender-IP mit RADIUS client IPv4 und das Shared Secret überein, verarbeitet die Firewall die Meldung.
5. Benutzername und Framed-IP-Address erscheinen als Zuordnung unter Live users.
6. Erst der anschliessende Nutztraffic kann eine Regel mit Match known users treffen.

Im offiziellen APX-Ablauf ist der RADIUS-Server nicht nur Authentifizierungs- und Accounting-Ziel, sondern auch Proxy: Er leitet die vom APX stammenden Accounting-Pakete an die Firewall weiter. Bei NPS wird dafür eine passende RADIUS-Proxy-Konfiguration benötigt. Massgebend für RADIUS client IPv4 ist die Source-IP dieses weitergeleiteten Pakets. Eine allgemeine Herstellerangabe wie «RADIUS Accounting unterstützt» genügt weder als Supportnachweis noch als Beleg für Benutzername und Client-IP im Accounting-Start.

Durchgängiges Beispiel

Die Anleitung verwendet diese Musterwerte:

• RADIUS- oder Accounting-Absender: 10.10.20.15
• Firewall-Adresse für RADIUS SSO: 10.10.20.1
• WLAN-Client: 10.30.40.50
• Accounting-Zielport: UDP 1813
• Benutzer: EXAMPLE\alex.muster
• Benutzerregel: RADIUS-SSO-WiFi-Out

Die Adressen stammen aus privaten Beispielnetzen und werden durch die echten Management-, Server- und Clientnetze ersetzt. Als RADIUS client IPv4 wird nicht automatisch die IP des Authentifizierungsservers eingetragen, sondern die Source-IP, die im Paket-Capture auf der Firewall wirklich zu sehen ist.

Gegenstelle vorbereiten

Beim offiziell beschriebenen APX-Aufbau werden Authentifizierung, Accounting zum RADIUS-Server und der Proxy-Rückweg zur Firewall getrennt geprüft. Der erfolgreiche 802.1X-Login beweist noch nicht, dass der RADIUS-Server das Accounting an Sophos Firewall weiterleitet.

Die Gegenstelle muss mindestens so vorbereitet sein:

1. APX und das 802.1X-WLAN unter Wireless einrichten und unter Wireless > Wireless settings den RADIUS-Server auswählen.
2. Accounting auf dem RADIUS-Server aktivieren und diesen als Accounting-Proxy zur Firewall-Adresse 10.10.20.1 konfigurieren.
3. Für die Weiterleitung zur Firewall UDP 1813 verwenden.
4. Ein eigenes starkes Shared Secret für diesen Pfad hinterlegen.
5. Accounting-Start erst senden, wenn die Client-IP bekannt ist.
6. Sicherstellen, dass Benutzername und Framed-IP-Address enthalten sind.
7. Quell-IP, Routing und eine mögliche NAT-Übersetzung zum Firewall-Interface dokumentieren.

Ein Accounting-Stop oder ein Update kann bei einzelnen Produkten die Sitzungspflege verbessern. Die öffentliche Sophos-Hilfe nennt für Wi-Fi SSO jedoch ausdrücklich die IP aus dem Accounting-Start als Anmeldegrundlage. Deshalb darf ein späteres Update ein unvollständiges Startpaket nicht als Erfolgskriterium ersetzen.

Bei SFOS-verwalteten APX-Installationen kann die DHCP-Zeit eine Rolle spielen. Sophos dokumentiert radius_accounting_start_delay mit einem Bereich von 0 bis 60 Sekunden. Der offizielle Beispielbefehl in der Device Console setzt 30 Sekunden:

system wireless-controller global radius_accounting_start_delay 30

30 ist ein anpassbarer Beispielwert, kein allgemeiner Default. Vor der Änderung mit system wireless-controller global show den aktuellen Wert anzeigen und dokumentieren. Den Parameter nur ändern, wenn ein Capture zeigt, dass das Accounting-Start vor der IP-Vergabe entsteht. Beim Rückbau den Einstellbefehl mit dem dokumentierten Vorwert ausführen. War dieser Wert 0 (keine Verzögerung), lautet der genaue Rückbaubefehl system wireless-controller global radius_accounting_start_delay 0. Die offiziellen Quellen nennen keinen allgemeingültigen Default; bei unbekanntem Vorwert darf deshalb keiner angenommen werden. Für FreeRADIUS nennt Sophos zusätzlich use_tunneled_reply; diese Option gehört auf den FreeRADIUS-Server und wird nicht ungeprüft auf NPS übertragen. Die allgemeine WLAN-Konfiguration steht in Wireless Network auf Sophos Firewall einrichten.

Die AP6 Release Notes nennen mit WIFIX-5189 zwar einen behobenen Fehler bei der Framed-IP in Accounting-Paketen. Die RADIUS-SSO-Anleitung grenzt den beschriebenen Ablauf dennoch auf APX ein. Der AP6-Fix ist daher kein Supportnachweis für diese Konfiguration.

RADIUS SSO auf Sophos Firewall konfigurieren

Absender und Shared Secret eintragen

Der Menüpfad lautet:

Authentication > Services > SSO using RADIUS accounting request

Vorgehen:

1. Unter RADIUS client IPv4 die im Capture erwartete Absender-IP 10.10.20.15 hinzufügen.
2. Das für diesen Pfad vereinbarte Shared secret eintragen.
3. Weitere Absender nur als eigene, dokumentierte Einträge ergänzen.
4. Apply wählen.

SFOS 22 bietet in diesem Abschnitt nur RADIUS client IPv4 und Shared secret; ein separater Port wird dort nicht konfiguriert. Nur Pakete von den eingetragenen IPv4-Adressen werden für RADIUS SSO berücksichtigt. Ein ganzes Netz oder eine beliebige Quelladresse ist kein sinnvoller Ersatz für eine fehlende Absenderplanung.

Diese Empfängerkonfiguration legt allein keinen RADIUS-Server unter Authentication > Servers an. Für den offiziellen APX-Ablauf wird der externe RADIUS-Server jedoch zusätzlich dort angelegt und unter Wireless > Wireless settings ausgewählt; das erklärt die allgemeine RADIUS-Server-Konfiguration auf Sophos Firewall. Ausgehende Authentifizierung und Accounting einerseits und die zurückgeleiteten RADIUS-SSO-Meldungen andererseits bleiben zwei getrennte Pfade.

Device Access eng erlauben

RADIUS SSO ist ein lokaler Dienst der Firewall. Eine normale LAN-to-WAN- oder WiFi-to-WAN-Regel öffnet diesen Empfangspfad nicht.

Unter Administration > Device access gibt es zwei saubere Varianten:

• Ist die Absenderzone klein und vollständig vertrauenswürdig, RADIUS SSO in der Zonentabelle aktivieren.
• Ist nur eine feste Gegenstelle vorgesehen, die Zonenfreigabe deaktiviert lassen und eine gezielte Accept Local service ACL exception rule für die Absender-IP, die verwendete Firewall-Adresse und den Dienst RADIUS SSO erstellen.

Eine zusätzliche Accept-Ausnahme schränkt eine bereits aktive Zonenfreigabe nicht ein. Für eine wirklich enge Ausnahme muss RADIUS SSO in der betreffenden Zone deshalb ausgeschaltet bleiben. Den vollständigen Ablauf erklärt Device Access und Local Service ACL.

Benutzerregel vorbereiten

Für den ersten Test wird keine breite Produktionsregel benötigt. Eine enge Regel ist aussagekräftiger:

1. Unter Rules and policies > Firewall rules eine Regel oberhalb allgemeinerer WiFi- oder LAN-Regeln erstellen.
2. Source Zone und Source Network auf das echte Clientnetz begrenzen.
3. Nur den Pilotbenutzer oder eine vorbereitete Pilotgruppe auswählen.
4. Match known users aktivieren.
5. Nur einen ungefährlichen Testdienst oder ein klar definiertes Ziel erlauben.
6. Log firewall traffic aktivieren.
7. Eine zweite, bewusst nicht erlaubte Benutzer- oder Zielkombination für den Negativtest festlegen.

RADIUS SSO liefert eine Identität, aber keine pauschale Netzwerkfreigabe. Wie Benutzer, Gruppen, Dienste und Logging zusammenspielen, erklärt Firewall-Regeln auf Sophos Firewall erstellen.

RADIUS SSO kontrolliert abnehmen

1. Accounting-Paket auf der Firewall nachweisen

Unter Diagnostics > Packet capture einen Filter für die Absender-IP 10.10.20.15, die Firewall-Adresse 10.10.20.1 und UDP 1813 setzen. Danach genau einen Pilotclient neu verbinden.

Der Capture muss mindestens bestätigen:

• Source-IP ist der konfigurierte RADIUS client IPv4.
• Destination ist die vorgesehene Firewall-Adresse.
• Zielport ist UDP 1813.
• Es erscheint ein Accounting-Start für den Pilotbenutzer.
• Framed-IP-Address entspricht der aktuellen Client-IP 10.30.40.50.

RADIUS-Accounting enthält Identitäts- und Sitzungsdaten, die im Paket sichtbar sein können. Capture-Dateien deshalb wie Authentifizierungslogs behandeln, nur kurz aufbewahren und nicht ungeschützt weitergeben. Die allgemeine Bedienung zeigt Packet Capture auf Sophos Firewall.

2. Live User prüfen

Unter Current activities > Live users müssen Benutzer, Client-IP und Clienttyp zusammenpassen. Für diesen Ablauf wird RADIUS SSO als Clienttyp erwartet.

Ein sichtbarer Benutzer mit falscher IP ist kein Teilerfolg. Benutzerregeln matchen später gegen die Traffic-Quelle, nicht gegen die gewünschte WLAN-Zuordnung.

3. Authentifizierungslog korrelieren

Im Log Viewer nach dem Pilotbenutzer und dem Incident-Zeitpunkt suchen. Für die tiefe Analyse ist access_server.log relevant, weil Sophos dort Benutzer-Authentifizierung, Autorisierung und Accounting verarbeitet.

Bei HA speichert jeder Node nur die Logs des Traffics, den er selbst verarbeitet hat. Deshalb den Node prüfen, der das Accounting zum Testzeitpunkt empfangen hat. Wie access_server.log ohne unkontrollierten Service-Neustart gelesen und gesichert wird, erklärt Sophos Firewall Services und Logs per CLI prüfen.

4. Positiv- und Negativtest durchführen

Mit dem Pilotclient werden vier Dinge getrennt geprüft:

1. Ein erlaubtes Ziel trifft die erwartete Firewall Rule ID und zeigt den richtigen Benutzer.
2. Ein absichtlich nicht erlaubtes Ziel bleibt blockiert.
3. Ein nicht zugewiesener Benutzer erhält die Pilotfreigabe nicht.
4. Nach einer neuen Verbindung oder einem kontrollierten Roaming bleibt Benutzer, IP und Regelzuordnung korrekt.

Der Test muss mit echtem Nutztraffic erfolgen. Ein Live-User-Eintrag allein beweist weder Regelmatching noch Routing oder Rückweg. Den wiederholbaren Ablauf beschreibt Firewall-Regeln sauber testen.

Fehler nach Symptom eingrenzen

Kein Accounting-Paket erreicht die Firewall

Zuerst Ziel-IP, UDP-Port, Routing und die Konfiguration der Gegenstelle prüfen. Danach Device Access oder die Local Service ACL Exception Rule kontrollieren. Ein erfolgreicher RADIUS-Login auf NPS oder am WLAN beweist nicht, dass der separate Accounting-Pfad zur Firewall existiert.

Kommt das Paket mit einer anderen Source-IP an, wird genau diese Ursache untersucht. Nicht vorschnell ein ganzes Netz als RADIUS-Client erlauben. Bei NAT oder HA muss die stabile, tatsächlich sichtbare Absenderadresse dokumentiert und gezielt freigegeben werden.

Accounting kommt an, aber Live Users bleibt leer

Dann Shared Secret, Absender-IP und Paketinhalt gemeinsam prüfen. Besonders wichtig sind Accounting-Start, Benutzername und Framed-IP-Address. Fehlt die Client-IP, wird zuerst der Access Point, Controller oder RADIUS-Proxy korrigiert. Ein Service-Neustart auf der Firewall erzeugt kein fehlendes Attribut.

Erst wenn das Paket vollständig ist und access_server.log den Vorgang trotzdem nicht verarbeitet, werden Zeitpunkt, Capture, CTR und Node-Logs für Sophos Support gesichert. Keine Authentifizierungsdatenbank löschen und keine Live Users auf Verdacht bereinigen.

Benutzer erscheint mit falscher IP

Das weist häufig auf eine zu frühe Accounting-Meldung, eine alte DHCP-Zuordnung, Roaming oder einen abweichenden NAT-Pfad hin. Client trennen, aktuelle Lease erfassen und einen einzelnen neuen Verbindungsaufbau mitschneiden. Entscheidend ist, welche IP im neuen Accounting-Start steht.

Bei SFOS-verwaltetem Wireless wird radius_accounting_start_delay nur nach diesem Nachweis und mit dokumentiertem Vorwert verändert. Bei Drittanbieter-Access-Points oder -Controllern gelten deren Accounting- und DHCP-Mechanismen; ein Sophos-Wireless-Parameter ändert diese Geräte nicht.

Live User stimmt, aber die Regel greift nicht

Dann ist der Accounting-Pfad bereits weiter als die Policy. Source Zone, Source Network, Benutzer oder Gruppe, Match known users, Regelreihenfolge, Firewall Rule ID und tatsächliche Traffic-IP prüfen. Trifft Regel #0 oder eine allgemeine Regel, wird die Policy korrigiert und nicht das Shared Secret geändert.

Benutzer bleibt nach dem Abmelden sichtbar

Zuerst prüfen, ob die Gegenstelle Accounting-Stop sendet und ob dieses Paket dieselbe Sitzungs- und Benutzerzuordnung betrifft. Danach Live User, aktuellen Clienttraffic und access_server.log korrelieren. Eine manuelle Trennung kann den Zustand kurzfristig bereinigen, beweist aber nicht, dass der automatische Ablauf korrekt ist.

Nach einem Neustart der Firewall müssen APX-Clients gemäss Sophos getrennt und neu verbunden werden, damit ein neuer Accounting-Start die Anmeldung wiederherstellt. Ist in der Benutzerregel Show captive portal to unknown users aktiv, kann das Portal zunächst erscheinen; beim dokumentierten APX-Ablauf erfolgt die transparente Anmeldung nach der konfigurierten Accounting-Verzögerung ohne erneute Eingabe der Zugangsdaten.

Sicherheit, HA und Betrieb

RADIUS Accounting verwendet UDP und schützt den Transport nicht wie TLS. Das Shared Secret authentifiziert den RADIUS-Pfad, verschlüsselt aber nicht alle Identitäts- und Sitzungsattribute. Accounting gehört deshalb in ein vertrauenswürdiges Management- oder Servernetz und sollte nicht ungeschützt über fremde Netze geführt werden.

Im Betrieb gelten diese Grenzen:

• Für jeden Absender ein eigenes starkes Shared Secret und einen dokumentierten Owner verwenden.
• RADIUS SSO nur aus den benötigten Zonen und möglichst nur von festen Hosts erlauben.
• Capture-Dateien, RADIUS-Logs und access_server.log als personenbezogene Betriebsdaten behandeln.
• Änderungen an DHCP, WLAN-Controller, NPS, RADIUS-Proxy oder NAT mit einem neuen End-to-End-Test abschliessen.
• In HA keinen unterbrechungsfreien Erhalt der Benutzerzuordnung versprechen. Nach einem geplanten Failover einen neuen Accounting-Start, Live User und echten Traffic auf dem verarbeitenden Node prüfen.
• Unbekannte Benutzer oder fehlende Zuordnungen durch eine sichere Default-Regel abfangen, nicht durch eine breite Allow-Regel.

Rollback

Der Rückbau erfolgt in einer Reihenfolge, die weder den Accounting-Dienst offen lässt noch Benutzer unbeabsichtigt freischaltet:

1. Frühere Authentifizierungs- und Regelstrategie für das Pilotnetz wiederherstellen.
2. Pilotregel deaktivieren und einen unbekannten Benutzer negativ testen.
3. Das Weiterleitungsziel zur Firewall aus der Proxy-Konfiguration des RADIUS-Servers entfernen oder den dokumentierten Proxy-Vorzustand wiederherstellen. Das APX-Accounting-Ziel nicht entfernen, wenn der RADIUS-Server weiterhin für WLAN-Authentifizierung und Accounting benötigt wird.
4. Den Absender unter SSO using RADIUS accounting request entfernen.
5. Die RADIUS-SSO-ACL-Ausnahme oder temporäre Zonenfreigabe zurücknehmen.
6. Live Users, Firewall Rule ID und normalen Clienttraffic erneut prüfen.

Die ursprüngliche Konfiguration, Shared-Secret-Verantwortung und getestete Rückkehr zur früheren Benutzererkennung werden im Change dokumentiert. Ein bloss gelöschter Live-User-Eintrag ist kein vollständiger Rollback.

FAQ