Konfigurera och testa en RADIUS-server på Sophos Firewall

RADIUS ansluter Sophos Firewall till Microsoft NPS, en MFA-gateway eller en annan central autentiseringstjänst. Förbered först motparten och nätverksvägen. Skapa därefter servern under Authentication > Servers och tilldela den under Authentication > Services endast till de inloggningstjänster som behöver den. Verifiera konfigurationen med en riktig inloggning och kontrollera användare, grupper och regler.

För traditionella användar- och gruppuppslagningar från en Windows-domän passar ofta en direkt Active Directory-anslutning till Sophos Firewall. För moderna fjärråtkomstscenarier kan Microsoft Entra ID SSO för Sophos Connect och VPN Portal vara en lämpligare arkitektur. Om brandväggen i stället ska identifiera redan autentiserade WLAN-användare via inkommande accounting-paket gäller ett annat arbetsflöde: Konfigurera RADIUS SSO med accounting på Sophos Firewall.

När RADIUS är lämpligt

Brandväggen skickar användarnamn och inloggningsuppgifter till RADIUS-servern. Där avgör användarkällan, Network Policy och eventuell MFA om svaret blir Access-Accept eller Access-Reject. Först därefter avgör den lokala användargruppen, VPN-policyn och brandväggsreglerna vilka resurser som blir åtkomliga.

I RADIUS-modellen lagras autentiserings- och auktoriseringsdata i användarprofiler. För att en tjänst ska tillåtas måste begäran matcha de avsedda attributen, exempelvis IP-adressen för den RADIUS-klient som skickar begäran. Shared Secret skyddar användarnas lösenord; det innebär inte att hela RADIUS-transporten krypteras.

Typiska användningsområden är:

• Remote Access VPN med Microsoft NPS eller en MFA-tjänst;
• central inloggning till User Portal, VPN Portal eller Captive Portal;
• en övergångslösning när AD eller LDAP inte ska anslutas direkt till brandväggen;
• flera nätverksenheter som använder samma RADIUS-tjänst.

Ett Enterprise-WLAN som hanteras av brandväggen använder dessutom servervalet under Wireless > Wireless settings. Det fullständiga 802.1X-arbetsflödet beskrivs därför i Konfigurera WLAN direkt på Sophos Firewall.

I ett Enterprise-WLAN som hanteras av SFOS innehåller Accounting Request och Accounting Response sessions- och accounting-information. De är separata från Access-begäranden, -svar och -challenges för inloggningen. För denna Wireless-väg dokumenterar Sophos stöd för accounting på alla Wi-Fi-kompatibla enheter; Wireless Network måste använda 802.1X och accounting måste vara aktiverat på RADIUS-servern. Den länkade WLAN-guiden förklarar de separata portarna och avsaknaden av Interim Accounting Updates. Stöd för accounting innebär inget löfte om stöd för en sekundär RADIUS-server.

Dokumentera utgångsläge och återställningsväg

Innan en produktionstjänst ändras dokumenterar du följande under Authentication > Services för varje berört avsnitt:

• valda servrar och deras ordning;
• status för Set authentication methods same as firewall, Same as VPN eller Same as firewall;
• den befintliga Default group för brandväggsautentisering;
• en användare som bevisligen fungerar med den befintliga metoden.

Låt en befintlig WebAdmin-session vara öppen medan administratörsinloggningen ändras. Kontrollera dessutom en lokal superadministratör via en redan tillåten administrationsväg. Servervalet för administratörer gäller inte denna superadministratör, men en extern administratörsinloggning ska ändå aldrig ändras utan en verifierad lokal återställningsväg.

Planera RADIUS-anslutningen

Roller, nätverksväg och protokoll

I en NPS-miljö är Sophos Firewall RADIUS-klient och NPS RADIUS-server. NPS kontrollerar begäran mot sin Connection Request Policy och Network Policy samt vanligtvis mot Active Directory. En efterföljande VPN- eller brandväggsregel avgör fortfarande den faktiska åtkomsten.

