Configurare Microsoft Entra ID SSO per Sophos Connect e VPN Portal

Con Microsoft Entra ID SSO, Sophos Firewall può autenticare gli utenti per il VPN Portal e per l’accesso remoto tramite Sophos Connect contro Microsoft Entra ID. Per molti ambienti Microsoft 365, questo è più sensato rispetto a password firewall locali separate, poiché identità, accesso condizionale e MFA sono gestiti centralmente nel provider di identità.

Il vantaggio è reale solo se l’intera catena è pianificata correttamente: l’app Entra, le URI di reindirizzamento, il VPN Portal, Sophos Connect, i metodi di autenticazione, i gruppi, l’accesso ai dispositivi e i profili client devono essere coerenti. Questo articolo descrive il processo pratico per VPN Portal, SSL VPN e IPsec Remote Access con Sophos Connect.

Per la configurazione generale di Sophos Connect, inizia con Configurare Sophos Connect su Sophos Firewall. Questo articolo integra i passaggi specifici per l’identità e SSO.

Scelta della versione: I percorsi dell’interfaccia, i nomi dei campi e i file di log specifici dei servizi finora descritti in questo articolo si riferiscono a SFOS 22. Per SFOS 23.0 si utilizza la procedura OpenID Connect descritta di seguito e i log indicati nella relativa sezione. Autorizzazioni dell’app, policy VPN, provisioning, MFA, test pilota e test di ripristino restano parte dello stesso processo; la sola modifica della schermata del server non concede ancora l’accesso VPN. Dalla disponibilità della documentazione di SFOS 23 non si deduce alcuna data di disponibilità generale (GA).

Cosa fa Entra ID SSO sul firewall

Sophos Firewall integra Microsoft Entra ID SSO tramite OAuth 2.0 e OpenID Connect. Il firewall utilizza Entra ID come server di autenticazione e può autenticare gli utenti per diversi servizi.

Per l’accesso remoto, questi servizi sono particolarmente rilevanti:

• VPN Portal
• SSL VPN tramite Sophos Connect
• IPsec Remote Access tramite Sophos Connect

Per il Captive Portal si applica un altro processo: qui un utente si autentica già nella rete locale tramite browser affinché le regole basate sugli utenti siano applicate. Questo caso è descritto separatamente in Configurare Microsoft Entra ID SSO per Sophos Firewall Captive Portal.

L’SSO diretto di Microsoft Entra ID non copre tutti i login tradizionali del firewall. Per User Portal e Client Authentication Agent, Sophos rimanda a Microsoft Entra ID Domain Services. Si tratta di un’architettura di directory separata compatibile con AD o LDAP, non di un’opzione aggiuntiva dell’oggetto server OAuth/OIDC. Se sono necessari User Portal o CAA, non si deve quindi presumere che l’applicazione SSO configurata qui autentichi automaticamente questi servizi.

È importante la distinzione: il firewall continua a gestire VPN, politiche, corrispondenza dei gruppi di utenti e accesso tramite regole firewall. Entra ID gestisce la verifica dell’identità, SSO e MFA basato su Entra.

Un server Entra ID, più servizi

Il server Microsoft Entra ID viene creato una sola volta su Sophos Firewall in Authentication > Servers. Lo stesso oggetto server può poi essere selezionato in Authentication > Services per servizi diversi, ad esempio VPN Portal, SSL VPN, IPsec Remote Access, Captive Portal o accesso amministrativo.

Questo non significa che ogni servizio funzioni automaticamente nello stesso modo. Ogni servizio richiede la Redirect URI corretta, il metodo di autenticazione corretto e un proprio percorso di test. Per VPN Portal, SSL VPN e IPsec Remote Access è rilevante soprattutto VPN portal and remote access URL. Se anche Captive Portal o WebAdmin usano Entra ID SSO, anche i rispettivi URL di servizio devono essere inseriti nell’app Entra e testati separatamente.

Il servizio amministrativo richiede inoltre ruoli o gruppi Entra, profili locali delle autorizzazioni e un accesso di emergenza testato. La procedura dedicata è descritta in Configurare Microsoft Entra ID SSO per WebAdmin di Sophos Firewall.

Per ogni metodo di autenticazione può essere usato un solo server Microsoft Entra ID. Con Sophos Connect Provisioning, VPN Portal, SSL VPN e IPsec dovrebbero quindi usare consapevolmente lo stesso server Entra ID, in modo che valore gateway, Redirect URI e profilo client coincidano.

Quando Entra ID SSO è utile

Entra ID SSO è adatto quando gli utenti lavorano già con Microsoft 365 e l’organizzazione utilizza l’accesso condizionale o Entra-MFA come controllo di sicurezza centrale.

