Configurare Sophos Firewall SATC per Remote Desktop Services

Sophos Authentication for Thin Client, in breve SATC, consente di applicare regole basate sugli utenti a Remote Desktop Services. Questo è importante ogni volta che più utenti accedono alla rete o a Internet tramite lo stesso Windows Remote Desktop Session Host. In questi casi il classico STAS vede spesso solo l’indirizzo IP del terminal server. SATC fornisce invece a Sophos Firewall informazioni utente dalle singole sessioni RDS.

Per i normali client Windows, il primo passo è configurare STAS su Sophos Firewall. SATC non sostituisce STAS in ogni ambiente, ma è il componente adatto per Remote Desktop Services.

Utilizzo e pianificazione

Quando SATC è utile

SATC è adatto quando gli utenti non passano attraverso il firewall direttamente dal proprio client, ma usano applicazioni o browser su un Remote Desktop Session Host.

Scenari tipici:

• Remote Desktop Services con più utenti simultanei
• terminal server su cui gli utenti hanno bisogno di accesso web o applicativo
• regole firewall basate su utente per utenti RDS
• reporting in cui non deve essere visibile solo l’indirizzo IP del server RDS
• ambienti in cui STAS non è sufficiente perché più utenti condividono lo stesso IP sorgente

SATC non è il punto di partenza giusto per normali client di dominio, utenti VPN o scenari puramente Captive Portal. In quei casi bisogna prima scegliere il modello di autenticazione appropriato: STAS, Captive Portal, autenticazione VPN, RADIUS o Microsoft Entra ID SSO.

Su un singolo endpoint non appartenente al dominio, il Client Authentication Agent può offrire un accesso utente esplicito. Non sostituisce SATC su un host multiutente, perché più sessioni condividono lo stesso IP sorgente.

Se un host multiutente deve distinguere soltanto HTTP e HTTPS tramite un proxy esplicito, Per-Connection AD SSO tramite Direct Web Proxy può essere sufficiente senza un agente SATC. Non appena anche RDP, SMB o altro traffico non proxy richiede un’identità per sessione utente, SATC rimane il design appropriato.

Separare correttamente STAS e SATC

La differenza più importante è l’associazione IP.

• Un client Windows appartiene di solito a un utente: STAS.
• Molti utenti condividono lo stesso IP del server RDS: SATC.
• Gli utenti effettuano il login nel browser perché le regole si applichino: Captive Portal.
• Gli utenti arrivano tramite Remote Access VPN: Autenticazione VPN o Entra ID SSO.
• Il traffico passa attraverso server tecnici senza riferimento utente: normali regole firewall senza utente.

Se un terminal server viene rappresentato erroneamente tramite STAS o Clientless User, nascono rapidamente aspettative sbagliate. Una regola sembra basata su utente, ma in realtà il firewall vede solo un IP server condiviso. SATC risolve esattamente questo problema, ma richiede una configurazione dedicata sul Windows Server e sul firewall.

Se STAS e SATC vengono usati contemporaneamente, la separazione concettuale da sola non basta. Citrix XenApp e Windows Server RDS possono far sì che STAS restituisca un’identità utente errata per lo stesso IP server se non viene escluso. Per questo motivo gli indirizzi IP dei server Citrix/RDS devono essere inseriti nella configurazione STAS sotto Login IP Address/Network Subnet mask Exclusion List e Logoff IP Address/Network Subnet mask Exclusion List. Senza questa esclusione, STAS può continuare a fornire una propria mappatura utente contraddittoria proprio per gli IP server che dovrebbero usare SATC.

Requisiti

Prima della configurazione questi punti dovrebbero essere chiariti:

• Sophos Server Protection può essere usato sul Remote Desktop Session Host.
• Il Windows Server funziona come Remote Desktop Session Host.
• Si usa Windows Server 2016 o versione successiva.
• La Sophos Firewall è raggiungibile.
• Active Directory è collegato alla Sophos Firewall.
• I gruppi AD necessari sono importati sul firewall.
• In Administration > Device access, la zona del server RDS è consentita nella riga Clients.
• Il server RDS può raggiungere l’IP del firewall tramite UDP 6060; eventuali firewall host o di rete intermedi consentono questo percorso.
• Le regole firewall potranno poi lavorare con Match known users.
• Esiste una finestra di manutenzione per la modifica Registry e il riavvio del server RDS.

