Configurare l'SSO Microsoft Entra ID per Sophos Firewall Captive Portal

Con Microsoft Entra ID SSO per Captive Portal, Sophos Firewall può autenticare gli utenti rispetto a Microsoft Entra ID tramite browser prima che le regole firewall basate sull’utente diventino effettive. Ciò è particolarmente interessante per le reti BYOD, le zone ospiti o partner, i dispositivi senza rilevamento AD trasparente o gli ambienti in cui STAS non si adatta a tutti i client.

È importante distinguere: il Captive Portal non è un portale VPN e non è un accesso remoto. L’utente è già sulla rete locale o Wi-Fi e accede al browser in modo che il firewall possa assegnare il traffico successivo a un’identità utente. Per l’accesso remoto con Sophos Connect, è adatto l’articolo separato Configurare l’SSO Microsoft Entra ID tramite Sophos Connect e il portale VPN.

Se Microsoft Entra ID SSO è già configurato per VPN Portal o Sophos Connect, non serve automaticamente un nuovo design Entra completo. In molti casi si può riutilizzare lo stesso oggetto server Microsoft Entra ID sul firewall. Captive Portal richiede comunque la Captive portal URL corretta come Redirect URI, l’assegnazione in Authentication > Services e un test separato della regola utente successiva.

Quando Captive Portal con Entra ID SSO ha senso

Captive Portal con Entra ID SSO ha senso se gli utenti accedono comunque con Microsoft 365 e il firewall necessita di un’identità utente per determinate reti.

Applicazioni tipiche:

• Reti BYOD o WiFi senza adesione al dominio.
• Ospiti o utenti esterni con accesso controllato ad alcune destinazioni.
• Regole Internet basate sull’utente senza STAS o SATC.
• Reti in cui l’autenticazione trasparente non è affidabile.
• Scenari di transizione in cui l’autenticazione AD locale dovrebbe essere ridotta.

Per i client Windows completamente gestiti in un dominio classico, Captive Portal non è automaticamente la soluzione migliore. Lì STAS, AD SSO o altre procedure trasparenti possono essere più ergonomiche perché gli utenti non devono attivare attivamente un accesso al browser. Il Captive Portal è più una soluzione di riserva o speciale per i dispositivi non gestiti.

Captive Portal, portale VPN e portale utente separati

Con Entra ID SSO, i termini del portale si confondono rapidamente. La separazione è fondamentale per la configurazione.

• Captive Portal: Gli utenti della rete locale accedono tramite browser affinché vengano applicate le regole basate sull’identità. Entra ID SSO viene utilizzato per il login nel browser e l’associazione dell’utente.
• Portale VPN: Gli utenti con accesso remoto scaricano Sophos Connect o le configurazioni VPN. Entra ID SSO viene utilizzato qui per l’accesso remoto e il login al portale.
• Portale utente: Questo portale contiene funzioni per l’utente, come OTP o opzioni personali meno recenti. A seconda dell’ambiente, può essere ancora rilevante per token o opzioni utente.

Una panoramica generale è disponibile in Portali Sophos: SophosID, Central, Supporto e accesso al firewall. Per Captive Portal occorre innanzitutto verificare da quale zona è raggiungibile il servizio locale del firewall e quale regola firewall elabora poi il traffico utente effettivo. Configurare e testare Captive Portal su Sophos Firewall spiega la configurazione classica senza il percorso specifico Microsoft, da Device Access e DNS fino alla regola utente e a Live users. Entra ID SSO aggiunge poi App Registration, Redirect URI e le verifiche OAuth/OIDC descritte in questo articolo.

Requisiti

Prima di procedere con la configurazione è opportuno chiarire questi punti:

• Sophos Firewall con versione SFOS che supporta Microsoft Entra ID SSO.
• Un tenant Microsoft Entra commerciale. Sophos Firewall non supporta questa integrazione SSO per i tenant Microsoft 365 GCC High.
• Tenant Microsoft Entra con autorizzazione per la registrazione dell’app, URI di reindirizzamento, autorizzazioni API, consenso dell’amministratore e segreto client.
• FQDN e certificato per il captive Portal in modo che gli utenti non visualizzino avvisi non necessari del browser.
• Accessibilità degli endpoint di accesso Microsoft dalla rete client interessata.
• Captive Portal è consentito in Administration > Device access per la zona corretta.
• Gli utenti o i gruppi vengono gestiti correttamente in Microsoft Entra ID.
• Le regole del firewall utilizzano gli utenti o i gruppi previsti.
• Sono disponibili un utente di prova e un accesso fallback.
• L’ora e l’NTP sul firewall e sui client sono corretti perché OAuth/OIDC dipende dal tempo.
• Se Assegnazione richiesta è attiva in Microsoft Entra ID, gli utenti o i gruppi richiesti vengono assegnati all’applicazione aziendale.