Motivi tipici:

• Gli utenti non devono gestire password firewall separate.
• MFA deve essere gestito tramite Entra ID anziché tramite Sophos OTP.
• L’accesso remoto deve essere più strettamente legato allo stato dell’utente, ai gruppi e all’accesso condizionale.
• Helpdesk e team di sicurezza devono gestire i processi di identità centralmente in Entra ID.
• Gli utenti firewall locali devono essere ridotti.

Non tutti gli ambienti dovrebbero passare immediatamente. In installazioni piccole senza un modello di gruppo Entra pulito, l’MFA di Sophos potrebbe essere più semplice. Per la variante OTP classica, consulta Attivare MFA per Sophos Firewall WebAdmin, VPN Portal e Remote Access.

Prerequisiti e limiti

Prima della configurazione, assicurati che questi punti siano soddisfatti:

• Sophos Firewall con versione SFOS supportata.
• Tenant Microsoft Entra con autorizzazione per creare una registrazione app.
• FQDN pubblico per il VPN Portal o l’accesso remoto.
• Certificato valido per il nome pubblico.
• VPN Portal è raggiungibile tramite la zona necessaria.
• Sophos Connect 2.4 o successivo su Windows, se si utilizza SSO nel client.
• Utenti o gruppi sono presenti correttamente in Entra ID.
• Firewall e Entra ID hanno l’ora corretta.
• Gli URL di login Microsoft sono raggiungibili dai client e, a seconda del percorso del traffico, dal firewall.

Limitazioni importanti:

• Per Sophos Connect SSO, Sophos menziona endpoint Windows con Sophos Connect 2.4 o successivo.
• Se si utilizza Microsoft Entra ID SSO, si utilizza MFA nel provider di identità. L’MFA proprio del firewall non può essere utilizzato in aggiunta per questo metodo di autenticazione.
• In SFOS 22, per ogni metodo di autenticazione può essere selezionato solo un server Microsoft Entra ID. In SFOS 23, il limite riguarda un solo server IdP OpenID Connect, non un server Entra in aggiunta a un altro provider OIDC.
• Gli utenti dello stesso dominio non dovrebbero essere sincronizzati contemporaneamente tramite AD e Microsoft Entra ID.
• Nei cluster HA, attualmente non si dovrebbe presumere che Microsoft Entra ID SSO funzioni per il WebAdmin del firewall ausiliario.

⚠️ Conditional Access richiede una versione firmware corretta: In SFOS 21.5 GA Build 171, Sophos Connect poteva riutilizzare una sessione SSO esistente senza verificare nuovamente MFA e le altre condizioni di Conditional Access. Disconnettere e riconnettere il tunnel VPN non era sempre sufficiente. Sophos identifica il problema come NC-167126 e non indica una soluzione temporanea ufficiale. È corretto a partire da SFOS 21.5 MR2 Build 323 o SFOS 22.0 MR1 Build 490. Se Conditional Access viene usato come barriera di sicurezza, è necessario aggiornare prima almeno a una di queste versioni. Force SSO re-login riduce il rischio sui sistemi precedenti, ma non sostituisce la correzione.

⚠️ L’upgrade a SFOS 22 può attivare automaticamente SSO: Se prima dell’upgrade VPN Portal, Remote Access IPsec o SSL VPN utilizzavano Same as firewall in Authentication > Services, SFOS 22.0 o successivo attiva automaticamente Microsoft Entra ID SSO per questi servizi. Prima dell’upgrade si documentano i metodi effettivi. Se Entra SSO è previsto, dopo l’upgrade occorre registrare nell’app Entra l’esatta VPN portal and remote access URL dell’oggetto server Entra e verificarla con un login reale. Non va utilizzato l’URL reverse SSO di Sophos Fusion (in precedenza Sophos Central). Se SSO non è previsto, si imposta espressamente il metodo desiderato invece di accettare senza verifica lo stato ereditato.

Pianificare l’architettura

Prima della configurazione tecnica, è necessario decidere quali servizi utilizzeranno SSO.

• VPN Portal: L’accesso al portale deve avvenire tramite Entra ID?
• SSL VPN: SSL VPN deve essere utilizzato tramite Sophos Connect con Entra SSO?
• IPsec Remote Access: IPsec Remote Access deve essere utilizzato tramite Sophos Connect con Entra SSO?
• File di provisioning: Viene utilizzato un file di provisioning automatico?
• Gruppi: Quali gruppi Entra possono utilizzare VPN?
• MFA: Quali regole di accesso condizionale e MFA si applicano all’accesso remoto?
• Fallback: Cosa succede se Entra ID o l’accesso a Internet a Microsoft non è disponibile?

