Felsök autentiseringsfel på Sophos Firewall systematiskt

Ett autentiseringsfel på Sophos Firewall kan uppstå på mycket olika ställen. Servern kan vara nåbar men inte vald för den berörda tjänsten. Inloggningen kan fungera medan huvudgruppen, en kvot eller en brandväggsregel hindrar åtkomsten. Brandväggen kanske inte heller ser användaren alls utan behandlar trafiken enbart utifrån IP-adressen.

Den säkra snabbvägen skiljer avsiktligt mellan dessa lager:

1. Anteckna användare, käll-IP, berörd tjänst, tidpunkt och förväntat resultat.
2. Testa portalens eller autentiseringstjänstens nåbarhet från den verkliga källzonen.
3. Kontrollera under Authentication > Services att rätt server är vald för den berörda tjänsten och ligger på avsedd plats.
4. Kör Test connection på autentiseringsservern, men betrakta resultatet endast som bevis på autentiseringsuppgifter och serveranslutning.
5. Skapa en ny inloggning och kontrollera användare, käll-IP och Client Type under Current activities > Live users.
6. Kontrollera status, huvudgrupp, övriga grupper, användarundantag och User ID under Authentication > Users.
7. Kontrollera Access Time, kvoter, MFA och Sign-in Restrictions endast för den användare som faktiskt berörs eller dennes effektiva grupp.
8. Först när identiteten har verifierats testas förväntad brandväggsregel, Rule ID, webb- eller VPN-policy, NAT och routing med verklig trafik.

⚠️ Ändra inte autentiseringsservrar, gruppordning, kvoter eller Device Access brett på misstanke. En tjänsteomstart, Purge AD users eller en Any-regel är inte ett normalt första diagnostiksteg. Fastställ först vid vilket lager arbetsflödet stannar.

Fem lager i stället för ett enda inloggningsfel

I praktiken hjälper en enkel modell. En användaråtkomst passerar inte en enda kontroll, utan minst fem separata lager:

1. Nåbarhet: klienten och brandväggen når portalen, proxyn eller autentiseringsservern via den avsedda vägen.
2. Tjänst och metod: rätt autentiseringsserver är vald under Authentication > Services för just denna tjänst.
3. Identitet: brandväggen känner igen den förväntade användaren och visar rätt käll-IP och passande Client Type.
4. Behörighet: användarstatus, grupp, huvudgrupp, Access Time, kvot, MFA och tjänstespecifika rättigheter stämmer.
5. Efterföljande trafik: en brandväggsregel, webbpolicy eller VPN-policy tillåter de önskade destinationerna och returvägen fungerar.

Denna uppdelning förhindrar två vanliga felaktiga slutsatser. En grön Test connection bevisar inte att SSO-inloggningen fungerar. Omvänt bevisar en användare under Live users ännu inte att trafiken matchar den avsedda regeln eller policyn.

Definiera ett reproducerbart testfall

Definiera ett enda testfall före den första ändringen. Säkra dokumentationsvärden är exempelvis:

• Användare: auth-pilot@example.com
• Klient-IP: 192.0.2.25
• Källzon: LAN
• Tjänst: Firewall authentication, User portal, VPN portal, SSL VPN eller Web admin console
• Testtid: brandväggens lokala tid med datum och minut
• Förväntad grupp: Internet-Standard
• Förväntad regel: LAN-Users-to-WAN
• Förväntat resultat: lyckad inloggning och HTTPS-åtkomst till en definierad testdestination

example.com och 192.0.2.0/24 är dokumentationsvärden. Ersätt användarnamn, käll-IP, zon, grupp, regel och destination med verkliga pilotvärden. Piloten bör använda samma autentiseringskälla och behörighetsgrupp som den berörda användaren, men inte ha onödiga administratörsrättigheter.

Testa om möjligt även en fungerande jämförelseanvändare från samma källa. Om båda misslyckas ligger orsaken mer sannolikt i tjänsten, servern eller nåbarheten. Om endast en användare misslyckas är användarobjekt, grupper, kvoter, MFA eller Sign-in Restrictions mer sannolika.

Kontrollera tjänst, nåbarhet och server

Kontrollera Device Access endast för den nödvändiga tjänsten

Portaler och lokala autentiseringstjänster tillåts inte med vanliga brandväggsregler. Under Administration > Device access, eller med en riktad Local service ACL exception rule, måste den nödvändiga tjänsten vara nåbar från den avsedda källzonen eller kända källnät.

