Konfigurera RADIUS SSO med accounting på Sophos Firewall

RADIUS SSO loggar in en användare på Sophos Firewall utan en extra captive portal. Användaren har redan autentiserats i ett trådlöst nätverk, på en network access server eller i ett annat RADIUS-system. Därefter tar brandväggen emot ett RADIUS-accountingpaket med användarnamn och klient-IP och kan använda kopplingen i användarbaserade regler.

Det avgörande är inte bara en lyckad 802.1X-inloggning. Brandväggen måste ta emot en användbar Accounting-Start från exakt den konfigurerade avsändaren. För Wi-Fi SSO använder Sophos Framed-IP-Address från detta startpaket. Om klientens IP-adress saknas kan brandväggen känna till användarnamnet men inte koppla det till trafiken.

⚠️ RADIUS SSO är inte samma sak som Enable accounting i RADIUS-serverobjektet. Under Authentication > Servers betyder Enable accounting att brandväggen skickar accounting till en RADIUS-server. Under Authentication > Services > SSO using RADIUS accounting request tar brandväggen i stället emot accounting från en RADIUS-klient och skapar en användar-IP-koppling.

Sophos aktuella procedur bekräftar detta flöde för SFOS-hanterade APX-accesspunkter. Den ger inget generellt godkännande för AP6 eller valfria tredjepartskontroller. För en annan plattform måste man före produktionsinförandet bekräfta med tillverkaren och vid behov Sophos Support att samma proxy- och attributväg stöds. Ett tekniskt lämpligt testpaket utökar inte i sig den dokumenterade supportomfattningen.

Snabb procedur

1. För det officiellt dokumenterade flödet använder man APX med 802.1X och konfigurerar RADIUS-accountingservern som proxy till brandväggen.
2. Fastställ den verkliga avsändaren, brandväggens destinationsadress, UDP-port 1813 och en stark shared secret.
3. Ange avsändarens IP-adress och shared secret under Authentication > Services > SSO using RADIUS accounting request.
4. Tillåt tjänsten RADIUS SSO under Administration > Device access endast för denna avsändare och rätt brandväggsadress.
5. Förbered en snävt avgränsad användarregel med Match known users och loggning.
6. Anslut en verklig klient och kontrollera accountingpaketet på brandväggen.
7. Kontrollera klienttypen RADIUS SSO, användaren och rätt klient-IP under Current activities > Live users.
8. Testa först därefter tillåten och avsiktligt otillåten trafik mot förväntat Firewall Rule ID.

När RADIUS SSO passar

RADIUS SSO passar särskilt bra för 802.1X-wifinätverk eller nätverksåtkomstsystem där autentiseringen redan sker utanför brandväggen. Brandväggen kan då identifiera användaren utan en andra inloggning i webbläsaren.

Proceduren kräver en entydig relation mellan användare och IPv4-adress. Typiska förutsättningar är:

• Klienten får en IPv4-adress som Sophos Firewall också ser som trafikens källa.
• Accountingavsändaren känner till användarnamnet och denna klient-IP.
• Accounting start når en brandväggsadress direkt och utan en oväntad ändring av source NAT.
• RADIUS-avsändaren kan skicka Framed-IP-Address i startpaketet.
• Användar- eller gruppobjekt och tillhörande brandväggsregel är redan planerade.

RADIUS SSO ersätter inte STAS på Sophos Firewall när Windows-inloggningshändelser från Active Directory är identitetskällan. Det går inte heller att skilja flera användare bakom samma RDS- eller Citrix-IP. Beroende på trafiken passar SATC för Remote Desktop Services eller AD SSO per anslutning via direct web proxy bättre.

När proceduren ska avbrytas

Aktivera inte i produktion så länge någon av dessa punkter är oklar:

