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.

Snabb procedur

1. Kontrollera att accesspunkten, kontrollern eller RADIUS-proxyn kan skapa en accounting start med användarnamn och Framed-IP-Address.
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å accesspunkten, wifikontrollern eller network access server.
2. Efter adresstilldelningen skapar infrastrukturen en accounting start eller vidarebefordrar den via en RADIUS-proxy.
3. Sophos Firewall tar emot 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.

Om wifikontrollern skickar direkt till brandväggen eller om en RADIUS-server som NPS vidarebefordrar accounting beror på produkten. Sophos-konfigurationen innehåller inget universellt NPS- eller controllerrecept. Paketet som faktiskt kommer fram till brandväggen är avgörande. Ett leverantörspåstående som ”stöd för RADIUS Accounting” räcker inte innan användarnamn och klient-IP har verifierats 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

På accesspunkten, kontrollern, network access server eller RADIUS-proxyn måste autentisering och accounting kontrolleras separat. En lyckad inloggning bevisar inte att accounting skapas eller vidarebefordras till Sophos Firewall.

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

1. Aktivera accounting för den berörda 802.1X- eller nätverksåtkomsten.
2. Ange den planerade brandväggsadressen 10.10.20.1 som accountingdestination.
3. Använd UDP 1813 eller den accountingport som uttryckligen har avtalats mellan båda parter.
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 parametern radius_accounting_start_delay med ett intervall från 0 till 60 sekunder. Ändra inte värdet på misstanke: först måste en capture visa att accounting start skapas före IP-tilldelningen. Den allmänna wifikonfigurationen beskrivs i Konfigurera Wireless Network på Sophos Firewall.

För AP6 listar versionsinformationen för 1.5.2167 MR5 korrigeringen WIFIX-5189 för ett fall där framed IP saknades i accounting start och accounting update. Uppdatera därför först en AP6 med äldre eller okänd firmware till en aktuell version som stöds och kontrollera sedan paketet igen. Korrigeringen bevisar inte automatiskt att varje kombination av controller, proxy eller NPS vidarebefordrar attributen korrekt.

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.

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.

Konfigurationen skapar ingen RADIUS-server under Authentication > Servers och ersätter inte heller den allmänna RADIUS-serverkonfigurationen på Sophos Firewall. Serverartikeln behandlar förfrågningar som brandväggen skickar till NPS, MFA eller en annan RADIUS-server. RADIUS SSO behandlar inkommande accountingmeddelanden.

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 den konfigurerade accountingporten.
• 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.

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 accountingdestinationen från accesspunkt, controller eller RADIUS-proxy, eller återställ det dokumenterade tidigare tillståndet.
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