Den allmänna hjälpen för SFOS 22 beskriver kommunikationen mellan brandväggen och RADIUS-servern med PAP. Under Authentication > Services anger Sophos däremot PAP, CHAP och MSCHAPv2 för L2TP- och PPTP-anslutningar. Denna protokollmatris innebär inte att samma metoder stöds för IPsec eller andra inloggningsvägar. Tjänsten, klienten och den tillåtna metoden på RADIUS-servern måste därför kontrolleras tillsammans.

Traditionell RADIUS använder UDP, och den dokumenterade SFOS-dialogrutan innehåller inga fält för TLS eller certifikat. Trafiken ska därför gå via en kontrollerad intern eller på annat sätt skyddad väg. Ett starkt Shared Secret ersätter varken segmentering eller en strikt regel mellan brandväggen och RADIUS-servern.

Äldre motparter kan förvänta sig andra portar, till exempel 1645/UDP och 1646/UDP. Det är de faktiskt konfigurerade portarna på båda sidor som gäller, inte dessa historiska värden.

Välj exempelvärden medvetet

Den här guiden använder:

• servernamnet NPS-HQ-RADIUS;
• server-IP-adressen 10.20.30.15;
• Authentication-porten 1812;
• Accounting-porten 1813;
• Time-out 5 sekunder;
• Domain name corp.example.

Ersätt 10.20.30.15 och corp.example med den interna adressen respektive organisationens namnstandard. Fem sekunder är ett startvärde för direkt lösenordsverifiering, inte ett standardvärde från Sophos. Vid pushnotiser, telefonsamtal eller en extern challenge måste värdet ligga inom det intervall på 1 till 60 sekunder som SFOS tillåter och passa både leverantören och den verkliga klienten.

Shared secret är den gemensamma tekniska hemligheten för RADIUS-klienten och RADIUS-servern, inte en användares lösenord. Sophos begränsar värdet till 48 tecken. Överför värdet via en separat skyddad kanal, lagra det säkert och ange exakt samma värde på båda sidor. RADIUS skickar inte själva hemligheten över nätverket.

Skapa RADIUS-servern under Authentication

Menysökvägen är Authentication > Servers.

1. Öppna Add och välj RADIUS server vid Server type.
2. Ange exempelvis NPS-HQ-RADIUS som Server name.
3. Ange RADIUS-serverns interna IP-adress under Server IP, i exemplet 10.20.30.15.
4. Anpassa Authentication port till servern, normalt 1812.
5. Ange Time-out. I exemplet används 5 sekunder för det första direkta testet.
6. Aktivera Enable accounting endast om motparten ska behandla accounting-data. Anpassa i så fall även Accounting port, normalt 1813.
7. Ange Shared secret exakt som på motparten.
8. Ange Domain name vid behov. När AD och RADIUS används parallellt förhindrar en enhetlig domän att samma person visas som olika lokala användarobjekt. Med Domain name skapas automatiskt en lokal post i formatet user@domainname vid den första inloggningen. Utan detta värde skapar RADIUS en användare utan domän, medan AD skapar en domänkvalificerad post; på så sätt kan två lokala poster för samma person uppstå.
9. Ange endast Group name attribute om motparten bevisligen returnerar det förväntade attributet. Sophos-hjälpen beskriver det som ett alias för det konfigurerade gruppnamnet, men dokumenterar här ingen generell mappning av valfria NPS-attribut till lokala grupper.
10. Öppna Enable additional settings endast om policyn kräver det. NAS-identifier identifierar den Network Access Server som skickar begäran, exempelvis med ett FQDN. NAS-port-type beskriver porttypen för inloggningen.
11. Kör Test connection med en särskild pilotanvändare och välj sedan Save.

Brandväggen stöder totalt högst 20 konfigurerade autentiseringsservrar. Även för varje autentiseringsmetod under Authentication > Services kan högst 20 servrar väljas.

API-gränser för SFOS 22 och 23

För automatisering ska API-referenserna läsas separat från WebAdmin-proceduren. Uppgifterna nedan räcker inte för en körbar Add/Edit-begäran.

