Configurare Per-Connection AD SSO su Sophos Firewall per host multiutente

Più utenti lavorano sullo stesso Remote Desktop Session Host, ma Sophos Firewall vede un solo IP del server per tutte le connessioni. Per-Connection AD SSO risolve proprio questo caso specifico per il traffico web: Direct Web Proxy autentica separatamente ogni connessione HTTP e HTTPS con Kerberos o NTLM.

La funzione non è limitata a Windows RDS: anche un server Linux multiutente può utilizzare questo modello di connessione, purché i suoi client supportino Direct Web Proxy e Kerberos o NTLM. Questo esempio illustra un progetto pilota su Windows RDS; i comandi Windows e la distribuzione tramite GPO non costituiscono una guida per Linux. Gli host non inclusi nell’elenco Multi-user hosts mantengono l’autenticazione basata su IP configurata in precedenza.

Il limite è importante quanto la funzione. Solo le connessioni inviate esplicitamente al proxy dal browser o dall’applicazione ricevono un’identità utente. DNS, RDP, SMB e altro traffico non proxy proveniente dallo stesso IP del server rimangono non autenticati. Se anche questi protocolli devono essere controllati in base all’utente, SATC per Remote Desktop Services è la scelta più adatta.

⚠️ Non appena si inserisce un indirizzo IP in Multi-user hosts, tale indirizzo non utilizza più altri metodi di autenticazione basati su IP. STAS, Captive Portal, Clientless User e AD SSO trasparente non si applicano più a questo IP. Occorre quindi iniziare con un solo server pilota e documentare prima il percorso di autenticazione esistente.

Per-Connection AD SSO in nove passaggi

1. Stabilire se solo HTTP e HTTPS debbano effettivamente essere gestiti in base all’utente tramite un proxy esplicito.
2. Verificare Active Directory, l’importazione dei gruppi, il DNS, l’ora e il join del firewall al dominio.
3. Preparare un FQDN del firewall risolvibile e un HTTP-SPN corrispondente per Kerberos.
4. Valutare prima ambito e impatto sulla sicurezza, quindi attivare AD SSO per la zona LAN necessaria in Administration > Device access e selezionare Apply. Limitare separatamente Web proxy all’host pilota tramite un’eccezione ACL mirata, se supportata; un’eccezione Accept non restringe un’autorizzazione di zona. Se l’autorizzazione richiesta non è accettabile, interrompere il rollout e ottenere una configurazione supportata con ambito ristretto.
5. Creare il server RDS come oggetto host IP con l’indirizzo esatto.
6. In Authentication > Web authentication, attivare Per-Connection AD SSO per questo host.
7. Configurare browser e applicazioni che supportano il proxy con il FQDN del firewall e la porta 3128.
8. Posizionare una regola dedicata all’host, con logging attivo, prima delle regole utente concorrenti e lasciare Match known users disattivato.
9. Verificare separatamente due sessioni RDS parallele, risultati differenti delle Web Policy e il traffico non proxy.

Per-Connection AD SSO, STAS o SATC?

Tutti e tre i metodi forniscono il contesto utente, ma rispondono a esigenze diverse.

• STAS è adatto ai normali client Windows, quando un IP client appartiene in genere a un solo utente. Il firewall riceve un’associazione utente-IP dagli eventi di accesso di Windows.
• Per-Connection AD SSO è adatto agli host multiutente, quando occorre distinguere solo le connessioni HTTP e HTTPS inviate esplicitamente al proxy. Non è necessario un agente SATC sul server RDS, ma tutte le applicazioni devono utilizzare Direct Web Proxy in modo affidabile.
• SATC è adatto ai sistemi Windows RDS supportati, quando anche altri tipi di connessione delle singole sessioni utente richiedono un’identità. A questo scopo è necessario Sophos Server Protection sul Session Host. La guida Sophos attuale non documenta un nuovo rollout Citrix; prima di modificare installazioni Citrix esistenti, è opportuno consultare Sophos Support.

Il classico STAS su Sophos Firewall non può distinguere più utenti dietro lo stesso IP RDS. Per-Connection AD SSO e SATC non sono quindi varianti più comode di STAS, ma modelli operativi distinti. Anche SATC associa solo i processi legati agli utenti; le connessioni generate dai servizi di sistema richiedono comunque una regola dedicata senza Match known users. Se un’applicazione non supporta un proxy esplicito o se i protocolli non web devono essere regolati in base all’utente, fermarsi qui e valutare SATC.

