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.

Brandväggen stöder totalt högst 20 autentiseringsservrar, och för varje autentiseringsmetod kan också högst 20 servrar väljas. Om en ytterligare server saknas när den läggs till eller i urvalet är det därför inte automatiskt ett anslutningsfel. Kontrollera först totalantalet, urvalet och om varje server fortfarande behövs.

User Portal och VPN Portal kan ärva brandväggens lista med autentiseringsservrar via Set authentication methods same as firewall. SSL VPN kan på motsvarande sätt använda Same as VPN eller Same as firewall. Arvet är praktiskt, men utökar effekten av senare ändringar i serverval eller ordning. Dokumentera därför alltid den faktiskt ärvda listan vid felsökning. Administrator authentication methods gäller dessutom inte för den lokala superadministratören admin; behåll och testa den återställningsvägen separat.

Kontrollera globala sessionsgränser separat: Maximum session timeout avslutar en autentiserad session när den maximala tiden har uppnåtts. SFOS kontrollerar auktorisering var tredje minut; Access Policies, Surfing Quota, Data Transfer Limit och den maximala sessionstiden kan begränsa åtkomsten tidigare. Det globala värdet Simultaneous logins gäller endast användare som skapas efter att värdet har ställts in.

Skilj mellan ändliga API-gränser och Unlimited: Dokumentationen för det äldre XML-API:et för SFOS 22 och SFOS 23 anger för MaximumSessionTimeoutMinutes ett ändligt intervall på 3–1440 minuter och för SimultaneousLogins ett intervall på 1–99 samtidiga inloggningar. Exemplet visar däremot Unlimited/{minutes} och Unlimited/{count}; utöver de numeriska INTEGER-raderna innehåller tabellen separata STRING-rader för Unlimited. Detta dokumenterar ett obegränsat alternativ, men ingen testad omvandling till ett Unlimited-attribut eller någon payload som är färdig att skicka. De snedstrecksseparerade alternativen är inte literalvärden för produktion. Tomma kolumner för standardvärden eller valfria fält innebär varken ett visst beteende när fält utelämnas eller att noll eller ett tomt värde betyder Unlimited. Läs först det faktiskt sparade valet och de effektiva användargränserna; den globala inloggningsgränsen gäller fortfarande endast användare som skapas därefter. Red ut oklarheter i automatiseringen med supporten för den aktuella builden före en skrivoperation i produktion.

I SFOS 22 och SFOS 23 kontrolleras även de metodspecifika värdena under Authentication > Services separat: AD SSO settings (NTLM and Kerberos) och Web client settings (iOS, Android and API) har vardera Inactivity time och Data transfer threshold. Om mindre än den minsta datamängden överförs inom den inställda tiden betraktas användaren som inaktiv; Inactivity time anger efter hur lång tids inaktivitet användaren loggas ut. Vid en oväntad utloggning dokumenterar du först den använda Client Type, båda värdena i motsvarande inställningsblock och den faktiska trafiken under samma tidsperiod. Ändra inte i stället det globala värdet Maximum session timeout eller STAS- och Captive Portal-timers.

NTLM: jämför minuter och byte. Dokumentationen för det äldre API:et för SFOS 22 och SFOS 23 anger standardvärdet 6 minuter och intervallet 6–1440 minuter för NTLMInActivtyTime, samt standardvärdet 1024 byte för NTLMDataTransferThreshold. För tröskelvärdet i byte anger den endast högst tio siffror, inte något fullständigt numeriskt intervall; inget minimi- eller maximivärde härleds ur detta. Stavningen InActivty är hämtad ordagrant från API:et, liksom NTLMChallegeRedirect för challenge-omdirigeringen: ändra inte stavningen till förmodat korrekta nycklar. Dessa dokumentationsvärden är inte avlästa värden från den egna brandväggen och är inget skäl att återställa standardvärden i produktion eller stänga av HTTP challenge redirect on intranet zone.

