Risolvere sistematicamente gli errori di autenticazione su Sophos Firewall

Un errore di autenticazione su Sophos Firewall può verificarsi in punti molto diversi. Il server può essere raggiungibile, ma non selezionato per il servizio interessato. L’accesso può riuscire mentre il gruppo principale, una quota o una regola firewall impedisce l’utilizzo. Oppure il firewall potrebbe non rilevare affatto l’utente e trattare il traffico soltanto in base all’indirizzo IP.

Il percorso rapido e sicuro separa deliberatamente questi livelli:

1. Annotare utente, IP sorgente, servizio interessato, ora e risultato atteso.
2. Verificare la raggiungibilità del portale o del servizio di autenticazione dalla zona sorgente reale.
3. In Authentication > Services, controllare che il server corretto sia selezionato per il servizio interessato e si trovi nella posizione prevista.
4. Eseguire Test connection sul server di autenticazione, ma considerarlo soltanto una prova delle credenziali e della connettività al server.
5. Generare un nuovo accesso e controllare utente, IP sorgente e Client Type in Current activities > Live users.
6. In Authentication > Users, controllare stato, gruppo principale, altri gruppi, override dell’utente e User ID.
7. Controllare Access Time, quote, MFA e Sign-in Restrictions soltanto per l’utente realmente interessato o per il suo gruppo effettivo.
8. Solo dopo aver verificato l’identità, testare con traffico reale la regola firewall attesa, la Rule ID, la policy web o VPN, il NAT e il routing.

⚠️ Non modificare in modo esteso server di autenticazione, ordine dei gruppi, quote o Device Access sulla base di un sospetto. Il riavvio di un servizio, Purge AD users o una regola Any non sono normali primi passi diagnostici. Occorre prima dimostrare a quale livello si interrompe il processo.

Cinque livelli invece di un unico errore di accesso

Nella pratica aiuta un modello semplice. L’accesso di un utente non attraversa un solo controllo, ma almeno cinque livelli distinti:

1. Raggiungibilità: client e firewall raggiungono il portale, il proxy o il server di autenticazione tramite il percorso previsto.
2. Servizio e metodo: il server di autenticazione corretto è selezionato in Authentication > Services per questo specifico servizio.
3. Identità: il firewall riconosce l’utente atteso e lo mostra con l’IP sorgente corretto e il Client Type appropriato.
4. Autorizzazione: stato utente, gruppo, gruppo principale, Access Time, quota, MFA e autorizzazioni specifiche del servizio sono coerenti.
5. Traffico successivo: una regola firewall, una policy web o una policy VPN consente le destinazioni richieste e il percorso di ritorno funziona.

Questa separazione evita due conclusioni errate frequenti. Un Test connection verde non dimostra che l’accesso SSO funzioni. Viceversa, la presenza di un utente in Live users non dimostra ancora che il suo traffico corrisponda alla regola o alla policy prevista.

Definire un caso di test riproducibile

Prima della prima modifica, definire un singolo caso di test. Come valori di documentazione sicuri si possono usare, ad esempio:

• Utente: auth-pilot@example.com
• IP client: 192.0.2.25
• Zona sorgente: LAN
• Servizio: Firewall authentication, User portal, VPN portal, SSL VPN o Web admin console
• Ora del test: ora locale del firewall con data e minuto
• Gruppo atteso: Internet-Standard
• Regola attesa: LAN-Users-to-WAN
• Risultato atteso: accesso riuscito e connessione HTTPS a una destinazione di test definita

example.com e 192.0.2.0/24 sono valori di documentazione. Nome utente, IP sorgente, zona, gruppo, regola e destinazione vanno sostituiti con valori pilota reali. Il pilota dovrebbe usare la stessa origine di autenticazione e lo stesso gruppo di autorizzazioni dell’utente interessato, senza privilegi amministrativi non necessari.

Se possibile, testare anche un utente di confronto funzionante della stessa origine. Se falliscono entrambi, la causa è più probabilmente nel servizio, nel server o nella raggiungibilità. Se fallisce un solo utente, sono più probabili l’oggetto utente, i gruppi, le quote, la MFA o le Sign-in Restrictions.

Verificare servizio, raggiungibilità e server

Controllare Device Access solo per il servizio necessario

I portali e i servizi di autenticazione locali non vengono autorizzati dalle normali regole firewall. In Administration > Device access, oppure tramite una Local service ACL exception rule mirata, il servizio necessario deve essere raggiungibile dalla zona sorgente prevista o dalle reti sorgente note.

A seconda del test possono essere rilevanti voci diverse, ad esempio Captive portal, User portal, VPN portal, SSL VPN, AD SSO o Client Authentication. Controllare soltanto il servizio effettivamente necessario. Un’autorizzazione generale per LAN o WAN nasconderebbe il problema e potrebbe esporre ulteriori servizi di gestione o portali. Device Access e Local Service ACL su Sophos Firewall spiega il confine sicuro.

La sola raggiungibilità non è ancora autenticazione. Una pagina del portale visibile conferma soltanto che il client raggiunge il servizio locale. Nome utente, password, token SSO, gruppo e successiva regola firewall non sono ancora stati verificati.

Controllare il metodo di autenticazione per ogni servizio

In Authentication > Services, ogni servizio dispone di una propria selezione dei server. Non basta quindi controllare che esista un server AD, LDAP, RADIUS o Entra. Occorre verificare che sia selezionato per il servizio interessato:

• Firewall authentication methods per il traffico utente e l’autenticazione firewall classica;
• User portal authentication methods per lo User Portal;
• VPN portal authentication methods per il VPN Portal;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods per questi accessi VPN;
• Administrator authentication methods per gli amministratori nominativi;
• SSL VPN authentication methods per SSL VPN.

Con più server conta anche l’ordine. Non spostare prematuramente un server in cima. Documentare prima l’ordine attuale, il Default Group e l’utente di confronto funzionante. Una modifica potrebbe altrimenti influire su altri utenti o servizi. Per gli amministratori esterni, TACACS+ per WebAdmin di Sophos Firewall separa inoltre l’autenticazione del server, il profilo amministratore locale e un fallback a prova di blocco.

Interpretare correttamente Test connection

In Authentication > Servers, Test connection verifica le credenziali e la connessione tra firewall e server. In caso di errore, correggere prima DNS, routing, porta, sicurezza della connessione, catena di certificati, account di servizio o password.

Un test riuscito rappresenta tuttavia soltanto il primo livello. Per AD SSO non verifica Kerberos, NTLM, SPN, Redirection Location, attendibilità del browser o accesso effettivo dell’utente. Anche per gli accessi al portale e alla VPN, selezione del servizio, gruppo, MFA e policy devono essere testati separatamente. Collegare Active Directory a Sophos Firewall descrive la configurazione AD completa.

Usare Live Users come prima prova dell’identità

Dopo un nuovo accesso, aprire Current activities > Live users. Sono importanti almeno tre valori:

Per il Client Authentication Agent, il tipo di client deve essere Authentication agent. Verificare inoltre separatamente il percorso verso 1.2.3.4:9922, la Authentication Server CA e il match effettivo della regola firewall.

• User: l’utente rilevato corrisponde davvero all’account pilota?
• IP address: l’indirizzo corrisponde alla connessione client osservata?
• Client Type: è stato usato il percorso previsto, ad esempio AD SSO Kerberos, AD SSO NTLM, STAS, Multi-host client, Captive portal, RADIUS SSO o un tipo VPN?

Se l’utente manca, il livello dell’identità non è ancora riuscito. Non proseguire la ricerca sulla successiva regola utente. Se al posto dell’utente connesso compare il nome di un computer, un servizio del sistema operativo come Windows Update potrebbe aver inviato le credenziali NTLM del dispositivo. Un vero accesso interattivo dell’utente e una nuova richiesta web permettono di isolare il caso.

Un utente esterno AD, LDAP o RADIUS compare normalmente in Authentication > Users solo dopo il primo accesso riuscito a un servizio del firewall. L’assenza di un record utente locale non dimostra quindi che l’account manchi nella directory. Per un account gestito direttamente in SFOS, creare e gestire utenti locali normali descrive invece l’intero processo relativo ad account, servizio, test e offboarding.

Per ripetere il test in modo pulito, una normale sessione esistente può essere disconnessa in Live users. Dopo la disconnessione manuale di una sessione AD SSO, possono trascorrere fino a tre minuti prima che l’utente possa accedere di nuovo. I Clientless Users non vengono disconnessi qui con Disconnect; vanno impostati su Inactive in Authentication > Clientless users.

Verificare oggetto utente, gruppo principale e restrizioni

Quando l’utente è visibile o esiste già un record locale, proseguire in Authentication > Users. Non modificare i valori alla cieca. Documentare prima le proprietà effettive:

• stato Active o Inactive;
• campo Group come gruppo principale degli utenti AD;
• Other group memberships;
• override delle policy specifici dell’utente;
• Access Time e Sign-in Restriction;
• Surfing Quota e Network Traffic Quota;
• assegnazione MFA per il servizio interessato;
• proprietà aggiuntiva User ID.

Non considerare equivalenti il gruppo principale e gli altri gruppi

Un utente AD può appartenere a più gruppi. Sophos Firewall mostra il gruppo principale effettivo nel campo Group e le altre appartenenze separatamente. Le regole firewall, le policy web e alcune altre funzioni possono considerare più gruppi. Access Time, quote, MFA e diverse funzioni di accesso remoto utilizzano invece soltanto il gruppo principale o un’assegnazione esplicita all’utente.

L’ordine dei gruppi non va quindi modificato come soluzione rapida. Prima bisogna stabilire quale funzione non riesce e quale logica dei gruppi supporta. Dopo una modifica pianificata, autenticare nuovamente l’utente e ricontrollare il gruppo principale.

La procedura operativa completa, dalla creazione dei gruppi e dal Default Group fino a Reorder, gruppi multipli, override degli utenti e ripristino, è descritta in Gestire correttamente i gruppi utenti e il gruppo principale su Sophos Firewall.

Trattare Access Time, quote e MFA come cause separate

Un Captive Portal inatteso o un accesso rifiutato può anche dipendere da un Access Time bloccato, da una Surfing Quota o Network Traffic Quota esaurita o da una registrazione MFA mancante. Confrontare queste impostazioni sull’utente e sul suo gruppo effettivo.

I rispettivi controlli e percorsi di ripristino sono descritti in Access Time per utenti e gruppi, Surfing e Network Traffic Quota e MFA per Sophos Firewall. Non reimpostare una quota o ampliare una policy Access Time prima di averne dimostrato l’assegnazione effettiva.

Attribuire il limite User ID solo dopo aver visto il valore

In Show additional properties è possibile visualizzare lo User ID. Un valore superiore a 65535 è fuori dall’intervallo supportato; l’utente non può quindi autenticarsi né diventare un Live User. Il numero di utenti visibili da solo non basta per questa diagnosi, perché i gruppi condividono lo stesso intervallo di ID.

Se l’ID è valido o l’utente è ancora completamente assente, continuare la diagnosi generale. Purge AD users è riservato a un caso di pulizia dimostrato. La procedura specialistica sicura è disponibile in Verificare il limite User ID di Sophos Firewall.

Approfondire la specifica modalità utilizzata

Quando servizio e livello di errore sono noti, approfondire soltanto il percorso del metodo pertinente. In questo modo la ricerca rimane circoscritta e non modifica più sistemi di autenticazione contemporaneamente.

Accesso classico e Captive Portal

Per un accesso manuale, controllare l’URL diretto del portale, Device Access, il metodo di autenticazione selezionato, lo stato utente, la password e la MFA. Per il Captive Portal, controllare anche se la connessione sconosciuta raggiunge la regola prevista con Use web authentication for unknown users e se il DNS funziona prima dell’accesso.

La configurazione completa, inclusi porta 8090, Live Users, regola utente e disconnessione, è descritta in Configurare e testare il Captive Portal di Sophos Firewall.

AD SSO con Kerberos o NTLM

Un test di connessione AD riuscito non è sufficiente per SSO. Devono essere corretti anche nome host o FQDN, risoluzione DNS, Redirection Location, certificato, attendibilità del browser, Domain Join e, per Kerberos, lo SPN HTTP corrispondente. Se Kerberos ripiega su NTLM o Captive Portal, controllare prima questo percorso di nomi e attendibilità.

nasm.log è rilevante per gli errori NTLM e Kerberos. Non modificare alla cieca SPN o Domain Join; acquisire prima lo stato esistente sul firewall e sul domain controller.

STAS, SATC e host multiutente

Con Synchronized User ID Authentication, l’identità di dominio Windows e l’IP client arrivano tramite Security Heartbeat. Stato dell’endpoint, dominio UPN, sAMAccountName, convalida AD e Live users devono quindi corrispondere; un heartbeat verde da solo non dimostra la regola utente.

Con STAS, lo stesso IP client deve essere seguito negli eventi Windows, nello STA Agent, nel Collector e nel firewall. Se l’utente manca soltanto da Live Users, controllare raggiungibilità del Collector, reti monitorate, Exclusion List e Client Authentication. La procedura completa è disponibile in Configurare STAS su Sophos Firewall.

Più utenti simultanei dietro un singolo IP di terminal server richiedono un modello di sessione. SATC per Remote Desktop Services può associare più protocolli a una sessione. Per-Connection AD SSO per host multiutente, invece, si applica soltanto alle connessioni HTTP e HTTPS attraverso il Direct Web Proxy. Una normale associazione basata su IP non può distinguere in modo affidabile più utenti dietro lo stesso indirizzo.

RADIUS SSO, Entra ID e VPN

RADIUS SSO richiede eventi di accounting con l’IP client corretto; un test di accesso RADIUS riuscito non dimostra questo percorso di accounting. RADIUS SSO con accounting descrive configurazione e verifica di Framed-IP-Address.

Con Microsoft Entra ID SSO, controllare inoltre il flusso OAuth specifico del servizio. Captive Portal, VPN Portal e WebAdmin utilizzano Redirect URIs, metodi di autenticazione e file di log diversi. Un accesso riuscito a uno di questi servizi non dimostra gli altri.

Per la VPN, dopo l’autenticazione verificare anche che l’utente o il suo gruppo sia incluso nella policy di accesso remoto corretta. Uno stato del tunnel verde non dimostra ancora l’accesso alle destinazioni interne.

Autenticazione riuscita, ma traffico ancora bloccato

Quando l’utente è visibile in Live users con l’IP atteso, spostare la diagnosi sull’autorizzazione e sul percorso dei pacchetti. Un flusso di test reale deve mostrare:

1. Quale Firewall Rule ID elabora la connessione?
2. La regola contiene l’utente atteso o un gruppo supportato?
3. Log firewall traffic è attivo?
4. La regola seleziona la corretta policy web, Application, IPS o Traffic Shaping?
5. Destinazione, servizio, NAT, route e percorso di ritorno corrispondono?

Una regola IP generale sopra la regola utente può aver già elaborato il traffico. Allo stesso modo, la regola utente corretta può corrispondere mentre la policy web, TLS Inspection, il DNS, il routing o il sistema di destinazione bloccano l’accesso successivo. Una modifica dell’autenticazione non va quindi usata come correzione di un errore di routing o di policy dimostrato.

Testare correttamente una regola Sophos Firewall spiega la verifica completa con Log Viewer, Policy tester e Packet Capture.

Correlare Log Viewer e file di log

In Log viewer, controllare il modulo Authentication usando l’utente annotato, l’IP sorgente e un intervallo di test ristretto. Cercare quindi lo stesso momento nel modulo firewall o VPN. In questo modo si distingue se fallisce già l’accesso o se viene bloccato soltanto il successivo flusso di dati.

Per autenticazione, autorizzazione e accounting classici, access_server.log è il primo file da controllare. Nell’Advanced Shell, i comandi seguenti sono di sola lettura:

cd /log
tail -n 200 access_server.log

Aggiungere soltanto il file pertinente al metodo:

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 riguarda NTLM e Kerberos.
• oauth_sso_captive.log riguarda il flusso Entra SSO del Captive Portal.
• oauth_sso_webadmin.log riguarda Entra SSO per WebAdmin.
• oauth_sso_vpn.log riguarda Entra SSO per VPN Portal, IPsec e SSL VPN.

I comandi leggono soltanto le ultime 200 righe. Non attivano il debug e non riavviano alcun servizio. Aggiungere file come vpnportal.log, sslvpn.log, strongswan.log, chromebook-sso-backend.log o csd.log soltanto dopo aver scelto il metodo. Log dei servizi Sophos Firewall ne spiega l’associazione.

In un cluster HA, ogni nodo conserva log e report soltanto per il traffico elaborato da quel nodo. Annotare ruolo, ora del test e nodo di elaborazione, quindi controllare i file su quel nodo. Un file vuoto sull’altro dispositivo non smentisce il problema.

Circoscrivere l’errore in base al sintomo

Test connection riesce, ma SSO non funziona

Il server di autenticazione e le relative credenziali sono raggiungibili. Controllare poi Authentication > Services, Device Access, Live Users e il percorso SSO specifico del metodo. Per AD ciò comprende in particolare DNS, FQDN, Redirection Location, SPN, attendibilità del browser, Domain Join e nasm.log.

Compare Captive Portal invece dell’accesso trasparente

Stabilire prima se AD SSO o STAS dovrebbe identificare l’utente prima dell’accesso web. Controllare quindi Client Type in Live Users, il modulo Authentication, Access Time, quote e credenziali. Il portale è il sintomo di un’identità mancante o rifiutata, non automaticamente un errore del portale.

Compare il nome del computer invece del nome utente

Un servizio di sistema può inviare le credenziali NTLM dell’endpoint anche se nessun utente ha ancora eseguito un accesso interattivo. Accedere con un utente reale, aprire una nuova sessione del browser e ripetere il test. Se il nome del computer rimane, controllare il percorso browser o proxy, il metodo SSO e nasm.log.

L’utente non compare in Live Users

Controllare prima la selezione del servizio, Device Access e il metodo concreto. Per STAS, Collector e firewall devono vedere lo stesso IP; per Captive Portal, l’accesso deve essere completato realmente; per i server esterni, il record utente locale viene creato soltanto dopo un accesso riuscito. Controllare User ID, Sign-in Restriction e quote solo se esiste un record utente corrispondente.

L’utente è visibile, ma il gruppo o la policy è errato

In Authentication > Users, confrontare gruppo principale, Other group memberships e override dell’utente. Verificare quindi se la funzione specifica supporta più gruppi. Modificare l’ordine dei gruppi soltanto in una finestra di manutenzione pianificata, perché la modifica può spostare anche MFA, quote, Access Time, VPN e altre policy.

L’accesso riesce, ma Internet o la destinazione VPN resta irraggiungibile

L’autenticazione non è più il primo livello di errore. Controllare Firewall Rule ID, ordine delle regole, logging, policy web o VPN, NAT, route e percorso di ritorno con un flusso reale. Devono essere corretti sia l’identità dell’utente sia il percorso dei pacchetti.

L’errore si verifica solo dopo un failover HA o in modo sporadico

Annotare build del firmware, cambio di ruolo, ruolo attivo del nodo, ora di accesso e metodo di autenticazione. Testare un nuovo accesso e una nuova connessione dopo il failover. Controllare quindi i log sul nodo che ha elaborato il tentativo. Non considerare una sessione esistente come prova di una nuova autenticazione riuscita.

Condizioni di arresto e dati per il supporto

Non apportare altre modifiche alla configurazione di produzione quando:

• il servizio o il metodo di autenticazione interessato non è univoco;
• Test connection fallisce mentre DNS, route, porta, TLS o credenziali restano irrisolti;
• l’utente pilota compare con un Client Type inatteso o un IP sorgente errato;
• non è possibile spiegare l’assegnazione di gruppo principale, override utente o quota;
• un test negativo ottiene inaspettatamente accesso;
• soltanto un’ampia autorizzazione Device Access o firewall sembra far riuscire il test;
• un problema HA non può essere associato a un nodo di elaborazione e a un orario.

Prima dell’escalation, acquisire almeno:

• modello dell’appliance, versione SFOS e build completo;
• in HA, entrambi i ruoli e il nodo di elaborazione;
• origine di autenticazione e servizio interessato;
• utente di test, IP sorgente, Client Type e intervallo temporale;
• ordine dei server in Authentication > Services;
• risultato di Test connection con il suo significato limitato;
• stato, gruppo principale, altri gruppi, override e User ID;
• evento di autenticazione, Firewall Rule ID e risultato del flusso di test reale;
• log corrispondenti di autenticazione, portale, VPN e firewall.

Nomi utente e gruppi possono contenere informazioni sensibili. Fornire il pacchetto soltanto attraverso il canale di supporto previsto. Creare un Consolidated Troubleshooting Report e un’esportazione mirata dei log prima di riavviare servizi, attivare debug o pulire dati.

Checklist

• Il caso di test contiene utente, IP sorgente, servizio, ora e risultato atteso.
• Il servizio locale è raggiungibile soltanto dalla zona o dalla sorgente prevista.
• Il server corretto è selezionato in Authentication > Services per il servizio interessato.
• Test connection non è stato confuso con un test SSO completo.
• Live Users mostra utente, IP e Client Type atteso.
• Stato, gruppo principale, altri gruppi, override e User ID sono stati controllati.
• Access Time, quote, Sign-in Restriction e MFA sono stati valutati soltanto sul percorso utente effettivo.
• Il successo dell’autenticazione e il successivo flusso firewall, web o VPN sono stati testati separatamente.
• Log Viewer e il file di log corrispondente sono stati correlati sullo stesso intervallo.
• In HA è stato controllato il nodo di elaborazione.
• Non sono stati usati come soluzione rapida riavvii generali, purge o autorizzazioni estese.
• I dati per il supporto sono stati acquisiti prima di ulteriori modifiche.

Domande frequenti