• XML-exempel och parametertabell: Exemplet placerar RADIUSServer inuti AuthenticationServer. Det använder ServerAddress, Port och DomainName; tabellen använder däremot ServerIP, AuthenticationPort och domainName. Betrakta inte dessa skrivsätt som utbytbara genom antagen tagnormalisering.
• Accounting: Exempelkommentaren säger att AccountingPort ska tas med för att aktivera accounting; utan denna parameter är accounting inaktiverat. Detta styrker inget testat beteende när ett fält utelämnas vid Edit eller en partiell uppdatering. 2222 är bara värdet i XML-exemplet, inte WebAdmin-standardvärdet 1813; ta inte tyst bort den avsedda accounting-porten från genererad XML.
• Oklara värden: För IntegrationType visar exemplet LooseIntegration/TightIntegration, men tabellen anger Only '1' are allowed.; för ServerType anger den Only '4' are allowed.. Härled ingen enum-mappning eller giltiga begärandevärden från detta. Vid ändringar förblir WebAdmin-proceduren ovan den säkra vägen tills API-syntaxen för den använda versionen har klargjorts.
• API-gränser för indata: ServerName är en sträng med högst 50 tecken; UTF-8 är tillåtet, kommatecken är förbjudna. GroupNameAttribute och domainName är strängar med högst 50 tecken vardera. AuthenticationPort är ett heltal från 1 till 65535, med högst 5 siffror och det dokumenterade standardvärdet 1812. Tabellen markerar ServerIP, AuthenticationPort, SharedSecret och GroupNameAttribute med Yes under Mandatory; WebAdmin-rådet ovan om Group name attribute gör inte API-fältet valfritt. Detta är gränser från API-referensen, inte nyligen bekräftade GUI-begränsningar.
• Delete och identitet: Även Delete dokumenterar ServerName som serveridentifierare med samma namngränser. Använd det exakta befintliga namnet för den avsedda borttagningen, inte ett namn som har normaliserats på nytt. Även om Add/Edit och Delete för ServerName anger Mandatory: No med en tom Default-cell styrker detta varken borttagning utan namn eller borttagning med jokertecken eller i bulk. Kontrollerna av tjänstetilldelningar och den säkra återställningsproceduren nedan behövs fortfarande.

API-anmärkning för SFOS 23: API-referensen för att lägga till och redigera RADIUS-servrar lägger till den valfria parametern EmailAddressAttribute (sträng, högst 50 tecken) och inkluderar den i XML-exemplet för RADIUSServer. Inget standardvärde anges. Denna anmärkning gäller API-dokumentationen, inte ett extra WebAdmin-fält.

API-svar vid migrering från SFOS 22 till 23: För befintlig automatisering ändras de dokumenterade svarsklasserna när RADIUS-servrar läggs till och redigeras. API-referenserna anger följande värden i kolumnen Status:

Svarshanteringen bör därför kontrolleras separat för varje SFOS-version och operation; logik som enbart bygger på de tidigare felvärdena räcker inte för SFOS 23. Dessa värden är dokumenterade API-statusvärden, inte bevis för HTTP-statuskoder. JavaScript-nycklarna i kolumnen Message styrker ingen specifik svarstext vid körning. Tabellerna ger varken en entydig mappning av varje gammalt fel till ett nytt eller någon regel för nya försök.

Förstå accounting-funktionen

Med Enable accounting skickar brandväggen ett Accounting-Start-meddelande vid inloggning och ett Accounting-Stop-meddelande vid normal utloggning för klienttyper som stöds. Sophos anger klienttyperna Windows client, HTTP client, Linux client, Android, iOS, iOS HTTP client, Android HTTP client och API client. Start- och Stop-begärandena innehåller även tidpunkten för inloggningen respektive utloggningen.

När brandväggen stängs av eller startas om skickas inget Accounting-Stop. Om en session därför förblir öppen på RADIUS-servern kontrollerar du tidpunkten för omstarten tillsammans med RADIUS-loggarna. Denna utgående accounting-funktion är inte samma sak som inkommande RADIUS SSO Accounting, där brandväggen registrerar externa sessioner.

Förbered Microsoft NPS som motpart

Sophos Firewall måste finnas som RADIUS-klient i NPS. Minimikontrollen i konsolen Network Policy Server är:

1. Öppna RADIUS Clients and Servers > RADIUS Clients.
2. Skapa en New RADIUS Client med ett unikt Friendly name, exempelvis Sophos-Firewall-HQ.
3. Ange under Address (IP or DNS) den adress som NPS faktiskt tar emot begäran från.
4. Välj normalt RADIUS standard som Vendor.
5. Ange samma Shared secret som på brandväggen.
6. Kontrollera villkor, åtkomstbeslut och tillåten autentiseringsmetod för pilotanvändaren i rätt Connection Request Policy och Network Policy.
7. Ha Event Viewer och NPS accounting-loggar tillgängliga inför verifieringen.