• Accountingpaketet innehåller inget användarnamn eller ingen Framed-IP-Address.
• Adressen i paketet skiljer sig från den käll-IP som brandväggen senare ser i nyttotrafiken.
• Flera användare delar samma klient-IP.
• NAT, HA eller routing gör den verkliga avsändaren eller brandväggens destinationsadress otydlig.
• RADIUS-klienten kan bara använda ett helt opålitligt nätverk i stället för en fast källadress.
• Regelstrategin för okända eller utloggade användare är inte klarlagd.

Förstå accountingvägen

Vid klassisk RADIUS-autentisering skickar brandväggen en Access-Request till RADIUS-servern. Med RADIUS SSO är riktningen den motsatta:

1. En klient autentiserar sig på den SFOS-hanterade APX-enheten mot RADIUS-servern som valts under Wireless > Wireless settings.
2. APX skickar accounting via brandväggen till servern. Servern är även konfigurerad som accountingproxy och vidarebefordrar meddelandet tillbaka till brandväggen.
3. Sophos Firewall tar emot det vidarebefordrade paketet på sin RADIUS SSO-tjänst.
4. Om avsändarens IP-adress matchar RADIUS client IPv4 och shared secret är korrekt behandlar brandväggen meddelandet.
5. Användarnamn och Framed-IP-Address visas som en koppling under Live users.
6. Först efterföljande nyttotrafik kan matcha en regel med Match known users.

I det officiella APX-flödet är RADIUS-servern både mål för autentisering och accounting och proxy som vidarebefordrar APX-accountingpaketen till brandväggen. NPS behöver därför en lämplig RADIUS-proxykonfiguration. För RADIUS client IPv4 är käll-IP-adressen för det vidarebefordrade paketet avgörande. Ett allmänt påstående om ”stöd för RADIUS Accounting” bevisar varken stöd för denna arkitektur eller att användarnamn och klient-IP finns i accounting start.

Komplett exempel

Guiden använder följande exempelvärden:

• RADIUS- eller accountingavsändare: 10.10.20.15
• Brandväggsadress för RADIUS SSO: 10.10.20.1
• Wifiklient: 10.30.40.50
• Destinationsport för accounting: UDP 1813
• Användare: EXAMPLE\alex.muster
• Användarregel: RADIUS-SSO-WiFi-Out

Adresserna kommer från privata exempelnätverk och ska ersättas med de verkliga management-, server- och klientnäten. Under RADIUS client IPv4 anges inte automatiskt autentiseringsserverns IP-adress, utan den käll-IP som faktiskt syns i brandväggens packet capture.

Förbered motparten

I den officiellt dokumenterade APX-arkitekturen kontrollerar man separat autentisering, accounting till RADIUS-servern och proxyns returväg till brandväggen. En lyckad 802.1X-inloggning bevisar inte att RADIUS-servern vidarebefordrar accounting till Sophos Firewall.

Förbered motparten minst på följande sätt:

1. Konfigurera APX och 802.1X-wifinätverket under Wireless och välj RADIUS-servern under Wireless > Wireless settings.
2. Aktivera accounting på RADIUS-servern och konfigurera den som proxy till brandväggsadressen 10.10.20.1.
3. Använd UDP 1813 för vidarebefordran till brandväggen.
4. Konfigurera en separat stark shared secret för denna väg.
5. Skicka accounting start först när klientens IP-adress är känd.
6. Säkerställ att användarnamn och Framed-IP-Address ingår.
7. Dokumentera käll-IP, routing och eventuell NAT-översättning mot brandväggsgränssnittet.

En accounting stop eller update kan förbättra sessionshanteringen i vissa produkter. Sophos offentliga hjälp anger dock uttryckligen IP-adressen i accounting start som inloggningsgrund för Wi-Fi SSO. En senare update får därför inte ersätta ett komplett startpaket som framgångskriterium.

I SFOS-hanterade APX-installationer kan DHCP-tidpunkten spela roll. Sophos dokumenterar radius_accounting_start_delay från 0 till 60 sekunder. Det officiella exemplet för Device Console ställer in 30 sekunder:

system wireless-controller global radius_accounting_start_delay 30

30 är ett anpassningsbart exempel, inte ett universellt standardvärde. Kör system wireless-controller global show före ändringen och dokumentera det aktuella värdet. Ändra parametern endast om en capture visar att accounting start skapas före IP-tilldelningen. Vid rollback körs inställningskommandot med det dokumenterade värdet. Om värdet var 0 (ingen fördröjning) är det exakta rollbackkommandot system wireless-controller global radius_accounting_start_delay 0. De officiella källorna anger inget universellt standardvärde; anta därför inget om det tidigare värdet är okänt. Sophos anger även use_tunneled_reply för FreeRADIUS; alternativet hör hemma på FreeRADIUS-servern och ska inte överföras till NPS utan belägg. Den allmänna wifikonfigurationen beskrivs i Konfigurera Wireless Network på Sophos Firewall.

AP6-versionsinformationen listar WIFIX-5189, ett åtgärdat problem med framed IP i accountingpaket. RADIUS SSO-proceduren begränsar dock det beskrivna flödet till APX. AP6-korrigeringen bevisar därför inte att denna konfiguration stöds.

Konfigurera RADIUS SSO på Sophos Firewall

Ange avsändare och shared secret

Menysökvägen är:

Authentication > Services > SSO using RADIUS accounting request

Gör så här:

1. Lägg till den förväntade avsändar-IP-adressen 10.10.20.15 under RADIUS client IPv4.
2. Ange den Shared secret som avtalats för vägen.
3. Lägg endast till ytterligare avsändare som separata, dokumenterade poster.
4. Välj Apply.

I detta avsnitt erbjuder SFOS 22 endast RADIUS client IPv4 och Shared secret; det finns ingen separat portinställning. Endast paket från de konfigurerade IPv4-adresserna beaktas för RADIUS SSO. Ett helt nätverk eller en godtycklig källadress är ingen rimlig ersättning för utebliven avsändarplanering.

Mottagarkonfigurationen skapar inte i sig någon RADIUS-server under Authentication > Servers. Det officiella APX-flödet kräver ändå att den externa RADIUS-servern läggs till där och väljs under Wireless > Wireless settings; den allmänna RADIUS-serverkonfigurationen på Sophos Firewall beskriver denna del. Utgående autentisering och accounting samt vidarebefordrade RADIUS SSO-meddelanden förblir separata vägar.

Tillåt Device Access restriktivt

RADIUS SSO är en lokal brandväggstjänst. En vanlig LAN-to-WAN- eller WiFi-to-WAN-regel öppnar inte denna mottagningsväg.

Under Administration > Device access finns två korrekta alternativ:

• Om avsändarzonen är liten och helt betrodd, aktivera RADIUS SSO i zonmatrisen.
• Om endast en fast motpart är planerad, låt zonåtkomsten vara avstängd och skapa en riktad Accept Local service ACL exception rule för avsändarens IP-adress, den använda brandväggsadressen och tjänsten RADIUS SSO.

Ett extra accept-undantag begränsar inte en redan aktiv zonåtkomst. För ett verkligt snävt undantag måste RADIUS SSO därför förbli avstängt i den berörda zonen. Hela proceduren beskrivs i Device Access och Local Service ACL.

Förbered användarregeln

Ingen bred produktionsregel behövs för det första testet. En snäv regel ger tydligare resultat:

1. Skapa en regel under Rules and policies > Firewall rules ovanför mer allmänna WiFi- eller LAN-regler.
2. Begränsa Source Zone och Source Network till det verkliga klientnätet.
3. Välj endast pilotanvändaren eller en förberedd pilotgrupp.
4. Aktivera Match known users.
5. Tillåt endast en ofarlig testtjänst eller ett tydligt definierat mål.
6. Aktivera Log firewall traffic.
7. Definiera en andra avsiktligt otillåten kombination av användare eller mål för det negativa testet.