Il collegamento AD deve essere configurato correttamente prima di implementare SATC. Se AD non è ancora pronto, verificare prima Collegare Active Directory a Sophos Firewall.

Limiti importanti

SATC ha alcuni limiti che bisogna conoscere prima del rollout:

• Standalone-SATC: Non è più supportato da Sophos Firewall.
• Distribuzione: SATC funziona tramite Sophos Server Protection o Sophos Fusion Server Core Agent.
• Piattaforma: secondo Sophos, la configurazione attuale con Sophos Server Protection supporta solo Windows Remote Desktop Services. La panoramica precedente cita ancora Citrix XenApp nel contesto del conflitto con STAS e il parametro CLI continua a chiamarsi citrix-ip. Nessuno dei due elementi costituisce una prova attuale del supporto per un nuovo rollout Citrix. Un’implementazione Citrix esistente va quindi verificata con Sophos Support prima di apportare modifiche e non deve essere ricreata seguendo questa guida RDS.
• Servizi di sistema: SATC assegna un’identità di directory solo alle connessioni create da processi utente. I processi avviati dai servizi di sistema Windows restano senza identità utente e richiedono una regola macchina separata e strettamente limitata con Match known users disattivato. Questa regola non deve diventare un fallback ampio per il restante traffico RDS.
• Limite server: Sophos indica fino a 192 Thin Client Server sul firewall.
• Autenticazione per IP server: Se un IP server RDS è registrato sul firewall come Thin Client, SATC funziona come metodo di autenticazione per questo IP. Altri metodi come Clientless User non si applicano a questo IP.

Proprio l’ultimo punto è importante. Non bisognerebbe inserire per prova IP di terminal server produttivi senza capire il set di regole e il percorso di ritorno. Appena l’IP viene trattato come sorgente SATC, cambiano le aspettative su associazione utente e rule matching.

Configurazione

Procedura in sintesi

La procedura tecnica consiste in cinque parti:

1. Installare Sophos Server Protection sul server RDS.
2. Attivare SATC sul server RDS tramite Registry.
3. Registrare l’IP del server RDS nella Device Console della Sophos Firewall.
4. Verificare server AD, gruppi e ordine di autenticazione sul firewall.
5. Validare Device Access, regola firewall e Live Users.

SATC non dovrebbe essere solo installato, ma anche testato. Un’installazione riuscita sul server non prova ancora che il firewall vedrà poi l’utente corretto nella regola corretta.

Installare Sophos Server Protection

L’installazione avviene tramite Sophos Fusion (in precedenza Sophos Central).

Procedura:

1. Accedere a Sophos Fusion.
2. Aprire Protect Devices.
3. Scaricare il Windows Server Installer sotto Server Protection.
4. Installare il programma di installazione sul Remote Desktop Session Host.
5. Verificare se il server appare correttamente in Sophos Fusion.
6. Definire una finestra di manutenzione per l’attivazione SATC.

SATC fa parte del Sophos Fusion Server Core Agent e, secondo Sophos, è disponibile con qualsiasi licenza Server Protection. I programmi di installazione effettivamente visibili in Sophos Fusion dipendono comunque dalle licenze disponibili. Se sul server è già in esecuzione Sophos Server Protection, va inoltre verificato se l’agent è aggiornato e se Tamper Protection può essere disattivata in modo controllato e poi riattivata.

Attivare SATC tramite Registry

SATC viene controllato sul server RDS tramite valori Registry sotto questo percorso:

HKLM\Software\Sophos\Sophos Network Threat Protection\Application

Prima della modifica, questo comando di sola lettura mostra quali valori SATC sono già presenti:

reg query "HKLM\Software\Sophos\Sophos Network Threat Protection\Application"

Attenzione: Le modifiche al Registry e il successivo riavvio interessano tutte le sessioni RDS attive. Documentare i valori attuali, utilizzare una finestra di manutenzione e disattivare Tamper Protection solo in modo controllato. Dopo la modifica deve essere riattivata.

La configurazione di base può essere impostata da un prompt dei comandi amministrativo:

reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SendSatcEvents /t REG_DWORD /d 1 /f
reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcDestinationAddr /t REG_SZ /d FIREWALL-IP /f
reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcDestinationPort /t REG_DWORD /d 6060 /f