I HA-kluster, routade anslutningar eller miljöer med NAT får NPS-klientadressen inte antas utifrån topologin. Ett första test visar i NPS vilken käll-IP-adress som faktiskt tas emot. Om begäran saknas helt eller NPS inte kan verifiera den kontrollerar du först routing, UDP-regeln, RADIUS-klientadressen och Shared Secret. Ett normalt Access-Reject tyder däremot på ett problem med användaren, policyn eller autentiseringsmetoden.

Tilldela RADIUS till rätt tjänster

När serverobjektet har sparats är det ännu inte aktivt för någon inloggning. Under Authentication > Services finns följande avsnitt i SFOS 22:

• Firewall authentication methods;
• User portal authentication methods;
• VPN portal authentication methods;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods;
• Administrator authentication methods;
• SSL VPN authentication methods.

För User Portal, VPN Portal, VPN och administratörer kan servervalet vara kopplat till brandväggsautentiseringen. SSL VPN erbjuder Same as VPN och Same as firewall. Kontrollera därför först om det berörda avsnittet använder en egen lista eller en kopplad lista innan du gör en ändring.

För en begränsad pilotdrift lägger du endast till NPS-HQ-RADIUS i det avsnitt där servern behövs, placerar den på avsedd plats och väljer Apply. Brandväggen frågar flera servrar i den ordning som visas. Om samma användare redan kan logga in via en tidigare server kommer en efterföljande RADIUS-MFA-policy inte att nås.

Captive Portal och Default Group

Captive Portal har inget eget avsnitt under Authentication > Services. Den använder Firewall authentication methods. Dessutom måste den avsedda zonen tillåta Captive portal under Administration > Device access, och en användarbaserad brandväggsregel måste vara korrekt konfigurerad. Ett officiellt funktionstest är att logga in på https://<firewall-ip>:8090.

Default group under Firewall authentication methods är säkerhetsrelevant. En extern användare skapas under Authentication > Users vid den första lyckade inloggningen till en brandväggstjänst. Om det inte finns någon lämplig lokal grupptilldelning används den konfigurerade standardgruppen. Kontrollera gruppens policyer och alla regler där den används före pilotdriften. En standardgrupp med för omfattande behörigheter får inte omärkligt bli reservval.

Avgränsa challenge-baserad MFA per tjänst

Enligt hjälpen för SFOS 22 stöder VPN Portal inte RADIUS-autentisering med challenge-baserad MFA. En lyckad Test connection säger därför inget om denna portalväg. Push, Call, OTP och Challenge är inte heller utbytbara: testa varje avsedd klient och tjänst separat. För lokal MFA i Sophos Firewall gäller det separata arbetsflödet i Aktivera MFA för Sophos Firewall WebAdmin, VPN Portal och Remote Access.

Verifiera konfigurationen

1. Anslutning och motpart

Öppna NPS-HQ-RADIUS under Authentication > Servers och kör Test connection med pilotanvändaren. Kontrollera samtidigt följande i NPS eller loggarna för den andra motparten:

• begäran kommer från brandväggens förväntade adress;
• rätt policy behandlar begäran;
• resultatet är Access-Accept;
• förväntade svarsattribut finns.

Testet bekräftar inloggningsuppgifterna och serverkommunikationen. Det bekräftar ännu inte tjänsteordningen, VPN-policyn, den lokala gruppen eller brandväggsregeln.

2. Testa den verkliga tjänsten

Logga därefter in samma användare via exakt den avsedda tjänsten. Captive Portal, SSL VPN, IPsec, User Portal och WebAdmin har olika förutsättningar. För WebAdmin måste den externa användaren dessutom tilldelas den avsedda administratörsprofilen. En lyckad RADIUS-inloggning ger inte i sig administratörsbehörighet. Lämna vägar som inte behövs oförändrade. För SSL VPN beskriver Konfigurera Sophos Firewall SSL VPN Remote Access policy, Device Access och brandväggsregel.