Beroende på testet kan olika poster vara relevanta, till exempel Captive portal, User portal, VPN portal, SSL VPN, AD SSO eller Client Authentication. Kontrollera endast den tjänst som faktiskt behövs. Ett brett tillstånd för LAN eller WAN skulle dölja felet och kan exponera ytterligare hanterings- eller portaltjänster. Device Access och Local Service ACL på Sophos Firewall förklarar den säkra avgränsningen.

Enbart nåbarhet är ännu inte autentisering. En synlig portalsida bekräftar endast att klienten når den lokala tjänsten. Användarnamn, lösenord, SSO-token, grupp och efterföljande brandväggsregel är ännu inte testade.

Kontrollera autentiseringsmetoden per tjänst

Under Authentication > Services har varje tjänst ett eget serverval. Kontrollera därför inte bara om det finns en AD-, LDAP-, RADIUS- eller Entra-server, utan även om den är vald för den berörda tjänsten:

• Firewall authentication methods för användartrafik och klassisk brandväggsautentisering;
• User portal authentication methods för User Portal;
• VPN portal authentication methods för VPN Portal;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods för dessa VPN-inloggningar;
• Administrator authentication methods för namngivna administratörer;
• SSL VPN authentication methods för SSL VPN.

Med flera servrar är även ordningen viktig. Flytta inte en server till toppen för tidigt. Dokumentera först aktuell ordning, Default Group och fungerande jämförelseanvändare. Annars kan en ändring påverka andra användare eller tjänster. För externa administratörer separerar TACACS+ för Sophos Firewall WebAdmin dessutom serverautentisering, den lokala administratörsprofilen och ett utelåsningssäkert reservalternativ.

Tolka Test connection korrekt

Under Authentication > Servers kontrollerar Test connection autentiseringsuppgifterna och anslutningen mellan brandvägg och server. Vid fel korrigeras först DNS, routing, port, anslutningssäkerhet, certifikatkedja, tjänstekonto eller lösenord.

Ett lyckat test är dock endast det första lagret. För AD SSO testar det varken Kerberos, NTLM, SPN, Redirection Location, webbläsarförtroende eller faktisk användaråtkomst. Även för portal- och VPN-inloggningar måste tjänsteval, grupp, MFA och policy testas separat. Ansluta Active Directory till Sophos Firewall beskriver hela AD-grundkonfigurationen.

Använd Live Users som första identitetsbevis

Öppna Current activities > Live users efter en ny inloggning. Minst tre värden är viktiga:

För Client Authentication Agent måste klienttypen vara Authentication agent. Kontrollera också separat vägen till 1.2.3.4:9922, Authentication Server CA och den faktiska matchningen mot brandväggsregeln.

• User: är den identifierade användaren verkligen pilotkontot?
• IP address: motsvarar adressen den observerade klientanslutningen?
• Client Type: användes den förväntade vägen, exempelvis AD SSO Kerberos, AD SSO NTLM, STAS, Multi-host client, Captive portal, RADIUS SSO eller en VPN-typ?

Om användaren saknas har identitetslagret ännu inte lyckats. Fortsätt då inte felsökningen vid den senare användarregeln. Om ett datornamn visas i stället för den inloggade användaren kan en operativsystemtjänst som Windows Update ha skickat enhetens NTLM-uppgifter. En verklig interaktiv användarinloggning och en ny webbförfrågan avgränsar detta fall.

En extern AD-, LDAP- eller RADIUS-användare visas normalt under Authentication > Users först efter den första lyckade inloggningen till en brandväggstjänst. Att en lokal användarpost saknas bevisar därför inte att kontot saknas i katalogen. För ett konto som hanteras direkt i SFOS beskriver skapa och hantera normala lokala användare däremot hela arbetsgången för konto, tjänst, testning och avveckling.

För ett rent omtest kan en befintlig normal session kopplas från under Live users. Efter att en AD SSO-session kopplats från manuellt kan det ta upp till tre minuter innan användaren kan logga in igen. Clientless Users loggas inte ut där med Disconnect; sätt dem i stället till Inactive under Authentication > Clientless users.

Kontrollera användarobjekt, huvudgrupp och begränsningar

När användaren är synlig eller en lokal post redan finns fortsätter kontrollen under Authentication > Users. Ändra inte värden på måfå, utan dokumentera först de effektiva egenskaperna:

• status Active eller Inactive;
• fältet Group som huvudgrupp för AD-användare;
• Other group memberships;
• användarspecifika policyundantag;
• Access Time och Sign-in Restriction;
• Surfing Quota och Network Traffic Quota;
• MFA-tilldelning för den berörda tjänsten;
• ytterligare egenskapen User ID.

Likställ inte huvudgruppen med övriga grupper

En AD-användare kan tillhöra flera grupper. Sophos Firewall visar den effektiva huvudgruppen i fältet Group och övriga medlemskap separat. Brandväggsregler, webbpolicies och vissa andra funktioner kan beakta flera grupper. Access Time, kvoter, MFA och flera funktioner för fjärråtkomst använder däremot endast huvudgruppen eller en uttrycklig användartilldelning.

Ändra därför inte gruppordningen som snabb lösning. Fastställ först vilken funktion som misslyckas och vilken grupplogik den stöder. Autentisera användaren igen efter en planerad ändring och kontrollera huvudgruppen på nytt.

Hela driftproceduren, från att skapa grupper och välja Default Group till Reorder, flera grupper, användaråsidosättningar och återställning, beskrivs i Hantera användargrupper och huvudgruppen korrekt i Sophos Firewall.

Behandla Access Time, kvoter och MFA som separata orsaker

En oväntad Captive Portal eller avvisad inloggning kan också orsakas av blockerad Access Time, en förbrukad Surfing Quota eller Network Traffic Quota eller en saknad MFA-registrering. Jämför dessa inställningar för användaren och den effektiva gruppen.

Motsvarande kontroller och återställningsvägar beskrivs i Access Time för användare och grupper, Surfing och Network Traffic Quota samt MFA för Sophos Firewall. Återställ inte en kvot och bredda inte en Access Time-policy innan den faktiska tilldelningen har verifierats.

Koppla User ID-gränsen först efter att värdet är synligt

Under Show additional properties kan User ID visas. Ett värde över 65535 ligger utanför det stödda intervallet; användaren kan då inte autentiseras eller bli en Live User. Antalet synliga användare räcker inte för diagnosen, eftersom grupper delar samma ID-intervall.

Om ID:t är giltigt eller användaren fortfarande saknas helt fortsätter den allmänna diagnosen. Purge AD users hör endast hemma i ett bekräftat rensningsfall. Den säkra specialproceduren finns i Kontrollera User ID-gränsen på Sophos Firewall.

Fortsätt med den metod som faktiskt används

När tjänst och fellager är kända fördjupas bara den relevanta metodvägen. Felsökningen förblir då avgränsad och flera autentiseringssystem ändras inte samtidigt.

Klassisk inloggning och Captive Portal

Vid manuell inloggning kontrolleras portalens direkta URL, Device Access, vald autentiseringsmetod, användarstatus, lösenord och MFA. För Captive Portal kontrolleras dessutom om den okända anslutningen når den avsedda regeln med Use web authentication for unknown users och om DNS fungerar före inloggningen.

Hela konfigurationen, inklusive port 8090, Live Users, användarregeln och utloggning, beskrivs i Konfigurera och testa Sophos Firewall Captive Portal.

AD SSO med Kerberos eller NTLM

Ett lyckat AD-anslutningstest räcker inte för SSO. Även värdnamn eller FQDN, DNS-upplösning, Redirection Location, certifikat, webbläsarförtroende, Domain Join och, för Kerberos, passande HTTP-SPN måste stämma. Om Kerberos faller tillbaka till NTLM eller Captive Portal kontrolleras först denna namn- och förtroendeväg.

nasm.log är relevant för NTLM- och Kerberos-fel. Ändra inte SPN eller Domain Join på måfå; spara först det befintliga tillståndet på brandväggen och domänkontrollanten.

STAS, SATC och fleranvändarvärdar

Med Synchronized User ID Authentication kommer Windows-domänidentiteten och klientens IP via Security Heartbeat. Endpointstatus, UPN-domän, sAMAccountName, AD-validering och Live users måste då stämma överens; endast ett grönt heartbeat bevisar inte användarregeln.

Med STAS måste samma klient-IP följas genom Windows-händelser, STA Agent, Collector och brandvägg. Om användaren bara saknas i Live Users kontrolleras Collectorns nåbarhet, övervakade nätverk, Exclusion List och Client Authentication. Hela arbetsflödet finns i Konfigurera STAS på Sophos Firewall.