Esempio e valori da sostituire

La procedura utilizza questo esempio:

• Host multiutente: RDS01
• Indirizzo IP: 10.20.30.40
• FQDN del firewall e destinazione del proxy: fw01.corp.example
• Porta di Direct Web Proxy: 3128
• Gruppi AD: RDS-Web-Standard e RDS-Web-Restricted
• Un account pilota per ciascun gruppo, con risultati delle Web Policy intenzionalmente differenti

10.20.30.40 va sostituito con l’IP fisso del server pilota visibile al firewall. Dietro questo indirizzo non devono comparire anche altri sistemi tramite NAT. fw01.corp.example è un nome usato per la documentazione e deve essere sostituito con il vero FQDN del firewall, risolvibile internamente. La parte relativa all’host dovrebbe contenere al massimo 15 caratteri ed essere scritta in minuscolo, affinché hostname, nome NetBIOS, oggetto computer AD e SPN corrispondano.

La porta 3128 è quella predefinita per Direct Web Proxy. Se nell’ambiente viene utilizzata una porta di ascolto diversa, firewall, file PAC o GPO, browser e test devono utilizzare lo stesso valore. I gruppi dell’esempio servono solo a rendere chiaro il collaudo; i nomi dei gruppi e le Web Policy devono essere adeguati alla propria struttura di autorizzazioni.

Preparare i prerequisiti

Verificare Active Directory e il join al dominio

Il firewall richiede un server Active Directory funzionante, gruppi importati e un join al dominio riuscito. Collegare Active Directory a Sophos Firewall illustra LDAPS, base di ricerca, importazione dei gruppi e prerequisiti generali di AD SSO.

Se il server AD non è ancora configurato, scegliere il tipo Active Directory in Authentication > Servers > Add. Inserire il nome del server, l’IP o il FQDN raggiungibile del DC, il dominio NetBIOS, il dominio AD e la base di ricerca del proprio ambiente. Per corp.example, la base di ricerca è dc=corp,dc=example. Cifrare la connessione con SSL/TLS sulla porta 636 o STARTTLS sulla porta 389 e predisporre la verifica del certificato secondo la procedura AD collegata. Inserire l’account di lettura/join con i diritti descritti di seguito, eseguire Test connection e salvare con Save. Non sostituire un server AD già in uso solo per il progetto pilota e non modificarne le credenziali senza verifica. Se il dominio impone requisiti rigorosi di channel binding LDAP o firma LDAP, chiarire la compatibilità seguendo la procedura AD prima del rollout; la guida Sophos per i server AD indica una limitazione al riguardo. Non disattivare un requisito di protezione a livello di dominio per risolvere un problema.

Durante l’importazione dei gruppi, la selezione di un’unità organizzativa (OU) seleziona automaticamente tutti i gruppi che contiene. Attach to all the Groups assegna le policy comuni selezionate a ogni gruppo importato dalla procedura guidata. Prima di completarla, verificare quindi l’elenco dei gruppi ampliato dalla selezione dell’OU e l’ambito di applicazione di queste policy; includere solo i gruppi effettivamente necessari e le assegnazioni di policy previste.

Per il progetto pilota, in Authentication > Servers > Manage aprire Import sul server AD, avviare Import group wizard con Start e scegliere la Base DN appropriata. Per il dominio di esempio corp.example, questa è dc=corp,dc=example; vanno sostituite le componenti del dominio, non la sintassi LDAP. Selezionare RDS-Web-Standard e RDS-Web-Restricted, verificare l’assegnazione delle policy comuni e il riepilogo, completare la procedura guidata e chiuderla con Close. Quindi verificare in Authentication > Groups che entrambi i gruppi siano effettivamente presenti. Il solo join al dominio riuscito non importa i gruppi necessari per le policy.

Per le normali query LDAP è sufficiente un account con diritti di lettura. Il join al dominio e la creazione dello SPN richiedono invece un account Domain Admin o un account con diritti delegati correttamente. L’account configurato deve consentire anche un successivo rejoin, perché HA, altri server AD o aggiornamenti possono richiederlo nuovamente. A questo scopo non si dovrebbe utilizzare inutilmente e in modo permanente un account Domain Admin senza restrizioni.

In Authentication > Services > Firewall authentication methods, selezionare il server AD previsto e collocarlo nell’ordine corretto. In presenza di più server, il firewall li verifica dall’alto verso il basso. Test connection sul server AD conferma solo le credenziali e la raggiungibilità, non la successiva autenticazione Kerberos o NTLM nel browser.

Nella stessa sezione, scegliere consapevolmente la Default group e salvare con Apply. Se il gruppo AD necessario non è importato, un utente autenticato correttamente può finire nel gruppo predefinito anziché ricevere la policy di gruppo desiderata. Gli utenti in un’OU che non appartengono a un gruppo della directory possono comparire nella Open group. In caso di appartenenza a più gruppi, il primo gruppo corrispondente può determinare la policy; controllare quindi non solo l’importazione, ma anche l’ordine e l’associazione effettiva. Per il progetto pilota, non usare dunque un gruppo predefinito con autorizzazioni ampie come sostituto di un’importazione mancante. Al primo nuovo accesso, verificare l’effettiva associazione al gruppo in Authentication > Users; non è necessario che un oggetto utente sia già visibile prima di tale accesso.

Controllare FQDN, DNS, SPN e ora

Kerberos funziona solo se i client utilizzano il FQDN del firewall come destinazione del proxy. Un indirizzo IP del proxy non è sufficiente. Su un client pilota Windows, sono utili questi controlli in sola lettura:

Resolve-DnsName fw01.corp.example
setspn -Q HTTP/fw01.corp.example
w32tm /query /status

L’HTTP-SPN, per esteso Service Principal Name, associa il FQDN del proxy all’oggetto computer AD del firewall. setspn -Q dovrebbe restituire esattamente un’associazione corrispondente. L’assenza di risultati o la presenza di più risultati devono essere chiarite prima del rollout.

Il suffisso DNS configurato nel campo Hostname non coincide automaticamente con il suffisso AD: durante il join al dominio, il firewall costruisce il nome computer AD e lo SPN a partire dal proprio nome NetBIOS e dal dominio AD. Se il dominio DNS e il dominio AD sono diversi, confrontare il FQDN registrato sull’oggetto computer AD con la destinazione del proxy prevista. L’esempio presuppone uno SPN corrispondente a fw01.corp.example; il semplice inserimento di questo nome in Admin and user settings non ne dimostra l’esistenza. Prima verificare congiuntamente DNS e SPN per la destinazione effettiva del proxy, poi distribuire la configurazione del proxy. Non creare SPN aggiuntivi sulla base di ipotesi.

La risposta DNS deve corrispondere al firewall previsto. Client, controller di dominio e firewall devono inoltre avere un’ora compatibile con il funzionamento di Kerberos. I comandi non modificano nulla. Non correggere SPN, join al dominio o configurazione dell’ora sulla base di ipotesi: prima documentare l’errore effettivo.

Verificare il supporto del proxy e rilevare le eccezioni

Ogni browser e ogni applicazione il cui traffico web deve ricevere un’identità utente deve utilizzare il proxy esplicito e supportare Kerberos o NTLM; nell’esempio Windows RDS, ciò avviene tramite l’autenticazione integrata di Windows. Prima del rollout, verificare almeno:

• Browser in ogni sessione RDS supportata
• Applicazioni con uno stack HTTP proprio
• Aggiornamenti di Windows e del software
• Servizi eseguiti nel contesto di sistema anziché in una sessione utente
• Destinazioni presenti nel file PAC o nell’elenco di bypass del proxy

Il traffico che aggira il proxy rimane, come previsto, privo di ID utente. Per le connessioni necessarie dei sistemi, pianificare una regola dedicata e strettamente limitata, senza riferimento all’utente. Una regola Any ampia ridurrebbe l’efficacia di sicurezza delle policy utente e web.

Configurare Per-Connection AD SSO

1. Preparare il FQDN del firewall e AD SSO