Kontrollera följande efter en lyckad inloggning:

1. Den lokala användaren, domänen och den faktiska Main Group under Authentication > Users.
2. Den aktiva sessionen under Current activities > Live users. Där kan den vid behov avslutas med Disconnect.
3. Öppna modulen Authentication i Log viewer längst upp till höger i WebAdmin och filtrera på användare, käll-IP-adress och ett snävt testintervall.
4. Kontrollera faktisk Firewall Rule ID och endast den tillåtna målresursen i trafikloggen.
5. Testa det negativa fallet med en användare utanför den tillåtna NPS-policyn.

Om inloggningen fungerar men programmet inte går att nå kontrollerar du zon, VPN-IP-pool, grupp, regelposition, NAT och routing. Sophos Firewall-regeln matchar inte: kontrollera orsakerna går igenom denna dataväg. Om identitet, tjänsteval eller Main Group redan är oklara hjälper Felsök autentiseringsfel på Sophos Firewall systematiskt.

Avgränsa fel utifrån observationen

Ingen begäran når motparten

Kontrollera först värdena som har konfigurerats under Server IP och Authentication port. Kontrollera därefter routing och regeln för UDP 1812 mellan den källadress som brandväggen använder och 10.20.30.15. Ett RADIUS-serverobjekt skapar inte automatiskt en brandväggsregel för transittrafik.

För ett trådlöst nätverk som hanteras av SFOS dokumenterar Sophos ett snävt avgränsat specialfall: Om RADIUS-servern är ansluten till brandväggen via en IPsec-tunnel behövs en Source-NAT-mappning för accesspunkternas nätverk. Den översätter käll-IP-adressen till exakt den IP-adress på brandväggen som används för att nå RADIUS-servern. Wireless-hjälpen hänvisar till en konfiguration via shell med sys-traffic-nat, men ger här inget fullständigt körbart kommando. Före en ändring måste accesspunkternas nätverk, den faktiskt använda källadressen, brandväggsadressen för källadressöversättningen, tunneln, returvägen och RADIUS-loggarna verifieras. Utan bekräftad syntax för detta måste den konkreta shell-konfigurationen, inklusive kontroll och återställning, hanteras genom riktad teknisk eskalering. För andra RADIUS-vägar styrker denna Wireless-guide inget generellt NAT-krav. En LAN-till-VPN-regel eller ett exempel på en Forwarding-IPsec-route ersätter inte detta arbetsflöde för systemtrafik.

NAT för systemtrafik på en bekräftad Wireless-IPsec-väg

Den separata CLI-hjälpen för SFOS 22 och 23 dokumenterar syntaxen nedan. Den kompletterar specialfallet för Wireless ovan; den ersätter inte kontrollen av AP-nätverken eller planeringen av tunneln och returvägen.

⚠️ Före ändringen: En NAT-ändring kan avbryta autentisering och andra systemtjänster till samma destination. Förbered en säkerhetskopia, ett underhållsfönster och oberoende administratörsåtkomst. RADIUS-destinationen, den observerade käll-IP-adressen, den nödvändiga brandväggs-IP-adressen, IPsec-selektorerna eller rutten, returvägen och NPS-klientadressen måste stämma överens. Om denna väg inte är bekräftad krävs fortfarande teknisk eskalering.

Logga in i Command-line console med administratörsbehörighet och välj 4 – Device Console, inte Advanced Shell. Dokumentera först den befintliga konfigurationen med detta skrivskyddade kommando:

show advanced-firewall

IPv4-exemplet nedan gäller endast om 10.20.30.15 är RADIUS-servern och 10.40.50.1 är exakt den brandväggs-IP-adress som är avsedd för denna väg. Ersätt båda adresserna. 255.255.255.255 begränsar destinationen till en värd; en bredare mask omfattar fler destinationer. Kommandot har inget filter för källnätverk eller port: det väljer inte enbart ett AP-nätverk eller UDP 1812. Utan interface gäller mappningen för trafik till denna destination genom vilket brandväggsinterface som helst. En verifierad parameter interface <interface> kan begränsa omfattningen; gissa inte ett interfacenamn. Skriv inte över och ta inte bort befintliga eller överlappande mappningar utan att kontrollera dem.