Se viene utilizzato un file di provisioning, il valore gateway impostato deve corrispondere al FQDN o all’IP utilizzato nella configurazione Microsoft Entra ID del firewall come URI di reindirizzamento. Dopo le modifiche a Entra ID o alla configurazione del firewall, gli utenti devono importare nuovamente la configurazione aggiornata.

Prima della modifica, documenta Authentication > Services, ordine dei server, gruppi e policy VPN, Device Access e profili distribuiti. Mantieni un amministratore locale indipendente da Entra ID come accesso break-glass protetto, monitorato e testato separatamente. Devono essere disponibili le licenze Entra richieste dalle policy Conditional Access. SFOS 22: Microsoft 365 Government Community Cloud High (GCC High) non è supportato da questa integrazione SSO. La documentazione di SFOS 23 non riporta più questa limitazione; ciò non viene interpretato qui come una conferma del supporto per GCC High. Per un tenant di questo tipo, il supporto deve essere chiarito separatamente prima del rollout.

Preparare l’applicazione Entra per il firewall

Sophos consiglia un’app dedicata. In App registrations > New registration crea un’app Accounts in this organizational directory only con piattaforma Web, quindi copia Application (client) ID e Directory (tenant) ID. In API permissions > Microsoft Graph concedi con Admin Consent le autorizzazioni delegate User.Read.All e Group.Read.All; aggiungi Group.Read.All come Application permission solo per l’importazione gruppi di SFOS. Crea un Client secret, salva subito la Value in modo sicuro e pianifica scadenza e rotazione.

In Enterprise application > Properties imposta Assignment required? su Yes e assegna solo il gruppo pilota/VPN e gli amministratori necessari. L’assegnazione è il primo controllo; la policy SSL/IPsec resta il secondo. Microsoft documenta l’assegnazione di utenti e gruppi e le regole per le Redirect URI. SFOS legge automaticamente gli attributi dal token; scegli un Fallback user group senza ampi diritti VPN, così l’assenza di un gruppo importato non amplia l’accesso.

L’assegnazione dell’applicazione basata sui gruppi richiede Microsoft Entra ID P1 o P2 e non include gli utenti che appartengono solo tramite un gruppo annidato. Senza tale licenza o con gruppi annidati, assegna direttamente gli utenti pilota; altrimenti Entra rifiuta l’accesso anche se l’appartenenza al gruppo VPN sembra corretta.

Creare un server Microsoft Entra ID sul firewall

SFOS 23.0: OpenID Connect con Microsoft Entra ID

In SFOS 23, Entra ID viene configurato come provider nell’oggetto server OpenID Connect condiviso. L’app Entra esistente resta necessaria; non si crea una seconda app solo perché la schermata è stata rinominata. Prima di una modifica, si documentano l’oggetto server esistente, le sue assegnazioni ai servizi e le Redirect URI. Un upgrade è considerato verificato solo dopo un nuovo test del portale e del tunnel.

1. Apri Authentication > Servers > Add e seleziona OpenID Connect sotto Server type.
2. Imposta Server name e seleziona IdP vendor: Microsoft Entra ID.
3. In Client ID, inserisci Application (client) ID dell’app Entra e, in Client secret, il valore del relativo secret.
4. In OpenID Connect URLs > Issuer URL, inserisci Directory (tenant) ID. Per questo provider, il campo SFOS documentato richiede il Tenant ID; non sostituirlo con una Issuer URL costruita manualmente. Le altre impostazioni URL non si applicano a Microsoft Entra ID.
5. In Redirect URIs, seleziona Use firewall URL oppure inserisci il FQDN o l’indirizzo IP previsto per il firewall tramite Enter manually. Se un singolo firewall viene gestito tramite Sophos Fusion, imposta manualmente l’hostname; l’URL reverse SSO non è un callback dell’appliance.
6. Apri Show URLs e registra l’esatta VPN portal and remote access URL come Redirect URI web nell’app Entra. Con il provisioning, il valore gateway deve corrispondere al FQDN o all’IP del firewall utilizzato qui. Le modifiche richiedono una nuova importazione della configurazione client.
7. In User attributes, mantieni i valori predefiniti Display name: name, Username: upn e Email address: email. Solo un token effettivamente strutturato in modo diverso e supportato giustifica attributi differenti.
8. Per i servizi destinati esclusivamente agli utenti VPN, lascia disattivato IdP authentication for firewall administrators e scegli una Fallback group con autorizzazioni limitate. Il mapping degli amministratori è un passaggio separato descritto nell’articolo WebAdmin.
9. Esegui Test connection, salva solo se il test riesce e assegna il server al VPN Portal, a SSL VPN e, se necessario, a IPsec in Authentication > Services. Esegui Apply per ogni servizio. SSL VPN e VPN Portal utilizzano sempre lo stesso server; con il provisioning, questo vale anche per IPsec.

