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 questo caso specifico per il traffico web: Direct Web Proxy autentica separatamente ogni connessione HTTP e HTTPS con Kerberos o NTLM.

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

Stabilire se solo HTTP e HTTPS inviati tramite un proxy esplicito devono essere elaborati in base all’utente.
Verificare Active Directory, l’importazione dei gruppi, DNS, l’ora e il Domain Join del firewall.
Preparare un FQDN risolvibile per il firewall e un HTTP SPN corrispondente per Kerberos.
Consentire AD SSO e Web proxy solo per la zona di origine o l’host pilota necessari.
Creare il server RDS come oggetto IP host esatto.
Attivare Per-Connection AD SSO per questo host in Authentication > Web authentication.
Configurare browser e applicazioni compatibili con il proxy affinché utilizzino il FQDN del firewall e la porta 3128.
Posizionare una regola host dedicata e con logging prima di regole utente concorrenti, lasciando Match known users disattivato.
Testare separatamente due sessioni RDS parallele, risultati diversi della Web Policy e traffico non proxy.

Per-Connection AD SSO, STAS o SATC?

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

STAS è adatto ai normali client Windows quando un IP client appartiene in genere a un solo utente. Il firewall riceve un’associazione tra utente e 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. Sul server RDS non è necessario un agente SATC, ma tutte le applicazioni devono utilizzare Direct Web Proxy in modo affidabile.
SATC è adatto ai sistemi RDS o Citrix quando anche altri tipi di connessione provenienti dalle singole sessioni utente devono ricevere un’identità. A tale scopo è necessario Sophos Server Protection sul Session Host.

Il normale 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. Se un’applicazione non supporta un proxy esplicito o i protocolli non web devono essere regolati in base all’utente, occorre fermarsi qui e valutare SATC.

Esempio e valori sostituibili

La guida utilizza questo esempio:

Host multiutente: RDS01
Indirizzo IP: 10.20.30.40
FQDN del firewall e destinazione proxy: fw01.corp.example
Porta di Direct Web Proxy: 3128
Gruppi AD: RDS-Web-Standard e RDS-Web-Restricted
un account pilota per gruppo con risultati della Web Policy volutamente diversi

Occorre sostituire 10.20.30.40 con l’IP fisso del server pilota così come viene visto dal firewall. Dietro questo indirizzo non devono comparire altri sistemi tramite NAT. fw01.corp.example è un nome di 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, in modo che hostname, nome NetBIOS, oggetto computer AD e SPN corrispondano.

La porta 3128 è il valore predefinito di Direct Web Proxy. Se l’ambiente utilizza un listening port diverso, firewall, file PAC o GPO, browser e test devono usare lo stesso valore. I gruppi di esempio servono solo a rendere comprensibile il collaudo; i nomi dei gruppi e le Web Policies devono corrispondere alla struttura di autorizzazione effettiva.

Preparare i prerequisiti

Verificare Active Directory e il Domain Join

Il firewall richiede un server Active Directory funzionante, gruppi importati e un Domain Join completato correttamente. Collegare Active Directory a Sophos Firewall spiega LDAPS, base di ricerca, importazione dei gruppi e prerequisiti generali di AD SSO.

Per le normali query LDAP è sufficiente un account con autorizzazioni di lettura. Il Domain Join e la creazione dell’SPN richiedono invece un account Domain Admin o un account con autorizzazioni correttamente delegate. L’account memorizzato deve consentire anche un successivo rejoin, perché HA, altri server AD o gli aggiornamenti possono attivarlo di nuovo. Non è opportuno mantenere inutilmente un account Domain Admin senza restrizioni per questo scopo.

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

Controllare FQDN, DNS, SPN e ora

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

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

L’HTTP SPN, ovvero Service Principal Name, associa il FQDN del proxy all’oggetto computer AD del firewall. setspn -Q dovrebbe restituire una sola associazione corrispondente. L’assenza di risultati o la presenza di più risultati deve essere chiarita prima del rollout.

