Vai al contenuto
Avanet
Accedi

Gestire correttamente i gruppi utenti e il gruppo principale su Sophos Firewall

Sophos Firewall

I gruppi di utenti riuniscono policy comuni per gli utenti autenticati. Prima di modificare un gruppo, chiarisci due aspetti: da dove proviene l’identità e se la funzione interessata valuta solo il Main Group o anche altri gruppi AD. Solo a quel punto potrai stabilire se modificare l’ordine dei gruppi, l’assegnazione di una policy oppure la regola firewall o VPN vera e propria.

Procedura rapida:

  1. Definire la fonte dell’utente e lo scopo del gruppo.
  2. Creare un gruppo locale o importare miratamente il gruppo di directory necessario.
  3. Controllare sotto Authentication > Services l’effettivo Default group oppure sul server Entra il Fallback user group.
  4. In AD documentare l’ordine sotto Authentication > Groups > Reorder e il Main Group previsto.
  5. Disconnettere e riconnettere l’utente pilota. Successivamente controllare sotto Authentication > Users > utente > Policies i campi Group e Other group memberships.
  6. Testare la funzione interessata con un utente autorizzato e uno non autorizzato. Per il traffico di rete controllare inoltre il Firewall Rule ID previsto.

⚠️ Reorder non è una semplice funzione di ordinamento. Per gli utenti AD, uno spostamento può modificare il Main Group e, di conseguenza, MFA, quote, orari di accesso, accesso remoto e altre policy per molti utenti. Annota prima l’ordine, le policy di gruppo e la procedura di ripristino.

Comprendere il modello di gruppo

Un gruppo definisce policy e impostazioni comuni. Non sostituisce né l’autenticazione né una regola firewall. Un utente può quindi trovarsi nel gruppo corretto e comunque non ottenere l’accesso se manca la regola prevista, la policy VPN, la zona, la route o il percorso di ritorno.

Per la risoluzione dei problemi, considera quattro domande distinte:

  1. L’identità proviene dal database locale, Active Directory, LDAP, RADIUS, Microsoft Entra ID o da una mappatura senza client?
  2. Qual è il Main Group?
  3. La funzione interessata supporta ulteriori appartenenze a gruppi AD?
  4. Quale regola o policy elabora il traffico effettivo?

Distinguere tra gruppi locali, importati e clientless

Normal e Clientless sono tipi di gruppo. Importato descrive invece l’origine di un gruppo e non costituisce un Group type distinto.

Un gruppo locale di tipo Normal è adatto agli utenti che effettuano l’accesso. Il gruppo degli utenti locali viene assegnato nell’oggetto utente. Con una fonte utenti esterna, i record locali degli utenti vengono in genere creati soltanto al primo accesso riuscito.

Gli utenti ospiti seguono un ciclo distinto e limitato nel tempo. Creare e gestire in sicurezza utenti ospiti su Sophos Firewall spiega il gruppo predefinito, la validità, il Captive Portal e la pulizia.

I gruppi AD ed Entra vengono importati tramite la procedura guidata del rispettivo server. La directory rimane la fonte delle appartenenze. Per AD, Sophos documenta anche la creazione manuale del gruppo sia in AD sia sul firewall come alternativa. Anche in questo caso occorre verificare l’assegnazione al gruppo e le autorizzazioni dopo un nuovo accesso. La procedura completa per AD, LDAPS e l’importazione è descritta in Collegare Active Directory a Sophos Firewall.

Per un server LDAP generico, Base DN, Authentication attribute, Group name attribute, l’ordine dei server e Default group devono essere configurati in modo coerente. Sophos consiglia memberOf come attributo di gruppo. Collegare un server LDAP a Sophos Firewall illustra questa configurazione.

Un gruppo di tipo Clientless raggruppa utenti senza client e le loro impostazioni comuni. Questi utenti non effettuano l’accesso tramite un client; il firewall controlla il loro accesso in base all’indirizzo IP. L’indirizzo IP fisso viene memorizzato sul singolo utente senza client, non nell’oggetto gruppo. Configurare utenti senza client su Sophos Firewall descrive l’assegnazione IP, la regola e il test negativo.

Non equiparare il gruppo predefinito e il fallback Entra