Dopo un upgrade, verifica anche l’avviso esistente relativo a Same as firewall: l’attivazione automatica per i metodi VPN ereditati si applica a SFOS 22.0 e successivi, quindi anche al relativo passaggio a SFOS 23. Una migrazione del server documentata non sostituisce né la verifica dei metodi effettivi né un login reale con controllo di reindirizzamento, gruppi, MFA e tunnel.

SFOS 22: Microsoft Entra ID SSO

La seguente schermata del server, con Directory (tenant) ID, User attribute mapping e Fallback user group, appartiene a SFOS 22. Per SFOS 23, utilizza i campi della procedura precedente.

Il percorso del menu è:

Authentication > Servers

Procedura sul firewall:

1. Apri Add.
2. Seleziona l’opzione Microsoft Entra ID SSO come Server type.
3. Assegna un nome descrittivo al server.
4. Inserisci Application (client) ID dall’app Entra.
5. Inserisci Directory (tenant) ID.
6. Inserisci Client secret.
7. Verifica o imposta manualmente il FQDN dell’URI di reindirizzamento.
8. Imposta il gruppo di fallback.
9. Se è necessario SSO WebAdmin, pianifica il mapping di ruoli o gruppi sui profili amministrativi.
10. Esegui Test connection.
11. Salva.

Per scenari SSO VPN puri, non è necessario il mapping del ruolo amministrativo. In tal caso, il server dovrebbe essere pianificato come servizio utente, non come accesso amministrativo generale.

⚠️ I Client Secrets sono dati di accesso produttivi. La data di scadenza, la rotazione, la responsabilità e la documentazione devono essere chiariti prima del rollout.

Impostare i metodi di autenticazione

Dopo aver creato il server Microsoft Entra ID, deve essere assegnato ai servizi appropriati sotto Authentication > Services.

Per l’accesso remoto, queste aree sono rilevanti:

• VPN portal authentication methods
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods
• SSL VPN authentication methods

Se viene utilizzato un file di provisioning, dovrebbe essere utilizzato lo stesso server Microsoft Entra ID per VPN Portal, IPsec e SSL VPN. Nei file di provisioning, è importante la stessa selezione del server per i metodi di autenticazione, in modo che il profilo client, il portale e il metodo di accesso remoto siano coerenti.

Senza un file di provisioning, SSL VPN e VPN Portal devono continuare a utilizzare lo stesso server Microsoft Entra ID; Remote Access IPsec può invece utilizzare un altro oggetto server Entra. Con un file di provisioning, VPN Portal, SSL VPN e IPsec devono puntare allo stesso oggetto. Questa distinzione va documentata consapevolmente e non dedotta in seguito da un errore di tenant nel dialogo SSO.

Dopo ogni modifica:

1. Seleziona il server nel metodo appropriato.
2. Trascina il server nella posizione corretta, se sono presenti più server.
3. Esegui Apply per ogni servizio modificato.
4. Utilizza un utente di test prima di distribuire ampiamente la modifica.

Inserire le URI di reindirizzamento in Microsoft Entra ID

Per far funzionare SSO, gli URL del firewall devono essere registrati nell’app Entra come URI di reindirizzamento.

Procedura:

1. Apri Authentication > Servers sul firewall.
2. Apri il server Microsoft Entra ID.
3. Copia gli URL necessari:
   • URL della console di amministrazione web, se si utilizza SSO WebAdmin
   • URL del captive portal, se si utilizza il Captive Portal
   • URL del portale VPN e dell’accesso remoto per VPN Portal, Remote Access IPsec e SSL VPN
4. Nel portale Azure, vai a Microsoft Entra ID > App registrations.
5. Apri l’applicazione per Sophos Firewall.
6. Sotto Manage > Authentication, aggiungi una piattaforma web o modifica la piattaforma web esistente.
7. Inserisci le URI di reindirizzamento copiate.
8. Salva.

Un errore comune è un hostname diverso nel profilo client, URI di reindirizzamento, certificato e DNS pubblico. Questi valori dovrebbero essere confrontati consapevolmente prima del rollout.

Se non si protegge l’accesso remoto, ma il Captive Portal, dovrebbe essere verificato anche il flusso specifico del Captive Portal: accesso ai dispositivi per la zona client, metodo di autenticazione del Captive Portal, gruppo di utenti e successivo matching delle regole firewall.

