Authenticatiefouten op Sophos Firewall systematisch oplossen

Een authenticatiefout op Sophos Firewall kan op heel verschillende punten ontstaan. De server kan bereikbaar zijn, maar niet voor de betreffende service zijn geselecteerd. De aanmelding kan slagen terwijl de hoofdgroep, een quota of een firewallregel de toegang verhindert. Of de firewall ziet de gebruiker helemaal niet en verwerkt het verkeer alleen op basis van het IP-adres.

De veilige korte route scheidt deze lagen bewust:

1. Noteer de gebruiker, het bron-IP, de betrokken service, het tijdstip en het verwachte resultaat.
2. Test de bereikbaarheid van de portal of authenticatieservice vanuit de werkelijke bronzone.
3. Controleer onder Authentication > Services of de juiste server voor de betrokken service is geselecteerd en op de bedoelde positie staat.
4. Voer Test connection uit op de authenticatieserver, maar beschouw dit alleen als bewijs van geldige referenties en serverconnectiviteit.
5. Genereer een nieuwe aanmelding en controleer onder Current activities > Live users de gebruiker, het bron-IP en Client Type.
6. Controleer onder Authentication > Users de status, hoofdgroep, overige groepen, gebruikersoverrides en User ID.
7. Controleer Access Time, quota, MFA en Sign-in Restrictions alleen voor de daadwerkelijk betrokken gebruiker of diens effectieve groep.
8. Test pas na een geslaagde identiteitscontrole met echt verkeer de verwachte firewallregel, Rule ID, web- of VPN-policy, NAT en routing.

⚠️ Wijzig authenticatieservers, groepsvolgorde, quota of Device Access niet breed op basis van een vermoeden. Een servicerestart, Purge AD users of een Any-regel is geen normale eerste diagnosestap. Bepaal eerst op welke laag het proces stopt.

Vijf lagen in plaats van één aanmeldfout

In de praktijk helpt een eenvoudig model. Gebruikerstoegang doorloopt niet één controle, maar ten minste vijf afzonderlijke lagen:

1. Bereikbaarheid: client en firewall bereiken de portal, proxy of authenticatieserver via het bedoelde pad.
2. Service en methode: de juiste authenticatieserver is onder Authentication > Services voor precies deze service geselecteerd.
3. Identiteit: de firewall herkent de verwachte gebruiker en toont die met het juiste bron-IP en het passende Client Type.
4. Autorisatie: gebruikersstatus, groep, hoofdgroep, Access Time, quota, MFA en servicespecifieke rechten kloppen.
5. Vervolgverkeer: een firewallregel, webpolicy of VPN-policy staat de gewenste bestemmingen toe en het retourpad werkt.

Deze scheiding voorkomt twee veelvoorkomende verkeerde conclusies. Een groene Test connection bewijst niet dat SSO-aanmelding werkt. Omgekeerd bewijst een gebruiker onder Live users nog niet dat diens verkeer de bedoelde regel of policy raakt.

Een reproduceerbare testcase vastleggen

Definieer vóór de eerste wijziging één testcase. Veilige documentatiewaarden zijn bijvoorbeeld:

• Gebruiker: auth-pilot@example.com
• Client-IP: 192.0.2.25
• Bronzone: LAN
• Service: Firewall authentication, User portal, VPN portal, SSL VPN of Web admin console
• Testtijd: lokale firewalltijd met datum en minuut
• Verwachte groep: Internet-Standard
• Verwachte regel: LAN-Users-to-WAN
• Verwacht resultaat: geslaagde aanmelding en HTTPS-toegang tot een vastgelegde testbestemming

example.com en 192.0.2.0/24 zijn documentatiewaarden. Vervang gebruikersnaam, bron-IP, zone, groep, regel en bestemming door echte pilotwaarden. De pilot moet dezelfde authenticatiebron en rechtengroep gebruiken als de betrokken gebruiker, maar geen onnodige beheerdersrechten hebben.