iOS-webbklient: använd dess eget dokumenterade intervall. Samma dokumentation för det äldre API:et anger standardvärdet 6 minuter och intervallet 6–1440 minuter för iOSWebClientInActivtyTime, samt standardvärdet 1024 byte och intervallet 1–4294967295 byte för iOSWebClientDataTransferThreshold. Minuter är inte sekunder, och byte är inte kilobyte. Även här förblir API-stavningen InActivty oförändrad. iOS-operationen belägger inte identiska nycklar eller numeriska intervall för Android eller API-klienter, även om GUI:t listar dessa klienttyper i det gemensamma inställningsblocket för webbklienter.

För dessa gränser ska du först, utan att göra några ändringar, jämföra det sparade tillståndet under Authentication > Services, den faktiska Client Type, enheterna och – vid ett misslyckat API-försök – begäran och det tillhörande svaret utan hemligheter. Ett avvisat värde bevisar inte att det har sparats; ett dokumenterat standardvärde bevisar inte att det är inställt för närvarande. Kontrollera med en ny pilotinloggning, tidsmässigt korrelerad trafik och de Authentication-loggar som beskrivs nedan om utloggningen stämmer med det faktiskt sparade paret av tids- och bytevärden. Spara de tidigare värdena före en godkänd korrigering och kontrollera en lokal administrativ åtkomst som inte är beroende av den externa autentiseringsväg som undersöks. Kontrollera därefter det sparade tillståndet, pilotinloggningen, Client Type, det negativa testet och regelmatchningen på nytt. Vid oväntad effekt ska du endast återställa de dokumenterade värden som berörs och läsa tillståndet igen, inte använda Reset to default som en generell återställning. Kontrollera begäran, svaret och återställningen separat i den aktuella builden.

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.

Ersätt eDirectory före uppgraderingen: Den inbyggda eDirectory-integrationen hör till SFOS 22. Före en uppgradering till SFOS 23.0 eller senare måste en ersättning som stöds valideras för alla berörda tjänster och den inbyggda eDirectory-konfigurationen tas bort; om den finns kvar misslyckas uppgraderingen. Ta inte bort produktionsautentiseringen innan inloggningar via ersättningen, grupper, policies och en oberoende lokal reservåtkomst har kontrollerats. Migrera eDirectory säkert beskriver den kontrollerade övergången och återställningsvägen.

Tolka VPN-autentiseringslistor via XML API

Vid automatiserade ändringar kontrolleras tjänsteval och serverlista separat. Följande XML-sökvägar gäller autentiseringskällan, inte VPN-protokollens styrka, kryptering eller MFA-konfiguration.

• För SSL VPN finns selektorn under SSLVPNAuthentication/SSLVPNAuthenticationMethods. I SFOS 22 och SFOS 23 stämmer exemplet och parametertabellen överens: SameAsVPN, SameAsFirewall och Custom är de dokumenterade värdena. De två första ärver VPN-autentiseringslistan respektive brandväggens autentiseringslista; Custom innebär ett eget serverval under SSLVPNAuthentication/SSLVPNAuthenticationServerList/AuthenticationServer.
• För övrig VPN-autentisering visar exemplet under VPNAuthentication/VPNAuthenticationMethods däremot SameAsFirewall/Custom, med serverlistan under VPNAuthentication/VPNAuthenticationServerList/AuthenticationServer. Parametertabellen kombinerar dock VPNAuthenticationMethods/UserPortalAuthenticationMethods och tillåter endast de token som skrivs som ''on'' och ''off''. Denna motsägelse finns i båda versionerna. Det går inte att härleda någon verifierad omvandling mellan exempelvärdena och tabellvärdena utifrån detta; inte heller är någon alias- eller selektorkompatibilitet med User Portal belagd. Ändra därför inte en VPN-selektor i produktion automatiskt utifrån denna koppling, utan red ut konflikten för den aktuella builden via supporten.