Consentire il VPN Portal tramite Device Access

Microsoft Entra ID SSO per l’accesso remoto utilizza la porta del VPN Portal per comunicare con il firewall. Per l’accesso da Internet, consenti quindi VPN Portal nella riga WAN sotto Administration > Device access. Abilita altre zone solo se i client devono realmente raggiungere il portale da tali zone.

Ciò non significa che il VPN Portal debba essere aperto indiscriminatamente in tutto il mondo. L’accesso remoto è una superficie di attacco pubblicamente accessibile. Per ambienti produttivi, dovresti anche verificare:

• certificato pubblico valido
• MFA e accesso condizionale in Entra ID
• limitazione geografica o di origine il più stretta possibile, se realistico
• registrazione e revisione dei tentativi di accesso
• disattivazione chiara degli utenti non più necessari

Il rafforzamento dei servizi firewall locali è descritto in Device Access e Local Service ACL su Sophos Firewall.

Se si verificano già molti accessi non riusciti, origini distribuite o blocchi degli account Entra, Rilevare e contenere gli attacchi brute force contro il VPN Portal combina i log del firewall con il controllo Entra, una restrizione ACL sicura e il controllo finale.

Consentire gli URL di login Microsoft

I client e i percorsi del firewall interessati devono poter raggiungere gli endpoint Microsoft Entra ID. Ciò include diversi URL di login e CDN Microsoft, ad esempio login.microsoftonline.com, login.microsoft.com, *.login.live.com, *.msauth.net e altri domini Azure/Microsoft Online.

In ambienti restrittivi, non dovresti scoprire solo al momento del rollout che le pagine di login, JavaScript o gli endpoint dei token sono bloccati. È sensato:

• Utilizzare l’allowlist per l’accesso Microsoft Entra completa per gli host FQDN e le eccezioni proxy.
• Nominare correttamente gli host FQDN o i gruppi di host FQDN.
• Impostare consapevolmente la regola firewall per DNS e HTTPS.
• In caso di proxy web diretto, verificare eccezioni web aggiuntive.
• Attivare la registrazione fino a quando l’accesso SSO non è stabile.

Con un Direct Web Proxy, la regola Allow verso il FQDN Host Group non è sufficiente da sola. L’articolo collegato sull’allowlist contiene i pattern URL esatti e descrive la procedura in Web > Exceptions. Limitare l’eccezione ai pattern di login e CDN necessari.

Verificare gruppi e autorizzazioni VPN

SSO da solo non concede l’accesso VPN. L’utente deve essere autorizzato anche nella configurazione di accesso remoto appropriata.

Importare selettivamente i gruppi Entra

Per importare i gruppi, l’applicazione del firewall deve disporre dell’autorizzazione Microsoft Graph Group.Read.All come Application permission, con Admin Consent concesso. In Authentication > Servers si apre quindi Assistant for importing groups per il server Entra. Invece di importare tutti i gruppi senza controllo, l’assistente può filtrare, ad esempio, per Display name o Description.

Durante l’importazione è possibile assegnare Surfing quota, Access time, Network traffic e Traffic shaping a tutti i gruppi o a gruppi specifici. Queste policy vengono assegnate solo quando sono realmente necessarie. L’ora del firewall e di Microsoft Entra ID deve essere sincronizzata, altrimenti può fallire l’importazione stessa.

Se il gruppo Entra esiste sul firewall, SFOS assegna l’utente a quel gruppo. In caso contrario si applica il Fallback user group configurato sul server Entra. Questo vale anche quando il server Entra viene utilizzato in Firewall authentication methods; il Default group presente in quella sezione non sostituisce il gruppo di fallback. Dopo l’importazione, il nuovo gruppo deve inoltre essere autorizzato nella relativa policy IPsec o SSL VPN.

Da verificare:

• Il gruppo Entra è stato importato nel firewall o è mappato correttamente.
• Il gruppo è selezionato in Remote Access IPsec sotto Allowed users and groups.
• Il gruppo è selezionato in SSL VPN sotto Policy members.
• Le regole firewall consentono il traffico dalla zona VPN solo verso le destinazioni necessarie.
• L’utente non è solo autenticato, ma riceve anche la policy prevista.

Se il tunnel è connesso ma non c’è traffico, spesso non è SSO la causa, ma regole, routing, DNS o NAT. Per l’analisi, consulta Testare la regola firewall con Log Viewer, Policy Test e Packet Capture.

Verificare UPN, e-mail e corrispondenza dei gruppi