In Administration > Admin and user settings, inserire il FQDN del firewall previsto e salvare con Apply. Quindi, in Authentication > Web authentication, alla voce If Active Directory (AD) SSO is configured, scegliere l’opzione Kerberos & NTLM e salvare anche qui con Apply. NTLM è tecnicamente supportato come fallback; Kerberos è più veloce e più sicuro e dovrebbe funzionare in modo affidabile nel progetto pilota. Poiché ogni connessione proxy può avviare un’autenticazione, prima di un rollout più ampio monitorare anche errori di accesso, tempi di risposta e carico sul firewall e su AD con traffico rappresentativo. Non ricavarne un moltiplicatore di carico fisso o una capacità utente garantita.

Se i dispositivi endpoint non sono configurati correttamente per Kerberos o il browser non supporta l’autenticazione Kerberos, viene utilizzato automaticamente NTLMv2 come fallback. A differenza di Kerberos, NTLMv2 non richiede un FQDN come destinazione del proxy. Questo fallback di compatibilità non garantisce però un accesso riuscito: i canali di autenticazione descritti di seguito devono essere inizializzati e il percorso di accesso effettivo deve essere verificato con gli account pilota.

Nel Log Viewer, sotto Authentication, dopo l’inizializzazione di AD SSO devono comparire questi messaggi di esito positivo:

• Kerberos authentication initialized successfully
• NTLM authentication channel established successfully

Il firewall offre questi metodi solo quando entrambi i canali funzionano. Cannot initialize Kerberos authentication o Cannot establish NTLM authentication channel sono segnali di arresto, non un invito a riavviare alla cieca un servizio.

2. Consentire Device Access in modo restrittivo

Sophos richiede di attivare AD SSO per la zona LAN necessaria in Administration > Device access e selezionare Apply come prerequisito per Kerberos/NTLM. Valutare prima l’ambito dell’autorizzazione di zona e l’impatto sulla sicurezza; non aprire indiscriminatamente la LAN senza questa verifica. Disattivare AD SSO in tutte le zone impedisce Kerberos/NTLM; un’eccezione ACL AD SSO limitata a un host non sostituisce il prerequisito. Aggiungere un’eccezione Accept non restringe un’autorizzazione di zona esistente. Se l’autorizzazione richiesta non è accettabile, interrompere il rollout e ottenere dal responsabile delle ACL o da Sophos Support una configurazione supportata e con ambito ristretto per la build installata. Separatamente, limitare l’accessibilità di Web proxy dall’origine all’host pilota tramite una Local service ACL exception rule mirata, se supportata. Un’eccezione Accept non restringe un’autorizzazione Web proxy già attiva per l’intera zona; tale autorizzazione ampia non deve restare attiva per un accesso realmente limitato all’host. Non abilitare altre zone o servizi non necessari. Device Access e Local Service ACL illustra la configurazione completa.

L’accesso al proxy web ha un effetto collaterale importante: un host autorizzato può raggiungere i servizi HTTP e HTTPS del firewall tramite il proxy, anche se la relativa zona non è autorizzata nella normale matrice dei servizi locali. Eseguire quindi test negativi di accesso a WebAdmin, User Portal e altre destinazioni locali dall’host pilota. Se questa esposizione non è accettabile nella propria rete, non attivare la configurazione in produzione.

In Web > General settings, verificare la Web proxy listening port effettiva e le porte di destinazione consentite. Modificare il valore predefinito 3128 solo se è possibile adeguare in modo coerente il file PAC, le GPO e tutte le applicazioni gestite.

3. Creare l’host multiutente

Creare un nuovo oggetto host nel seguente percorso:

Hosts and services > IP host > Add

Per l’esempio vengono utilizzati questi valori:

1. Name: RDS01
2. IP version: IPv4
3. Type: IP
4. IP address: 10.20.30.40

Salvare con Save e verificare che l’oggetto contenga l’IP esatto del server pilota prima di selezionarlo nell’elenco multiutente.

Per il primo test, non inserire un intero intervallo o una subnet. In caso contrario, molti sistemi potrebbero perdere contemporaneamente la propria autenticazione basata su IP. Dopo il collaudo positivo di ogni singolo host, più host approvati in seguito possono essere riuniti in modo controllato in un gruppo di host.

4. Attivare Per-Connection AD SSO

Accedere a questa sezione:

Authentication > Web authentication > Authentication settings for direct web proxy

Quindi:

1. Attivare Use per-connection AD SSO authentication for multi-user hosts.
2. In Multi-user hosts, aggiungere l’oggetto RDS01 con Add new item.
3. Salvare con Apply.

Da questo momento, STAS, Captive Portal, Clientless User e AD SSO trasparente non sono più disponibili per 10.20.30.40. Eseguire quindi la modifica durante una finestra di manutenzione e non utilizzare una sessione RDS esistente come unico test.

Mappatura API opzionale per l’automazione

Chi desidera automatizzare questo passaggio nell’interfaccia grafica trova nella documentazione di riferimento API per SFOS 22.0 e 23.0 l’entità DirectWebProxyAuthentication. L’entità associa l’interruttore e l’elenco multiutente come descritto di seguito. Per una richiesta eseguibile servono anche l’envelope dell’operazione e gli altri campi obbligatori.

• DirectWebProxyAuthentication > PerConnectionAuth corrisponde all’interruttore di attivazione/disattivazione di Per-Connection AD SSO. Il parametro è documentato come SCALAR non obbligatorio e ammette esclusivamente Enable o Disable. La notazione con la barra nell’esempio della documentazione di riferimento indica alternative, non un terzo valore consentito.
• DirectWebProxyAuthentication > MultiUserHosts > Host descrive l’elenco dei nomi degli host multiutente, quindi, nell’esempio, il nome dell’oggetto host RDS01 creato in precedenza, non il suo indirizzo IP. Host non è obbligatorio ed è documentato come ARRAY con tipo di dati STRING. Sono consentiti più valori e, secondo la documentazione di riferimento, i valori duplicati vengono ignorati. La documentazione indica un massimo di 1500 caratteri, ma non chiarisce se questo limite si applichi a ciascun valore o all’intero elenco.

Le colonne Default sono vuote: da questo non si può dedurre né un valore predefinito documentato né l’effetto dell’omissione dei campi. La sezione relativa all’operazione non descrive neppure se un elenco inviato aggiunga voci a quelle esistenti o le sostituisca, né come rimuovere le voci. Non interpretare quindi né l’omissione né un elenco vuoto come un metodo sicuro di ripristino; prima di automatizzare, occorre chiarire il comportamento concreto di aggiornamento e rimozione per la build in uso.

La tabella degli stati contiene 200 e 500. Questi valori non rappresentano stati HTTP e non confermano la corretta elaborazione di utenti e policy. I campi dei messaggi rimandano a JavaScript; la sezione dell’operazione qui disponibile non fornisce il testo letterale dei messaggi di risposta.

Anche per una successiva modifica API autorizzata restano validi i prerequisiti indicati sopra e il progetto pilota strettamente limitato a un singolo host. Prima della modifica, salvare in modo sicuro le impostazioni effettive e predisporre un accesso di gestione indipendente. Dopo la modifica, rileggere l’interruttore e l’intero elenco multiutente proprio sul firewall modificato e confrontarli con lo stato previsto; quindi eseguire i test positivi e negativi descritti di seguito per proxy, utenti, policy, traffico non proxy e servizi locali. Una risposta che accetta la configurazione non sostituisce questo collaudo. Per il ripristino, ristabilire lo stato precedente salvato, senza dedurne una sintassi di eliminazione API non documentata.

5. Distribuire Direct Web Proxy

Impostare il proxy del browser o del sistema tramite GPO, file PAC o applicazione gestita su questo valore:

fw01.corp.example:3128

Per Kerberos è necessario utilizzare esattamente il FQDN corrispondente allo SPN. Un indirizzo IP come destinazione del proxy, un nome breve non risolvibile o un altro alias causano spesso il fallback a NTLM o una richiesta di credenziali. Limitare consapevolmente le voci di bypass e documentarle, perché ogni connessione che aggira il proxy non riceve un’identità Per-Connection.

La configurazione generale di listener, PAC, regole e rollback è descritta in Configurare Direct Web Proxy con un file PAC. Questo articolo integra tale configurazione solo con l’autenticazione multiutente.

6. Posizionare una regola firewall dedicata

In Rules and policies > Firewall rules, creare una regola in uscita dedicata a RDS01 con un nome chiaro. Deve precedere le regole che includono lo stesso host con Match known users.