⚠️ Captive Portal è un’area di accesso sul firewall. Dovrebbe essere accessibile solo nelle zone in cui è realmente necessario. L’accesso al dispositivo e l’ACL del servizio locale sono controlli di sicurezza qui, non solo impostazioni di connessione.

Per rafforzare i servizi firewall locali, è adatto Protezione dell’accesso a Sophos Firewall: configurare correttamente l’accesso al dispositivo. In questo progetto, l’MFA viene implementato in Microsoft Entra ID, ad esempio tramite accesso condizionale. L’MFA locale di Sophos Firewall non sostituisce il fattore di accesso Microsoft con Entra ID SSO. Questo in genere è migliore dal punto di vista dell’utente perché viene utilizzata la stessa MFA di Microsoft 365, ma deve essere attentamente pianificata e testata nel tenant.

Progettare l’architettura prima della configurazione

Prima della configurazione tecnica, dovresti decidere quale attività Captive Portal deve risolvere in modo specifico. Altrimenti vi ritroverete rapidamente con un login che funziona ma non attiva una regola firewall adeguata.

Domande importanti sulla progettazione:

• Quale zona utilizza Captive Portal?: L’accesso al dispositivo e l’origine della regola dipendono dalla zona.
• Quale gruppo di utenti è autorizzato ad accedere?: Il gruppo Entra deve corrispondere alla regola firewall successiva.
• Quali obiettivi si possono raggiungere dopo aver effettuato l’accesso?: Il captive portale non sostituisce la segmentazione pulita.
• Per quanto tempo devono essere valide le sessioni?: Le sessioni troppo lunghe diluiscono l’allocazione degli utenti, mentre le sessioni troppo brevi interrompono le operazioni.
• Cosa succede in caso di interruzione della Entra o di Internet?: È necessario un chiaro ripiego per i lavori critici.
• Come viene attivato il login?: Gli utenti necessitano di un URL del captive Portal accessibile o di un reindirizzamento pulito.

Il Captive Portal non deve essere utilizzato in sostituzione di VLAN, zone o regole firewall minime. Il firewall conosce meglio l’utente dopo il login, ma l’architettura di rete deve comunque rimanere pulita. Per la logica di base delle zone, è adatto Configurare la zona e l’interfaccia di Sophos Firewall.

Crea il server ID Microsoft Entra

La configurazione è composta da due parti: innanzitutto viene preparata la registrazione dell’app nell’ID Microsoft Entra. Questa app viene quindi registrata come server di autenticazione sul firewall Sophos.

Prepara la registrazione dell’app nell’ID Microsoft Entra

È necessario creare una registrazione dell’app separata per il firewall nell’ID Microsoft Entra. Ciò significa che gli URI di reindirizzamento, le autorizzazioni e i segreti client rimangono nettamente separati dalle altre applicazioni.

Processo tipico:

1. Apri l’interfaccia di amministrazione di Microsoft Entra.
2. Apri Registrazioni app > Nuova registrazione.
3. Assegnare un nome descrittivo, ad esempio Sophos-Firewall-SSO.
4. Di norma, seleziona il tuo tenant come tipo di account supportato.
5. Utilizza la piattaforma Web.
6. Annotare l’ID dell’applicazione (client) e l’ID della directory (tenant).
7. Crea un segreto client in Certificati e segreti e salva immediatamente il valore del segreto in modo sicuro.
8. In API permissions > Microsoft Graph > Delegated permissions, aggiungere User.Read.All e Group.Read.All.
9. Solo se si importano gruppi con l’assistente del firewall, aggiungere anche Group.Read.All in Application permissions.
10. Eseguire Grant admin consent per queste autorizzazioni.
11. In Enterprise applications > [app del firewall] > Properties, impostare preferibilmente Assignment required? su Yes, quindi assegnare soltanto gli utenti o i gruppi autorizzati.

Senza le autorizzazioni API e il consenso amministratore corretti, dopo l’accesso Microsoft il firewall non può elaborare correttamente utenti o gruppi. Se Assignment required? rimane su No, tutti gli utenti del tenant possono tentare l’accesso ai servizi utente del firewall; gruppi, policy e regole del firewall continuano comunque a determinare l’accesso effettivo. L’assegnazione obbligatoria riduce quindi la superficie di login, ma non sostituisce un’autorizzazione restrittiva sul firewall.