Sotto Authentication > Services > Firewall authentication methods, Default group definisce quale gruppo un utente riceve da un server di autenticazione esterno se nessuno dei suoi gruppi della directory è presente come gruppo locale. L’impostazione di fabbrica è Open group. Controlla il valore corrente anziché dare per scontato quello predefinito. Per gli ambienti di produzione, Avanet consiglia un gruppo di fallback dedicato e restrittivo, privo di autorizzazioni VPN, quote o autorizzazioni di accesso non intenzionali.

Descrizioni AD discordanti sul primo accesso: La guida alla configurazione AD descrive l’assegnazione automatica alla Default group al primo accesso; le FAQ AD, invece, indicano la Default group solo quando nessuno dei gruppi AD dell’utente è presente sul firewall. La panoramica dei server AD indica espressamente Open group per gli utenti che appartengono solo a una OU e a nessun gruppo della directory, mentre la panoramica dei gruppi e le FAQ fanno riferimento alla Default group configurata. Queste descrizioni non sono coerenti tra loro e non dimostrano l’esistenza di un gruppo specifico per il primo accesso valido universalmente, né di una sua priorità. La Default group configurata va distinta dall’impostazione di fabbrica Open group.

Prima del rollout, verificare la Default group effettiva e le autorizzazioni ereditate da questo gruppo. Verificare separatamente il primo accesso con due nuovi account pilota dedicati: uno con un gruppo AD già importato sul firewall e uno i cui gruppi AD non sono stati importati sul firewall. Per entrambi, controllare sotto Policies i campi Group e Other group memberships, nonché gli accessi consentiti e quelli intenzionalmente non consentiti. In caso di assegnazione inattesa, interrompere il rollout e chiarirne la causa. Non eliminare gruppi di produzione né ampliare le autorizzazioni di fallback a questo scopo.

Microsoft Entra ID SSO utilizza il Fallback user group separato nella configurazione del server Entra. Si applica anche se il server Entra è selezionato sotto Firewall authentication methods. Il gruppo predefinito generale non si applica in questo caso.

Anche l’ordine dei server di autenticazione è rilevante. Sophos Firewall consente al massimo 20 server per metodo di autenticazione e inoltra le richieste nell’ordine mostrato. Non modificare questo ordine per aggirare un problema di gruppo prima di aver verificato il server interessato e la relativa mappatura.

Pianificare l’esempio e documentare lo stato iniziale

L’esempio prevede tre gruppi con funzioni distinte:

  • Local_Contractors: gruppo pilota locale per pochi collaboratori esterni;
  • SFOS_Internet_Standard: gruppo AD importato per il normale accesso a Internet;
  • SFOS_SSLVPN: gruppo AD importato per una policy SSL-VPN.

auth-pilot@example.com funge da account di prova, mentre la regola con registrazione del traffico LAN-Users-to-WAN viene usata per il test del traffico. example.com è un dominio riservato alla documentazione. Sostituisci nomi e utenti in base alla tua convenzione di denominazione. Un nome legato alla funzione come SFOS_SSLVPN rimane comprensibile anche dopo una riorganizzazione.

Annota prima della modifica:

  • ordine attuale dei gruppi;
  • Default group e, se del caso, Fallback user group;
  • policy dei gruppi e override specifici per utente;
  • servizi di autenticazione e policy VPN coinvolti;
  • un accesso amministrativo verificato e un secondo percorso di gestione, se sono interessati Main Group, MFA o restrizioni di accesso;
  • utenti pilota, Main Group previsto e test positivi e negativi.

Creare un gruppo di utenti locale

Vai in Authentication > Groups e seleziona Add:

  1. Inserisci Local_Contractors come nome del gruppo.
  2. In Group type seleziona Normal.
  3. Seleziona solo le policy comuni necessarie:
    • Surfing quota limita il tempo di utilizzo in base a periodo e ciclo.
    • Access time permette o nega l’accesso in intervalli di tempo ricorrenti.
    • Network traffic limita la quantità di dati trasferiti.
    • Traffic shaping assegna una policy QoS con priorità e limiti di larghezza di banda.
  4. Imposta SSL VPN policy, Clientless SSL VPN policy, L2TP, PPTP e IPsec remote access solo per l’accesso effettivamente pianificato. PPTP non è adatto alle nuove architetture; L2TP resta un’opzione di compatibilità limitata, come illustrato in Accesso remoto L2TP su Sophos Firewall.
  5. Limita Sign-in restriction, se possibile, a Selected nodes o Node range in base alle origini necessarie. Selected nodes consente l’accesso solo dagli indirizzi IP specificati; Node range consente l’accesso dagli indirizzi all’interno dell’intervallo IP specificato. Any node permette l’accesso da qualsiasi rete.
  6. Attiva Quarantine digest e MAC binding solo se il gruppo ha bisogno di queste funzioni. Quarantine digest invia alla casella di posta dell’utente un riepilogo delle e-mail trattenute in quarantena. MAC binding limita l’accesso ai dispositivi previsti.
  7. Seleziona Save per salvare.