För båda serverlistorna beskriver tabellen AuthenticationServer som en valfri ARRAY med datatypen STRING och flera möjliga värden. Servernamnen måste stämma med den egna konfigurationen. SSL-VPN-selektorn är markerad som en valfri SCALAR, medan den kombinerade VPN-/User Portal-posten i tabellen är markerad som en obligatorisk SCALAR. Kolumnerna för standardvärden är tomma; detta bekräftar inget beteende för utelämnade eller tomma fält. De snedstrecksseparerade alternativen i exemplet är inte färdiga värden som kan skickas oförändrade.

Spara det aktuella valet, ordningen, den faktiskt ärvda listan och den testade lokala reservåtkomsten före en godkänd ändring. Kontrollera därefter det sparade tillståndet under Authentication > Services, en ny pilotinloggning, Client Type, ett negativt test och den faktiska regelmatchningen. Vid ett oväntat resultat ska du läsa det sparade tillståndet och relevanta loggar, inte skriva på nytt på måfå; återställ vid behov endast den dokumenterade konfiguration som berörs. Kontrollera API-begäran och dess effekt separat.

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:

Kapacitetsgräns: SFOS 22 och SFOS 23 stöder högst 32,000 aktiva användare. Användare och grupper delar User ID-intervallet; för diagnostik är ett synligt ID till och med 65535 giltigt. I mycket stora miljöer kontrolleras denna gräns separat från en enskild misslyckad inloggning. Ta inte bort sessioner eller användarobjekt okontrollerat.

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, Web client, RADIUS SSO eller en VPN-typ?

Tolka typen efter dess källa, inte som en allmän inloggning. Webbläsarbaserade Captive Portal- och gästsessioner visas som Web client, Android web client eller iOS web client. Klientinitierade mappningar omfattar STAS, Thin client, Heartbeat och API; serverinitierad SSO omfattar RADIUS SSO och Chromebook SSO. eDirectory SSO ingår endast i listan för SFOS 22; i SFOS 23 tas det inbyggda stödet för eDirectory SSO bort och denna typ listas inte längre. VPN-poster skiljer mellan IPsec VPN, SSL VPN, L2TP VPN och PPTP VPN. Den observerade typen måste motsvara den avsedda mekanismen.

Clientless Users är undantaget från testet med en ny inloggning: de visas i listan så snart de har konfigurerats eftersom SFOS autentiserar dem via IP-adressen, och de visas inte när de är Inactive.

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 väljer du en befintlig normal session under Live users, klickar på Disconnect, ändrar vid behov aviseringstexten och bekräftar med Disconnect. Efter att en AD SSO-session kopplats från manuellt kan det ta upp till tre minuter innan användaren kan logga in igen. Aviseringen når endast användare som är inloggade med Authentication agent, Android client, iOS client eller Chromebook SSO.

Clientless Users loggas inte ut med Disconnect. Sätt i stället den specifika användaren till Inactive under Authentication > Clientless users. Om Disconnect redan har använts för en Clientless User och åtkomsten måste återställas, ändrar du användarens status till Inactive och sedan till Active.

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.

Om endast MFA misslyckas kontrolleras Issued tokens, tokenstatus samt tiden på brandväggen och telefonen. Med Synchronize token time offset går det att upptäcka och korrigera tidsdrift. SFOS 22 stöder SHA1, SHA256 och SHA512; autentiseringsappen måste stödja den konfigurerade algoritmen. Att byta algoritm eller ta bort en token är inte ett diagnostiktest, utan en planerad migrering eller ny registrering.

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. Användarnamn och lösenord får innehålla högst 50 tecken vardera.

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.

Om /log/nasm.log visar ett KVNO-fel kan klienten fortfarande ha en Kerberos-ticket med den gamla nyckelversionen efter att brandväggen anslutit till domänen på nytt. Lås och lås först upp Windows-klienten, eller logga ut och in användaren, så att en ny ticket hämtas. Om felet kvarstår kontrolleras Key Version Number, brandväggens datorobjekt och SPN på domänkontrollanten; ännu en Domain Join är inte det första steget.

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.

Legacy SATC Client stöds inte längre. Sophos rekommenderar att SATC-installationer migreras till Sophos Server Protection i Sophos Fusion. Fastställ före felsökningen vilken SATC-klient som faktiskt är installerad; ändringar av brandväggsregler eller grupper reparerar inte en föråldrad legacy-klient.

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. VPN Portal stöder inte RADIUS-autentisering med challenge-baserad MFA, så ett avvisat challenge-flöde där är inte ett fel i serverordningen.

API-validering före felsökning av accounting-nätverket: Dokumentationen för det äldre XML-API:et för SFOS 22 och SFOS 23 begränsar SharedSecret till 50 tecken. En längre genererad delad hemlighet kan därför förklara en avvisad konfiguration, inte ett nätverksfel i accounting-trafiken. ClientIP är där dokumenterat som en ARRAY med flera värden, datatypen IPADDRESS och högst 15 tecken; GUI-fältet är RADIUS client IPv4. Detta är inget bevis på IPv6-stöd. Den kopierade iOS-beskrivningen på RADIUS-API-sidan är ett dokumentationsfel, inte ett uttalande om RADIUS-/iOS-kompatibilitet. Jämför först den faktiska avsändaren med den sparade tillåtna klient-IP-adressen och kontrollera på ett säkert sätt att konfigurationen av den delade hemligheten stämmer överens på båda sidor; visa aldrig verkliga hemligheter och ta inte med dem i loggar, skärmbilder eller supportpaket. Förkorta, försvaga eller rotera inte hemligheter i produktion för diagnostik. Vid ett API-fel ska du läsa det rensade svaret och det faktiskt sparade tillståndet i stället för att skriva på nytt på måfå. Ett nödvändigt byte av autentiseringsuppgifter är en ändring som ska godkännas separat och samordnas på båda sidor, med säkrad lokal administrativ åtkomst och en dokumenterad återställningsväg; kontrollera därefter den sparade konfigurationen, accounting-händelsen, användare/IP under Live users och regelmatchningen.

SFOS 22: 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.

SFOS 23.0: Under Authentication > Servers är servertypen OpenID Connect; IdP vendor skiljer mellan Microsoft Entra ID och Google Workspace. För den faktiskt berörda tjänsten används de versionsspecifika verifieringsflödena för Entra WebAdmin, Entra VPN Portal och fjärråtkomst eller Google Workspace OIDC. Redirect URI, tjänstetilldelning, grupper eller administratörsmappning, MFA samt positiva, negativa och lokala reservåtkomsttester förblir separata kontroller. En lyckad IdP-inloggning ger inte automatiskt administratörsrättigheter.

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.

Metodspecifika kontroller före konfigurationsändringar

AD SSO: tid, DNS och säker felsökning

Jämför klockorna på klienten, brandväggen och domänkontrollanten. Kerberos-biljetter har begränsad giltighet; standardtoleransen är fem minuter, men den konfigurerade domänpolicyn gäller. Kontrollera namnuppslagningen för _ldap._tcp.dc._msdcs.<AD domain> och AD-sökfrågorna. Att läsa kataloggrupper och ansluta brandväggen till domänen kräver olika behörigheter: behåll ett konto med lämpligt delegerade rättigheter för en senare återanslutning efter HA-, uppgraderings- eller serverändringar. Ge inte en vanlig testanvändare Domain Admin-rättigheter.

Felsökningsanvisningarna föreslår tillfälligt Plaintext på port 389, medan AD-konfigurationen stöder STARTTLS på 389 eller SSL/TLS på 636. Stäng inte av krypteringen på en autentiseringsväg i produktion för att isolera ett fel. Kontrollera i stället TLS-kedjan, namnet, porten och AD-serverloggarna; eskalera ett olöst fel med den säkra anslutningen. Granska HTTP challenge redirect on intranet zone under Authentication > Services, i stället för att stänga av inställningen för att kringgå webbläsarens tillit. Felsök omdirigeringsnamnet och intranettilliten med AD-arbetsflödet.

SATC och STAS: skilj registrering från nåbarhet

För SATC ger alternativ 4. Device Console denna skrivskyddade registreringskontroll:

system auth thin-client show