Secondo Microsoft, l’assegnazione basata sui gruppi richiede Entra ID P1 o P2 e non include i gruppi annidati. Occorre quindi eseguire il test con un membro diretto del gruppo, non soltanto con un utente di un sottogruppo.

Creare o riutilizzare il server Entra ID su Sophos Firewall

Microsoft documenta separatamente App Registration, Redirect URIs, assegnazioni dell’app e Conditional Access. Consultare queste fonti primarie se nel portale Entra cambiano etichette o prerequisiti del tenant.

Applicare Conditional Access in modo mirato alla Enterprise Application e valutarla prima in modalità Report-only con un utente pilota. Prima dell’attivazione, controllare il risultato con What If e i log di accesso Entra ed escludere gli account di emergenza documentati. Mantenere aperta una sessione amministrativa del firewall e disponibile il metodo di autenticazione precedente finché non sono stati verificati un utente autorizzato, uno rifiutato e l’MFA, evitando così un blocco dovuto a una policy errata.

Il percorso del menu su Sophos Firewall è:

Authentication > Servers

Processo di base:

1. Aprire Add.
2. Selezionare Microsoft Entra ID SSO come Server type.
3. Assegnare un nome descrittivo, ad esempio Entra-SSO-Firewall.
4. Inserire l’Application (client) ID dell’app Entra.
5. Inserire il Directory (tenant) ID.
6. Inserire Client secret.
7. Impostare consapevolmente il Fallback user group e mantenerlo il più restrittivo possibile.
8. Eseguire Test connection.
9. Salva.

Il gruppo di fallback si applica quando il gruppo Entra di un utente non esiste sul firewall. Non deve ricevere un accesso ampio e non è né un accesso di emergenza né un’autenticazione alternativa durante un’interruzione di Entra.

In Redirect URI, impostare il FQDN o l’indirizzo IP di produzione; il firewall genera gli URL dei servizi da copiare senza modifiche in Entra ID. Test connection verifica connettività di rete, Application permissions e validazione del certificato TLS.

⚠️ I client secrets sono dati di accesso produttivi. Data di scadenza, rotazione e responsabilità devono essere documentate. Un secret scaduto spesso sembra un normale problema di accesso dal punto di vista dell’utente, ma in realtà è un problema di configurazione o operativo.

Per una rotazione con interruzioni minime, creare un nuovo secret prima della scadenza, inserire la sua Value sul firewall ed eseguire Test connection seguito da un accesso a Captive Portal. Mantenere valido il secret precedente come ritorno fino al superamento di entrambe le prove e solo allora eliminarlo da Entra ID. Non inserire mai i valori dei secret in screenshot, ticket o esportazioni della configurazione.

Inserisci correttamente gli URI di reindirizzamento

Copiare senza modifiche l’URI di reindirizzamento generato dal firewall nell’App Registration di Microsoft Entra ID. Protocollo, nome host, porta, percorso e persino la barra finale devono coincidere esattamente. Il certificato del portale non fa parte dell’URI, ma deve essere valido per lo stesso nome host e considerato attendibile dai client.

Sophos Firewall visualizza gli URL dei servizi richiesti sul server Entra ID. L’URL del Captive Portal è particolarmente rilevante per questo articolo. Se vengono utilizzati anche WebAdmin o Accesso remoto con Entra ID SSO, questi servizi hanno i propri URL:

• URL della console di amministrazione Web: Entra ID SSO per Console WebAdmin.
• URL del portale captive: Entra ID SSO per Captive Portal nella rete locale.
• Portale VPN e URL di accesso remoto: Entra ID SSO per portale VPN e Sophos Connect.

Se lo stesso server Entra ID è già usato per Remote Access, aggiungere la Captive portal URL alle Redirect URI esistenti nell’app Entra. Captive Portal deve comunque essere testato separatamente, perché percorso di login, Device Access, corrispondenza dei gruppi e regola firewall successiva hanno errori tipici diversi rispetto a Sophos Connect o VPN Portal.

Imposta il metodo di autenticazione del captive Portal

Dopo aver creato il server Entra, il metodo di autenticazione per Captive Portal deve puntare al server corretto.

L’area interessata è sotto:

Authentication > Services

Per verificare:

1. Apri l’area Firewall authentication methods.
2. Aggiungi o trascina il server ID Microsoft Entra nella posizione corretta.
3. Conservare altri server di autenticazione solo se fungono da fallback deliberato.
4. Applicare la modifica con Applica.
5. Eseguire un accesso di prova con un singolo utente.

Sophos Firewall consente un solo server Microsoft Entra ID per metodo di autenticazione. Non è quindi possibile sovrapporre più tenant o app Entra nella stessa lista Firewall authentication methods.

Se sono attivi più metodi di autenticazione in parallelo, deve essere chiaro quale server è responsabile di quale gruppo di utenti. Per lo stesso utente dovrebbe essere utilizzata, se possibile, una sola fonte di autenticazione. Su una versione firmware interessata da NC-167128, il firewall può rifiutare la sessione con no permission se un utente passa da Entra ID SSO all’accesso AD locale e in seguito riutilizza un token Entra precedente. Questo funzionamento misto è più difficile da testare e dovrebbe essere utilizzato e documentato solo consapevolmente.

Verificare inoltre in Authentication > Web authentication come viene aperto Captive Portal nel browser. HTTPS è importante per Entra ID SSO. L’opzione Use insecure HTTP instead of HTTPS non deve essere attivata perché il flusso Entra-OAuth su HTTP non è supportato correttamente e sarebbe inutilmente non sicuro.

Quanto segue è utile per il funzionamento:

1. Apri Captive Portal in una nuova finestra del browser.
2. Mantenere aperta la finestra del Captive Portal durante la sessione.
3. Chiedere agli utenti di disconnettersi consapevolmente tramite il captive Portal se l’associazione deve essere terminata.
4. Dopo l’accesso, controllare in Current activities > Live users se l’utente è visibile.

Le opzioni di disconnessione automatica per inattività o chiusura della scheda del browser non si applicano attualmente a Microsoft Entra ID SSO. Sui dispositivi condivisi, la finestra del portale rimane aperta finché l’utente non esegue esplicitamente il logout; la chiusura di una scheda non è considerata una conclusione affidabile della sessione.

A seconda dell’interfaccia e del certificato, anche l’URL standard https://<Firewall-IP>:8090 può aiutare per il test. Un FQDN pulito con un certificato adeguato è molto più piacevole per il funzionamento produttivo.

Controlla l’accesso al dispositivo e l’accessibilità al portale

Captive Portal è un servizio locale del firewall. Una normale regola del firewall da sola non consente questo accesso. L’accessibilità è controllata in Administration > Device access per la zona interessata.

Dovresti controllare:

• Il Captive Portal è consentito solo nelle zone richieste.
• Ciò significa che non a caso WebAdmin e SSH sono anche ampiamente accessibili.
• Il certificato e il nome di dominio completo corrispondono all’URL dell’utente.
• Il DNS nella rete client risolve correttamente il nome del portale.
• Le regole di eccezione ACL del servizio locale vengono impostate solo quando sono realmente necessarie.

Se Captive Portal non è accessibile da una rete, non è necessario creare prima una normale regola Consenti. La causa è spesso l’accesso al dispositivo, l’ACL del servizio locale, il DNS, il certificato o la mappatura della zona errata.

Considerare l’accesso Microsoft e il filtro web

Il client deve raggiungere le pagine di accesso di Microsoft e le risorse correlate durante l’accesso. Altrimenti, nelle reti restrittive, il flusso SSO può interrompersi in un punto che agli utenti sembra un errore del firewall o del browser.

Per verificare:

• La risoluzione DNS per i domini di accesso Microsoft funziona.
• È consentito HTTPS agli endpoint di accesso Microsoft.
• Il filtro Web, l’ispezione TLS o il proxy non bloccano la pagina di accesso.
• Il tempo trascorso sul firewall e sul client è plausibile.
• I cookie del browser non sono resi inutilizzabili da una politica rigorosa.

Negli ambienti restrittivi, configurare come host FQDN l’elenco completo documentato da Sophos per SFOS 22, invece di ricavarlo da poche richieste osservate:

• *.aadcdn.microsoftonline-p.com
• *.login.live.com
• login.microsoftonline.com
• *.login.microsoftonline.com
• *.logincdn.msftauth.net
• *.microsoftonline-p.com
• *.microsoftonline.com
• *.msauth.net
• aadcdn.msftauth.net
• login.microsoft.com
• account.activedirectory.windowsazure.com
• *.aadcdn.msauthimages.net
• *.aadcdn.msftauthimages.net
• *.aadcdn.msftauth.net
• browser.events.data.msn.com
• ent-nfc-api.msn.com
• img-s-msn-com.akamaized.net
• ntp.msn.com
• edge-consumer-static.azureedge.net
• msedge.b.tlu.dl.delivery.mp.microsoft.com

Creare esplicitamente gli oggetti e la regola in SFOS:

1. Aprire Hosts and services > FQDN host e selezionare Add. Per ogni voce precedente, specificare un Name univoco, inserire il valore elencato in FQDN e salvare l’oggetto.
2. Aprire Hosts and services > FQDN host group e selezionare Add. Specificare un Name, usare Add new item, aggiungere come membri tutti gli host FQDN creati al punto 1 e salvare il gruppo.
3. Aprire Rules and policies > Firewall rules > IPv4, selezionare Add firewall rule > New firewall rule e impostare Action su Accept. Limitare Source zones e Source networks and devices al segmento client interessato, impostare Destination zones su WAN, selezionare il gruppo di host FQDN in Destination networks e soltanto DNS e HTTPS in Services. Posizionare la regola dove necessario, abilitare Log firewall traffic e restringere utenti, pianificazione, origine e destinazione quanto consentito dal flusso di accesso.

Dopo il salvataggio, verificare che ogni host FQDN risolva indirizzi aggiornati e che il gruppo contenga tutti i 20 oggetti. Avviare un accesso di prova dalla rete client delimitata e verificare che il contatore delle corrispondenze della regola aumenti e che il relativo Rule ID e l’azione Accept compaiano in Log Viewer. Se il contatore resta a 0, controllare risoluzione e appartenenza degli oggetti, zona/rete di origine, zona di destinazione, servizi e ordine delle regole prima di ampliarne l’ambito. La modalità Direct Web Proxy richiede inoltre eccezioni URL con espressioni regolari; l’elenco FQDN da solo non le sostituisce.

Se il filtro web, un proxy o un’ispezione TLS hanno effetto prima del login, questi target non dovrebbero essere decrittografati o bloccati inutilmente.

Creare l’eccezione Direct Web Proxy

Per Direct Web Proxy, creare l’eccezione corrispondente come descritto in Eccezioni Web:

Origine dei pattern: Questo elenco è un esempio adattato basato sulla documentazione Sophos per SFOS 22, non una riproduzione letterale di tutti i pattern. L’ottavo pattern per msauth.net vi compare come ^([A-Za-z0-9.-]*\.)?.msauth.net\.?/ (citazione della fonte, non consigliata come modello da copiare). Qui viene invece mantenuto ^([A-Za-z0-9.-]*\.)?msauth\.net\.?/: l’adattamento locale rimuove il punto aggiuntivo non preceduto da una barra inversa prima di msauth e inserisce una barra inversa davanti al punto tra msauth e net. Nella sintassi regex comune, un punto non preceduto da una barra inversa indica generalmente un carattere qualsiasi tranne un’interruzione di riga, mentre \. indica un punto letterale. Questa spiegazione riguarda soltanto la sintassi; non è una correzione confermata dal produttore né una prova di compatibilità verificata con il motore regex di Sophos. Gli altri 13 pattern restano invariati. Prima dell’uso in produzione, i pattern devono essere verificati sulla versione SFOS in uso con un accesso Entra consentito e un URL che non corrisponde ai pattern; se il comportamento non è chiaro, chiedere prima un chiarimento a Sophos, anziché adottare senza verifica il pattern anomalo della fonte.

1. Aprire Web > Exceptions e selezionare Add.
2. Inserire un nome descrittivo e selezionare URL pattern matches.
3. Usare Search e Add per ciascuno dei seguenti 14 pattern regex di questo esempio adattato:

• login\.microsoftonline\.com\.?/
• ^([A-Za-z0-9.-]*\.)?login.live.com\.?/
• aadcdn\.msftauth.net\.?/
• ^([A-Za-z0-9.-]*\.)?aadcdn\.microsoftonline-p\.com\.?/
• ^([A-Za-z0-9.-]*\.)?login.microsoftonline.com\.?/
• ^([A-Za-z0-9.-]*\.)?logincdn.msftauth.net\.?/
• ^([A-Za-z0-9.-]*\.)?aadcdn.msauthimages.net\.?/
• ^([A-Za-z0-9.-]*\.)?msauth\.net\.?/
• ^([A-Za-z0-9.-]*\.)?aadcdn.msftauthimages.net\.?/
• ^([A-Za-z0-9.-]*\.)?microsoftonline\.com\.?/
• ^([A-Za-z0-9.-]*\.)?microsoftonline-p.com\.?/
• ^([A-Za-z0-9.-]*\.)?aadcdn.msftauth.net\.?/
• ^([A-Za-z0-9.-]*\.)?account.activedirectory.windowsazure.com\.?/
• login\.microsoft\.com\.?/

4. Selezionare tutti i checks e le actions per questi pattern.
5. Salvare l’eccezione.

Verificare che la Web Exception salvata sia abilitata. Durante un accesso di prova, controllare nei log web/proxy che l’URL Microsoft richiesto corrisponda al pattern previsto e che l’eccezione venga applicata; in caso contrario, confrontare carattere per carattere nome host e percorso registrati con l’espressione regolare con una sola barra inversa e controllare ambito e ordine dell’eccezione.

Limitare l’eccezione il più possibile alle reti client e al flusso di accesso Entra; non deve diventare un’eccezione generale per i servizi Microsoft. Convalidare entrambi i casi: un accesso Entra consentito deve completarsi, mentre un URL Microsoft non correlato che non corrisponde ai pattern deve continuare a seguire la normale policy Web e TLS. Se anche il test negativo viene escluso, ridurre l’ambito prima del rollout.

Se Protezione Web o Ispezione TLS sono attivi, nel visualizzatore del registro dovrebbe essere osservato l’accesso con un utente di prova. A volte il problema non è il Captive Portal stesso, ma una policy Web, un’eccezione TLS o una rete client che non raggiunge completamente gli endpoint Microsoft.

Testare i gruppi di utenti e le regole del firewall

Dopo un accesso riuscito al captive Portal, la regola firewall effettiva deve vedere l’utente o il gruppo nel traffico. Questa è la prova pratica più importante.

Processo tipico:

1. Controlla gli utenti nell’ID Microsoft Entra.
2. Confronta UPN, indirizzo email e appartenenza al gruppo.
3. Controllare il gruppo Entra su Sophos Firewall.
4. Attivare Match known users e Use web authentication for unknown users nella regola utente.
5. Eseguire l’accesso al captive Portal con l’utente di prova.
6. Quindi attiva il traffico utente reale, ad esempio HTTPS verso una destinazione consentita.
7. Nel Visualizzatore log, controlla se l’utente, il gruppo, la zona di origine, la rete di origine e l’ID regola corrispondono alla regola prevista.

Un accesso riuscito al browser dimostra solo l’autenticazione. Ciò non dimostra che si applichi la regola dell’utente successivo. Se il contatore delle regole rimane su 0 o nessun utente è visibile nel visualizzatore log, è necessario utilizzare il flusso da La regola di Sophos Firewall non funziona: verificare le cause.

Corrispondenza dei gruppi e precedente limitazione del Primary Group

Per le regole utente, il gruppo Entra previsto deve essere presente sul firewall. Dopo il login, verificare in Current activities > Live users e nel Log Viewer a quale gruppo è stato assegnato l’utente e quale Rule ID elabora il traffico.

In SFOS 20.0 GA Build 222 esisteva una limitazione nota: con NC-167130, l’accesso a Internet tramite un gruppo Entra secondario non funzionava; la regola doveva contenere il Primary Group o il singolo utente. Sophos indica SFOS 21.5 MR2 Build 323 e SFOS 22.0 MR1 Build 490 come versioni corrette. Nei build attuali, il Primary Group non è quindi più un requisito generale di progettazione.

Prima di un’implementazione, dovresti quindi registrare quanto segue per ciascun utente di prova:

• Gruppo Entra: Il gruppo di destinazione e l’appartenenza dell’utente sono noti.
• Gruppo sul Sophos Firewall: Lo stesso gruppo viene importato o mappato correttamente.
• Regola firewall: Il gruppo previsto è incluso nella condizione dell’utente o del gruppo.
• Traffico di prova dopo il login: Il Log Viewer mostra utente, gruppo, Rule ID e azione prevista.
• Build precedente interessata: Utilizzare il Primary Group o una regola di prova specifica per l’utente e pianificare l’aggiornamento.

Ciò non influisce su Sophos Connect VPN con Microsoft Entra ID SSO. Per l’accesso remoto, è pertanto necessario verificare il processo separato per SSO ID Microsoft Entra tramite Sophos Connect e portale VPN.

Convalida dopo il lancio

Per la convalida, non basta controllare se viene visualizzata la pagina di accesso di Microsoft.

• Aprire l’URL del Captive Portal dalla rete client: Il browser mostra il login Entra previsto o il reindirizzamento di Sophos.
• Accedi con l’utente consentito: Accesso riuscito, l’utente appare sul firewall.
• Accedi con utente non consentito: L’accesso è comprensibilmente negato.
• Test della regola di gruppo: L’utente di prova soddisfa la regola utente prevista.
• Traffico utente dopo il login: regola firewall corretta abbinata al riferimento utente.
• Flusso della sessione: Dopo un timeout è necessario effettuare nuovamente il login.
• Accesso Microsoft bloccato: Il visualizzatore di log o i log web mostrano un motivo comprensibile.
• Scenario di riserva: Verificare il metodo di autenticazione precedente documentato; il fallback user group da solo non consente l’autenticazione durante un’interruzione di Entra.

Soprattutto con le reti BYOD, dovresti eseguire il test con più browser e dispositivi. Le modalità di navigazione privata, i cookie di terze parti bloccati, i vecchi accessi salvati o più account Microsoft sullo stesso dispositivo possono produrre risultati diversi.

Ripristino sicuro

Prima delle modifiche, annotare l’ordine in Authentication > Services > Firewall authentication methods, le impostazioni in Authentication > Web authentication e le regole firewall interessate. Uno screenshot o un export della configurazione evita di dover ricostruire a memoria lo stato precedente.

Se l’accesso Entra interrompe il servizio, ripristinare prima il metodo di autenticazione precedente nella sua posizione originale. Riportare soltanto Match known users e Use web authentication for unknown users ai valori registrati prima del rollout. Verificare quindi un accesso con il metodo precedente, Current activities > Live users e traffico reale che deve corrispondere alla regola.

Non eliminare subito l’app Entra, l’oggetto server, i gruppi importati o il client secret: potrebbero essere utilizzati anche da WebAdmin, VPN Portal o Remote Access. Rimuovere la Captive portal URL dall’App Registration solo dopo aver confermato che non è utilizzata da alcun servizio o altro nodo firewall.

Risoluzione dei problemi

Il portale prigioniero non è raggiungibile

Controllare prima Administration > Device access per la zona interessata. Quindi controlla DNS, certificato, FQDN del portale, ACL del servizio locale e mappatura delle zone. Se l’accesso avviene al firewall stesso, una normale regola del firewall non è il primo punto di controllo.

L’accesso a Microsoft si avvia ma non ritorna

Confronta URI di reindirizzamento, FQDN, certificato e porta. L’URL esatto utilizzato da Sophos Firewall per Captive Portal deve essere memorizzato nell’ID Entra di Microsoft. Anche le regole di ispezione proxy o TLS possono interferire con il reso.

Quando Microsoft mostra l’errore AADSTS50011, l’URI di reindirizzamento nella registrazione dell’app in genere non corrisponde all’URL utilizzato dal firewall. Successivamente è necessario confrontare esattamente protocollo, FQDN, porta e percorso.

Viene visualizzato un errore interno dopo l’accesso a Microsoft

Un 500 Internal Server Error o un errore altrettanto generico dopo un accesso Microsoft riuscito spesso indica una mancanza di autorizzazioni Microsoft Graph, una mancanza di consenso dell’amministratore o un problema con il segreto client. Quindi dovresti controllare le autorizzazioni API, il consenso dell’amministratore, la validità del segreto e l’assegnazione dell’app aziendale nell’ID Microsoft Entra.

Se oauth_sso_captive.log mostra invece x509: certificate signed by unknown authority, si legge prima la catena di certificati Microsoft raggiunta dal firewall e si importa da una fonte attendibile soltanto una CA root o intermedia la cui assenza sia stata verificata:

openssl s_client -connect login.microsoftonline.com:443 -showcerts

Successivamente si esegue di nuovo Test connection. Solo se la catena CA è già stata corretta e l’errore persiste, il riavvio locale sul nodo del servizio Captive SSO documentato da Sophos è un ultimo passaggio facoltativo durante una finestra di manutenzione:

service oauth_sso_captive:restart -ds nosync

Infine si ripetono Test connection e un nuovo login al Captive Portal. Il riavvio del servizio non sostituisce la verifica dei certificati né un Admin Consent mancante.

Nome utente e password non funzionano direttamente

Entra ID SSO è un browser e un flusso OAuth/OIDC. Gli utenti non accedono direttamente al firewall con le credenziali classiche, ma vengono reindirizzati a Microsoft. Se un client o un flusso supporta solo nome utente e password senza reindirizzamento del browser, questo metodo non è adatto.

