Sophos XG Firewall configurazione STAS per implementare la Clientless SSO con DC multipli

Tramite Sophos Transparent Authentication Suite (STAS) è possibile implementare la funzionalità Sophos Clientless Single Sign-On (SSO) authentication che permette il logon automatico degli utenti Sophos Firewall (SFOS) se è stato eseguito il login in Windows senza la necessità di eseguire login multipli e senza che sia necessario installare SSO clients su ogni workstation.

Lo Sophos Transparent Authentication Suite (STAS) è composta da due componenti:

  • Lo STA Agent che monitore le richieste di autenticazione e invia le informazioni allo STA Collector for authentication.
  • Lo STA Collector che raccoglie le richieste di autenticazione degli utenti da uno o più STA Agent, processa le richieste e le invia all’Sophos Firewall (SF).

Nel seguente articolo Sophos XG Firewall: How to Implement Clientless SSO with multiple Active Directory Domain Controllers vengono forniti maggiori dettagli sul come funziona il processo di raccolta delle informazioni delle autenticazioni utente:

“How does STAS work?

It is a User Authentication Information Collection Process:

  • The User logs in to the Active Directory Domain Controller from any workstation in the LAN. The Domain Controller authenticates the user’s credentials.
  • The STA Agent captures and communicates this authentication process to the STA Collector over the default TCP port (5566) at the same time.
  • The STA Collector registers the user in the Local database and communicates the user’s information to SF over the default UDP port (6677).
  • SFOS queries Active Directory in order to determine the user’s group membership and registers the user in the SF database.

Based on data from the STA Agent, SF queries the AD server to determine group membership; depending on the data, access is granted or denied. Users logged into a workstation directly (or locally) but not logged in to the domain will not be authenticated and are considered as Unauthenticated users. For users that are not logged into the domain, the Captive Portal prompt for a manual login will be displayed for further authentication.”

Ulteriori approfondimenti sul funzionamento di STAS sono forniti nell’articolo Sophos XG Firewall: Clientless Single Sign-On in a Single Active Directory Domain Controller environment in cui vengono analizzati nel dettaglio i passi del processo di raccolta delle informazioni delle autenticazioni utente:

  1. The user logs in to the Active Directory (AD) Domain Controller from any workstation in the LAN. The Domain Controller authenticates the user’s credentials
  2. AD gets the user logon session information and creates a security audit log. Upon successful user authentication, AD creates an event with an ID of 672 (Windows 2003) or 4768 (Windows 2008 and above).
  3. The Agent, while monitoring the AD server, gets the user logon session information from the above event IDs.
  4. The Agent queries the DNS server to resolve the workstation name to IP address using DNS or NetBIOS.
  5. The Agent collects the user’s group information from the AD server.
  6. The Agent passes on the username, IP address and group information to the Collector over the default TCP port (5566) at the same time.
  7. The XG Firewall sends a user map request on UDP port 6677 to the Collector and syncs its user map with the Collector. The Collector responds by sending successful authentication updates to the XG Firewall on UDP port 6060.
  8. A user initiates an internet request.
  9. The XG Firewall matches the user information with its local user map and applies security policies accordingly.

Di seguito la lista delle porte TCP e UDP utilizzate nell’ambito della Sophos Clientless Single Sign-On (SSO) authentication e le relative comunicazioni necessarie ricavate sulla base delle precedenti informazioni:

  • Lo STA Collector comunica con l’XG Firewall che deve quindi accettare connessioni in ingresso sulla porta UDP 6060 provenienti dai computer su cui è installato lo STA Collector
  • L’XG Firewall comunica lo STA Collector che deve accettare connessioni in ingresso sulla porta UDP 6677 provenienti dall’XG Firewall
  • Lo STA Agent comunica lo STA Collector che deve accettare connessioni in ingresso sulla porta TCP 5566 provenienti dai computer su cui è installato lo STA Agent
  • Lo STA Collector comunica con le workstation via WMI se si intende gestire la user log off detection, quindi le workstation devono accettare le connessioni in ingresso sulle porte TCP 135 e TCP 445 dai computer su cui è installato lo STA Collector nel caso venga usato il Workstation Polling Method WMI o il Registry Read Access per determinare il logoff, nel caso venga utilizzato il Logoff Detection Ping le workstation devono accettare le connessioni in ingresso ICMP dai computer su cui è installato lo STA Collector. Aa riguardo si vedano gli articoli:
  • Nel caso si desideri eseguire la sincronizzazione delle configurazioni tra due STAS il computer che deve ricevere le configurazioni deve accettare le connessioni in ingresso sulle porte TCP 27015 e UDP 50001 dal computer che invia le configurazioni, le porte di comunicazione sono state ricavare sulla base dell’analisi del traffico in quanto al momento non vi è documentazione in merito. Per i dettagli sul funzionamento della sincronizzazione si veda l’articolo Sophos Firewall: How to synchronize configurations between two STAS installations.

Nel caso si desideri implementare la Sophos Clientless Single Sign-On (SSO) authentication in un ambiente Active Directory in cui sono presenti più controller di dominio occorrerà prestare alcune attenzioni per non avere malfunzionamenti facendo riferimento a quanto riportato nell’articolo Sophos XG Firewall: How to Implement Clientless SSO with multiple Active Directory Domain Controllers in cui viene illustrato il deploy dello Sophos Transparent Authentication Suite (STAS) nel seguente scenario di esempio dove sono presenti due Domain Controller:

In uno scenario dove sono presenti più Domain Controller è importante che le richieste di autenticazione utente vengano raccolte da tutti i Domain Controller mediate lo STA Agent inoltre occorre far sì che quando l’XG Firewall contatta lo STA Collector questo disponga di tutte le autenticazioni utente attive. Quindi in uno scenario come questo, dove dono presenti due Domain Controller, sono possibili due tipi di approcci:

Approccio 1: Centralizzazione delle richieste di autenticazione su un unico STA Collector

  • Installare sul DC01 sia lo STA Agent che lo STA Collector
  • Installare sul DC02 lo STA Agent
  • Configurare lo STA Agent su DC02 per inviare i dati allo STA Collector sul DC01
  • Configurare l’XG Firewall per contattare lo STA Collector sul DC01

In questo modo tutte le richieste di autenticazione ricevute dai due Domain Controller vengono inviate allo STA Collector su DC01 che quindi dispone di tutte le autenticazioni utente attive, ma essendo l’unico STA Collector può rappresentare un single point of failure (SPOF) per il funzionamento della Sophos Clientless Single Sign-On (SSO) authentication.

Approccio 2: Centralizzazione delle richieste di autenticazione su due STA Collector, un primario e uno di backup

  • Installare sul DC01 sia lo STA Agent che lo STA Collector
  • Installare sul DC02 lo STA Agent che lo STA Collector
  • Configurare lo STA Agent su DC01 per inviare i dati allo STA Collector sul DC02
  • Configurare lo STA Agent su DC02 per inviare i dati allo STA Collector sul DC01
  • Configurare l’XG Firewall per contattare prima lo STA Collector sul DC01 e nel caso di mancata risposta lo STA Collector sul DC02 configurando un collector group

A riguardo si veda la risposta di Leon Friend (Sales Engineer at Sophos) nella discussione SSO AD User logout continuously

“When you have a multiple DC you have a Agent on both servers and the collector on one. Both agents populate the identity table on the single collector and the appliance only talks to one collector at a time. This means you can have a second collector deployed, however it is a backup collector and is only used when the primary collector is unavailable (both the agents and the appliance will switch to it)”

Per consentire la gestione degli eventi di logon da parte dello STA Agent occorre configurare una Group Policy da applicare ai Domain Controller (evitare di modificare la Default Domain Controller Policy quando possibile) configurando abilitando Success e Failure sulla policy Security Settings \ Local Policies \ Audit Policy \ Audit account logon events. Per dettagli su tale impostazione si veda il post Deciphering Account Logon Events:

Audit Account Logon generates events for credential validation. These events occur on the machine which is authoritative for the credentials. For domain accounts, the domain controller is authoritative. For local accounts, the local machine is authoritative. Since domain accounts are used much more frequently in enterprise environments than local accounts, most of the Account Logon events in a domain environment occur on the domain controllers which are authoriative for the domain accounts. However, these events can occur on any machine, and may occur in conjunction with or on separate machines from logon/logoff events.”

Per l’esecuzione dello STA Agent occorre predisporre un account utente che abbia i seguenti privilegi:

  • Privilegi amministrativi sul Domain Controller in quanto deve avere accesso agli eventi di sicurezza (anche se sarebbe possibile modificare questa impostazione di default, a riguardo si veda il post Giving Non Administrators permission to read Event Logs Windows 2003 and Windows 2008)
  • Privilegi amministrativi sulle workstation nel caso venga usato il Workstation Polling Method WMI o il Registry Read Access per determinare il logoff
  • Privilegio Log on as a service, che viene concesso automaticamente quando le credenziali dell’account vengono impostate per eseguire il servizio

Quindi la configurazione più semplice è quella di creare un account con password complessa (ad esempio lunga 14 caratteri) membro del gruppo Domain Admins con cui eseguire lo STA Agent.

Sull’XG Firewall occorre eseguire le seguenti configurazioni:

  • Configurare il firewall per poter eseguire query su Active Directory mediante l’utilizzo di un account che abbia i soli privilegi di Domain User e su cui è stata impostata una password complessa (ad esempio lunga 14 caratteri). Per i dettagli sulla configurazione si veda l’articolo Sophos Firewall: How to integrate Sophos Firewall with Active Directory.
  • Abilitare la CTA Authentication.
  • Creare un Collector Group in cui impostare l’elenco dei STA Collector che è possibile interrogare e l’ordine con cui vengono interrogati in caso di mancata risposta.

La gestione dell’individuazione del Logoff viene gestita tramite Workstation Polling Method WMI o il Registry Read Access o Logoff Detection Ping e non basandosi sull’evento di Logoff in quanto questo non può fornire un’informazione precisa dell’avvenuto Logoff in tutte le situazioni a riguardo si veda i seguenti:

KB828857 The User Logoff Event ID 538 Is Not Logged to the Security Event Log When You Shut Down Your Computer and Then Restart It per Windows Server 2003 or Windows XP

“If you configure an audit policy to audit successful logon and logoff events, you may find that the user logoff audit event ID 538 is not logged to the security event log after you shut down your computer and then restart it.”

“This behavior occurs because during the shutdown process, the service that writes to the security event log is already stopped when the last token for the user who logs off is released. As a result, the user logoff audit event ID 538 is not logged to the security event log when you shut down your computer and then restart it. This behavior is by design.”

Audit Logoff per Windows 7, Windows Server 2008 R2

“Logoff events are not 100 percent reliable. For example, the computer can be turned off without a proper logoff and shutdown taking place; in this case, a logoff event will not be generated.”

Per ulteriori informazioni si faccia riferimento agli articoli pubblicati sulla Knowledge Base di Sophos ed in particolare per la gestione di particolari scenari come accessi tramite Remote Desktop Services Server o VPN si vedano: