Collegare Active Directory a Sophos Firewall

Active Directory resta in molti ambienti Sophos Firewall la fonte centrale per utenti, gruppi e autenticazione. La firewall usa l’integrazione AD, per esempio, per regole utente, Remote Access VPN, Captive Portal, User Portal, reporting o scenari Single Sign-On.

Questo articolo spiega come aggiungere un server Active Directory su Sophos Firewall, quali campi sono davvero importanti e come verificare poi la connessione. Per nuovi design Remote Access conviene inoltre decidere se siano più adatti AD classico, RADIUS oppure Microsoft Entra ID SSO per Sophos Connect e VPN Portal.

Se Active Directory diventa la destinazione di un ambiente eDirectory esistente, è opportuno pianificare prima la procedura controllata di migrazione da eDirectory, con verifica dei gruppi, cutover per singolo servizio e rollback.

Il seguente video Sophos Techvids mostra il processo di base come integrazione visiva. È stato creato con SFOS v21; la logica resta utile, anche se in SFOS 22 alcune schermate possono essere leggermente diverse.

Il flusso pratico è composto da quattro parti. Un test di connessione riuscito è solo l’inizio; VPN, portali, regole utente e SSO devono essere validati separatamente.

1. Aggiungere il server: inserire correttamente Domain Controller, dominio NetBIOS, search base e account di servizio.
2. Proteggere la connessione: pianificare consapevolmente LDAPS, verifica del certificato e risoluzione DNS interna.
3. Importare gruppi: importare solo i gruppi AD necessari e capire la Main Group.
4. Testare l’uso: verificare login, MFA, VPN, User Portal, Captive Portal, SSO e Log Viewer.

Inquadramento

Sophos Firewall può usare diverse sorgenti di autenticazione. Active Directory è utile quando utenti e gruppi sono già gestiti localmente in un dominio Windows e la firewall deve usare direttamente queste identità.

Casi d’uso tipici:

• sincronizzazione di utenti e gruppi dal proprio Active Directory locale
• regole firewall con riferimento a utenti o gruppi
• Remote Access VPN con utenti AD
• User Portal o Captive Portal con account di dominio
• reporting per utente invece che solo per indirizzo IP
• Active Directory SSO con NTLM o Kerberos

Il collegamento AD però non risolve automaticamente ogni tema di autenticazione. Bisogna distinguere se la firewall interroga soltanto utenti via LDAP/LDAPS, se vengono importati gruppi, se viene usato SSO o se per Remote Access serve anche MFA. Per le basi MFA si adatta attivare MFA per Sophos Firewall WebAdmin, VPN Portal e Remote Access.

Decisioni importanti prima della configurazione

Prima di aggiungere il server, chiarire questi punti:

• Connessione: usare se possibile LDAPS con SSL/TLS sulla porta 636.
• Account di servizio: usare un account AD dedicato con diritti di lettura invece di Domain Admin.
• Search base: cercare solo nelle OU necessarie, non alla cieca in tutto il dominio.
• Display attribute: scegliere consapevolmente sAMAccountName, userPrincipalName o displayName.
• Gruppi: importare solo gruppi realmente necessari per firewall, VPN o portali.
• MFA: proteggere Remote Access e portali anche con MFA.
• Ordine dei server: con più server AD definire consapevolmente l’ordine di interrogazione.
• Esercizio: controllare regolarmente auth log, import gruppi, certificati e scadenza password.

Occorre inoltre definire il routing e il percorso sorgente dalla firewall al Domain Controller. LDAPS richiede TCP 636, STARTTLS TCP 389; la risoluzione DNS interna e una catena di certificati completa e valida devono funzionare dal percorso effettivamente usato dalla firewall. Prima della modifica, creare e scaricare un backup cifrato della configurazione in Backup and firmware > Backup and restore e conservarne la password in modo sicuro.

⚠️ La connessione tra firewall e server di autenticazione dovrebbe essere cifrata. LDAP non cifrato sulla porta 389 può funzionare in laboratorio, ma non è una buona soluzione permanente in produzione.

Per l’integrazione AD sono supportate anche versioni più vecchie di Windows Server; negli ambienti attuali sono però rilevanti soprattutto Windows Server 2016, 2019, 2022 e 2025. Da SFOS 21.5 MR1 è possibile Active Directory SSO con Windows Server 2025 per NTLM e Kerberos. SFOS 22 contiene componenti Samba aggiornati per autenticazione Kerberos e NTLM e rimuove vecchi metodi di cifratura. Proprio dopo upgrade della firewall o dei Domain Controller conviene quindi testare in modo mirato AD SSO, import gruppi e Remote Access.

Importante: l’applicazione rigida di LDAP Channel Binding e LDAP Signing non è attualmente supportata da Sophos Firewall. Se i Domain Controller impongono requisiti LDAP molto restrittivi, l’integrazione AD va testata in una finestra di manutenzione prima di una modifica produttiva.

Aggiungere il server Active Directory

La configurazione avviene nel WebAdmin di Sophos Firewall:

Authentication > Servers

Con Add si crea un nuovo server di autenticazione e come Server Type si seleziona Active Directory.

Campi della configurazione Active Directory

La numerazione nello screenshot è voluta: i campi principali vengono spiegati dall’alto verso il basso. A seconda della versione SFOS, l’ordine può variare leggermente. Nelle versioni più recenti compare inoltre Validate server certificate, se si vuole attivare la verifica del certificato per LDAPS.