Per questo esempio IPv4, scegliere IPv4 > Add firewall rule > New firewall rule. Impostare, ad esempio, RDS01_DirectProxy_Outbound come Rule name e Accept come Action. Il nome è a scelta, ma dovrebbe rendere riconoscibili l’host e lo scopo. Verificare la posizione prima delle regole utente concorrenti sulla base dell’elenco completo delle regole, non solo del nome.

Un’impostazione sicura:

• Source zones: la zona RDS effettiva, ad esempio LAN
• Source networks and devices: solo RDS01
• Destination zones: WAN
• Destination networks: solo le destinazioni necessarie oppure, consapevolmente, Any
• Services: HTTP, HTTPS e un servizio TCP dedicato per 3128 o per la porta di ascolto del proxy effettivamente configurata; usare Any solo consapevolmente. Selezionare solo la porta di ascolto non costituisce una selezione completa dei servizi per Direct Web Proxy.
• Log firewall traffic: attivo
• Match known users: disattivato
• Web filtering > Web policy: selezionare la policy predisposta in base all’utente o al gruppo

Le Web Policy possono distinguere utenti e gruppi all’interno del traffico proxy, ma hanno effetto solo quando sono assegnate alla regola firewall. Questa distinzione va configurata nella Web Policy, non in Match known users di questa regola host. Dopo aver selezionato o modificato la Web Policy, controllare nuovamente l’interruttore, perché una dipendenza dall’utente può riattivarlo.

Salvare con Save, riaprire la regola e verificare Match known users, logging, Web Policy e posizione. La regola host consente il percorso di traffico previsto; la Web Policy decide, all’interno di questo percorso, come trattare utenti e gruppi. Un’identità riconosciuta correttamente non implica quindi automaticamente l’autorizzazione corretta.

La guida generale di AD SSO descrive anche regole utente con Match known users attivo. Questo non è il modello di regole per l’IP multiutente inserito qui: la guida specifica di Per-Connection richiede espressamente una regola dedicata con questo interruttore disattivato. Non copiare neppure i criteri di corrispondenza dei servizi da una regola HTTP/HTTPS trasparente: la porta di ascolto del proxy descrive il percorso dal client al proxy, mentre una connessione separata dal proxy alla destinazione utilizza servizi di destinazione come HTTP o HTTPS. Confermare la Rule ID effettiva e la porta corrispondente nel progetto pilota sulla base dei log. Un client IPv6 con destinazione IPv4 può richiedere due regole; questo esempio IPv4 non costituisce una guida completa per il dual stack.

Per DNS, aggiornamenti e altre connessioni non proxy necessarie, creare una regola separata per il traffico dei sistemi. Non aggiungere una regola generica da WAN a LAN; l’esempio in ingresso mostrato da Sophos non è necessario per il normale accesso web RDS e, senza uno specifico scopo di pubblicazione, costituirebbe una superficie di attacco inutile. Creare correttamente le regole firewall illustra configurazione, ordine e logging.

Se esiste una necessità motivata di accesso in ingresso all’host multiutente indipendentemente dal proxy, anche la relativa regola dedicata deve avere Match known users disattivato. Definire in modo restrittivo la zona di origine e gli host di origine autorizzati, la zona di destinazione e RDS01, nonché i servizi effettivamente necessari; attivare il logging e verificare la posizione prima delle regole utente concorrenti. Questo non è un invito a esporre RDP pubblicamente; per il normale accesso web non viene creata alcuna nuova regola in ingresso.

Eseguire il collaudo con due utenti RDS

Una singola richiesta riuscita dal browser dimostra solo che una parte del traffico proxy funziona. Il collaudo effettivo richiede due sessioni parallele.

1. Assegnare due account AD pilota a gruppi con Web Policy differenti.
2. Aprire due nuove sessioni RDS su RDS01.
3. Verificare la configurazione proxy effettiva in entrambe le sessioni.
4. Eseguire in ciascuna sessione una richiesta HTTP o HTTPS consentita e una intenzionalmente valutata in modo diverso.
5. In Current activities > Live users, verificare entrambi gli utenti con Client Type Multi-host client.
6. In Log viewer > Authentication, controllare gli utenti e Log Comp per Kerberos o NTLM.
7. Nei log web e firewall, confrontare utente, policy, Rule ID, azione e orario.
8. Eseguire un test non proxy necessario e confermare che non riceva erroneamente un’identità utente.
9. Dall’host pilota, rilevare quali servizi HTTP e HTTPS locali del firewall siano raggiungibili tramite il proxy. Se è raggiungibile un servizio non consentito dal progetto di sicurezza, interrompere il rollout e riprenderlo solo con una misura di protezione aggiuntiva effettivamente in atto e comprovata.

Un confronto significativo utilizza la stessa destinazione di test approvata in entrambe le sessioni: un account in RDS-Web-Standard può aprirla, mentre uno in RDS-Web-Restricted viene bloccato dalla Web Policy predisposta. Annotare data, ora, utente, IP di origine, Rule ID, policy e risultato. Quindi accedere a una destinazione di controllo utilizzabile da entrambi i gruppi. In questo modo si distingue una restrizione di gruppo intenzionale da un’interruzione generale del proxy o del DNS. Le destinazioni di test provengono dal proprio elenco di test approvato; non bloccare un sito web aziendale in produzione solo per il collaudo.

Aggiungere altri host RDS solo quando entrambi gli utenti vengono distinti correttamente e contemporaneamente, si ottengono i risultati previsti delle Web Policy e il percorso non proxy è stato chiarito. Per il collaudo generale delle regole è utile Testare in modo controllato le regole di Sophos Firewall.

Risoluzione dei problemi

Il proxy non è raggiungibile

Verificare la risoluzione del FQDN, la porta, la configurazione risultante da PAC/GPO, la zona di origine e le autorizzazioni Web proxy e AD SSO. Un test riuscito del server AD non dimostra l’accessibilità del proxy. Con le route SD-WAN, la porta del proxy o Any deve corrispondere ai criteri di selezione dei servizi; il firewall genera autonomamente la connessione proxy esterna, quindi non tutte le caratteristiche del client si applicano come nel normale traffico instradato.

Il browser richiede le credenziali o utilizza NTLM

Verificare destinazione del proxy, DNS, HTTP-SPN, zona del browser e autenticazione integrata. Kerberos richiede il FQDN corrispondente, non l’IP del firewall. Il fallback a NTLM è un sintomo da chiarire prima di tutto, non un motivo per effettuare preventivamente un rollout solo NTLM.

Entrambe le sessioni compaiono come lo stesso utente

Verificare che entrambi i browser utilizzino effettivamente il proxy esplicito e che un’applicazione non generi connessioni al di fuori della rispettiva sessione utente. Anche un proxy a monte o il NAT può modificare il modello di connessione desiderato. In Live Users deve comparire il tipo Multi-host client; una normale associazione basata su IP indica un percorso errato per questo host.

L’utente è visibile, ma la Web Policy non viene applicata

Verificare congiuntamente gruppo AD, Main Group, ordine delle Web Policy, regola firewall e voce di log. Match known users deve rimanere disattivato nella regola host specifica. Un’autenticazione visibile non dimostra ancora che la richiesta utilizzi la Web Policy o la Firewall Rule ID prevista.

Se l’utente pilota si trova nella Default group anziché nel gruppo AD importato previsto, verificare prima Authentication > Groups, la base di ricerca e l’importazione dei gruppi. Non assegnare una policy più permissiva al gruppo predefinito per mascherare l’errore. Dopo una correzione controllata, verificare con un nuovo accesso che l’associazione e i due test delle policy siano corretti.

Il traffico non web non mostra alcun utente

È il comportamento previsto. Per-Connection AD SSO identifica solo HTTP e HTTPS tramite Direct Web Proxy. Per il traffico necessario dei sistemi si applica una regola senza riferimento all’utente. Se RDP, SMB, traffico di database o altro traffico non proxy devono essere distinti per sessione, passare a SATC.

SSO non funziona più dopo un aggiornamento o un failover HA

AD SSO può richiedere un nuovo join al dominio dopo un aggiornamento, quando si utilizzano più server AD o in HA. L’account con diritti delegati per il join deve quindi rimanere valido. Dopo un failover controllato, eseguire un test con una nuova connessione proxy ed entrambi gli account pilota; non presumere che le connessioni proxy o i ticket Kerberos esistenti proseguano senza interruzioni. In ogni modalità HA, ciascun nodo memorizza solo i log del traffico che ha elaborato personalmente. Per un evento, verificare quindi il nodo attivo o responsabile dell’elaborazione in quel momento.

In caso di aggiornamento da SFOS 21.5 o precedente direttamente a SFOS 22.0 GA Build 411, può essere rilevante anche il problema noto NC-176853: NTLM e Kerberos AD SSO possono smettere di funzionare subito dopo l’aggiornamento, impedendo la corrispondenza delle policy basate sull’identità. Sophos indica SFOS 22.0 MR1 Build 490 come versione correttiva. La procedura interna relativa a KBA-000048429 descrive diagnosi e workaround. La Known Issues List non menziona separatamente Per-Connection AD SSO; il problema è quindi rilevante solo se il percorso AD SSO sottostante smette di funzionare dopo questo specifico aggiornamento. Conservare build del firmware, orario e log, verificare la KBA per la build interessata e non aggirare il problema con regole ampie o con un cambio del metodo di autenticazione.

Leggere i log rilevanti

Nella Advanced Shell sono rilevanti questi file:

cd /log
tail -n 200 nasm.log
tail -n 200 access_server.log
tail -n 200 awarrenhttp.log

nasm.log mostra problemi NTLM, Kerberos ed eventuali problemi KVNO. access_server.log è utile per autenticazione e autorizzazione, awarrenhttp.log per Web Proxy. awarrenhttp_access.log viene creato solo con il logging di debug temporaneamente attivato e non rientra nella normale fase iniziale. Prima di riavviare servizi o ampliare il logging di debug, conservare la finestra temporale, l’utente, la destinazione, la regola e i log esistenti.

Rollback

Un ripristino corretto non ripristina solo il proxy, ma anche il precedente modello di autenticazione.

1. Documentare l’elenco multiutente attuale, le eccezioni Device Access, le regole, la Web Policy e la distribuzione del proxy.
2. Rimuovere RDS01 da Multi-user hosts e salvare con Apply.
3. Revocare in modo controllato la GPO del proxy, il file PAC o la configurazione dell’applicazione.
4. Ripristinare la precedente associazione STAS, Clientless o Captive Portal solo se era stata documentata in precedenza ed era adatta a questo IP.
5. Dopo aver verificato le altre dipendenze, rimuovere l’eccezione ACL del progetto pilota o le autorizzazioni temporanee di zona per AD SSO e Web Proxy, oppure riportarle esattamente allo stato precedente.
6. Disattivare o rimuovere le regole specifiche per host e sistemi non appena il percorso sostitutivo è stato confermato.
7. Ripetere i test con nuove sessioni browser e RDS e, in caso di HA, su entrambi i ruoli operativi.

Checklist

• Per-Connection AD SSO è previsto solo per il traffico HTTP/HTTPS tramite proxy esplicito.
• L’host pilota ha un IP fisso e univoco, senza altri sistemi dietro di esso.
• AD, gruppi, join al dominio, FQDN, DNS, SPN e ora sono stati verificati.
• Prerequisito di zona AD SSO e impatto sulla sicurezza verificati; zona LAN necessaria attivata e Apply selezionato, accesso Web proxy limitato separatamente all’host pilota senza autorizzazioni proxy ampie. Se l’autorizzazione di zona non è accettabile, interrompere il rollout e ottenere una configurazione supportata con ambito ristretto.
• Browser e applicazioni utilizzano fw01.corp.example:3128 o i valori sostitutivi del proprio ambiente.
• La regola host specifica ha il logging attivo e Match known users disattivato.
• Il traffico non proxy è stato pianificato come traffico dei sistemi oppure la configurazione è stata modificata per utilizzare SATC.
• Sono stati eseguiti test positivi e negativi con due utenti paralleli, policy differenti e accesso di gestione.
• Per failover HA e aggiornamenti esiste una procedura documentata di rejoin e ripetizione dei test.
• È documentato il rollback dell’elenco multiutente, della distribuzione del proxy, di Device Access, delle regole e dell’autenticazione precedente.

Domande frequenti