Con Microsoft Entra ID SSO, dovresti verificare con particolare attenzione l’identità dell’utente e la corrispondenza dei gruppi. Un login può avere successo nel provider di identità e comunque essere assegnato in modo errato sul firewall se UPN, indirizzo e-mail, gruppo importato o identificativo utente locale non corrispondono.

Questo è particolarmente rilevante in ambienti in cui gli utenti hanno storicamente valori diversi:

• User Principal Name: max.muster@example.com è spesso il nome di login previsto.
• Indirizzo e-mail: m.muster@example.com può essere diverso e creare confusione nell’associazione o nel login al portale.
• Nome visualizzato: Max Muster è leggibile per le persone, ma non è adatto come identificativo tecnico.
• Gruppo: VPN-Users deve essere importato nel firewall e utilizzato nella configurazione di accesso remoto corretta.

Anche il formato di login è importante durante la migrazione da Active Directory locale a Entra ID. AD utilizza spesso sAMAccountName@domain, mentre Entra ID utilizza UserPrincipalName@domain. SFOS considera stringhe diverse come oggetti utente distinti anche quando appartengono alla stessa persona. Quando possibile, il formato va uniformato prima della migrazione. Se si utilizzano consapevolmente nomi diversi, vengono creati duplicati; i vecchi utenti AD vengono rimossi solo dopo avere verificato regole, gruppi, reporting e il nuovo login Entra.

Il precedente problema noto NC-157635 causava il fallimento degli accessi al portale SSL VPN o IPsec quando l’indirizzo e-mail e l’UPN erano diversi. Sophos lo ha risolto con SFOS 21.0 MR2 Build 349, 21.5 MR1 Build 261 e 22.0 EAP0 Build 274. La verifica degli attributi utente resta utile in caso di problemi con singoli account, perché permette di individuare oggetti utente locali o autorizzazioni di gruppo non corrispondenti.

Procedura di verifica pratica:

1. Apri l’utente di test in Microsoft Entra ID.
2. Confronta UPN e indirizzo e-mail.
3. Verifica se l’utente è membro del gruppo VPN pianificato.
4. Sul firewall, apri il gruppo importato e controlla se l’utente appare come previsto.
5. Sotto Authentication > Services, verifica se il server Microsoft Entra ID corretto è selezionato per VPN Portal, SSL VPN e IPsec.
6. Esegui un test di login e verifica Log Viewer e oauth_sso_vpn.log.

Se solo alcuni utenti sono interessati, è più probabile che si tratti di un problema di attributi o gruppi piuttosto che di un errore generale del server Entra ID. Se tutti gli utenti sono interessati, verifica prima Tenant ID, Client ID, Client Secret, URI di reindirizzamento, ora e endpoint Microsoft.

Per le regole utente dopo un login VPN riuscito, inoltre: la regola firewall deve vedere l’utente o il gruppo nel traffico effettivo. Se il tunnel è attivo, ma la regola utente pianificata non corrisponde, consulta l’analisi in La regola Sophos Firewall non si applica: verificare le cause.

Introdurre MFA e Conditional Access in modo controllato

Limita la policy alla Enterprise Application del firewall e inizia con utenti pilota o modalità Report-only. Verifica MFA e ogni condizione con un caso consentito e uno negato nei log Entra. Microsoft raccomanda di pianificare e valutare le policy prima dell’applicazione.

Mantieni almeno due account di emergenza Entra cloud-only, separati, monitorati ed esclusi da Conditional Access. Non sostituiscono l’amministratore locale indipendente da Internet, Entra e dall’app e non vanno assegnati alla VPN solo per testare un bypass. Vedi Manage emergency access accounts.

Testare Sophos Connect e il provisioning

Per Sophos Connect: dopo la configurazione di Entra ID o dopo modifiche alla configurazione SSO, la configurazione del client deve essere nuovamente importata.

Testare macOS separatamente: Per Microsoft Entra ID SSO con Sophos Connect 2.1 o successivo su macOS (non 2.0), seguire il flusso di autenticazione nel browser su macOS. auto inizia nel browser integrato e passa al browser di sistema quando lo richiedono le condizioni pertinenti di Conditional Access; embedded non prevede alcun passaggio automatico. La scelta di system tramite un file .pro approvato è descritta nello schema di provisioning, non si effettua modificando manualmente .ovpn o .scx. Completare l’accesso, inclusa la MFA, nel browser aperto dal client, tornare al client e verificare tunnel, DNS e accesso. Cambiare browser non aggira la conformità del dispositivo: soddisfare i requisiti o contattare l’IT, senza indebolire Conditional Access. Il test Windows seguente resta riferito a Sophos Connect 2.4 o successivo.

Procedura di test:

1. Installa l’attuale client Sophos Connect su Windows.
2. Importa la configurazione di provisioning o VPN appropriata.
3. Verifica se l’opzione SSO è visibile e cliccabile nel client.
4. Accedi con Entra ID.
5. Attiva MFA o accesso condizionale come pianificato e controlla il risultato nei log di accesso di Entra.
6. Verifica lo stato del tunnel.
7. Verifica IP VPN, DNS, obiettivi interni e corrispondenza delle regole firewall.
8. Su un dispositivo condiviso, testa un re-login SSO forzato.

Per l’ultimo test, apri il menu in alto a destra nel client Sophos Connect, seleziona Force SSO re-login e conferma con OK. Solo a quel punto l’utente successivo dovrà accedere con le proprie credenziali Entra. La normale disconnessione del tunnel non equivale a questo passaggio. Sui dispositivi Windows condivisi, questa operazione fa parte di un cambio utente corretto anche con firmware aggiornato.

Registra per ogni test ora, utente, tipo VPN e risultato atteso. Applicazione, utente, esito MFA/Conditional Access e codice errore nei log Entra devono corrispondere a oauth_sso_vpn.log o al modulo Authentication del Log Viewer. Prima del rollout verifica nel tuo ambiente: utente pilota assegnato e utente non assegnato al portale; ogni profilo SSL/IPsec usato con IP VPN, DNS e sole destinazioni consentite; utente senza gruppo VPN; Force SSO re-login su un dispositivo condiviso; e login dell’amministratore break-glass dal percorso limitato. Non sono test dichiarati come già eseguiti.

Per l’installazione del client su Windows, consulta Installare Sophos Connect Client su Windows. Per SSL VPN con Sophos Connect, consulta anche Configurare Sophos SSL VPN con Sophos Connect su Windows.

Rollback con conservazione dello stato

Non rimuovere l’autenticazione precedente finché pilota e rollback non sono riusciti; conserva i vecchi profili sotto controllo. In caso di problemi, accedi con l’amministratore locale e ripristina in Authentication > Services server e ordine documentati per VPN Portal, SSL VPN e IPsec, scegliendo Apply per ogni servizio. Reimporta il vecchio profilo su un dispositivo pilota e verifica portale, tunnel, DNS e una destinazione interna consentita.

Elimina app Entra, nuovo server, gruppi importati e secret solo dopo che accesso e log confermano il ripristino. Se Device Access era stato ampliato solo per SSO, ripristinalo dopo, per non bloccare contemporaneamente il percorso VPN recuperato.

Operatività e sicurezza

Entra ID SSO sposta la sicurezza del login più nel provider di identità. Questo è positivo se Entra ID è gestito correttamente. È problematico se gruppi, accesso condizionale o segreti delle app sono gestiti superficialmente.

In operatività, questi punti dovrebbero essere verificati regolarmente:

• Il segreto dell’app non scade inaspettatamente.
• I gruppi Entra contengono solo utenti autorizzati.
• L’accesso condizionale si applica all’accesso remoto.
• Gli accessi di emergenza e fallback sono documentati.
• Il VPN Portal è raggiungibile solo quanto necessario.
• Le versioni di Sophos Connect sono aggiornate.
• I vecchi profili client vengono ritirati dopo le modifiche.
• I log vengono esaminati tempestivamente in caso di problemi di accesso.

Per il lato client, dovrebbe esistere anche un processo di aggiornamento separato. L’articolo Verificare e aggiornare in sicurezza la versione del client Sophos Connect riassume quali argomenti Windows, macOS, SSO, OTP e provisioning dovrebbero essere verificati prima di un rollout.

Risoluzione dei problemi

SFOS 23.0: Per il flusso di autenticazione OIDC si utilizza /log/oauth_sso_svc.log; gli errori di Test connection con x509: certificate signed by unknown authority si verificano in /log/sfos-macro-cfg.log. Nel Log Viewer, il modulo Authentication resta rilevante per VPN Portal, IPsec e SSL VPN. I riferimenti successivi a oauth_sso_vpn.log e il riavvio specifico del servizio si riferiscono a SFOS 22.

Dopo aver corretto una catena CA di cui è stata accertata l’incompletezza, si ripete prima Test connection. Solo se il riavvio è ancora necessario e un’interruzione dei servizi di autenticazione OIDC utilizzati è accettabile nella finestra di manutenzione, il comando Advanced Shell documentato da Sophos per SFOS 23 è:

service oauth_sso_svc:restart -ds nosync