1. Server type: Per un classico dominio Windows si usa Active Directory. Altri tipi come RADIUS, LDAP o Microsoft Entra ID sono integrazioni diverse e non vanno mescolate.
2. Server name: Nome visualizzato internamente sulla firewall. Non influenza DNS o AD, ma deve essere chiaro, per esempio AD-ZH-DC01 o AD-HQ-LDAPS. Con più Domain Controller un nome pulito aiuta nel Log Viewer e nel troubleshooting.
3. Server IP/domain: Indirizzo IP o nome DNS del Domain Controller. Un nome DNS è più pulito se certificato, DNS interno e failover combaciano. Un IP è più semplice da debuggare, ma lega la firewall a un Domain Controller specifico.
4. Port: Porta per la connessione LDAP. In produzione è preferibile 636 con SSL/TLS. 389 viene usata per LDAP non cifrato o STARTTLS, ma non dovrebbe essere la soluzione permanente se l’autenticazione utente è produttiva.
5. NetBIOS domain: Nome NetBIOS breve del dominio AD, per esempio AVANET. Non è il nome DNS del dominio. Valori NetBIOS errati causano spesso utenti trovati male o associati in modo non corretto.
6. ADS user name: Nome utente dell’account usato per le query AD. Nell’esempio Sophos compare il nome breve administrator. In produzione Avanet raccomanda invece un account di servizio dedicato autorizzato a cercare, leggere e interrogare l’appartenenza ai gruppi, non un account Domain Admin. Sophos non conferma in generale che nome breve, DOMAIN\user e UPN siano equivalenti in ogni configurazione; usare quindi il formato verificato nel proprio ambiente AD e documentarlo.
7. Password: Password dell’account di servizio. Se scade o viene cambiata, query utenti, import gruppi, VPN login o portal login possono smettere improvvisamente di funzionare. L’account deve quindi essere documentato e monitorato.
8. Connection security: Definisce se e come la connessione viene protetta. Per LDAPS si usa SSL/TLS con porta 636. STARTTLS usa normalmente porta 389, ma richiede che il Domain Controller offra STARTTLS correttamente. Plaintext è non cifrato e dovrebbe essere usato al massimo per test.
9. Display name attribute: Attributo AD usato per il nome visualizzato sulla firewall. Il valore deve corrispondere allo schema della propria directory ed essere verificato con un utente di prova; la guida generale Sophos non descrive valori standard universalmente intercambiabili. Per Microsoft Entra Domain Services Sophos indica espressamente DisplayName.
10. Email address attribute: Attributo per l’indirizzo e-mail. Di solito è mail. Il campo è utile solo se gli indirizzi e-mail sono davvero mantenuti in AD. Altrimenti nascono informazioni utente vuote o incoerenti.
11. Domain name: Nome DNS del dominio AD, per esempio ad.example.com. Non è il NetBIOS name. Deve corrispondere a dominio, search base e Domain Controller usato.
12. Search queries: Base di ricerca per query utenti e gruppi. Qui si inseriscono Distinguished Names come DC=ad,DC=example,DC=com oppure, in modo più mirato, OU=Users,OU=Company,DC=ad,DC=example,DC=com. Una OU mirata limita gli utenti visibili e mantiene ordinato l’import.

Solo gli utenti inclusi da almeno una Search query possono comparire per questo server AD in Current activities > Live users. Se manca un utente previsto nonostante un Test connection riuscito, verificare prima che il Base DN e l’ambito dell’OU includano il suo effettivo oggetto nella directory. La search base non va estesa preventivamente all’intero dominio.

Se sono presenti più Domain Controller, bisogna decidere consapevolmente se la firewall debba parlare con un DC specifico o se un nome DNS interno stabile debba puntare a un’infrastruttura AD adatta. DNS, certificato, routing e regole firewall devono combaciare.

Automazione AD nel passaggio da SFOS 22 a SFOS 23: La documentazione API per l’aggiunta e la modifica di un server AD usa in SFOS 23 denominazioni più ristrette nelle tabelle rispetto a SFOS 22: ServerIpDomain/ServerAddress diventa ServerAddress, ServerName/NetBIOSDomain diventa NetBIOSDomain e ADSUsername/Administrator/Username diventa ADSUsername/Administrator. L’esempio XML, invece, usa in entrambe le versioni gli stessi elementi ServerAddress, NetBIOSDomain e ADSUsername. Questo dimostra una modifica delle denominazioni nella documentazione, non il rifiuto dei vecchi alias da parte della firewall né una ridenominazione dei campi WebAdmin spiegati sopra. L’esempio, internamente incoerente, non è un modello API verificato e direttamente eseguibile.

Anche le denominazioni della sicurezza della connessione restano distinte: Plaintext è la denominazione usata nel WebAdmin; la documentazione API indica per ConnectionSecurity i valori Simple, SSL e StartTLS. Le denominazioni della GUI non vanno adottate come valori API senza verificarle.

Tra SFOS 22 e SFOS 23 cambiano inoltre le tabelle di stato e messaggi documentate per Add ed Edit. Queste tabelle, da sole, non garantiscono né i codici di risposta effettivi o i testi dei messaggi restituiti, né gli stati del trasporto HTTP o la sicurezza dei tentativi di ripetizione. Durante la migrazione dell’automazione AD, l’interpretazione delle risposte va quindi verificata sulla base della documentazione API della versione in uso e di risposte effettivamente acquisite, invece di mantenere invariate le vecchie associazioni degli errori. Successivamente vanno controllati la configurazione AD salvata e il login di un normale utente di test al servizio previsto.

Validate server certificate

Nelle versioni SFOS attuali si può attivare anche Validate server certificate. Per LDAPS è sensato, perché la firewall non solo connette in modo cifrato, ma verifica anche se si fida del certificato del Domain Controller.

Devono essere corretti questi punti:

1. Il certificato server del Domain Controller viene caricato in Certificates > Certificates > Add > Upload certificate. Un certificato della sola CA va invece importato in Certificates > Certificate authorities; le due liste non vanno confuse.
2. Come indicato da Sophos, in Server IP/domain si inserisce il CNAME; questo nome DNS deve essere incluso nel Subject Alternative Name del certificato server.
3. La firewall deve poter risolvere internamente il CNAME.
4. Data e ora su firewall e Domain Controller sono corrette.