I nomi dei campi e il loro effetto sono definiti dal prodotto; la selezione dipende dall’ambiente. Un gruppo per l’accesso a Internet non richiede automaticamente VPN, quote o binding MAC. I gruppi con funzioni ben definite sono più facili da testare e riportare allo stato precedente.

Assegnare utenti locali e individuare gli override

Creare e gestire utenti locali normali descrive in dettaglio nome utente, password, ereditarietà del gruppo e collaudo. Gli utenti locali possono essere assegnati a un gruppo sotto Authentication > Users. Nella modifica del gruppo, Show group members mostra i membri; tramite Add member(s) si includono gli utenti locali appropriati. Per le identità gestite esternamente, invece, la directory rimane la fonte dell’appartenenza.

L’impostazione dell’utente o del gruppo utilizzata da una regola o policy dipende dalla selezione effettiva di utenti e gruppi. Nell’utente, in Policies, controlla se è stato selezionato un valore specifico invece dell’impostazione di gruppo. Se la policy di gruppo deve tornare ad applicarsi, ripristina in modo mirato lo stato di ereditarietà precedentemente documentato e testa di nuovo solo la funzione interessata. Un override rimane utile se viene documentata espressamente un’eccezione giustificata.

Sophos distingue due casi per la selezione nella regola o policy interessata:

  • Solo il gruppo selezionato: il firewall usa le impostazioni del gruppo, non automaticamente l’override dell’utente.
  • L’utente e il suo gruppo selezionati: il firewall usa le impostazioni dell’utente.

Un test pilota limitato rende visibile la differenza: per auth-pilot@example.com in Local_Contractors, documenta un valore di gruppo A e un valore utente diverso B per la stessa impostazione supportata. A e B sono segnaposto per due valori di test pianificati consapevolmente nel tuo ambiente. In una regola o policy di test isolata con selezione di utenti e gruppi, controlla prima la selezione effettiva: solo Local_Contractors significa A; auth-pilot@example.com insieme a Local_Contractors significa B. Testa il servizio o il percorso dati interessato con un nuovo accesso in ciascun caso; per il traffico firewall, controlla anche il Firewall Rule ID. Poi ripristina la selezione precedentemente annotata ed entrambe le impostazioni e ripeti il test. Non ampliare una regola di produzione né modificare l’ordine dei gruppi per questo test.

Questa selezione non è l’ordine del Main Group. Restano valide le limitazioni del supporto per più gruppi e la combinazione delle policy SSL-VPN corrispondenti descritte di seguito; ciò non stabilisce una precedenza universale delle policy utente per ogni servizio.

La configurazione completa delle policy per gli orari di accesso, delle quote di navigazione e traffico di rete e dell’MFA per Sophos Firewall è descritta nei rispettivi articoli specialistici. Nell’oggetto gruppo assegna soltanto una policy già pianificata.

Inquadrare i campi dei gruppi nell’API XML

Chi gestisce i gruppi in modo automatizzato trova nel modello XML UserGroup come oggetto gruppo, GroupDetail come corpo della configurazione e GroupMembers con GroupName e UserName come dati di appartenenza. Non si tratta di un’importazione delle appartenenze AD; per gli utenti della directory, la directory rimane la fonte autorevole. L’autenticazione, gli involucri espliciti delle operazioni e la valutazione della risposta XML sono trattati in Usare l’API XML in sicurezza.

Il frammento seguente mostra soltanto la struttura documentata per gli esempi pilota esistenti. Non è una richiesta Add/Edit completa; in particolare, mancano l’involucro dell’operazione e altri campi di configurazione necessari. L’omissione di alcuni campi non implica che una modifica mantenga i valori esistenti.

<UserGroup>
  <GroupDetail>
    <Name>Local_Contractors</Name>
    <LoginRestriction>SelectedNodes</LoginRestriction>
    <NodeList>
      <IPAddress>192.0.2.10</IPAddress>
    </NodeList>
  </GroupDetail>
  <GroupMembers>
    <GroupName>Local_Contractors</GroupName>
    <UserName>auth-pilot@example.com</UserName>
  </GroupMembers>
</UserGroup>

Il nome del gruppo e l’utente devono essere sostituiti con quelli della destinazione locale pianificata con precisione. 192.0.2.10 è un indirizzo IPv4 riservato alla documentazione e deve essere sostituito con un’origine di accesso consentita effettivamente necessaria. I nomi dei campi XML rimangono invariati. La corrispondenza con i campi dell’interfaccia è la seguente:

  • SurfingQuotaPolicy: Surfing quota; AccessTimePolicy: Access time.
  • DataTransferPolicy: Network traffic; QoSPolicy: Traffic shaping.
  • SSLVPNPolicy: SSL VPN policy; ClientlessPolicy: Clientless SSL VPN policy, non il tipo di gruppo Clientless.
  • SophosConnectClient: IPsec remote access tramite Sophos Connect Client.

Per LoginRestriction, l’esempio di riferimento distingue AnyNode, SelectedNodes e NodeRange. AnyNode corrisponde a Any node e non limita l’origine di accesso; non è un valore predefinito da usare per la risoluzione dei problemi. SelectedNodes utilizza NodeList con le singole voci IPAddress. NodeRange utilizza invece FromIP e ToIP, ad esempio da 192.0.2.10 a 192.0.2.20. Anche entrambi gli estremi dell’intervallo sono valori riservati alla documentazione e devono essere sostituiti con il più piccolo intervallo IPv4 necessario, senza ampliare le restrizioni esistenti. Sebbene la tabella contrassegni FromIP e ToIP come campi obbligatori, la loro descrizione ne limita l’uso a Node range; questo non implica un obbligo generale per le altre varianti.

Il riferimento API indica, per ciascuno dei campi QuarantineDigest, MACBinding, L2TP, PPTP e SophosConnectClient, i valori Enable o Disable e documenta Disable come valore predefinito. Si tratta di informazioni di riferimento, non di una prova dello stato del gruppo attualmente memorizzato. Quando QuarantineDigest è attivo, il riepilogo della quarantena viene inviato ogni giorno via e-mail. PPTP rimane escluso dalle nuove architetture; L2TP continua a essere soltanto l’opzione di compatibilità limitata descritta sopra.

Limiti dell’esempio di riferimento: l’esempio separa le impostazioni per i gruppi Normal da un ramo Clientless che mostra QoSPolicy. Per GroupType, tuttavia, è contraddittorio: il modello contiene Normal/Clienless, la descrizione indica Normal o Clientless e definisce il tipo di dati come INTEGER. Inoltre, il modello contiene segnaposto con due punti anziché contenuti XML completi. Da questo non si può dedurre né una codifica Clientless corretta né una corrispondenza numerica. Per un’operazione di scrittura, utilizzare un valore letto o esportato dalla versione installata, la cui corrispondenza sia già accertata; in caso contrario, utilizzare la procedura sicura nell’interfaccia. Le alternative separate da una barra, come Enable/Disable, non sono singoli valori da riportare.

Il modello mostra inoltre After con un Name annidato al suo interno come indicazione di posizione. La seconda riga della tabella relativa a Name menziona moveto, ma non dimostra l’esistenza di un’operazione eseguibile autonomamente. Una modifica della posizione va trattata come Reorder: può modificare il Main Group. Prima, salvare l’ordine, le appartenenze, lo stato attuale e quello previsto delle policy, nonché la procedura di ripristino; successivamente, verificare con l’utente pilota e, in caso di effetti inattesi, ripristinare l’ordine salvato. Il modello non dimostra né il comportamento di sostituzione o unione di GroupMembers né la semantica di aggiornamento di After o dei campi omessi.

Prima di un’operazione di scrittura Add/Edit strettamente circoscritta, annotare il nome della destinazione e lo stato desiderato. Successivamente, valutare il risultato effettivo dell’operazione XML, rileggere esattamente il gruppo nominato ed eseguire sul servizio interessato i test positivi e negativi descritti sopra. Per Add ed Edit, il riferimento associa 502 alla chiave UserGroupRecordExists e 503 alla chiave UserGroupDuplicateIPInLoginRestriction. In presenza di un risultato corrispondente, controllare prima il nome previsto del gruppo esistente oppure gli indirizzi duplicati in SelectedNodes. Non inviare nuovamente alla cieca né ampliare LoginRestriction. Queste corrispondenze indicano chiavi di riferimento, non testi risolti dei messaggi di runtime.

Importare gruppi di directory in modo controllato

Gruppi di Active Directory

Vai su Authentication > Servers e avvia la procedura guidata di importazione per il server AD configurato. In un cluster HA l’importazione deve essere eseguita sul Primary. La procedura guidata importa solo i gruppi selezionati. Un gruppo creato successivamente in AD non apparirà quindi automaticamente e dovrà essere importato con una nuova importazione.

Prima dell’importazione, le query AD devono funzionare: il server richiede i valori corretti per NetBIOS domain e Domain name, un ADS username con i diritti per cercare, leggere e interrogare le appartenenze ai gruppi, nonché la relativa Password. Per l’importazione dei gruppi non è necessario un account amministratore di dominio. Connection security offre SSL/TLS come impostazione predefinita e STARTTLS come alternativa cifrata; Plaintext trasmette le credenziali senza cifratura e non è una soluzione sicura per gli ambienti di produzione. Il Port deve corrispondere al tipo di connessione selezionato. Per Validate server certificate, il certificato del server AD viene caricato sotto Certificates > Certificates > Add > Upload certificate; Server IP/domain deve utilizzare il CNAME indicato nel certificato. Se il firewall non riesce a risolvere questo nome, occorre controllare la risoluzione DNS interna oppure Network > DNS > DNS host entry. La configurazione completa del server è descritta nell’articolo su AD collegato sopra.

Le Search queries delimitano l’insieme degli utenti individuati. Ad esempio, OU=VPN_Users,DC=example,DC=com cerca nell’OU VPN_Users del dominio di documentazione example.com; l’OU e i componenti del dominio devono essere sostituiti con il Distinguished Name effettivo. Una base di ricerca più ristretta mantiene gestibile l’insieme degli utenti, ma non deve escludere quelli previsti. Solo gli utenti individuati possono apparire come Live Users tramite questo server. Test connection verifica la connessione e le credenziali, ma non dimostra ancora la corretta assegnazione del gruppo a un utente normale. LDAP Channel Binding e LDAP Signing con applicazione rigorosamente obbligatoria non sono supportati; un requisito di sicurezza AD di questo tipo va chiarito prima dell’integrazione, non aggirato come se fosse un errore di gruppo.

L’importazione vera e propria si svolge così:

  1. Sul server AD previsto, clicca su Import e avvia Import group wizard con Start.
  2. Seleziona la Base DN appropriata per la ricerca dei gruppi. Deve includere i gruppi necessari ed è distinta dalla base di ricerca degli utenti.
  3. Seleziona solo i gruppi AD previsti, ad esempio SFOS_Internet_Standard e SFOS_SSLVPN.
  4. Seleziona le policy comuni dei gruppi, quindi controlla la selezione e i risultati.
  5. Sotto Authentication > Groups, verifica entrambi i gruppi e le rispettive policy. La procedura guidata importa i gruppi, non immediatamente tutti i record degli utenti o le appartenenze.
  6. Sotto Authentication > Services > Firewall authentication methods, verifica che il server AD sia selezionato per il servizio previsto. Se, in questa procedura di configurazione, AD deve essere interrogato per primo, sposta il server in prima posizione e clicca su Apply. In un ambiente esistente, mantieni l’ordine dei server pianificato in precedenza anziché modificarlo indiscriminatamente.

I gruppi AD nidificati non vengono valutati. Se un sottogruppo deve valere per una regola firewall o una policy VPN, deve essere importato esattamente quel sottogruppo. Anche il gruppo primario AD di un utente non viene acquisito come una normale appartenenza. Per le policy, pertanto, i gruppi di sicurezza espliciti sono più adatti del gruppo standard AD Domain Users.

Questo non vale solo per Domain Users: se, ad esempio, SFOS_Internet_Standard diventa il gruppo primario AD dell’utente, proprio questa appartenenza non viene acquisita come una normale appartenenza AD. Di conseguenza, il successivo gruppo importato corrispondente può diventare il gruppo principale. Il gruppo principale del firewall viene determinato in base all’elenco dei gruppi del firewall stesso e non coincide con il gruppo primario in AD.

Dopo modifiche alle appartenenze AD, ai gruppi importati o all’ordine dei gruppi, l’utente deve accedere di nuovo. Solo allora il firewall valuterà nuovamente i gruppi e aggiornerà l’oggetto utente.

Se STAS e Synchronized User ID sono configurati contemporaneamente, il server di autenticazione utilizza il meccanismo da cui arriva per prima la richiesta di accesso. Se i test pilota danno risultati diversi, controlla quindi anche Client Type, anziché riordinare subito gruppi o server.

Gruppi Entra

Per l’importazione dei gruppi Entra, la registrazione dell’app in Microsoft Graph necessita dell’autorizzazione applicativa Group.Read.All con consenso dell’amministratore. Gli orologi del firewall e di Microsoft Entra ID devono essere sincronizzati; in caso contrario, la connessione potrebbe non riuscire.

Vai poi su Authentication > Servers e clicca sulla procedura guidata per l’importazione dei gruppi del server Microsoft Entra ID. È possibile importare tutti i gruppi oppure solo quelli il cui Display name o la cui Description corrisponde a un filtro. Surfing quota, Access time, Network traffic e Traffic shaping possono essere assegnati a tutti o a singoli gruppi importati. I gruppi appena importati devono inoltre essere aggiunti alle policy IPsec per l’accesso remoto o SSL VPN utilizzate; l’importazione da sola non concede l’accesso VPN.

Valutare correttamente il gruppo principale e le appartenenze a più gruppi

Apri l’utente sotto Authentication > Users e scorri fino a Policies:

  • Group mostra il primo gruppo corrispondente nell’elenco del firewall e quindi il gruppo principale.
  • Other group memberships mostra altri gruppi AD importati dell’utente.

Sotto Policies compaiono altri due campi solo se, per ciascuno, sono soddisfatti entrambi i requisiti:

  • Group SSL VPN policies: l’utente appartiene a più gruppi AD e almeno due di questi gruppi sono inclusi nelle policy SSL VPN per l’accesso remoto.
  • Group clientless SSL VPN policies: l’utente appartiene a più gruppi AD e almeno due di questi gruppi sono inclusi nelle policy SSL VPN senza client.

Se uno di questi campi non compare, controlla quindi prima le appartenenze AD, i gruppi importati e la loro inclusione nella rispettiva policy VPN. L’appartenenza a più gruppi AD, da sola, non è sufficiente per la visualizzazione. Non ampliare le autorizzazioni VPN di produzione per rendere visibile il campo. Inoltre, la visualizzazione non costituisce un test di accesso; la combinazione effettiva delle autorizzazioni viene spiegata più avanti.

In Authentication > Groups > Reorder puoi modificare l’ordine mediante trascinamento. Seleziona Close per chiudere la finestra di dialogo. Se auth-pilot@example.com appartiene a SFOS_Internet_Standard e SFOS_SSLVPN, il gruppo corrispondente posizionato più in alto diventerà il gruppo principale al prossimo accesso.

Questo ordine non riguarda soltanto il problema attuale. Prima di apportare una modifica, verifica se la funzione interessata supporta altri gruppi. Altrimenti, uno spostamento può risolvere un caso VPN e allo stesso tempo modificare MFA, quote o orari di accesso per altri utenti.

Funzioni con supporto per più gruppi AD

La seguente matrice si applica espressamente ad Active Directory. Non dare per scontato che valga anche per LDAP, RADIUS o Microsoft Entra ID senza verificarlo.

Diversi gruppi AD possono essere presi in considerazione per:

  • Firewall rules e SSL/TLS inspection rules;
  • SD-WAN routes;
  • Web policies;
  • IPS e Application control policies;
  • Policy test;
  • Remote access SSL VPN;
  • Clientless SSL VPN.

Per Remote access SSL VPN vengono combinate le autorizzazioni delle policy utente e di gruppo corrispondenti. Non appena è coinvolta una policy full tunnel corrispondente, il risultato è un full tunnel. Verifica questa combinazione con un test su un client reale.

Per Clientless SSL VPN vengono considerate le autorizzazioni di tutte le policy a cui appartiene uno dei gruppi AD dell’utente. Controlla quindi non solo la policy prevista, ma anche eventuali bookmark o risorse aggiuntivi autorizzati tramite altri gruppi.

Hotspots considera esclusivamente il gruppo principale.

Solo il gruppo principale o un’assegnazione esplicita a un utente vengono considerati per:

  • WAF rules, My policy overrides;
  • Remote access IPsec VPN, L2TP e PPTP;
  • Surfing quota, Access time, Network traffic e Traffic shaping;
  • Quarantine digest, MAC binding e Sign-in restriction;
  • MFA.