Successivamente, ripeti Test connection, un nuovo login al VPN Portal e la verifica del tunnel effettivamente utilizzato. Il servizio condiviso non comporta un riavvio limitato alla VPN; anche gli altri servizi utilizzati tramite questo oggetto OIDC devono essere nuovamente testati separatamente. Nessun riavvio sostituisce le verifiche di DNS, ora, autorizzazioni o CA.

Il pulsante SSO non è utilizzabile nel client Sophos Connect

Se il client segnala che SSO non è configurato, testa prima la connessione al server Microsoft Entra ID sul firewall. Poi, sotto Authentication > Services, verifica se il server Entra ID è impostato correttamente per SSL VPN o IPsec e VPN Portal.

L’utente non può accedere al VPN Portal

In tal caso, SSO può funzionare in generale, ma manca l’autorizzazione VPN. Verifica se il gruppo Entra è incluso nella configurazione di Remote Access IPsec sotto Allowed users and groups o in SSL VPN sotto Policy members.

Solo alcuni utenti non possono accedere

In tal caso, verifica prima UPN, indirizzo e-mail, appartenenza al gruppo e gruppo firewall importato. Soprattutto per utenti con indirizzo e-mail diverso, nomi modificati o account migrati, l’identificativo tecnico può apparire diverso da quanto previsto.

Microsoft segnala tenant o applicazione errati

In tal caso, spesso i metodi di autenticazione, l’app Entra, il Tenant ID o la selezione del server sul firewall non corrispondono. Soprattutto con più server Entra ID, verifica se VPN Portal, SSL VPN e IPsec utilizzano lo stesso server previsto.

Il reindirizzamento o il login termina su una pagina di errore

Confronta FQDN, certificato, DNS pubblico, URI di reindirizzamento e valore gateway del file di provisioning. Anche piccole discrepanze in hostname, porta o percorso possono disturbare il flusso OAuth/OIDC.

Test connection fallisce con un errore x509

Se oauth_sso_vpn.log mostra l’errore x509: certificate signed by unknown authority, nella catena di certificati verso Microsoft Entra ID può mancare una CA root o intermedia. Il problema noto NC-176806 è stato risolto con SFOS 22.0 MR2 Build 546; restano comunque possibili altre catene di certificati incomplete o errori TLS.

Nella Advanced Shell è possibile verificare la catena fornita da Microsoft:

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

1. Verifica la catena di certificati e gli issuer nell’output.
2. Ottieni solo la CA root o intermedia mancante da una fonte attendibile. Non importare un certificato server come CA.
3. Aggiungi e applica la CA in Certificates > Certificate Authority.
4. Apri il server Entra ID in Authentication > Servers ed esegui nuovamente Test connection.
5. Solo se il test continua a non riuscire ed è accettabile una breve interruzione dei login VPN SSO in corso, riavvia il servizio VPN SSO nella Advanced Shell:

service oauth_sso_vpn:restart -ds nosync

Esegui quindi nuovamente Test connection. Il riavvio del servizio è un ultimo passaggio facoltativo, non la prima misura da adottare in caso di errore x509.

L’importazione dei gruppi non funziona

Verifica l’ora del firewall, i dati del tenant, le autorizzazioni dell’app, il Client Secret e la raggiungibilità degli endpoint Microsoft. Se i gruppi locali esistenti non corrispondono ai gruppi Entra, deve essere deciso se devono essere ripuliti, mappati o gestiti manualmente.

La connessione è attiva, ma i sistemi interni non sono raggiungibili

In tal caso, probabilmente l’autenticazione non è più l’errore principale. Verifica IP VPN, DNS, regole firewall, NAT, routing e sistema di destinazione. Nel Log Viewer dovrebbe essere visibile quale regola colpisce il traffico dalla zona VPN.

Checklist

• L’app Entra con Client ID, Tenant ID e Client Secret è documentata.
• Le URI di reindirizzamento per VPN Portal e Remote Access sono registrate in Entra ID.
• FQDN pubblico, certificato e gateway di provisioning corrispondono.
• VPN Portal è consentito sotto Device Access consapevolmente.
• Gli URL di login Microsoft sono raggiungibili.
• I servizi di autenticazione utilizzano il server Entra ID corretto.
• I gruppi VPN sono importati e consentiti nelle politiche SSL/IPsec.
• UPN, indirizzo e-mail e appartenenza al gruppo sono stati verificati con un utente di test.
• Sophos Connect 2.4 o successivo è in uso su Windows.
• I profili client sono stati reimportati dopo le modifiche.
• Entra-MFA e accesso condizionale sono stati verificati con un utente di test.
• oauth_sso_vpn.log, Log Viewer e i log del server di accesso sono noti per la risoluzione dei problemi.

Domande frequenti