Se la risoluzione DNS interna non risolve correttamente un CNAME o il nome del Domain Controller, può aiutare un DNS Host Entry in Network > DNS > DNS host entry.

Dominio NetBIOS e nome dominio

Sophos Firewall richiede sia l’informazione sul dominio NetBIOS sia il nome dominio. Entrambi devono corrispondere esattamente al dominio AD.

Il dominio NetBIOS si trova per esempio in Active Directory Users and Computers nelle proprietà del dominio.

Il nome dominio è il nome DNS del dominio, per esempio ad.example.com.

Errori tipici in questo punto:

• NetBIOS name e DNS domain name vengono confusi.
• Il Domain Controller inserito appartiene a un altro dominio.
• La firewall non riesce a risolvere il nome DNS del Domain Controller.
• Una firewall di rete o Windows Firewall blocca la connessione tra firewall e Domain Controller.

Account di servizio e password

Per l’accesso ad Active Directory conviene usare un account di servizio dedicato. Un account Domain Admin non è necessario per normali query LDAP e aumenta inutilmente il rischio.

Indicazioni utili:

• account dedicato per la firewall, per esempio svc-sophos-fw-ldap
• solo i diritti di lettura necessari
• owner documentato per cambi password
• password lunga e univoca
• nessun login interattivo, se le policy AD lo permettono in modo pulito
• monitoring o promemoria prima della scadenza password

Se la password dell’account di servizio scade o viene cambiata, la firewall non può più interrogare utenti e gruppi. In seguito sembra spesso un problema VPN, portale o regola utente, anche se la causa reale è nel collegamento AD.

Sicurezza della connessione e LDAPS

Negli ambienti produttivi conviene preferire LDAPS. Il Domain Controller deve disporre di un certificato server adatto. Se Validate server certificate è attivo, seguire la procedura Sophos descritta sopra per importare il certificato server; un eventuale certificato CA necessario va importato separatamente come Certificate Authority.

Verificare:

• la porta 636 è raggiungibile dall’interfaccia firewall al Domain Controller
• il certificato del Domain Controller è valido
• il nome del certificato corrisponde al nome DNS usato
• il certificato server e, se necessario, la CA emittente sono importati ciascuno nell’elenco certificati corretto
• data e ora su firewall e Domain Controller sono corrette

Rimane un limite importante del prodotto: SFOS 22 attualmente non supporta l’applicazione rigorosa di LDAP Channel Binding e LDAP Signing. LDAPS con convalida del certificato protegge la connessione, ma non dimostra la conformità a una policy di sicurezza AD che impone channel binding o signing. Se l’organizzazione richiede questa applicazione, validare l’integrazione rispetto alla specifica policy AD prima del rollout e non approvarla basandosi soltanto su un Test connection riuscito.

Per i certificati è importante anche la distribuzione della CA. Per distribuire la CA di Sophos Firewall ai client si adatta Distribuire il certificato CA Sophos Firewall per HTTPS Scanning. Per LDAPS è invece decisiva soprattutto la CA del Domain Controller o della PKI interna.

Collegare Microsoft Entra Domain Services

Un dominio gestito Microsoft Entra Domain Services può essere collegato come un server Active Directory. Sophos indica WebAdmin, Captive Portal, User Portal, Client Authentication Agent e Remote Access SSL VPN. Non si tratta di un collegamento SSO diretto a Entra ID; in particolare, questa documentazione non ne deduce il supporto del VPN Portal.

Per l’uso in produzione, attivare Secure LDAP e consentire la porta 636 dal percorso firewall scelto al dominio gestito. Il certificato server deve includere l’Extended Key Usage Server Authentication. Se possibile, evitare di rendere LDAPS accessibile pubblicamente: usare una connessione privata tramite reti Azure o IPsec e limitare nella Network Security Group l’accesso all’indirizzo sorgente necessario.

La configurazione di esempio ufficiale Sophos usa l’IP pubblico di Secure LDAP, SSL/TLS, la porta 636, DisplayName e mail e disattiva Validate server certificate. La connessione privata tramite reti Azure o IPsec è un’ulteriore raccomandazione di sicurezza Sophos. La verifica del certificato con un nome corrispondente e una catena di trust corretta è invece una proposta di hardening Avanet da provare nel proprio ambiente prima della produzione; non va presentata come parte dell’esempio ufficiale. Gli utenti Entra devono prima accedere e cambiare la password affinché vengano creati e sincronizzati gli hash Kerberos/NTLM; l’account di bind deve appartenere al gruppo amministratori Entra Domain Services configurato.

Display attribute ed Email attribute

Il Display attribute determina come gli utenti vengono mostrati in Sophos Firewall. Tra gli attributi della directory che si possono incontrare e che vanno verificati nel proprio ambiente prima dell’uso rientrano:

• sAMAccountName
• userPrincipalName
• displayName
• name

Questi valori non sono universalmente intercambiabili. Sono determinanti lo schema della directory, l’univocità e il risultato con un utente di prova. Per Entra Domain Services Sophos documenta DisplayName; ciò non costituisce una regola generale per l’AD locale.

Gli attributi si possono verificare in Active Directory Users and Computers quando Advanced Features è attivo.

L’attributo e-mail è normalmente mail. È rilevante soprattutto se la firewall deve associare agli utenti informazioni legate all’e-mail.

Search base e gruppi

La search base definisce quale parte di Active Directory viene cercata dalla firewall. Per un intero dominio un esempio sarebbe:

DC=ad,DC=example,DC=com

Per una singola OU il percorso può essere, per esempio:

OU=Users,OU=Company,DC=ad,DC=example,DC=com

Il Distinguished Name di una OU si trova negli attributi della OU in Active Directory Users and Computers.

Una search base troppo ampia spesso funziona, ma rende la configurazione meno chiara. In produzione è meglio:

• OU dedicata o search base chiara per gli utenti rilevanti
• gruppi AD separati per VPN, portali o regole firewall
• nessun riutilizzo casuale di grandi gruppi di reparto
• test dell’import gruppi dopo modifiche
• rimozione regolare di gruppi vecchi o vuoti

Import gruppi troppo ampi possono gravare nel tempo anche sulla gestione utenti interna della firewall. Se si creano molti vecchi utenti o gruppi e in seguito i download nel VPN Portal falliscono in modo inatteso, aiuta verificare il limite User ID di Sophos Firewall.

Importante per Remote Access: in SFOS 21.5 MR1 Sophos ha modificato il comportamento in modo che L2TP e PPTP non vengano più attivati automaticamente durante l’import di gruppi da Active Directory e Microsoft Entra ID. Questo riduce la superficie d’attacco involontaria, ma va verificato dopo gli upgrade se vecchi processi Remote Access facevano affidamento su tale comportamento. Configurare L2TP Remote Access su Sophos Firewall spiega l’assegnazione esplicita dei membri, il limite della Main Group e la verifica.

Importare gruppi e capire gli utenti

Dopo l’aggiunta del server AD, i gruppi AD non sono automaticamente tutti presenti nella firewall. I gruppi vengono importati tramite l’assistente:

Authentication > Servers > Import

Procedura:

1. Selezionare il server AD e avviare Import.
2. Selezionare il Base DN per la ricerca gruppi.
3. Selezionare i gruppi AD necessari.
4. Verificare le Group Policies comuni.
5. Controllare la selezione e completare l’import.
6. In Authentication > Groups verificare se i gruppi sono presenti correttamente.

Se AD deve essere il metodo di autenticazione principale per questa procedura, andare in Authentication > Services, selezionare il server AD configurato in Firewall authentication methods, spostarlo nella prima posizione dell’elenco dei server selezionati e fare clic su Apply. Verificare poi i gruppi importati in Authentication > Groups e far accedere nuovamente un utente di test per aggiornare l’assegnazione ai gruppi. Questa prima posizione riguarda la procedura con AD come metodo principale, non ogni ordine di server esistente.

Gli utenti compaiono in Authentication > Users solo dopo aver effettuato l’accesso a un servizio, per esempio User Portal, VPN Portal, Captive Portal o Remote Access VPN. A ogni accesso, la firewall verifica di nuovo quali gruppi importati appartengono all’utente e aggiorna l’associazione.

Se nessun gruppo AD di un utente esiste sulla firewall, l’utente riceve la Default group configurata in Authentication > Services. Il valore predefinito del prodotto è Open group. Prima del rollout va comunque verificato il valore effettivo, perché potrebbe essere stato modificato e determina direttamente le impostazioni ereditate.

In ambienti HA si importano i gruppi AD sul dispositivo Primary. Lo stesso vale per la pulizia di vecchi utenti AD con Purge AD users.

La procedura completa per gestire e verificare policy di gruppo, Default Group, gruppo principale, override degli utenti e comportamento dei gruppi multipli in base alla funzione è descritta in Gestire correttamente i gruppi utenti e il gruppo principale su Sophos Firewall.

Main Group, ordine gruppi e gruppi annidati

Un utente AD può appartenere a più gruppi. Sophos Firewall distingue:

• Group: Il primo gruppo corrispondente nella lista gruppi della firewall. È la Main Group dell’utente.
• Other group memberships: Altri gruppi importati in cui l’utente è membro.
• Group order: Ordine in Authentication > Groups. Decide quale gruppo diventa Main Group in caso di più corrispondenze.

Questo è importante perché non tutte le funzioni valutano più gruppi. Alcune usano solo la Main Group. Se un utente è in più gruppi AD, può quindi applicarsi una policy diversa da quella attesa.

L’ordine dei gruppi si cambia qui:

Authentication > Groups > Reorder

I gruppi AD annidati non sono supportati. Se una firewall policy deve valere per un sottogruppo, questo sottogruppo deve essere importato direttamente. Non basta importare solo il gruppo AD superiore.

Anche il gruppo AD primario di un utente non viene preso come una normale membership. Questo riguarda soprattutto il gruppo standard AD Domain Users. Per le firewall policies bisogna quindi usare gruppi di sicurezza espliciti e inserire direttamente gli utenti in questi gruppi.

Funzioni che supportano più gruppi

Per l’esercizio questa distinzione è particolarmente importante.

Più gruppi AD possono essere considerati per:

• Firewall rules: resta decisivo l’ordine delle regole firewall.
• SSL/TLS inspection rules: si applica la prima Inspection Rule corrispondente.
• Web policies: prima corrisponde la firewall rule, poi la regola Web Policy adatta.
• IPS policies: viene applicata la policy della regola corrispondente.
• Application control policies: la valutazione avviene tramite la firewall rule corrispondente.
• SD-WAN routes: criteri utente o gruppo possono considerare più gruppi.
• Policy test: utile per verificare group e policy matching.
• Remote access SSL VPN: vengono considerate le autorizzazioni da Full e Split Tunnel Policies corrispondenti. Con Full Tunnel, Full Tunnel ha priorità.
• Clientless SSL VPN: le autorizzazioni dei gruppi corrispondenti vengono combinate.

Solo Main Group o utenti espliciti vengono considerati per:

• WAF rules
• Remote access IPsec VPN
• L2TP e PPTP
• Hotspots
• MFA, se MFA viene applicata specificamente a gruppi
• Surfing quota, Access time, Network traffic e Traffic shaping
• Quarantine digest, MAC binding e Sign-in restriction

Access Time di Sophos Firewall per utenti e gruppi mostra come verificare il gruppo principale per un accesso utente basato sull’orario e distinguere le eccezioni utente.

