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.

Kurzablauf

1. Prüfen, ob Access Point, Controller oder RADIUS-Proxy ein Accounting-Start mit Benutzername und Framed-IP-Address erzeugen kann.
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 Access Point, WLAN-Controller oder Network Access Server.
2. Diese Infrastruktur erzeugt nach der Adressvergabe ein Accounting-Start oder leitet es über einen RADIUS-Proxy weiter.
3. Die Sophos Firewall empfängt das 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.

Ob der WLAN-Controller direkt an die Firewall sendet oder ein RADIUS-Server wie NPS das Accounting weiterleitet, hängt vom Produkt ab. Die Sophos-Konfiguration enthält dafür kein allgemeines NPS- oder Controller-Rezept. Massgebend ist das Paket, das tatsächlich an der Firewall ankommt. Eine Herstellerangabe wie «RADIUS Accounting unterstützt» genügt nicht, solange Benutzername und Client-IP im Accounting-Start nicht nachgewiesen sind.

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

Auf Access Point, Controller, Network Access Server oder RADIUS-Proxy müssen Authentifizierung und Accounting getrennt geprüft werden. Der erfolgreiche Login beweist noch nicht, dass Accounting erzeugt oder an die Sophos Firewall weitergeleitet wird.

Die Gegenstelle muss mindestens so vorbereitet sein:

1. Accounting für den betroffenen 802.1X- oder Netzwerkzugang aktivieren.
2. Als Accounting-Ziel die vorgesehene Firewall-Adresse 10.10.20.1 setzen.
3. UDP 1813 oder den tatsächlich gemeinsam festgelegten Accounting-Port 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 dafür den Parameter radius_accounting_start_delay mit einem Bereich von 0 bis 60 Sekunden. Diesen Wert nicht auf Verdacht verändern: Zuerst muss ein Capture zeigen, dass das Accounting-Start vor der IP-Vergabe entsteht. Die allgemeine WLAN-Konfiguration steht in Wireless Network auf Sophos Firewall einrichten.

Für AP6 führt Sophos in den Release Notes von 1.5.2167 MR5 den Fix WIFIX-5189 für einen Fall, in dem die Framed-IP in Accounting-Start und Accounting-Update fehlte. Bei einem AP6 mit älterem oder unbekanntem Firmwarestand wird deshalb zuerst auf eine aktuelle unterstützte Firmware aktualisiert und danach das Paket erneut geprüft. Der Fix belegt nicht automatisch, dass jede Controller-, Proxy- oder NPS-Kombination die Attribute korrekt weiterleitet.

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.

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 Konfiguration legt keinen RADIUS-Server unter Authentication > Servers an und ersetzt auch nicht die allgemeine RADIUS-Server-Konfiguration auf Sophos Firewall. Der Serverartikel behandelt Anfragen, welche die Firewall an NPS, MFA oder einen anderen RADIUS-Server sendet. RADIUS SSO behandelt eingehende Accounting-Meldungen.

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 der konfigurierte Accounting-Port.
• 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.

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. Accounting-Ziel auf Access Point, Controller oder RADIUS-Proxy entfernen oder auf den dokumentierten Vorzustand setzen.
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