Test indien mogelijk ook een werkende vergelijkingsgebruiker uit dezelfde bron. Als beide mislukken, ligt de oorzaak waarschijnlijker bij de service, server of bereikbaarheid. Als slechts één gebruiker mislukt, zijn het gebruikersobject, groepen, quota, MFA of Sign-in Restrictions waarschijnlijker.

Service, bereikbaarheid en server controleren

Device Access alleen voor de benodigde service controleren

Portalen en lokale authenticatieservices worden niet met normale firewallregels toegestaan. Onder Administration > Device access, of met een gerichte Local service ACL exception rule, moet de benodigde service bereikbaar zijn vanuit de bedoelde bronzone of bekende bronnetwerken.

Afhankelijk van de test kunnen verschillende vermeldingen relevant zijn, zoals Captive portal, User portal, VPN portal, SSL VPN, AD SSO of Client Authentication. Controleer alleen de werkelijk benodigde service. Een brede vrijgave voor LAN of WAN zou de fout verhullen en kan extra beheer- of portalservices blootstellen. Device Access en Local Service ACL op Sophos Firewall legt de veilige afbakening uit.

Bereikbaarheid alleen is nog geen authenticatie. Een zichtbare portalpagina bevestigt alleen dat de client de lokale service bereikt. Gebruikersnaam, wachtwoord, SSO-token, groep en de latere firewallregel zijn daarmee nog niet getest.

De authenticatiemethode per service controleren

Onder Authentication > Services heeft elke service een eigen serverselectie. Controleer daarom niet alleen of er een AD-, LDAP-, RADIUS- of Entra-server bestaat, maar ook of die voor de betrokken service is geselecteerd:

• Firewall authentication methods voor gebruikersverkeer en klassieke firewallauthenticatie;
• User portal authentication methods voor de User Portal;
• VPN portal authentication methods voor de VPN Portal;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods voor deze VPN-aanmeldingen;
• Administrator authentication methods voor beheerders met een eigen account;
• SSL VPN authentication methods voor SSL VPN.

Bij meerdere servers is ook de volgorde belangrijk. Verplaats een server niet voortijdig naar boven. Documenteer eerst de huidige volgorde, Default Group en werkende vergelijkingsgebruiker. Een wijziging kan anders andere gebruikers of services raken. Voor externe beheerders scheidt TACACS+ voor Sophos Firewall WebAdmin bovendien serverauthenticatie, het lokale beheerdersprofiel en een fallback die uitval voorkomt.

Test connection juist interpreteren

Onder Authentication > Servers controleert Test connection de referenties en de verbinding tussen firewall en server. Corrigeer bij een fout eerst DNS, routing, poort, verbindingsbeveiliging, certificaatketen, serviceaccount of wachtwoord.

Een geslaagde test is echter alleen de eerste laag. Bij AD SSO controleert deze noch Kerberos, NTLM, SPN, Redirection Location, browservertrouwen noch de werkelijke gebruikerstoegang. Ook bij portal- en VPN-aanmeldingen moeten serviceselectie, groep, MFA en policy afzonderlijk worden getest. Active Directory verbinden met Sophos Firewall beschrijft de volledige AD-basisconfiguratie.

Live Users als eerste identiteitsbewijs gebruiken

Open na een nieuwe aanmelding Current activities > Live users. Minstens drie waarden zijn belangrijk:

Voor de Client Authentication Agent moet het clienttype Authentication agent zijn. Controleer daarnaast afzonderlijk het pad naar 1.2.3.4:9922, de Authentication Server CA en de daadwerkelijke match met de firewallregel.

• User: is de gedetecteerde gebruiker werkelijk het pilotaccount?
• IP address: komt het adres overeen met de waargenomen clientverbinding?
• Client Type: is het verwachte pad gebruikt, bijvoorbeeld AD SSO Kerberos, AD SSO NTLM, STAS, Multi-host client, Captive portal, RADIUS SSO of een VPN-type?