Lo stesso limite della Main Group vale per i crediti di tempo e dati basati sul consumo. Surfing Quota e Network Traffic Quota su Sophos Firewall illustra la procedura completa.

Esempio pratico: un utente è in VPN-Users e Firewall-Admins. Per SSL VPN la membership multipla può funzionare. Per IPsec Remote Access o l’assegnazione MFA per gruppi può contare invece solo la Main Group. Per Remote Access e accessi amministrativi bisogna quindi testare consapevolmente quale gruppo è impostato come Group nell’oggetto utente.

Più server Active Directory

Si possono configurare più server AD. Per i Firewall authentication methods vale una semantica importante: la firewall passa al server successivo solo se quello precedente non è raggiungibile; credenziali rifiutate non attivano un normale fallback. Questo ordine non è quindi né bilanciamento del carico né un sostituto di un design AD pianificato correttamente.

Raccomandazioni:

• Impostare consapevolmente l’ordine dei server in Authentication > Services.
• Documentare per ogni server search base e dominio.
• Non usare gruppi contraddittori con lo stesso nome in sorgenti diverse.
• Pianificare DNS e AD in modo pulito in caso di più UPN o più domini.
• Testare il failover non solo con Test connection, ma con un vero login utente.
• Se un server AD non è disponibile, il messaggio per l’utente può sembrare una password errata.

Se più UPN appartengono alla stessa infrastruttura di dominio, i record DNS e la configurazione AD server devono corrispondere al dominio rispettivo. È importante che search base, Domain Name e risoluzione server appartengano allo stesso contesto.

Per più domini UPN sullo stesso server di dominio, Sophos descrive questa configurazione specifica: creare un record DNS per ogni dominio che punti all’indirizzo IP di quel server e una configurazione di server AD separata sulla firewall per ogni dominio. Usare il rispettivo dominio AD come Search query in formato DN LDAP, per esempio DC=ad,DC=example,DC=com per ad.example.com. Sostituire i valori con i propri domini e verificare accesso e assegnazione ai gruppi per ogni dominio UPN. Non è una procedura di bilanciamento del carico o failover tra più Domain Controller; con LDAPS, il nome del server usato deve continuare a essere compatibile con la validazione del certificato.

Testare la connessione

Dopo il salvataggio, la connessione va testata direttamente. Il test verifica se la firewall raggiunge il server e se i dati inseriti sono corretti a livello di base.

Un test riuscito non significa automaticamente che regole utente, SSO o VPN funzionino già. Dopo vanno verificati almeno questi punti:

1. Utenti o gruppi AD vengono trovati correttamente.
2. Un utente di test può autenticarsi nel punto previsto.
3. La membership di gruppo corrisponde all’autorizzazione firewall o VPN desiderata.
4. Il Log Viewer mostra eventi di autenticazione comprensibili.
5. Remote Access VPN, User Portal o Captive Portal funzionano con un utente di test normale.
6. MFA viene richiesta, se prevista per il caso d’uso.
7. Il server AD è inserito nella posizione desiderata sotto Authentication > Services nelle Firewall Authentication Methods.

Se non è ancora chiaro se fallisca la selezione del servizio, l’identità dell’utente, la Main Group, la quota o soltanto la successiva regola firewall, Risolvere sistematicamente gli errori di autenticazione su Sophos Firewall separa questi livelli con un caso di test riproducibile.

Per Remote Access con Sophos Connect il passo successivo adatto è configurare Sophos Connect Client su Sophos Firewall.

Validazione per caso d’uso

Dopo il collegamento AD non basta documentare un singolo test di connessione. Funzioni diverse usano l’integrazione AD in modi diversi. Per ogni caso d’uso previsto va quindi fatto un test dedicato.

• Import gruppi: cercare il gruppo AD rilevante e importarlo sulla firewall. Se qualcosa non torna, il gruppo non viene trovato o contiene utenti inattesi.
• User Portal: testare il login con un normale utente AD. Un sintomo tipico è un login fallito, anche se il test del server è riuscito.
• Remote Access VPN: verificare VPN login, autorizzazione gruppo, MFA e accesso a destinazioni interne. In caso di errore l’utente può autenticarsi, ma non ricevere una policy adatta o accesso.
• Regola firewall basata su utente: generare traffico di test e verificare utente, gruppo e Rule ID nel Log Viewer. Se l’associazione non funziona, il traffico appare solo con IP o incontra un’altra regola.
• Captive Portal: testare login browser e traffico successivo. Gli errori si mostrano spesso così: il login funziona, ma l’utente poi non viene associato correttamente.
• AD SSO o STAS: verificare Live Users e Log Viewer dopo login Windows. In caso di problemi, l’utente resta sconosciuto o viene assegnato a un IP errato.

Questa separazione fa risparmiare tempo in esercizio. Un test LDAP riuscito dimostra solo che server, porta, bind account e search base sono in linea di principio raggiungibili. Non dimostra che gruppi VPN, MFA o traffico utente in regole firewall vengano valutati correttamente.

Per regole basate su utenti bisogna sempre generare un vero test di traffico e controllare nel Log Viewer se utente, gruppo, Firewall Rule ID e azione corrispondono alle attese. Se è visibile solo l’indirizzo IP, la causa è spesso SSO, STAS, Captive Portal o l’ordine delle regole firewall. Per ambienti STAS si adatta Configurare STAS su Sophos Firewall come articolo successivo.

Se Sophos Endpoint invia già Security Heartbeat, Synchronized User ID Authentication può trasmettere al firewall un utente di dominio Windows 10 senza un agente di autenticazione aggiuntivo. Il processo richiede comunque la convalida AD corrispondente e un vero test della regola.

Considerare Active Directory SSO

Active Directory SSO è un’area operativa propria. La semplice connessione AD server ne è una base, ma SSO richiede anche condizioni client, browser, DNS, Kerberos o NTLM coerenti.