L’MFA non viene visualizzato o viene visualizzato in modo diverso dal previsto

Con Entra ID SSO, MFA è controllato in Microsoft Entra ID. L’autenticazione a più fattori del firewall locale non è il punto di controllo corretto per questo flusso SSO. Se è richiesta l’autenticazione a più fattori, è necessario controllare l’accesso condizionale, i gruppi di utenti, le esclusioni e gli utenti di prova nell’ID Microsoft Entra.

L’utente vede no permission o viene rifiutato dopo un funzionamento prolungato

Questo errore corrisponde a NC-167128 su SFOS 21.0 GA Build 169: se lo stesso utente utilizza prima Entra ID SSO, poi AD locale nella rete interna e infine riutilizza il vecchio token Entra, può comparire no permission. Il problema è corretto a partire da SFOS 21.5 MR2 Build 323 oppure SFOS 22.0 MR1 Build 490.

Sulla versione interessata, eliminare prima i cookie del browser. Se il problema si verifica in Sophos Connect, eseguire Force SSO re-login; il percorso è descritto in Configurare Microsoft Entra ID SSO per Sophos Connect e VPN Portal. A lungo termine è preferibile utilizzare sempre Entra ID oppure AD locale per lo stesso utente e aggiornare a una versione firmware corretta.

L’accesso funziona, ma la regola dell’utente non corrisponde

Allora probabilmente il captive Portal non è più l’unico problema. Controlla la zona di origine, la rete di origine, il gruppo di utenti, la posizione delle regole e il visualizzatore di log. Spesso una regola più generale è al di sopra della regola dell’utente oppure il traffico proviene da una rete diversa da quella prevista.

Verificare inoltre che il gruppo Entra previsto sia importato e che l’utente gli sia assegnato sul firewall. Solo in SFOS 20.0 GA Build 222, interessato da NC-167130, la regola deve contenere il Primary Group o il singolo utente per questo errore.

Sono interessati solo i singoli utenti

Confronta UPN, indirizzo email, nome visualizzato, appartenenza al gruppo e gruppo importato. Con Entra ID SSO non dovresti dare per scontato che il nome visibile e l’identificatore tecnico siano identici. Se l’indirizzo e-mail e l’UPN storicamente divergono, si verificano facilmente errori di mappatura.

Quali log sono utili?

Per Captive Portal con Entra ID SSO, oauth_sso_captive.log è particolarmente rilevante. Sono inoltre utili Log Viewer con il modulo Authentication, access_server.log e, a seconda del problema successivo, i log Web, firewall o di autenticazione. L’associazione dei file più importanti è disponibile in Risoluzione dei problemi di Sophos Firewall: servizi e log.

Lista di controllo

• Il caso d’uso del Captive Portal è chiaro: BYOD, guest, dispositivi non gestiti o fallback.
• L’FQDN e il certificato per il captive Portal sono puliti.
• L’app Microsoft Entra ID con URI di reindirizzamento, ID client, ID tenant e segreto client è documentata.
• Sono impostati le autorizzazioni dell’API Microsoft Graph e il consenso dell’amministratore.
• Le assegnazioni delle app aziendali vengono selezionate se Assegnazione richiesta è attiva.
• Il segreto del cliente ha data di scadenza, proprietario e processo di rotazione.
• L’URI di reindirizzamento del Captive Portal è stato rilevato dal firewall e inserito esattamente nell’ID Entra.
• Authentication > Services utilizza il server Entra corretto per Captive Portal.
• Authentication > Web authentication utilizza HTTPS e le impostazioni appropriate della finestra del browser.
• Administration > Device access consente Captive Portal solo nelle zone richieste.
• Gli endpoint di accesso Microsoft possono essere raggiunti dalla rete client.
• Il filtraggio Web e l’ispezione TLS non bloccano il flusso SSO.
• L’autenticazione a più fattori e l’accesso condizionale sono pianificati e testati in Microsoft Entra ID.
• Corrispondenza del gruppo Entra e del gruppo firewall.
• Il gruppo Entra previsto è importato e viene effettivamente valutato per l’utente di prova.
• L’utente di prova può accedere e quindi attivare la regola firewall prevista.
• Il visualizzatore di log mostra l’utente, l’ID della regola e l’azione.
• oauth_sso_captive.log e access_server.log sono noti per i casi di supporto.
• Il fallback per il guasto Entra o Portal è documentato.

Domande frequenti