Sostituire FIREWALL-IP con l’indirizzo IPv4 di Sophos Firewall raggiungibile dalla zona del server RDS. Sophos documenta UDP 6060 per SATC, quindi nell’esempio 6060 resta invariato. Non usare un indirizzo WAN pubblico quando server e firewall comunicano tramite un’interfaccia interna.

Raccomandazione Avanet: Collegare inizialmente un solo host RDS e consentire UDP 6060 esclusivamente tra questo host e il firewall. In questo modo un errore resta limitato al server pilota prima di aggiungere altri Session Host.

Dopo:

1. Riattivare Tamper Protection.
2. Riavviare il server RDS.
3. Dopo il riavvio verificare se il servizio Sophos è in esecuzione.
4. Eseguire nuovamente il comando di sola lettura reg query e controllare i valori impostati.
5. Solo dopo proseguire con configurazione firewall e test.

Escludere account locali e destinazioni

Per impostazione predefinita anche account locali come SYSTEM o Administrator possono generare eventi SATC. Per le regole utente questo di solito non è utile e può sporcare inutilmente i log.

Con SatcExcludedUsers si possono escludere utenti. Le voci distinguono tra maiuscole e minuscole, quindi i nomi devono rispettare esattamente la grafia usata nel sistema.

Esempio:

reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcExcludedUsers /t REG_MULTI_SZ /d "SYSTEM\0administrator" /f

Con SatcExcludedAddresses si possono escludere destinazioni per le quali non devono essere inviate informazioni SATC al firewall. Questo può essere utile per destinazioni locali di management, update o infrastruttura, ma va documentato in modo esplicito.

SatcExcludedAddresses è un valore multistringa (MULTISTRING / REG_MULTI_SZ). Per impostare più destinazioni con reg add nel prompt dei comandi di Windows, separare le voci nell’argomento dati /d con \0, non con virgole. Anche questa modifica richiede i passaggi di manutenzione, protezione antimanomissione, verifica e ripristino descritti sopra.

Formati possibili:

192.0.2.10
192.0.2.10:443
*:443

192.0.2.10 è un indirizzo di documentazione e va sostituito con l’IP effettivo della destinazione. La seconda voce vale soltanto per la porta 443 di quella destinazione, mentre *:443 copre la porta per ogni destinazione. Un’eccezione così ampia sottrarrebbe praticamente tutto il traffico HTTPS alla mappatura SATC e non è adatta alle normali regole utente.

Raccomandazione Avanet: Iniziare senza eccezioni e aggiungerle solo dopo un riscontro chiaro nei log. Assegnare a ogni eccezione un responsabile, uno scopo e una data di revisione.

In caso di latenza di rete percepibile tra il server RDS e il firewall, si può impostare anche SatcPendDurationMs. Il valore determina per quanto tempo vengono trattenute le connessioni TCP IPv4 in uscita, affinché l’associazione utente sia disponibile in tempo. Se il valore Registry non è presente, SATC usa 100 millisecondi; 0 disattiva solo questo ritardo della connessione, non SATC. Modificarlo solo in presenza di reali problemi di latenza, non per precauzione.

reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcPendDurationMs /t REG_DWORD /d 300 /f

300 è un esempio diagnostico adattabile, non un nuovo valore predefinito consigliato. Aumenta il ritardo rispetto al default documentato di 100 millisecondi per ogni connessione TCP IPv4 in uscita interessata. Misurare prima e dopo con lo stesso utente e la stessa destinazione. Se non porta benefici, il seguente comando amministrativo ripristina il default eliminando il valore opzionale:

reg delete "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcPendDurationMs /f

Come per le altre modifiche al registro, in seguito è necessario riavviare il server RDS.

Registrare il server RDS sul firewall

Il firewall deve sapere quali server forniscono informazioni SATC. Questo avviene nella Device Console, non nella Advanced Shell.

Procedura:

1. Accedere alla Sophos Firewall tramite console o SSH.
2. Aprire l’opzione 4. Device Console.
3. Visualizzare le voci esistenti:

system auth thin-client show

4. Aggiungere l’IP del server RDS solo se non è ancora elencato:

system auth thin-client add citrix-ip <RDS-SERVER-IP>

<RDS-SERVER-IP> viene sostituito dall’indirizzo IP del Remote Desktop Session Host.

Se sono presenti più server RDS, registrare ogni server singolarmente e in modo documentato. Dopo deve essere chiaro:

• quali server valgono come sorgenti SATC
• quale zona usano questi server
• quali regole firewall valutano gli utenti di questi server
• chi approva modifiche alla lista server RDS

Se è stato registrato un IP errato, controllare nuovamente l’elenco e rimuoverlo in modo mirato:

system auth thin-client delete citrix-ip <RDS-SERVER-IP>

Il comando rimuove solo la voce Thin Client sul firewall; i valori Registry e Sophos Server Protection restano sul server RDS. Per un IP produttivo viene così meno l’associazione SATC e le regole basate sugli utenti possono non fare più match. Sophos non documenta come reagiscono le sessioni già esistenti. Rimuovere quindi la voce solo durante una finestra di manutenzione e con una procedura di ripristino preparata.

Verificare Active Directory e gruppi

SATC fornisce informazioni utente. Affinché il firewall possa usare queste informazioni nelle regole, collegamento AD e gruppi devono essere corretti.

Verificare:

1. Aprire Authentication > Servers.
2. Verificare il server AD con Test connection.
3. Controllare l’importazione dei gruppi.
4. Aprire Authentication > Groups.
5. Cercare i gruppi rilevanti.
6. Aprire Authentication > Services.
7. Verificare il server AD nell’ordine corretto delle Firewall authentication methods.

Solo se si vuole interrogare AD per primo: Prima di modificare la configurazione, documentare l’ordine attuale e verificare l’ordine di autenticazione previsto e il piano di ripristino; non riordinare indiscriminatamente l’autenticazione in produzione. In Authentication > Services > Firewall authentication methods, selezionare il server AD pertinente, spostarlo nella prima posizione dell’elenco dei server selezionati e fare clic su Apply. In caso di effetti indesiderati, ripristinare l’ordine precedente documentato e fare clic su Apply.

Per l’assegnazione ai gruppi AD, Sophos documenta che durante l’autenticazione gli utenti vengono associati ai propri gruppi AD importati sul firewall; i gruppi vengono valutati e aggiornati a ogni accesso. Solo se nessuno dei gruppi AD dell’utente esiste sul firewall viene assegnata la Default group configurata in Authentication > Services > Firewall authentication methods. Questo meccanismo di fallback non sostituisce l’importazione dei gruppi mancanti.

Contraddizione tra le fonti al primo accesso: La descrizione della configurazione SATC indica un’assegnazione automatica al gruppo predefinito al primo accesso al firewall, mentre la descrizione dei gruppi AD prevede un fallback condizionale. Non è stato chiarito se si intenda uno stato iniziale specifico di SATC. Non presumere quindi né un’assegnazione generalizzata al gruppo predefinito né una particolare priorità dei gruppi per SATC.

Prima del rollout in produzione: Verificare i gruppi importati in Authentication > Groups e il valore effettivamente configurato di Default group, insieme alle impostazioni ereditate, in Authentication > Services. Far accedere nuovamente un utente di test, controllarne l’assegnazione effettiva ai gruppi in Authentication > Users e usare traffico di test RDS in Log Viewer per verificare la regola prevista e gli accessi sia consentiti sia bloccati. Se si intende utilizzare il fallback, provarlo anche con un account di test i cui gruppi AD non siano presenti sul firewall, senza eliminare gruppi di produzione. L’appartenenza al gruppo predefinito da sola non dimostra che venga applicata la regola desiderata. In caso di assegnazione inattesa, interrompere il rollout e chiarire con Sophos Support; non ampliare gruppi di utenti o regole per aggirare il problema.

Se gli utenti compaiono nell’area Live Users, ma le regole non si applicano, la causa spesso non è SATC stesso, ma importazione gruppi, gruppo standard, criterio della regola o posizione della regola.

Impostare Device Access e regola firewall

Affinché il firewall accetti i messaggi SATC dalla zona server, il servizio locale Clients deve essere consentito per questa zona. SFOS 22 documenta UDP 6060; Clients comprende anche STAS e Client Authentication Agent sulla relativa porta.

Percorso:

Administration > Device access

Attivare la zona del server RDS nella riga Clients. Non bisogna aprire alla cieca WAN o una zona ampia e insicura. Device Access controlla servizi locali del firewall e fa parte dell’hardening del management.

Dopo serve una regola firewall per il traffico effettivo.

Procedura tipica:

1. Aprire Rules and policies > Firewall rules.
2. Creare una regola adatta al traffico dal server RDS o dalla zona server. Come esempio adattabile, la regola RDS-Web-Users può inizialmente consentire solo il servizio HTTPS necessario dall’oggetto host RDSH-01 in LAN verso WAN.
3. Adattare Source zones, Source networks and devices, Destination zones e Services alla propria topologia. RDSH-01, LAN, WAN e HTTPS sono esempi, non requisiti del prodotto.
4. Attivare Match known users.
5. Selezionare gli utenti AD o i gruppi AD necessari.
6. Attivare Logging, così il test sarà tracciabile in seguito.
7. Salvare la regola.
8. Generare traffico di test da una sessione RDS.

Raccomandazione Avanet: Rendere la regola pilota più restrittiva di quella di produzione e posizionarla subito sopra una regola di blocco documentata. Ampliare servizi o gruppi utenti solo dopo un test riuscito con due utenti RDS diversi.

Per il troubleshooting successivo il logging è importante. Se una regola utente viene creata senza logging, è più difficile riconoscere se il problema è SATC, group matching, ordine delle regole o un altro percorso.

Validazione e operatività

Validazione dopo la configurazione

Dopo la configurazione non bisogna verificare solo se un utente ha accesso a Internet. È decisivo se il firewall vede l’utente corretto e applica la regola corretta.

Test pratico:

1. Effettuare il login con un utente in una sessione RDS.
2. Generare traffico di test definito, per esempio una connessione HTTPS consentita.
3. Aprire nella Sophos Firewall Current activities > Live users.
4. Verificare se l’utente compare con Client type Thin client.
5. Verificare che l’indirizzo IP del server RDS appaia con un ID sessione univoco per ogni utente.
6. Aprire Log Viewer.
7. Filtrare per Source IP del server RDS, utente e regola.
8. Verificare se si applica la regola basata su utente attesa.

Ripetere il test con un secondo utente e la stessa connessione di destinazione. Il successo non significa soltanto che entrambe le connessioni siano consentite: Live users deve mostrare due identità con lo stesso IP del server RDS ma ID sessione differenti, e Log Viewer deve mostrare ogni volta l’utente corretto. Verificare anche un servizio di sistema documentato se è stata creata una regola macchina separata; questo traffico non deve essere attribuito erroneamente a un utente connesso.

Per un’analisi più approfondita nell’Advanced Shell, firewall_rule.log è rilevante per il rule match e access_server.log per autenticazione e autorizzazione. Log Viewer resta il percorso iniziale più rapido.

Se il traffico non scorre come previsto, aiuta inoltre Testare una regola firewall con Log Viewer, Policy Test e Packet Capture. Se gli utenti sono visibili, ma gruppi o singoli utenti non fanno match, La regola Sophos Firewall non matcha è il prossimo percorso di verifica adatto.

Operatività e documentazione

SATC dovrebbe essere gestito come un componente produttivo di autenticazione, non come un hack Registry una tantum.

Documentare:

• server RDS e indirizzi IP
• IP firewall e porta SATC usati
• valori Registry impostati
• utenti e destinazioni esclusi
• regole firewall interessate
• gruppi AD e responsabile
• utente di test e rule match atteso
• finestra di manutenzione e orario di riavvio

Dopo update di Sophos Server Protection, Windows Server, Sophos Firewall o AD, SATC dovrebbe essere verificato in modo mirato con un utente di test. I problemi di autenticazione spesso diventano evidenti solo quando le regole utente improvvisamente si applicano in modo troppo ampio o non si applicano più.

Rollback durante una finestra di manutenzione

Sophos documenta che SendSatcEvents attiva SATC solo quando il valore è presente e diverso da 0, e che la voce Thin Client sostituisce gli altri metodi di autenticazione per questo IP server. Ne deriva un percorso di ritorno pianificato, ma non un ripristino automatico del precedente metodo di identità.

1. Registrare prima la query Registry, l’output di system auth thin-client show, le regole interessate e il precedente modello di autenticazione.
2. Disconnettere le sessioni RDS attive nella finestra di manutenzione, disattivare Tamper Protection in modo controllato e disattivare SendSatcEvents da un prompt dei comandi amministrativo:

reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SendSatcEvents /t REG_DWORD /d 0 /f

3. Riattivare Tamper Protection e riavviare il server RDS.
4. Nella Device Console controllare la voce con system auth thin-client show, quindi eliminarla in modo mirato:

system auth thin-client delete citrix-ip <RDS-SERVER-IP>

5. Ripristinare il modello di regole e autenticazione precedentemente documentato e validarlo con un utente di test. Non attivare senza verifica un Clientless User o una regola macchina ampia come sostituzione.

Raccomandazione Avanet: Non eliminare tutti i valori Registry prima di aver chiarito la causa. Il valore 0 conserva l’indirizzo di destinazione e le liste di esclusione per una riattivazione controllata; un export Registry preserva inoltre lo stato iniziale esatto.

Troubleshooting

Nessun utente Thin Client visibile

Verificare:

• il server RDS è stato riavviato dopo la modifica Registry.
• SendSatcEvents è impostato e diverso da 0.
• SatcDestinationAddr punta all’IP firewall corretto.
• SatcDestinationPort corrisponde alla porta attesa.
• il percorso di rete dal server RDS al firewall è aperto per UDP 6060.
• l’IP del server RDS è stato registrato sul firewall tramite system auth thin-client add citrix-ip.
• la zona del server RDS è consentita nella riga Clients sotto Device Access.

L’utente rimane non autenticato a causa di un conflitto della porta sorgente

Un software proxy o di sicurezza sul server RDS può modificare la Source Port. Il firewall rileva quindi un port mismatch e tratta il traffico come non autenticato. Non confondere questa Source Port con SatcDestinationPort: il valore Registry definisce la porta di destinazione per i messaggi SATC, per impostazione predefinita 6060. Testare tale software in modo controllato o configurarlo correttamente per il percorso SATC; non disattivare genericamente le funzioni di protezione.

L’utente appare, ma la regola non matcha

Verificare:

• l’utente o il gruppo è importato sul firewall.
• la regola usa Match known users.
• il gruppo AD corretto è selezionato nella regola.
• la posizione della regola è corretta.
• non esiste una regola precedente che matcha lo stesso traffico senza riferimento utente.
• Log Viewer mostra lo stesso utente, la stessa Source IP e lo stesso servizio.

Account locali compaiono nei log

Controllare SatcExcludedUsers e aggiungere account tecnici. Candidati frequenti sono amministratori locali, servizi e account di sistema. La lista non dovrebbe però diventare così ampia da escludere per errore utenti reali.

Singole destinazioni non ricevono contesto utente

Controllare SatcExcludedAddresses. Se una destinazione o una porta è stata esclusa, SATC non invia per essa informazioni di autenticazione al firewall. Questo può essere intenzionale, ma nelle regole utente crea facilmente confusione.

Dopo la registrazione dell’IP server un vecchio Clientless User non funziona più

È previsto. Se l’IP del server RDS è stato registrato come Thin Client Server, SATC dovrebbe essere il modello di autenticazione per questo IP. Vecchi workaround con Clientless User dovrebbero essere rimossi o sostituiti in modo pianificato.

Nessun accesso a Internet dopo un aggiornamento a SFOS 22.0 GA

Se l’utente appare come Thin client, ma dopo l’aggiornamento non ha accesso a Internet, acquisire prima la versione firmware, il rule match, firewall_rule.log e access_server.log. Le note di rilascio ufficiali di SFOS 22.0 elencano NC-178903 sotto SFOS 22.0 MR2 Build 546 come problema corretto per gli aggiornamenti a SFOS 22.0 GA. Sophos non indica una firma di log univoca né un workaround separato. L’inquadramento della release è disponibile nella panoramica di SFOS 22.0 MR2.

Checklist

• Lo scenario RDS è davvero adatto a SATC e non a normale STAS.
• Sophos Server Protection è installato sul Remote Desktop Session Host.
• Versione Windows Server e ruolo RDS sono verificati.
• Tamper Protection è stata disattivata solo in modo controllato e poi riattivata.
• SendSatcEvents, SatcDestinationAddr e SatcDestinationPort sono impostati.
• Il server RDS è stato riavviato.
• L’IP del server RDS è stato registrato nella Device Console sul firewall.
• Server AD e gruppi AD sono verificati sul firewall.
• Clients è consentito per la zona corretta sotto Device Access e UDP 6060 è raggiungibile.
• La regola firewall usa Match known users e ha Logging attivo.
• L’utente compare sotto Current activities > Live users con Client type Thin client.
• Log Viewer mostra l’utente atteso e la regola attesa.

FAQ