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.

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.

⚠️ 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 di servizio con cui la firewall esegue le query AD. Usare un account dedicato con diritti di lettura, non un Domain Admin. A seconda dell’ambiente funzionano il logon name breve, DOMAIN\user oppure un UPN come svc-firewall-ldap@example.local.
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. Simple è non cifrato e dovrebbe essere usato al massimo per test.
9. Display name attribute: Attributo AD che la firewall usa come nome visualizzato. Valori comuni sono sAMAccountName, userPrincipalName, displayName o name. Per esercizio e troubleshooting è più importante un attributo univoco che un nome bello da leggere.
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 example.local o 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=example,DC=local oppure più mirati come OU=Users,OU=Company,DC=example,DC=local. Più stretta è la search base, più ordinato e performante resta l’import.

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.

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. La CA che ha emesso il certificato del Domain Controller è nota alla firewall in Certificates > Certificates.
2. Il valore in Server IP/domain corrisponde al nome del certificato o a un Subject Alternative Name.
3. Se si usa un CNAME, la firewall può risolvere questo nome internamente.
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 example.local o 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

Per ambienti produttivi conviene preferire LDAPS. Serve un certificato adatto sul Domain Controller e la firewall deve fidarsi della CA emittente.

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
• la CA emittente è nota alla firewall, se viene richiesta la verifica
• data e ora su firewall e Domain Controller sono corrette

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.

Display attribute ed Email attribute

Il Display attribute determina come gli utenti vengono mostrati in Sophos Firewall. Valori tipici:

• sAMAccountName
• userPrincipalName
• displayName
• name

sAMAccountName è spesso robusto e breve negli ambienti AD classici. userPrincipalName è più vicino ai nomi di login moderni e alle identità cloud. displayName è leggibile per le persone, ma non sempre abbastanza univoco per esercizio e troubleshooting.

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=example,DC=local

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

OU=Users,OU=Company,DC=example,DC=local

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.

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.

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 un utente non viene trovato in nessun gruppo AD importato, finisce nella Default Group. Questa Default Group si vede in Authentication > Services nelle Firewall Authentication Methods. Di default è spesso la Open group.

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.

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

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. La firewall valida gli utenti nell’ordine configurato nel WebAdmin. Questo non sostituisce un design AD pianificato in modo pulito.

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.

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.

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.

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.

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

1. Impostare un hostname o FQDN sotto Administration > Admin and user settings. Per Kerberos usare un FQDN, scritto in minuscolo, con parte host lunga al massimo 15 caratteri, così NetBIOS name, oggetto computer AD e SPN non divergono.
2. Sotto Administration > Admin and user settings, impostare la Redirection Location in modo che i client possano risolvere il nome e fidarsi della destinazione. Negli scenari Kerberos trasparenti questo nome deve corrispondere allo SPN. Su un client Windows, setspn -Q HTTP/* aiuta a verificare gli SPN HTTP esistenti.
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. Sotto Authentication > Services, portare il server AD nella posizione desiderata in Firewall authentication methods. AD SSO usa i server in questo ordine e passa al successivo solo se quello precedente non è raggiungibile.
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.

Se Use web authentication for unknown users deve autenticare traffico HTTPS in modalità trasparente, la firewall può decifrare la connessione per il processo di autenticazione. 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.

La questione dell’account è importante. Per normali query LDAP spesso basta un Domain User con diritti di lettura. Per AD SSO, però, la firewall deve entrare nel dominio e creare un oggetto computer oppure uno SPN. Serve quindi un account Domain Admin oppure un account con diritti delegati correttamente per il domain join. In ambienti HA, con più server AD o dopo upgrade, la firewall potrebbe dover eseguire nuovamente il join. Per questo non conviene fare il join una volta con Domain Admin e poi passare a un account più debole se quell’account non può fare il rejoin in seguito.

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.

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/* 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.

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.

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.
• 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