Flera samtidiga användare bakom ett enda terminalserver-IP kräver en sessionsmodell. SATC för Remote Desktop Services kan koppla flera protokoll till en session. Per-Connection AD SSO för fleranvändarvärdar gäller däremot endast HTTP- och HTTPS-anslutningar via Direct Web Proxy. Normal IP-baserad mappning kan inte tillförlitligt skilja flera användare bakom samma adress.

RADIUS SSO, Entra ID och VPN

RADIUS SSO kräver accounting-händelser med korrekt klient-IP; ett lyckat RADIUS-åtkomsttest bevisar inte denna accounting-väg. RADIUS SSO med accounting beskriver konfiguration och kontroll av Framed-IP-Address.

För Microsoft Entra ID SSO kontrolleras dessutom det tjänstespecifika OAuth-flödet. Captive Portal, VPN Portal och WebAdmin använder olika Redirect URIs, autentiseringsmetoder och loggfiler. En lyckad inloggning till en av dessa tjänster bevisar inte de andra.

För VPN kontrolleras efter autentiseringen även att användaren eller gruppen finns i rätt policy för fjärråtkomst. Grön tunnelstatus bevisar ännu inte åtkomst till interna destinationer.

Autentiseringen lyckas men trafiken blockeras fortfarande

När användaren visas under Live users med förväntat IP flyttas diagnosen till behörighet och paketväg. Ett verkligt testflöde måste visa:

1. Vilken Firewall Rule ID behandlar anslutningen?
2. Innehåller regeln den förväntade användaren eller en grupp som stöds?
3. Är Log firewall traffic aktiverat?
4. Väljer regeln rätt webb-, Application-, IPS- eller Traffic Shaping-policy?
5. Stämmer destination, tjänst, NAT, route och returväg?

En allmän IP-regel ovanför användarregeln kan redan behandla trafiken. På samma sätt kan rätt användarregel matcha medan webbpolicy, TLS Inspection, DNS, routing eller destinationssystemet blockerar den senare åtkomsten. Använd därför inte en autentiseringsändring som lösning på ett bekräftat routing- eller policyfel.

Testa en Sophos Firewall-regel korrekt förklarar hela verifieringen med Log Viewer, Policy tester och Packet Capture.

Korrelera Log Viewer och loggfiler

I Log viewer kontrolleras modulen Authentication med antecknad användare, käll-IP och ett snävt testintervall. Sök sedan samma tidpunkt i brandväggs- eller VPN-modulen. Då går det att se om själva inloggningen misslyckas eller om endast det efterföljande dataflödet blockeras.

För klassisk autentisering, behörighetskontroll och accounting är access_server.log den första filen att kontrollera. I Advanced Shell är följande kommandon endast läsande:

cd /log
tail -n 200 access_server.log

Lägg endast till filen som hör till metoden:

tail -n 200 nasm.log
tail -n 200 oauth_sso_captive.log
tail -n 200 oauth_sso_webadmin.log
tail -n 200 oauth_sso_vpn.log

• nasm.log hör till NTLM och Kerberos.
• oauth_sso_captive.log hör till Entra SSO-flödet för Captive Portal.
• oauth_sso_webadmin.log hör till Entra SSO för WebAdmin.
• oauth_sso_vpn.log hör till Entra SSO för VPN Portal, IPsec och SSL VPN.

Kommandona läser endast de senaste 200 raderna. De aktiverar inte debug och startar inte om någon tjänst. Lägg till filer som vpnportal.log, sslvpn.log, strongswan.log, chromebook-sso-backend.log eller csd.log först efter att metoden har valts. Sophos Firewall-tjänsteloggar förklarar tilldelningen.

I ett HA-kluster lagrar varje nod endast loggar och rapporter för den trafik som den själv behandlar. Dokumentera därför roll, testtid och behandlande nod och kontrollera filerna på den noden. En tom fil på den andra enheten motbevisar inte felet.

Avgränsa felet efter symptom

Test connection lyckas men SSO fungerar inte

Autentiseringsservern och dess uppgifter är nåbara. Kontrollera därefter Authentication > Services, Device Access, Live Users och den metodspecifika SSO-vägen. För AD omfattar detta särskilt DNS, FQDN, Redirection Location, SPN, webbläsarförtroende, Domain Join och nasm.log.

Captive Portal visas i stället för transparent inloggning

Fastställ först om AD SSO eller STAS ska identifiera användaren före webbåtkomst. Kontrollera därefter Client Type under Live Users, modulen Authentication, Access Time, kvoter och autentiseringsuppgifter. Portalen är ett symptom på saknad eller avvisad identitet, inte automatiskt ett portalfel.