Per WAF, L2TP, PPTP e Remote access IPsec, la policy utente può mostrare Enable, anche se l’autorizzazione proviene solo da Other group memberships e quindi l’accesso non è consentito. Valuta questi servizi in base al gruppo principale o a un’assegnazione diretta dell’utente, non solo in base a quanto visualizzato.

Per le funzioni che supportano più gruppi, resta determinante l’ordine della relativa regola o policy. Una regola firewall può applicarsi tramite SFOS_SSLVPN, anche se SFOS_Internet_Standard è il gruppo principale. Questo non significa che MFA o quote usino anche SFOS_SSLVPN.

Per Web policies si tratta di due decisioni distinte: prima la regola firewall corrispondente determina la policy web. All’interno di questa policy si applica la prima regola che corrisponde sia all’utente sia al sito web. Se l’utente pilota appartiene a entrambi i gruppi dell’esempio e la prima regola web blocca i siti sportivi per SFOS_SSLVPN, un sito sportivo viene bloccato anche se SFOS_Internet_Standard è il suo gruppo principale e una regola successiva consente i siti di notizie per questo gruppo. IPS e Application control utilizzano invece la policy della regola firewall corrispondente; l’ordine dei gruppi non produce un’ulteriore combinazione di queste policy.

Per MFA, anziché selezionare un gruppo, è possibile includere esplicitamente l’utente oppure applicare MFA a tutti gli utenti. Un’assegnazione solo tramite Other group memberships non è sufficiente. Gli hotspot nello User Portal dipendono esclusivamente dal gruppo principale; un ulteriore gruppo AD non amplia questo elenco.

Verificare l’effetto del gruppo

Un gruppo salvato e un utente visibile non sono ancora una prova di successo:

  1. Termina la sessione esistente dell’utente pilota e fallo accedere nuovamente.
  2. Annota sotto Authentication > Users > utente > Policies lo stato, Group, Other group memberships ed eventuali override.
  3. Sotto Current activities > Live users, controlla nome utente, IP sorgente e Client Type.
  4. Per una regola firewall basata sull’utente, genera il traffico previsto e controlla Firewall Rule ID nel Log Viewer.
  5. Testa orari di accesso, quote, MFA e accesso remoto ciascuno tramite il servizio effettivamente interessato.
  6. Ripeti lo stesso tentativo con un utente al di fuori del gruppo pilota come test negativo.

Per controllare la quota, apri Authentication > Users > utente > View usage. I dati di utilizzo sono disponibili solo se una regola firewall basata sull’utente elabora il traffico e Log firewall traffic è attivato.

Verificare le regole del firewall con Log Viewer, Policy Test e Packet Capture mostra il test completo del traffico. Se già la scelta del servizio, l’identità o il gruppo principale non sono chiari, Risolvere sistematicamente gli errori di autenticazione di Sophos Firewall guida attraverso l’intera sequenza di verifiche.

Ripristinare le modifiche e pulire i gruppi

Modifica sempre una sola policy di gruppo o una sola posizione alla volta. Se il test pilota mostra un effetto inatteso, ripristina l’ordine e l’assegnazione delle policy annotati, fai accedere nuovamente l’utente e ripeti il test positivo e quello negativo.

I gruppi AD vengono prima eliminati nella directory e successivamente, con un’operazione separata, sotto Authentication > Groups sul firewall. Purge AD users non pulisce alcun gruppo.

Per gli utenti AD, procedi come segue:

  1. Elimina prima l’utente in AD. Finché esiste nella directory, il firewall può ricrearlo a un accesso successivo.
  2. In Authentication > Users, clicca su Purge AD users. Non è necessario selezionare prima gli utenti; il firewall controlla il server AD e rimuove solo quelli già eliminati dalla directory.
  3. In HA, avvia l’operazione sul Primary. I record vengono rimossi su Primary e Auxiliary. La pulizia non interrompe Sign-in, Sign-out e User Accounting.

Un’esportazione della configurazione include i gruppi AD importati e quelli creati localmente, ma nessun utente dei server di autenticazione esterni. Un backup completo, invece, comprende tutti gli utenti e i gruppi. Considera questo limite se la procedura di ripristino non riguarda solo una singola modifica di policy.

Eliminare in sicurezza tramite API un gruppo identificato per nome