Jämför adresserna i listan med terminalservrarna. Om en server saknas, följ SATC-konfigurationen och återställningsflödet i stället för att ändra registreringen oplanerat. Kontrollera den valda AD-servern, destinationen för SATC-händelser och om proxy- eller säkerhetsprogram ändrar källportar. En portavvikelse kan lämna trafiken oautentiserad även om serveradressen är registrerad.

Kontrollera för STAS att Collector-värden och tjänsten körs, att UDP 6060 och 6677 endast tillåts på nödvändiga vägar, att säkerhetsprogram inte stör och att en Collector med flera nätverkskort är bunden till rätt gränssnitt. Kontrollera SNAT-källan för systemgenererad trafik över IPsec. Medan SFOS väntar på identifiering från Collector kan det kasta bort den okända användarens trafik. En portalfördröjning på två minuter kan vara standardinlärningsperioden på 120 sekunder, inte ett portalfel. Förkorta den inte till under 20 sekunder som snabb lösning. Windows-DCOM-händelser 10009 eller 10028, eller LogonType: 1-mappningar från oövervakade nätverk, kräver kontroll av WMI-nåbarhet och matchande Agent-/Collector-subnätsfilter. Följ STAS-felsökningen och den kontrollerade återställningen; dokumentera tidigare filter och timerinställningar före ändringar och testa en pilotanvändare igen efter en eventuell nödvändig omstart.

Chromebook SSO och SSL VPN

Chromebook SSO är inte samma sak som Google Workspace OIDC. Jämför Domain, Port, Certificate och Logging level under Authentication > Services > Chromebook SSO med de hanterade enheternas inställningar. Certifikatet behöver en privat nyckel, sin tillhörande CA installerad och ett CN som motsvarar det avsedda gatewaynamnet för användarnas nätverk. Fortsätt med Chromebook-SSO-flödet för certifikat, tillägg och regler.

För SSL VPN, jämför användare/grupper i fjärråtkomstpolicyn med Authentication > Multi-factor authentication och kontrollera klientens exakta fel. Sophos Connect-användarnamn måste använda ASCII; kontrollera även sekvenser av specialtecken som inte stöds. SSL-VPN-anvisningarna nämner både Call/Push-MFA och <password><otp>; detta är ingen universell kombinerad procedur. Lägg bara till en OTP för ett konfigurerat lösenord-plus-OTP-flöde, inte som lösning på en misslyckad push eller ett misslyckat samtal. Bekräfta den faktiska MFA-metoden och klient-/serverkompatibiliteten via SSL-VPN-arbetsflödet, utan att stänga av MFA.

Jämför även det förhandlade autentiseringsprotokollet i befintliga L2TP-/PPTP-installationer: lokalt och RADIUS stöder PAP, CHAP eller MSCHAPv2; AD och LDAP använder PAP; TACACS+ stöder PAP eller CHAP. Detta är en kompatibilitetskontroll, inte en rekommendation att använda PPTP eller försvaga krypteringen. Upprepa en ny inloggning, klienttypskontrollen, testet av nekad åtkomst och regelmatchningen efter en godkänd korrigering; återställ den dokumenterade konfigurationen om korrigeringen inte hjälper.

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

Följande tjänstespecifika Entra-läsexempel gäller endast SFOS 22, inte SFOS 23:

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.
• SFOS 22: oauth_sso_captive.log hör till Entra SSO-flödet för Captive Portal.
• SFOS 22: oauth_sso_webadmin.log hör till Entra SSO för WebAdmin.
• SFOS 22: oauth_sso_vpn.log hör till Entra SSO för VPN Portal, IPsec och SSL VPN.

SFOS 23.0: Kontrollera OIDC-inloggningsflödet i /log/oauth_sso_svc.log. För Entra hör ett TLS-fel från Test connection i stället till /log/sfos-macro-cfg.log. Använd Admin för WebAdmin och Authentication för Captive Portal, VPN Portal, IPsec och SSL VPN i Log viewer. Leverantörsflödena som länkas ovan kopplar verifiering och felsökning till den faktiska tjänsten; denna läsande diagnostik kräver ingen omstart.

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 endpointens 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