Als de gebruiker ontbreekt, is de identiteitslaag nog niet geslaagd. Zoek dan niet verder bij de latere gebruikersregel. Verschijnt een computernaam in plaats van de aangemelde gebruiker, dan kan een besturingssysteemservice zoals Windows Update de NTLM-referenties van het apparaat hebben verzonden. Met een echte interactieve gebruikersaanmelding en een nieuw webverzoek is dit geval af te bakenen.

Een externe AD-, LDAP- of RADIUS-gebruiker verschijnt normaal pas onder Authentication > Users na de eerste geslaagde aanmelding bij een firewallservice. Een ontbrekend lokaal gebruikersrecord bewijst daarom niet dat het account in de directory ontbreekt. Voor een rechtstreeks op SFOS beheerd account beschrijft normale lokale gebruikers maken en beheren daarentegen de volledige workflow voor account, service, tests en offboarding.

Voor een schone herhalingstest kan een bestaande normale sessie onder Live users worden verbroken. Na het handmatig verbreken van een AD SSO-sessie kan het tot drie minuten duren voordat de gebruiker opnieuw kan aanmelden. Clientless Users worden daar niet met Disconnect afgemeld; zet ze onder Authentication > Clientless users op Inactive.

Gebruikersobject, hoofdgroep en beperkingen controleren

Zodra de gebruiker zichtbaar is of er al een lokaal record bestaat, gaat de controle verder onder Authentication > Users. Wijzig waarden niet blind, maar documenteer eerst de effectieve eigenschappen:

• status Active of Inactive;
• veld Group als hoofdgroep voor AD-gebruikers;
• Other group memberships;
• gebruikersspecifieke policy-overrides;
• Access Time en Sign-in Restriction;
• Surfing Quota en Network Traffic Quota;
• MFA-toewijzing voor de betrokken service;
• aanvullende eigenschap User ID.

Hoofdgroep en overige groepen niet gelijkstellen

Een AD-gebruiker kan lid zijn van meerdere groepen. Sophos Firewall toont de effectieve hoofdgroep in het veld Group en andere lidmaatschappen afzonderlijk. Firewallregels, webpolicies en sommige andere functies kunnen meerdere groepen meenemen. Access Time, quota, MFA en verschillende functies voor externe toegang gebruiken daarentegen alleen de hoofdgroep of een expliciete gebruikerstoewijzing.

Wijzig de groepsvolgorde daarom niet als snelle oplossing. Bepaal eerst welke functie faalt en welke groepslogica deze ondersteunt. Authenticeer de gebruiker na een geplande wijziging opnieuw en controleer de hoofdgroep nogmaals.

De volledige beheerprocedure, van het maken van groepen en de Default Group tot Reorder, meerdere groepen, gebruikersoverrides en terugdraaiing, staat in Sophos Firewall-gebruikersgroepen en de hoofdgroep correct beheren.

Access Time, quota en MFA als afzonderlijke oorzaken behandelen

Een onverwachte Captive Portal of geweigerde aanmelding kan ook worden veroorzaakt door een geblokkeerde Access Time, een opgebruikte Surfing Quota of Network Traffic Quota of ontbrekende MFA-registratie. Vergelijk deze instellingen bij de gebruiker en de effectieve groep.

De bijbehorende controles en herstelpaden staan in Access Time voor gebruikers en groepen, Surfing en Network Traffic Quota en MFA voor Sophos Firewall. Reset geen quota en verruim geen Access Time-policy voordat de effectieve toewijzing is aangetoond.

De User ID-limiet alleen na een zichtbare waarde toewijzen

Onder Show additional properties kan de User ID worden weergegeven. Een waarde boven 65535 ligt buiten het ondersteunde bereik; de gebruiker kan dan niet authenticeren en geen Live User worden. Alleen het aantal zichtbare gebruikers is onvoldoende voor deze diagnose, omdat groepen hetzelfde ID-bereik delen.