RADIUS SSO ger en identitet, inte ett generellt nätverkstillstånd. Skapa brandväggsregler på Sophos Firewall förklarar hur användare, grupper, tjänster och loggning samverkar.

Validera RADIUS SSO kontrollerat

1. Verifiera accountingpaketet på brandväggen

Ställ in ett filter under Diagnostics > Packet capture för avsändar-IP 10.10.20.15, brandväggsadress 10.10.20.1 och UDP 1813. Återanslut sedan exakt en pilotklient.

Capture måste minst bekräfta:

• Käll-IP är konfigurerad RADIUS client IPv4.
• Destinationen är den avsedda brandväggsadressen.
• Destinationsporten är UDP 1813.
• En accounting start visas för pilotanvändaren.
• Framed-IP-Address motsvarar aktuell klient-IP 10.30.40.50.

RADIUS-accounting innehåller identitets- och sessionsdata som kan vara synliga i paketet. Behandla capturefiler som autentiseringsloggar, spara dem bara kortvarigt och dela dem inte oskyddade. Den allmänna användningen beskrivs i Packet Capture på Sophos Firewall.

2. Kontrollera Live User

Under Current activities > Live users måste användare, klient-IP och klienttyp stämma överens. I denna procedur förväntas RADIUS SSO som klienttyp.

En synlig användare med fel IP-adress är ingen delvis framgång. Användarregler matchar senare den verkliga trafikkällan, inte den önskade wifikopplingen.

3. Korrelera autentiseringsloggen

Sök efter pilotanvändaren och händelsetiden i Log Viewer. För djupare analys är access_server.log relevant, eftersom Sophos bearbetar användarautentisering, auktorisering och accounting där.

I HA lagrar varje nod endast loggarna för trafik som den själv har behandlat. Kontrollera den nod som tog emot accounting vid testtillfället. Kontrollera Sophos Firewall-tjänster och loggar via CLI förklarar hur access_server.log kan läsas och sparas utan en okontrollerad tjänsteomstart.

4. Utför positiva och negativa test

Fyra saker testas separat med pilotklienten:

1. Ett tillåtet mål matchar förväntat Firewall Rule ID och visar rätt användare.
2. Ett avsiktligt otillåtet mål förblir blockerat.
3. En otilldelad användare får inte pilotåtkomsten.
4. Efter en ny anslutning eller kontrollerad roaming förblir kopplingen mellan användare, IP och regel korrekt.

Testet måste använda verklig nyttotrafik. En Live User-post bevisar inte ensam regelmatchning, routing eller returväg. Testa brandväggsregler tillförlitligt beskriver den upprepningsbara proceduren.

Avgränsa fel efter symptom

Inget accountingpaket når brandväggen

Kontrollera först destinations-IP, UDP-port, routing och motpartens konfiguration. Kontrollera sedan Device Access eller Local Service ACL Exception Rule. En lyckad RADIUS-inloggning på NPS eller wifinätverket bevisar inte att den separata accountingvägen till brandväggen finns.

Om paketet anländer med en annan käll-IP ska just denna orsak undersökas. Tillåt inte snabbt ett helt nätverk som RADIUS-klient. Vid NAT eller HA måste den stabila avsändaradress som faktiskt syns dokumenteras och tillåtas specifikt.

Accounting kommer fram, men Live Users förblir tomt

Kontrollera shared secret, avsändar-IP och paketinnehåll tillsammans. Accounting start, användarnamn och Framed-IP-Address är särskilt viktiga. Om klient-IP saknas ska accesspunkten, kontrollern eller RADIUS-proxyn korrigeras först. En tjänsteomstart på brandväggen kan inte skapa ett saknat attribut.

Först när paketet är komplett och access_server.log ändå inte behandlar händelsen ska tidpunkt, capture, CTR och nodloggar sparas för Sophos Support. Ta inte bort autentiseringsdatabasen och rensa inte Live Users på misstanke.