Prima di ogni eliminazione, definire l’esatto Name del gruppo di destinazione e salvare policy, ordine, membri e utilizzi. Il fatto che la tabella API meno recente contrassegni Name come non obbligatorio non autorizza un’eliminazione senza nome: la descrizione richiede un nome per identificare l’oggetto. Prima, verificare gli utenti effettivi del gruppo, le assegnazioni VPN comprese quelle L2TP/IPsec, la selezione per l’autenticazione esterna, i riferimenti nelle regole firewall e l’utilizzo come gruppo predefinito per gli ospiti. Se il gruppo è ancora necessario, eseguire una migrazione esplicitamente pianificata e strettamente circoscritta oppure interrompere l’operazione. Non forzare la rimozione, eliminare utenti o allentare le restrizioni di accesso soltanto per riuscire a completare l’eliminazione. La sequenza AD descritta sopra e la distinzione rispetto a Purge AD users rimangono valide.

Il riferimento per l’eliminazione collega le righe dei risultati a chiavi di messaggi JavaScript relative a tali dipendenze. Le chiavi non sostituiscono né i testi risolti dei messaggi né l’analisi di un errore concreto dell’appliance. Per la struttura della richiesta e la gestione del risultato XML vale quanto descritto in Usare l’API XML in sicurezza; il riferimento per l’eliminazione dei gruppi non fornisce un esempio di payload, quindi qui non viene inventato alcun involucro Delete. In caso di rifiuto, mantenere il gruppo e verificare in modo mirato il riferimento indicato nel risultato. Anche dopo un risultato positivo, rileggere esattamente la destinazione, verificarne l’assenza e ripetere i test previsti sui servizi e sugli accessi.

Utenti e gruppi condividono l’intervallo di ID interno fino a 65535. Un elevato numero di oggetti visibili, da solo, non dimostra un problema di limite. Se un utente mostra un User ID superiore a 65535 e non compare come Live User, il comportamento è compatibile con il limite ID utente di Sophos Firewall.

Individuare gli errori in base al sintomo

Fai accedere nuovamente l’utente interessato dopo ogni correzione e controlla Group e Other group memberships. Successivamente è sufficiente un solo passaggio mirato per ciascun sintomo.

Il nuovo gruppo AD non appare

Avvia nuovamente la procedura guidata di importazione del server AD ed eseguila in HA sul Primary. Controlla poi sotto Authentication > Groups che sia presente esattamente il gruppo necessario. Non creare un gruppo sostitutivo con autorizzazioni ampie solo per far funzionare un accesso.

L’utente LDAP finisce nel gruppo predefinito

Controlla sul server LDAP Base DN, Authentication attribute e Group name attribute, poi sotto Authentication > Services l’ordine dei server e Default group. Esegui Test connection per il server LDAP. La procedura guidata di importazione AD non gestisce questa mappatura.

L’utente Entra finisce nel gruppo di fallback

Verifica se il gruppo Entra è stato importato e se il token restituisce il gruppo previsto. Controlla quindi Fallback user group direttamente sul server Entra. Il Default group generale sotto Authentication > Services non viene utilizzato per questa mappatura.

L’utente ha il gruppo principale sbagliato

Confronta le appartenenze AD, i gruppi importati e l’ordine attuale. Verifica il nuovo ordine solo dopo il prossimo accesso e con diversi utenti rappresentativi.

La regola firewall si applica, ma MFA o quote no

Le regole firewall supportano ulteriori gruppi AD, mentre MFA e quote no. Controlla sotto Authentication > Users > utente > Policies il gruppo principale, eventuali override e l’effettiva assegnazione della policy. L’effetto della regola non dimostra che MFA o quote valutino lo stesso gruppo.

La modifica del gruppo non ha effetto per un solo utente

Confronta i campi delle policy specifici per l’utente e la selezione effettiva di utenti e gruppi nella regola o policy interessata: selezionare solo il gruppo usa i valori del gruppo; selezionare l’utente e il suo gruppo usa i valori dell’utente. Verifica anche i limiti della funzione per il gruppo principale e le appartenenze a più gruppi. Ripristina il valore del gruppo solo se l’eccezione documentata non è più necessaria.

Il gruppo AD nidificato non ha effetto

Importa il sottogruppo necessario e aggiungi l’utente direttamente a quel sottogruppo. Importare solo il gruppo superiore non è sufficiente.