Als de ID geldig is of de gebruiker nog volledig ontbreekt, gaat de algemene diagnose verder. Purge AD users hoort alleen bij een bewezen opschoningsgeval. De veilige specialistische procedure staat in De User ID-limiet van Sophos Firewall controleren.

Gericht doorgaan met de gebruikte methode

Zodra de service en foutlaag bekend zijn, wordt alleen het relevante methodepad verder onderzocht. Zo blijft de diagnose beperkt en worden niet meerdere authenticatiesystemen tegelijk gewijzigd.

Klassieke aanmelding en Captive Portal

Controleer bij een handmatige aanmelding de directe portal-URL, Device Access, geselecteerde authenticatiemethode, gebruikersstatus, wachtwoord en MFA. Controleer bij Captive Portal daarnaast of de onbekende verbinding de bedoelde regel met Use web authentication for unknown users bereikt en of DNS vóór de aanmelding werkt.

De volledige configuratie, inclusief poort 8090, Live Users, de gebruikersregel en afmelding, staat in Sophos Firewall Captive Portal instellen en testen.

AD SSO met Kerberos of NTLM

Een geslaagde AD-verbindingstest is niet voldoende voor SSO. Ook hostnaam of FQDN, DNS-resolutie, Redirection Location, certificaat, browservertrouwen, Domain Join en bij Kerberos de passende HTTP-SPN moeten kloppen. Als Kerberos terugvalt op NTLM of Captive Portal, controleer dan eerst dit naam- en vertrouwenspad.

nasm.log is relevant voor NTLM- en Kerberos-fouten. Wijzig SPN of Domain Join niet blind; leg eerst de bestaande toestand op firewall en domeincontroller vast.

STAS, SATC en multi-user hosts

Bij Synchronized User ID Authentication komen de Windows-domeinidentiteit en het client-IP via Security Heartbeat binnen. Endpointstatus, UPN-domein, sAMAccountName, AD-validatie en Live users moeten dan overeenkomen; alleen een groene heartbeat bewijst de gebruikersregel nog niet.

Bij STAS moet hetzelfde client-IP via Windows-events, STA Agent, Collector en firewall worden gevolgd. Ontbreekt de gebruiker alleen in Live Users, controleer dan de bereikbaarheid van de Collector, bewaakte netwerken, Exclusion List en Client Authentication. De volledige procedure staat in STAS op Sophos Firewall instellen.

Meerdere gelijktijdige gebruikers achter één terminalserver-IP vereisen een sessiemodel. SATC voor Remote Desktop Services kan meerdere protocollen aan een sessie koppelen. Per-Connection AD SSO voor multi-user hosts geldt daarentegen alleen voor HTTP- en HTTPS-verbindingen via de Direct Web Proxy. Een normale IP-gebaseerde koppeling kan meerdere gebruikers achter hetzelfde adres niet betrouwbaar onderscheiden.

RADIUS SSO, Entra ID en VPN

RADIUS SSO vereist accounting-events met het juiste client-IP; een geslaagde RADIUS-toegangstest bewijst dit accountingpad niet. RADIUS SSO met accounting beschrijft de configuratie en controle van Framed-IP-Address.

Controleer bij Microsoft Entra ID SSO daarnaast de servicespecifieke OAuth-flow. Captive Portal, VPN Portal en WebAdmin gebruiken verschillende Redirect URIs, authenticatiemethoden en logbestanden. Een geslaagde aanmelding bij één van deze services bewijst de andere niet.

Controleer bij VPN na de authenticatie bovendien of de gebruiker of diens groep in de juiste remote-access-policy staat. Een groene tunnelstatus bewijst nog geen toegang tot interne bestemmingen.

Authenticatie slaagt, maar verkeer blijft geblokkeerd

Zodra de gebruiker onder Live users met het verwachte IP zichtbaar is, verschuift de diagnose naar autorisatie en het pakketpad. Een echte testflow moet aantonen:

1. Welke Firewall Rule ID verwerkt de verbinding?
2. Bevat deze regel de verwachte gebruiker of een ondersteunde groep?
3. Is Log firewall traffic ingeschakeld?
4. Selecteert de regel de juiste web-, Application-, IPS- of Traffic Shaping-policy?
5. Kloppen bestemming, service, NAT, route en retourpad?

Een algemene IP-regel boven de gebruikersregel kan het verkeer al verwerken. Ook kan de juiste gebruikersregel matchen terwijl webpolicy, TLS Inspection, DNS, routing of het doelsysteem de latere toegang blokkeert. Gebruik een authenticatiewijziging daarom niet als oplossing voor een aangetoonde routing- of policyfout.

Een Sophos Firewall-regel correct testen legt de volledige controle met Log Viewer, Policy tester en Packet Capture uit.

Log Viewer en logbestanden correleren

Controleer in Log viewer de module Authentication met de genoteerde gebruiker, het bron-IP en een nauw testinterval. Zoek daarna hetzelfde tijdstip in de firewall- of VPN-module. Zo wordt zichtbaar of de aanmelding zelf al mislukt of pas de daaropvolgende gegevensstroom wordt geblokkeerd.

Voor klassieke authenticatie, autorisatie en accounting is access_server.log het eerste te controleren bestand. In de Advanced Shell zijn de volgende opdrachten alleen-lezen:

cd /log
tail -n 200 access_server.log

Voeg alleen het bestand toe dat bij de methode hoort:

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 hoort bij NTLM en Kerberos.
• oauth_sso_captive.log hoort bij de Entra SSO-flow van Captive Portal.
• oauth_sso_webadmin.log hoort bij Entra SSO voor WebAdmin.
• oauth_sso_vpn.log hoort bij Entra SSO voor VPN Portal, IPsec en SSL VPN.

De opdrachten lezen alleen de laatste 200 regels. Ze activeren geen debug en starten geen service opnieuw. Voeg bestanden zoals vpnportal.log, sslvpn.log, strongswan.log, chromebook-sso-backend.log of csd.log pas toe nadat de methode is gekozen. Sophos Firewall-servicelogs legt de toewijzing uit.

In een HA-cluster bewaart elk knooppunt alleen logs en rapporten voor verkeer dat het zelf verwerkt. Noteer daarom de rol, testtijd en het verwerkende knooppunt en controleer de bestanden op dat knooppunt. Een leeg bestand op het andere apparaat weerlegt de fout niet.

Fouten per symptoom afbakenen

Test connection slaagt, maar SSO werkt niet

De authenticatieserver en de bijbehorende referenties zijn bereikbaar. Controleer vervolgens Authentication > Services, Device Access, Live Users en het servicespecifieke SSO-pad. Bij AD gaat het vooral om DNS, FQDN, Redirection Location, SPN, browservertrouwen, Domain Join en nasm.log.

Captive Portal verschijnt in plaats van transparante aanmelding

Bepaal eerst of AD SSO of STAS de gebruiker vóór webtoegang hoort te herkennen. Controleer daarna Client Type onder Live Users, de module Authentication, Access Time, quota en referenties. De portal is een symptoom van een ontbrekende of afgewezen identiteit en niet automatisch een portalfout.

Computernaam verschijnt in plaats van gebruikersnaam

Een systeemservice kan de NTLM-referenties van het endpoint verzenden terwijl nog geen gebruiker interactief is aangemeld. Meld een echte gebruiker aan, open een nieuwe browsersessie en herhaal de test. Blijft de computernaam staan, controleer dan browser- of proxypad, SSO-methode en nasm.log.

Gebruiker ontbreekt in Live Users

Controleer eerst de serviceselectie, Device Access en de concrete methode. Bij STAS moeten Collector en firewall hetzelfde IP zien; bij Captive Portal moet de aanmelding echt zijn voltooid; bij externe servers wordt het lokale gebruikersrecord pas na een geslaagde aanmelding gemaakt. Controleer User ID, Sign-in Restriction en quota alleen wanneer een passend gebruikersrecord bestaat.

Gebruiker is zichtbaar, maar groep of policy is verkeerd

Vergelijk onder Authentication > Users de hoofdgroep, Other group memberships en gebruikersoverrides. Controleer daarna of de concrete functie meerdere groepen ondersteunt. Wijzig de groepsvolgorde alleen in een gepland onderhoudsvenster, omdat daarmee ook MFA, quota, Access Time, VPN en andere policies kunnen verschuiven.

Aanmelding slaagt, maar internet of de VPN-bestemming blijft onbereikbaar

Authenticatie is niet langer de eerste foutlaag. Controleer Firewall Rule ID, regelvolgorde, logging, web- of VPN-policy, NAT, route en retourpad met een echte flow. Zowel gebruikersidentiteit als pakketpad moet kloppen.

Fout treedt alleen na HA-failover of sporadisch op

Noteer firmwarebuild, rolwissel, actieve knooppuntrol, aanmeldtijd en authenticatiemethode. Test na de failover een nieuwe aanmelding en een nieuwe verbinding. Controleer vervolgens de logs op het knooppunt dat de poging verwerkte. Beschouw een bestaande sessie niet als bewijs van een nieuwe geslaagde authenticatie.

Stopvoorwaarden en supportgegevens

Wijzig de productieconfiguratie niet verder wanneer:

• de betrokken service of authenticatiemethode niet eenduidig is;
• Test connection mislukt en DNS, route, poort, TLS of referenties nog onduidelijk zijn;
• de pilotgebruiker verschijnt met een onverwacht Client Type of verkeerd bron-IP;
• hoofdgroep, gebruikersoverride of quota niet verklaarbaar kan worden toegewezen;
• een negatieve test onverwacht toegang krijgt;
• alleen een brede Device Access- of firewallvrijgave de test schijnbaar laat slagen;
• een HA-probleem niet aan een verwerkend knooppunt en tijdstip kan worden gekoppeld.

Leg vóór escalatie minstens vast:

• appliancemodel, SFOS-versie en volledige build;
• bij HA beide rollen en het verwerkende knooppunt;
• authenticatiebron en betrokken service;
• testgebruiker, bron-IP, Client Type en tijdvenster;
• servervolgorde onder Authentication > Services;
• resultaat van Test connection met de beperkte betekenis ervan;
• status, hoofdgroep, overige groepen, overrides en User ID;
• authenticatie-event, Firewall Rule ID en resultaat van de echte testflow;
• passende authenticatie-, portal-, VPN- en firewalllogs.

Gebruikersnamen en groepen kunnen gevoelige informatie bevatten. Verstrek het pakket alleen via het bedoelde supportkanaal. Maak vóór servicerestarts, debug of gegevensopschoning een Consolidated Troubleshooting Report en gerichte logexport.

Checklist

• De testcase bevat gebruiker, bron-IP, service, tijdstip en verwacht resultaat.
• De lokale service is alleen bereikbaar vanuit de bedoelde zone of bron.
• De juiste server is onder Authentication > Services geselecteerd voor de betrokken service.
• Test connection is niet verward met een volledige SSO-test.
• Live Users toont gebruiker, IP en verwacht Client Type.
• Status, hoofdgroep, overige groepen, overrides en User ID zijn gecontroleerd.
• Access Time, quota, Sign-in Restriction en MFA zijn alleen op het effectieve gebruikerspad beoordeeld.
• Authenticatiesucces en de daaropvolgende firewall-, web- of VPN-flow zijn afzonderlijk getest.
• Log Viewer en het passende logbestand zijn voor hetzelfde tijdvenster gecorreleerd.
• In HA is het verwerkende knooppunt gecontroleerd.
• Er is geen brede restart, purge of vrijgave als snelle oplossing gebruikt.
• Supportgegevens zijn vóór verdere wijzigingen vastgelegd.

Veelgestelde vragen