Lägg endast till mappningen om dessa bieffekter uttryckligen har godkänts och det inte redan finns en lämplig mappning:

set advanced-firewall sys-traffic-nat add destination 10.20.30.15 netmask 255.255.255.255 snatip 10.40.50.1
show advanced-firewall

Kontrollera sedan 802.1X, Accounting-Start och normal utloggning med Accounting-Stop med en verklig trådlös testklient. RADIUS-loggarna måste visa den förväntade käll-IP-adressen från brandväggen, beslutet Access-Accept och mottagen accounting; kontrollera också tunneln, svarsvägen och andra tjänster till samma destination. Att NAT-mappningen visas bevisar inte i sig att inloggningen fungerar. Utöka inte åtkomstreglerna vid avvikelser.

För att återställa enbart den nyligen tillagda exempelmappningen, använd samma anpassade värden med delete. Om du lade till interface, behåll samma parameter även vid borttagningen:

set advanced-firewall sys-traffic-nat delete destination 10.20.30.15 netmask 255.255.255.255 snatip 10.40.50.1
show advanced-firewall

Jämför med det dokumenterade utgångsläget och testa den ursprungliga autentiseringen och berörda systemtjänster på nytt. Ett konsolfel eller en oklar post är ett skäl att avbryta, inte att göra en generell återställning.

NPS svarar med Access-Reject

Ett Reject visar att nätverksvägen och porten i princip fungerar. Kontrollera nu Reason Code, relevant Network Policy, användarstatus och tillåten autentiseringsmetod i NPS. Ett felaktigt Shared Secret leder däremot till uteblivna, ogiltiga eller ej verifierbara svar.

Test connection fungerar, men inte tjänsteinloggningen

Kontrollera rätt avsnitt, kopplingsinställning, serverordning och Apply under Authentication > Services. För Captive Portal kontrollerar du dessutom Device access och den användarbaserade brandväggsregeln. För SSL VPN måste Policy Member, SSL-VPN-åtkomst under Device Access och den nödvändiga brandväggsregeln vara korrekta.

Inloggningen fungerar, men fel grupp används

Kontrollera Domain och Main Group under Authentication > Users. Jämför sedan Group name attribute, motpartens svarsattribut och Default group. En lyckad autentisering bevisar inte att auktoriseringen är den förväntade. Den negativa testanvändaren måste därför bevisligen nekas på grund av grupp- eller NPS-villkoret.

Push eller Challenge når Time-out

Använd den verkliga klienten och jämför tidpunkterna i loggarna från brandväggen, NPS och MFA-leverantören. Öka SFOS-värdet för Time-out endast inom intervallet 1 till 60 sekunder och välj det lägsta värde som tillförlitligt täcker det normala challenge-flödet. Challenge-baserad RADIUS-MFA på VPN Portal kan inte åtgärdas med längre Time-out eftersom Sophos inte stöder denna väg.

Återställ säkert

Om pilotdriften misslyckas återställer du den tidigare dokumenterade serverlistan och dess ordning, kopplingsinställningarna samt Default group i det berörda avsnittet under Authentication > Services och väljer Apply. Logga därefter in referensanvändaren med den ursprungliga metoden och kontrollera den lokala superadministratören.

Ta inte bort NPS-HQ-RADIUS från ytterligare tjänstetilldelningar förrän alla berörda tjänster fungerar igen. Ta endast bort serverobjektet under Authentication > Servers om det inte längre finns någon planerad användning. Återställ klient, policy och Shared Secret i NPS till det dokumenterade utgångsläget. Redan skapade lokala användarobjekt måste kontrolleras separat. Att ta bort dem avslutar inte automatiskt alla befintliga sessioner, så kontrollera även Current activities > Live users.

Drift

RADIUS är en produktionskritisk identitetstjänst. Efter ändringar i NPS, MFA-leverantören, AD eller tjänsteordningen ska verifieringen omfatta en verklig positiv och negativ inloggning. Dokumentera Shared Secret på ett skyddat sätt och rotera det enligt plan. Konfigurera övervakning av motparten och fastställ lagringstiden för dess beslutsloggar. Då går det att avgöra om ett fel uppstod före brandväggen, under autentiseringen eller först vid auktoriseringen.

FAQ