Användaren visas med fel IP-adress

Detta tyder ofta på ett för tidigt accountingmeddelande, en gammal DHCP-koppling, roaming eller en annan NAT-väg. Koppla från klienten, registrera aktuell lease och fånga en enda ny anslutning. IP-adressen i den nya accounting start är avgörande.

I SFOS-hanterat wireless ändras radius_accounting_start_delay först efter detta bevis och med det tidigare värdet dokumenterat. Tredjepartsaccesspunkter och kontroller använder egna accounting- och DHCP-mekanismer; en Sophos-wirelessparameter ändrar inte dessa enheter.

Live User stämmer, men regeln matchar inte

Då har accountingvägen kommit längre än policyn. Kontrollera Source Zone, Source Network, användare eller grupp, Match known users, regelordning, Firewall Rule ID och trafikens verkliga IP-adress. Om regel #0 eller en allmän regel matchar ska policyn korrigeras, inte shared secret.

Användaren förblir synlig efter utloggning

Kontrollera först om motparten skickar accounting stop och om paketet avser samma session och användarkoppling. Korrelera sedan Live User, aktuell klienttrafik och access_server.log. En manuell frånkoppling kan tillfälligt rensa tillståndet men bevisar inte att den automatiska processen fungerar korrekt.

Efter en omstart av brandväggen måste APX-klienterna enligt Sophos koppla från och ansluta igen så att en ny accounting start återställer inloggningen. Om Show captive portal to unknown users är aktiverat i användarregeln kan portalen visas först; i det dokumenterade APX-flödet följer transparent inloggning efter den konfigurerade accountingfördröjningen utan att autentiseringsuppgifterna anges igen.

Säkerhet, HA och drift

RADIUS-accounting använder UDP och skyddar inte transporten som TLS. Shared secret autentiserar RADIUS-vägen men krypterar inte alla identitets- och sessionsattribut. Accounting hör därför hemma i ett betrott management- eller servernät och ska inte gå oskyddat över främmande nät.

Följande gränser gäller i drift:

• Använd en separat stark shared secret och en dokumenterad ägare för varje avsändare.
• Tillåt RADIUS SSO bara från nödvändiga zoner och helst bara från fasta värdar.
• Behandla capturefiler, RADIUS-loggar och access_server.log som personrelaterade driftdata.
• Avsluta ändringar av DHCP, wifikontroller, NPS, RADIUS-proxy eller NAT med ett nytt end-to-end-test.
• Lova inte att användarkopplingen bevaras utan avbrott i HA. Efter en planerad failover ska en ny accounting start, Live User och verklig trafik kontrolleras på den behandlande noden.
• Hantera okända användare eller saknade kopplingar med en säker standardregel, inte med en bred allow-regel.

Rollback

Återställningen görs i en ordning som varken lämnar accountingtjänsten öppen eller oavsiktligt ger användare åtkomst:

1. Återställ tidigare autentiserings- och regelstrategi för pilotnätet.
2. Inaktivera pilotregeln och genomför ett negativt test med en okänd användare.
3. Ta bort proxyvidarebefordringens destination till brandväggen från RADIUS-servern eller återställ proxyns dokumenterade tidigare tillstånd. Ta inte bort APX-enhetens accountingdestination om RADIUS-servern fortfarande behövs för wifiautentisering och accounting.
4. Ta bort avsändaren under SSO using RADIUS accounting request.
5. Ta bort RADIUS SSO-ACL-undantaget eller den tillfälliga zonåtkomsten.
6. Kontrollera Live Users, Firewall Rule ID och normal klienttrafik igen.

Dokumentera ursprunglig konfiguration, ansvar för shared secret och den testade återgången till tidigare användaridentifiering i ändringen. Att bara ta bort en Live User-post är ingen fullständig rollback.

FAQ