Per Web Authentication, Sophos Firewall supporta AD SSO classico con Kerberos e NTLM. Kerberos è più pulito e più veloce, ma richiede più precisione su FQDN, DNS, SPN e fiducia del browser. NTLM è più tollerante e in ambienti vecchi può essere un fallback pragmatico, ma non dovrebbe diventare in modo silenzioso l’unico metodo funzionante.

Sophos colloca NTLM, avviato dal browser, dopo General Authentication Client, Clientless single sign-on e Client-based single sign-on. NTLM viene usato come fallback solo quando tali assegnazioni non si applicano; se fallisce anche NTLM, viene visualizzato Captive Portal. Se un utente compare con un metodo inatteso in Current activities > Live users, occorre controllare prima il Client type visualizzato e le fonti di identità già attive, quindi valutare modifiche allo SPN o a Web Authentication.

L’impostazione Kerberos & NTLM propone entrambi i metodi al browser, ed è il client a decidere quale usare. Non esiste una modalità esclusivamente Kerberos perché non è supportata dalla specifica HTTP. Per il traffico web trasparente, la firewall reindirizza l’autenticazione alla porta TCP 8091.

Quando più utenti condividono lo stesso IP RDS o del terminal server, la normale associazione IP non è sufficiente. Per il traffico HTTP e HTTPS inviato esclusivamente tramite un proxy esplicito, Per-Connection AD SSO per host multiutente spiega la procedura dedicata e la distinzione rispetto a SATC.

⚠️ Nota di upgrade per SFOS 22: Dopo un upgrade da SFOS 21.5 o precedente a SFOS 22.0 GA, AD SSO con Kerberos e NTLM può smettere di funzionare. Le regole basate sull’identità non riconoscono più gli utenti di dominio interessati, mentre il resto del traffico firewall continua a transitare. Sophos ha corretto l’errore in SFOS 22.0 MR1 Build 490. AD SSO va testato con traffico di un utente reale prima e subito dopo l’upgrade. Riparare AD SSO dopo un upgrade a SFOS 22 spiega come verificare nasm.log, eseguire il cleanup NASM mirato e controllare il risultato con traffico utente reale.

Il flusso AD SSO è quindi più di un semplice Test connection sul server AD:

Sophos descrive la registrazione della firewall nel dominio Windows come la creazione di un oggetto per la firewall sul Domain Controller primario. Questo contesto riguarda il domain join per AD SSO; le sole query LDAP/LDAPS alla directory non richiedono automaticamente tale join. I diritti necessari per il join restano separati dai diritti di lettura dell’account di bind LDAP.

1. Impostare un hostname o FQDN in Administration > Admin and user settings. Per Kerberos usare un FQDN scritto in minuscolo, con una parte host lunga al massimo 15 caratteri, affinché NetBIOS name, oggetto computer AD e SPN non divergano.

   Esempio: la firewall è configurata come fw01.edge.example.com e il dominio AD si chiama corp.example.com. Durante il Domain Join, SFOS usa l’hostname NetBIOS fw01 con il dominio AD. Il nome noto in AD è quindi fw01.corp.example.com, non automaticamente il FQDN configurato sulla firewall. Il nome di reindirizzamento per Kerberos trasparente deve corrispondere allo SPN HTTP registrato in AD ed essere risolvibile nel DNS.

2. In Administration > Admin and user settings, impostare la Redirection Location in modo che i client possano risolvere il nome e considerare attendibile la destinazione. Negli scenari Kerberos trasparenti questo nome deve corrispondere allo SPN. Un account con accesso in lettura ad AD può eseguire la seguente query mirata e di sola lettura su un sistema Windows:

   setspn -Q HTTP/fw01.corp.example.com
   

   Sostituire il valore di esempio con il proprio FQDN di reindirizzamento. L’output deve mostrare esattamente lo SPN e l’oggetto computer previsti; nessun risultato o un risultato su un altro oggetto va chiarito con il responsabile AD prima del rollout.

3. Salvare il server AD sotto Authentication > Servers ed eseguire Test connection. Questo test verifica connettività e credenziali, ma non prova ancora che AD SSO funzioni.

4. In Authentication > Services, portare il server AD nella posizione desiderata in Firewall authentication methods. AD SSO passa al server successivo solo se quello precedente non è raggiungibile, non se le credenziali vengono rifiutate.

5. Sotto Administration > Device access, attivare AD SSO per le zone necessarie. Di solito è LAN o una rete client interna chiaramente definita, non tutte le zone in modo generico.

6. Sotto Authentication > Web authentication, impostare If Active Directory (AD) SSO is configured su Kerberos & NTLM oppure consapevolmente su NTLM only.

7. Nelle regole firewall interessate, verificare se Match known users e, per richieste web sconosciute, Use web authentication for unknown users corrispondono al flusso voluto. Una regola separata e ben nominata per HTTP e HTTPS è spesso più semplice da gestire.

In Authentication > Services, HTTP challenge redirect on intranet zone dovrebbe rimanere attivo. Se un sito web ospitato su Internet avvia una challenge NTLM, la firewall gestisce così lo scambio tramite l’IP dell’interfaccia locale nella zona intranet. Se l’opzione viene disattivata, il browser può inviare le credenziali attraverso Internet. Non si tratta di un’impostazione di compatibilità innocua.

Quando Use web authentication for unknown users autentica traffico HTTPS in modalità trasparente, la firewall decifra la connessione per l’autenticazione indipendentemente dalle impostazioni della regola firewall o della regola SSL/TLS Inspection. Questo deve essere coerente con il design TLS Inspection e certificati; altrimenti AD SSO sembra rapidamente un problema di browser, certificato o webfilter.

Per la validazione è decisivo il Log Viewer. Sotto Log viewer > Authentication, all’avvio della connessione AD SSO dovrebbero comparire messaggi come Kerberos authentication initialized successfully e NTLM authentication channel established successfully. Messaggi come Cannot initialize Kerberos authentication o Cannot establish NTLM authentication channel sono problematici. La colonna Log Comp mostra inoltre se un client usa Kerberos o NTLM.