Datornamn visas i stället för användarnamn

En systemtjänst kan skicka slutpunktens NTLM-uppgifter trots att ingen användare ännu har loggat in interaktivt. Logga in en verklig användare, öppna en ny webbläsarsession och upprepa testet. Om datornamnet kvarstår kontrolleras webbläsar- eller proxyvägen, SSO-metoden och nasm.log.

Användaren saknas i Live Users

Kontrollera först tjänsteval, Device Access och den konkreta metoden. För STAS måste Collector och brandvägg se samma IP; för Captive Portal måste inloggningen verkligen slutföras; för externa servrar skapas den lokala användarposten först efter lyckad inloggning. Kontrollera User ID, Sign-in Restriction och kvoter endast om motsvarande användarpost finns.

Användaren är synlig men grupp eller policy är fel

Jämför huvudgrupp, Other group memberships och användarundantag under Authentication > Users. Kontrollera därefter om den konkreta funktionen stöder flera grupper. Ändra gruppordningen endast i ett planerat underhållsfönster, eftersom detta också kan flytta MFA, kvoter, Access Time, VPN och andra policies.

Inloggningen lyckas men internet eller VPN-destinationen är fortfarande onåbar

Autentisering är inte längre det första fellagret. Kontrollera Firewall Rule ID, regelordning, loggning, webb- eller VPN-policy, NAT, route och returväg med ett verkligt flöde. Både användaridentitet och paketväg måste stämma.

Felet uppstår endast efter HA-failover eller sporadiskt

Dokumentera firmware-build, rollbyte, aktiv nodroll, inloggningstid och autentiseringsmetod. Testa en ny inloggning och anslutning efter failover. Kontrollera därefter loggarna på den nod som behandlade försöket. Betrakta inte en befintlig session som bevis på en ny lyckad autentisering.

Stoppvillkor och supportdata

Gör inga ytterligare ändringar i produktionskonfigurationen när:

• den berörda tjänsten eller autentiseringsmetoden inte är entydig;
• Test connection misslyckas och DNS, route, port, TLS eller autentiseringsuppgifter fortfarande är oklara;
• pilotanvändaren visas med oväntad Client Type eller fel käll-IP;
• huvudgrupp, användarundantag eller kvot inte kan förklaras;
• ett negativt test oväntat får åtkomst;
• endast en bred Device Access- eller brandväggsregel verkar få testet att lyckas;
• ett HA-problem inte kan kopplas till behandlande nod och tidpunkt.

Säkra minst följande före eskalering:

• enhetsmodell, SFOS-version och fullständig build;
• för HA båda rollerna och den behandlande noden;
• autentiseringskälla och berörd tjänst;
• testanvändare, käll-IP, Client Type och tidsfönster;
• serverordning under Authentication > Services;
• resultatet av Test connection med dess begränsade innebörd;
• status, huvudgrupp, övriga grupper, undantag och User ID;
• autentiseringshändelse, Firewall Rule ID och resultat av det verkliga testflödet;
• matchande autentiserings-, portal-, VPN- och brandväggsloggar.

Användarnamn och grupper kan innehålla känslig information. Paketet lämnas endast via avsedd supportkanal. Skapa en Consolidated Troubleshooting Report och riktad loggexport före tjänsteomstarter, debug eller datarensning.

Checklista

• Testfallet innehåller användare, käll-IP, tjänst, tidpunkt och förväntat resultat.
• Den lokala tjänsten är endast nåbar från avsedd zon eller källa.
• Rätt server är vald under Authentication > Services för den berörda tjänsten.
• Test connection har inte förväxlats med ett fullständigt SSO-test.
• Live Users visar användare, IP och förväntad Client Type.
• Status, huvudgrupp, övriga grupper, undantag och User ID har kontrollerats.
• Access Time, kvoter, Sign-in Restriction och MFA har endast utvärderats på den effektiva användarvägen.
• Lyckad autentisering och det efterföljande brandväggs-, webb- eller VPN-flödet har testats separat.
• Log Viewer och matchande loggfil har korrelerats för samma tidsfönster.
• I HA har den behandlande noden kontrollerats.
• Ingen bred omstart, purge eller bred tillåtelse har använts som snabb lösning.
• Supportdata har säkrats före ytterligare ändringar.

Vanliga frågor