La risposta DNS deve corrispondere al firewall previsto. Client, Domain Controller e firewall devono inoltre utilizzare un’ora compatibile con Kerberos. I comandi non modificano nulla. Non si devono correggere SPN, Domain Join o configurazione dell’ora sulla base di un sospetto, ma occorre prima dimostrare l’errore effettivo.

Rilevare il supporto del proxy e le eccezioni

Ogni browser e applicazione il cui traffico web deve ricevere un’identità utente deve utilizzare il proxy esplicito e supportare l’autenticazione Windows integrata. Prima del rollout occorre verificare almeno:

i browser in ogni sessione RDS supportata
le applicazioni con un proprio stack HTTP
gli aggiornamenti di Windows e del software
i servizi eseguiti nel contesto di sistema anziché in una sessione utente
le destinazioni presenti nel file PAC o nell’elenco di bypass del proxy

Il traffico che bypassa il proxy rimane, come previsto, privo di ID utente. Per le connessioni macchina necessarie occorre pianificare una regola separata, strettamente limitata e senza riferimento all’utente. Una regola ampia con Any ridurrebbe l’efficacia di sicurezza delle regole utente e delle Web Policies.

Configurare Per-Connection AD SSO

1. Preparare il FQDN del firewall e AD SSO

In Administration > Admin and user settings, inserire il FQDN previsto del firewall. Quindi, in Authentication > Web authentication, selezionare Kerberos & NTLM per If Active Directory (AD) SSO is configured. NTLM è tecnicamente supportato come fallback, ma nelle installazioni più grandi Kerberos dovrebbe funzionare in modo affidabile, perché Per-Connection AD SSO può generare molte richieste di autenticazione aggiuntive.

Dopo l’inizializzazione di AD SSO, in Authentication nel Log Viewer devono comparire questi messaggi di esito positivo:

Kerberos authentication initialized successfully
NTLM authentication channel established successfully

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

2. Limitare Device Access

In Administration > Device access, AD SSO e Web proxy devono essere consentiti per il percorso di origine previsto. Per un IP pilota fisso, una Local service ACL exception rule mirata è in genere più restrittiva di un’autorizzazione per l’intera zona LAN. Un’ulteriore eccezione di accettazione non limita tuttavia un’autorizzazione di zona già attiva; per un design realmente ristretto, l’autorizzazione ampia deve rimanere disattivata. Device Access e Local Service ACL descrive la configurazione completa.

L’accesso al Web Proxy ha un importante effetto collaterale: un host autorizzato può raggiungere i servizi HTTP e HTTPS del firewall tramite il proxy anche se la relativa zona non è abilitata nella normale matrice Local Service. Da tale host occorre quindi testare in negativo WebAdmin, User Portal e altre destinazioni locali. Se questa esposizione non è accettabile nel design di sicurezza della rete, non si deve attivare il modello in produzione.

In Web > General settings, verificare il Web proxy listening port effettivo e le porte di destinazione consentite. Modificare il valore predefinito 3128 solo se file PAC, GPO e tutte le applicazioni gestite possono essere adattati in modo coerente.

3. Creare l’host multiutente

Creare un nuovo oggetto host nel seguente percorso:

Hosts and services > IP host > Add

Per l’esempio utilizzare questi valori:

Name: RDS01
IP version: IPv4
Type: IP
IP address: 10.20.30.40

Per il primo test non inserire un intero intervallo o una subnet. In caso contrario, molti sistemi potrebbero perdere contemporaneamente l’autenticazione basata su IP precedente. Dopo il collaudo individuale, più host approvati possono essere raggruppati in modo controllato in un host group.

4. Attivare Per-Connection AD SSO

Passare a:

Authentication > Web authentication > Authentication settings for direct web proxy

Quindi:

Attivare Use per-connection AD SSO authentication for multi-user hosts.
Aggiungere l’oggetto RDS01 in Multi-user hosts.
Salvare con Apply.

Da questo momento STAS, Captive Portal, Clientless User e AD SSO trasparente non sono più disponibili per 10.20.30.40. La modifica deve quindi essere eseguita durante una finestra di manutenzione e non si deve usare una sessione RDS esistente come unico test.

5. Distribuire Direct Web Proxy

Configurare il proxy del browser o del sistema mediante GPO, file PAC o applicazione gestita con questo valore:

fw01.corp.example:3128

Kerberos richiede esattamente il FQDN corrispondente all’SPN. Un indirizzo IP come destinazione proxy, un nome breve non risolvibile o un altro alias causano spesso un fallback a NTLM o una richiesta di credenziali. Le voci di bypass devono essere volutamente limitate e documentate, perché ogni connessione ignorata non riceve un’identità Per-Connection.

La configurazione generale di listener, PAC, regola e rollback è descritta in Configurare Direct Web Proxy con un file PAC. Questo articolo aggiunge soltanto l’autenticazione multi-utente.

6. Posizionare una regola firewall dedicata

In Rules and policies > Firewall rules, creare una regola outbound dedicata e chiaramente denominata per RDS01. Deve trovarsi prima delle regole che includono lo stesso host con Match known users.

Il quadro sicuro è il seguente:

Source zones: zona RDS effettiva, ad esempio LAN
Source networks and devices: solo RDS01
Destination zones: WAN
Destination networks: solo le destinazioni necessarie oppure, in modo consapevole, Any
Services: un servizio TCP personalizzato per 3128 o per il proxy listening port realmente configurato; Any solo in modo consapevole
Log firewall traffic: attivo
Match known users: disattivato
Web filtering > Web policy: selezionare la policy preparata in base all’utente o al gruppo

Le Web Policies possono distinguere utenti e gruppi nel traffico proxy, ma hanno effetto solo dopo essere state assegnate alla regola firewall. Questa distinzione deve essere configurata nella Web Policy, non in Match known users della regola host. Dopo aver selezionato o modificato la Web Policy, controllare nuovamente l’interruttore, perché una dipendenza dall’utente può riattivarlo.

Creare una regola macchina separata per DNS, aggiornamenti e altre connessioni necessarie non proxy. Non aggiungere una regola generale da WAN a LAN; l’esempio inbound mostrato da Sophos non è necessario per il normale accesso web RDS e, senza uno scopo di pubblicazione distinto, costituirebbe una superficie di attacco inutile. Creare correttamente le regole firewall spiega struttura, ordine e logging.

Eseguire il collaudo con due utenti RDS

Una singola richiesta riuscita nel browser dimostra solo che un qualche traffico proxy funziona. Il collaudo effettivo richiede due sessioni parallele.

Assegnare due account pilota AD a gruppi Web Policy diversi.
Aprire due nuove sessioni RDS su RDS01.
Verificare la configurazione proxy effettiva in entrambe le sessioni.
Generare una richiesta consentita e una richiesta HTTP o HTTPS valutata volutamente in modo diverso.
In Current activities > Live users, verificare entrambi gli utenti con Client Type Multi-host client.
In Log viewer > Authentication, controllare l’utente e Log Comp per Kerberos o NTLM.
Confrontare utente, policy, Rule ID, azione e orario nei log web e firewall.
Generare un test non proxy necessario e confermare che non riceva erroneamente un’identità utente.
Dall’host pilota, rilevare quali servizi HTTP e HTTPS locali del firewall sono raggiungibili tramite il proxy. Se è accessibile un servizio vietato dal design di sicurezza, interrompere il rollout e proseguire solo dopo aver dimostrato una misura di protezione aggiuntiva.

Aggiungere altri host RDS solo quando entrambi gli utenti vengono distinti correttamente nello stesso momento, si ottengono i risultati previsti della Web Policy e si comprende il percorso non proxy. Testare in modo controllato le regole di Sophos Firewall aiuta con il collaudo generale delle regole.

Risoluzione dei problemi

Il proxy non è raggiungibile

Verificare la risoluzione del FQDN, la porta, il risultato del file PAC o della GPO, la zona di origine e le autorizzazioni Web proxy e AD SSO. Un test riuscito del server AD non dimostra l’accesso al proxy. Con le rotte SD-WAN, la porta proxy o Any devono corrispondere al servizio; il firewall crea autonomamente la connessione proxy esterna, pertanto non tutte le caratteristiche del client si applicano come nel normale traffico instradato.