Sophos Firewall offre uno dei due metodi al browser solo dopo che Kerberos e NTLM sono stati inizializzati correttamente sulla firewall. Un fallback NTLM visibile non è quindi un motivo per saltare il controllo di Kerberos. DNS, SPN e ora di sistema devono essere coerenti; per impostazione predefinita, gli orologi coinvolti in Kerberos non possono differire di più di cinque minuti.

I ruoli degli account vanno tenuti separati. L’account di bind LDAP richiede solo i diritti di lettura necessari per le query della directory. L’operazione di domain join per AD SSO richiede invece un account Domain Admin oppure un account con diritti delegati per creare l’oggetto computer o lo SPN. In ambienti HA, con più server AD o dopo un upgrade, potrebbe servire un nuovo domain join; occorre quindi poter disporre di credenziali adeguate per il join, senza assegnare tali privilegi elevati all’account di bind LDAP.

Da SFOS 21.5 MR1 Windows Server 2025 è supportato per Active Directory SSO con NTLM e Kerberos. SFOS 22 porta inoltre componenti Samba aggiornati e rimuove vecchi metodi di cifratura. Per gli admin significa:

• Testare AD SSO dopo upgrade dei Domain Controller.
• Verificare autenticazione e associazione utenti dopo upgrade SFOS.
• Documentare dipendenze Kerberos/NTLM in ambienti vecchi.
• Non pianificare vecchie cifrature come soluzione permanente.
• Verificare DNS request routes per domini AD se la firewall non trova i service record AD tramite il resolver normale.
• Non confondere SSO con Entra ID SSO per Sophos Connect.

Se è previsto Entra ID SSO per VPN o VPN Portal, usare l’articolo separato Configurare Microsoft Entra ID SSO per Sophos Connect e VPN Portal. È un modello di autenticazione diverso rispetto al classico collegamento AD locale.

Troubleshooting

Il test di connessione fallisce

Per prima cosa controllare raggiungibilità, porta, routing e DNS. Poi verificare connection security, certificato, account di servizio e password.

Controlli pratici:

• La firewall può raggiungere il Domain Controller via IP?
• Il nome DNS viene risolto correttamente?
• La porta 389 o 636 è raggiungibile?
• SSL/TLS corrisponde davvero alla porta e al certificato?
• L’account di servizio è attivo e non bloccato?
• Sul lato Windows esistono regole firewall o requisiti LDAP Signing?

L’utente non viene trovato

Spesso la search base è errata o troppo stretta. Verificare il distinguishedName della OU e assicurarsi che l’utente si trovi davvero dentro la search base. Anche maiuscole, caratteri speciali e display attribute scelto possono complicare la ricerca.

Il gruppo viene importato, ma l’accesso non funziona

Verificare tutta la catena di autorizzazione: gruppo AD, gruppo firewall importato, regola VPN/portale/firewall assegnata, MFA e posizione della regola. Per Remote Access la configurazione VPN corretta deve inoltre essere collegata al gruppo.

Se l’utente è in più gruppi AD, controllare anche la Main Group in Authentication > Users. In particolare MFA, Remote access IPsec VPN, WAF, Hotspots e diverse impostazioni utente considerano solo la Main Group.

I nuovi utenti AD non riescono ad accedere al VPN Portal

Se un utente AD esistente può utilizzare il VPN Portal, ma un utente appena creato con autorizzazioni analoghe non riesce a farlo, confrontare prima l’assegnazione dei gruppi, il metodo di Remote Access e la versione del firmware. In Authentication > Users, Group mostra la Main Group; gli altri gruppi importati sono elencati in Other group memberships. SSL VPN può considerare più appartenenze ai gruppi, mentre IPsec Remote Access considera solo la Main Group o un utente selezionato esplicitamente.

Per la diagnosi:

1. Confrontare il nuovo utente interessato con un utente esistente funzionante.
2. Controllare la Main Group e Other group memberships.
3. In Authentication > Services, controllare i VPN portal authentication methods; in Administration > Device access, la zona di origine consentita; e nella policy di Remote Access, l’utente o il gruppo.
4. Registrare la versione e il build di SFOS.

Sophos ha corretto con NC-180824 un errore che impediva ai nuovi utenti AD appartenenti a una Secondary AD Group di accedere al VPN Portal. La correzione è inclusa in SFOS 22.0 MR2 Build 546, pubblicato il 14 luglio 2026. Sophos non indica né la versione in cui è stato introdotto il problema né un workaround ufficiale. Se la configurazione e la logica dei gruppi sono corrette, aggiornare un’installazione precedente interessata a SFOS 22.0 MR2 o versione successiva, quindi ripetere il test con un utente AD che accede alla firewall per la prima volta e la cui autorizzazione VPN viene concessa esclusivamente tramite la Secondary Group interessata in una policy SSL VPN.

⚠️ Non riordinare i gruppi sulla base di un sospetto, non eliminare prematuramente gli utenti con Purge AD users e non ricreare i gruppi. Sophos non documenta queste misure come soluzioni per NC-180824 e potrebbero modificare altre autorizzazioni.

Un nuovo gruppo AD non appare automaticamente

I gruppi AD appena creati non vengono sincronizzati automaticamente nella firewall. Il gruppo deve essere importato di nuovo tramite l’assistente o creato manualmente in modo adatto. Poi un utente di test dovrebbe autenticarsi nuovamente, così la firewall rivaluta le membership.

Un utente cancellato in AD resta visibile sulla firewall

Gli utenti AD che hanno già effettuato login possono restare visibili sulla firewall. Se utenti sono stati cancellati in AD, bisogna rimuoverli prima in AD e poi usare Purge AD users sulla firewall. In ambienti HA questo si fa sul dispositivo Primary.

Il login funziona, ma la regola utente non viene applicata

In questo caso spesso non è LDAP il problema, ma associazione utente, SSO, posizione della regola o logging. Nel Log Viewer dovrebbe essere visibile se il traffico viene valutato con identità utente o solo con indirizzo IP. Per l’analisi regole si adatta Testare una regola firewall con Log Viewer, Policy Test e Packet Capture.

AD SSO ricade su Captive Portal o NTLM

Se AD SSO non funziona in modo trasparente, di solito sono coinvolti Redirection URL, SPN, risoluzione DNS o fiducia del browser. Per Kerberos, il nome verso cui la firewall reindirizza deve appartenere allo SPN HTTP corrispondente ed essere risolvibile dal client. Per NTLM, il browser deve considerare attendibile il nome di destinazione, altrimenti chiede credenziali o ricade sul Captive Portal.

In pratica si controllano prima Administration > Admin and user settings, la risoluzione DNS del nome di redirect, setspn -Q HTTP/fw01.corp.example.com su un client Windows e Log viewer > Authentication. Se appare solo NTLM invece di Kerberos, spesso è un indizio di problema SPN o browser trust, non necessariamente di connessione AD server rotta.

Il certificato selezionato in Admin console and end-user interaction > Certificate deve includere l’hostname o FQDN di redirect ed essere considerato attendibile dagli endpoint. Il certificato autofirmato preinstallato della firewall normalmente non soddisfa nessuno dei due requisiti per un nome appena configurato. Un avviso di certificato non va ignorato, ma risolto con un certificato pubblico o interno corrispondente.

Per NTLM, la fiducia può essere limitata al nome di redirect interno. In Windows, Microsoft Edge e Google Chrome ereditano l’impostazione da Internet Options > Security > Local intranet > Sites > Advanced. In Firefox, aggiungere lo stesso FQDN a network.automatic-ntlm-auth.trusted-uris sotto about:config. Consentire solo il nome interno effettivamente utilizzato, non un dominio ampio o siti web arbitrari.

Dopo un upgrade alcuni login non funzionano più

Dopo upgrade SFOS o dei Domain Controller bisogna prestare attenzione soprattutto a SSO, Kerberos/NTLM, vecchi metodi di cifratura, certificati e import gruppi. Se sono interessati solo alcuni utenti, controllare anche caratteri speciali, spazi, UPN, membership gruppi e stato password.

Per log di autenticazione e servizi aiuta Sophos Firewall Troubleshooting: Services e Logs.

La connessione non funziona con verifica certificato attiva

Se Validate server certificate è attivo, certificato, CNAME, risoluzione DNS e trust CA devono combaciare. Cause frequenti sono un certificato con nome diverso, una CA interna mancante sulla firewall o un CNAME che la firewall non riesce a risolvere.

Annullare la modifica e proseguire in sicurezza

Prima delle modifiche, documentare l’ordine dei server, i servizi usati, i gruppi e le impostazioni dei certificati. Se il collaudo fallisce, ripristinare prima l’ordine precedente, il metodo di connessione cifrato originale e la relativa porta. Un Plaintext di prova sulla porta 389 resta esclusivamente una breve diagnosi e non va mai lasciato come rollback di produzione.

Se occorre ripristinare l’intera configurazione, usare il backup scaricato in precedenza da Backup and firmware > Backup and restore. Il ripristino sostituisce la configurazione corrente, annulla le modifiche successive e riavvia la firewall; deve quindi avvenire in una finestra di manutenzione. Un rollback del firmware avvia la partizione precedente con la relativa configurazione e interrompe anch’esso le sessioni. Il rollback automatico del firmware interviene solo se la migrazione della configurazione fallisce, non per un guasto AD SSO che emerge soltanto durante l’esercizio.

Dopo ogni ritorno, ripetere Test connection, un normale login a un servizio, la verifica dell’effetto dei gruppi e, per SSO, un accesso utente reale con Log viewer > Authentication. In HA, import gruppi e Purge AD users vanno eseguiti sul dispositivo Primary; testare l’indisponibilità del DC secondario previsto solo in una finestra di manutenzione autorizzata, confermando che il primo server sia davvero irraggiungibile e che il login riesca tramite il secondo.

Checklist operativa

Prima della configurazione:

• Domain Controller, porta e nome DNS definiti.
• LDAPS e catena certificati verificati.
• Account di servizio dedicato creato.
• Search base e gruppi rilevanti definiti.
• Design MFA e Remote Access chiarito.

Dopo la configurazione:

• Test di connessione riuscito.
• Server AD inserito come Authentication Method primaria o corretta.
• Utente e gruppo di test verificati.
• Gruppi AD importati tramite l’assistente.
• Main Group di un utente di test controllata.
• In caso di più gruppi: login al VPN Portal testato con un utente esistente e con un utente che accede alla firewall per la prima volta, la cui autorizzazione viene concessa esclusivamente tramite una Secondary Group in una policy SSL VPN.
• Remote Access, portale o regola utente testati con un utente normale.
• Log Viewer mostra gli eventi di autenticazione attesi.
• Per AD SSO, i messaggi Kerberos/NTLM sono verificati nell’Authentication log.
• Scadenza password dell’account di servizio documentata.
• Test di upgrade pianificato per AD SSO, import gruppi e processi VPN.

In esercizio:

• Rimuovere gruppi non più necessari.
• Importare attivamente nuovi gruppi AD, senza aspettarsi sincronizzazione automatica.
• Controllare regolarmente l’account di servizio.
• Rinnovare i certificati LDAPS prima della scadenza.
• Verificare l’ordine gruppi dopo modifiche AD.
• Usare Named Admins e MFA per accessi amministrativi.
• Non trattare errori di autenticazione solo come problema utente, ma verificare anche AD, rete, certificati e regole firewall.

FAQ