Il browser richiede le credenziali o utilizza NTLM

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

Entrambe le sessioni compaiono con lo stesso utente

Verificare se entrambi i browser utilizzano realmente il proxy esplicito e se un’applicazione crea connessioni al di fuori della rispettiva sessione utente. Anche un proxy a monte o NAT può modificare il modello di connessione previsto. In Live Users deve comparire il tipo Multi-host client; una normale associazione basata su IP è il percorso errato per questo host.

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

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

Il traffico non web non mostra alcun utente

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

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

AD SSO può richiedere un nuovo Domain Join dopo un aggiornamento, quando si utilizzano più server AD o in HA. L’account di join delegato deve quindi rimanere valido. Dopo un failover controllato, eseguire il test con una nuova connessione proxy e con 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. Occorre quindi controllare il nodo attivo o che elaborava il traffico al momento dell’evento.

Leggere i log rilevanti

Nell’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 e possibili errori KVNO. access_server.log aiuta per autenticazione e autorizzazione, awarrenhttp.log per Web Proxy. awarrenhttp_access.log viene creato solo con il debug attivato temporaneamente e non fa parte del normale primo passaggio. Prima di riavviare i servizi o ampliare il debug, salvare innanzitutto intervallo di tempo, utente, destinazione, regola e log esistenti.

Rollback

Un rollback ordinato ripristina non solo il proxy, ma anche il precedente modello di autenticazione.

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

Lista di controllo

Per-Connection AD SSO è previsto solo per traffico HTTP e HTTPS inviato tramite un proxy esplicito.
L’host pilota dispone di un IP fisso e univoco senza altri sistemi dietro di esso.
Sono stati verificati AD, gruppi, Domain Join, FQDN, DNS, SPN e ora.
AD SSO e Web Proxy sono consentiti solo per il percorso di origine necessario.
Browser e applicazioni utilizzano fw01.corp.example:3128 o i valori sostitutivi dell’ambiente.
La regola host dedicata ha il logging attivo e Match known users disattivato.
Il traffico non proxy è pianificato come traffico macchina oppure il design è stato modificato in SATC.
Sono stati eseguiti test positivi e negativi con due utenti paralleli, policy diverse e accesso di gestione.
Failover HA e aggiornamenti dispongono di una procedura documentata di rejoin e nuovi test.
È documentato il rollback di elenco multiutente, distribuzione del proxy, Device Access, regole e autenticazione precedente.

Domande frequenti

Per-Connection AD SSO può sostituire SATC?

Solo quando è necessaria una valutazione in base all’utente esclusivamente per HTTP e HTTPS tramite Direct Web Proxy. SATC può associare tutti i tipi di connessione supportati provenienti dalle sessioni utente RDS ed è quindi necessario quando anche il traffico non proxy deve ricevere un’identità utente.

Perché Match known users deve essere disattivato?

La regola firewall dedicata deve prima corrispondere all’IP dell’host multiutente. Se Match known users è attivo, il firewall può elaborare il traffico dell’host tramite un’associazione IP esistente, spesso quella di un utente amministrativo, e ignorare le regole successive. In questo design, le differenze tra utenti e gruppi vengono valutate nella Web Policy.

Perché il browser utilizza NTLM anziché Kerberos?

Spesso la destinazione proxy non corrisponde all’HTTP SPN, il FQDN del firewall non viene risolto correttamente oppure il browser non considera attendibile la destinazione per l’autenticazione integrata. Kerberos richiede il FQDN come destinazione proxy e non funziona con un indirizzo IP.

Anche il traffico RDP, SMB o DNS riceve un'identità utente?

No. Per-Connection AD SSO si applica solo alle connessioni HTTP e HTTPS tramite Direct Web Proxy. Il traffico restante rimane non autenticato e richiede una regola macchina adatta o un altro metodo come SATC.