Configurare Synchronized User ID Authentication su Sophos Firewall

Synchronized User ID Authentication collega l’accesso di un endpoint gestito a Sophos Firewall. Sophos Endpoint trasmette l’identità tramite Security Heartbeat. Nel processo AD per SFOS 22, il firewall convalida l’utente di dominio tramite Active Directory; la guida di SFOS 23 descrive inoltre Microsoft Entra ID con risoluzione dell’UPN e interrogazione dei gruppi. Gli utenti associati correttamente compaiono in Current activities > Live users.

Questo approccio è adatto alle postazioni gestite su cui Sophos Endpoint e Security Heartbeat sono già operativi. Non richiede un agente di autenticazione aggiuntivo sul client o sul server. Sophos Endpoint rimane tuttavia un requisito.

⚠️ La guida di SFOS 22 conferma il precedente processo AD per Windows 10 ed esclude altri servizi di directory. Questa affermazione non si applica indistintamente a SFOS 23: per questa versione è documentato un processo specifico per Entra ID. Gli utenti locali e i dispositivi con Server Protection rimangono esclusi. La pagina di SFOS 23 non indica una versione specifica del sistema operativo; non dedurre da questo, né da un pilota riuscito, il supporto per ulteriori sistemi operativi.

SFOS 23: identità Entra tramite Security Heartbeat

Questo percorso descrive l’accesso all’endpoint, non l’accesso SSO interattivo a VPN Portal o WebAdmin. L’integrazione Entra deve essere già configurata correttamente. La configurazione di base comune di Entra illustra app, autorizzazioni, server di autenticazione e importazione dei gruppi; l’accesso VPN in sé non è un prerequisito per questo pilota heartbeat. Per l’accesso amministrativo si applica separatamente Entra ID per WebAdmin.

Prerequisiti minimi e risoluzione dell’identità

Prima del pilota, verificare questi prerequisiti:

• Il firewall esegue la build SFOS 23 prevista, è collegato a Sophos Central o Sophos Fusion e dispone di un Security Heartbeat funzionante. Le indicazioni sulle licenze mantenute più avanti provengono espressamente dalla guida di SFOS 22; non dimostrano un obbligo di licenza nuovo o modificato per SFOS 23. Verificare separatamente i diritti di utilizzo per la versione effettivamente impiegata.
• Sophos Endpoint 2025.1 o successivo è installato sul pilota gestito. La guida di SFOS 23 richiede Endpoint su dispositivi aggiunti al dominio; non dedurre da questo il supporto aggiuntivo per modelli di join o sistemi operativi arbitrari.
• L’account utente utilizza lo stesso indirizzo e-mail in Sophos Central/Fusion, sul firewall e nella directory configurata. L’utente Entra che ha effettuato l’accesso deve poter essere associato senza ambiguità.
• Microsoft Entra ID è configurato correttamente sul firewall come server di autenticazione. In Authentication > Servers, verificare il server Entra e Test connection; controllare sincronizzazione dell’ora, raggiungibilità, autorizzazioni dell’app e importazione dei gruppi secondo la configurazione di base collegata.
• Endpoint trasmette tramite heartbeat l’UPN valido dell’utente Entra che ha effettuato l’accesso. A partire da Endpoint 2025.1 vengono trasmessi nome di accesso, nome di dominio e UPN; le versioni precedenti non inviano l’UPN. Senza UPN, il firewall non può associare l’heartbeat a un utente Entra. Un heartbeat verde da solo non è quindi sufficiente.

⚠️ Non sincronizzare contemporaneamente tramite AD ed Entra ID gli utenti di uno stesso dominio. I prerequisiti Entra escludono questa combinazione. Non interpretare un percorso AD esistente come una migrazione automatica: chiarire prima quale directory sia responsabile e il percorso di ripristino; interrompere il pilota se la doppia associazione non è stata chiarita.

Il processo Entra è composto da cinque passaggi:

1. L’utente accede con il proprio account Entra ID al dispositivo protetto da Sophos Endpoint.
2. Endpoint invia le informazioni sull’identità al firewall tramite Security Heartbeat.
3. Il firewall identifica l’utente Entra in base al suo UPN. A differenza del percorso AD, qui sAMAccountName non viene utilizzato come chiave di associazione Entra.
4. Il firewall recupera le appartenenze ai gruppi Entra e attiva l’utente con le policy utente e di gruppo appropriate e le corrispondenti policy Synchronized Security.
5. L’utente compare in Current activities > Live users. In questo processo il firewall non utilizza né condivide password.

Convalidare il pilota Entra e l’autorizzazione

Come esempio di documentazione vengono utilizzati anna.muster@example.com, l’IP client 10.20.30.101, il gruppo pilota Entra SFOS-Internet-Users e la regola LAN_User_Internet. Sostituire UPN, IP e gruppo con i valori del proprio pilota. Limitare deliberatamente il gruppo agli utenti di test necessari; il solo nome non dimostra appartenenza o autorizzazione.

1. Documentare lo stato precedente dell’associazione alla directory, degli oggetti utente e di gruppo, delle regole e dei nodi HA, oltre a un accesso amministrativo indipendente. Utilizzare un client di test e account di test approvati; non bloccare né eliminare account di produzione.
2. Importare il gruppo Entra necessario secondo la configurazione di base e selezionarlo in una regola con ambito ristretto e logging in Rules and policies > Firewall rules, con Match known users e Users or groups. Limitare origine, destinazione e servizi al pilota; la regola pilota descritta più avanti mostra i campi.
3. Disconnettere completamente l’utente dal pilota ed eseguire un nuovo accesso con l’account Entra. Verificare insieme heartbeat e Current activities > Live users: utente previsto, IP client e Client Type: Heartbeat devono corrispondere all’accesso di test. Documentare l’identità effettivamente visualizzata, senza presumere un nome visualizzato specifico.
4. Generare un nuovo flusso di test consentito e confrontare in Log viewer utente, origine, destinazione, servizio, azione, ora e Firewall Rule ID. Solo il flusso corretto dimostra l’effetto della regola; una voce in Live users da sola non dimostra l’autorizzazione tramite gruppo.
5. Verificare lo stesso percorso di destinazione con un utente di test separato esterno al gruppo pilota. Questo utente non deve essere autorizzato tramite la regola del gruppo pilota. Un’altra regola consentita può comunque applicarsi: documentarne la Rule ID invece di aspettarsi un blocco totale indiscriminato.
6. Convalidare come casi di test negativi un UPN mancante o non valido, un account di test Entra inesistente o inattivo e la mancata raggiungibilità di Entra dal firewall. Provocare anomalie solo in un ambiente di test isolato e approvato, non tramite blocchi estesi all’intero tenant o blocchi di rete globali. In assenza di tale ambiente, documentare i casi di test come aperti, non come testati con successo. Se manca l’UPN, non aspettarsi un’associazione Entra; per errori dell’account e di raggiungibilità, non garantire un messaggio di errore specifico o la disconnessione immediata delle sessioni esistenti.
7. Verificare in modo controllato la perdita dell’heartbeat e la sospensione o riattivazione. Quando l’heartbeat manca, l’utente sincronizzato viene disconnesso; altri metodi di autenticazione possono continuare ad applicarsi e il traffico può interrompersi fino al nuovo accesso. La sequenza di verifica dell’heartbeat descritta di seguito si applica anche a questo percorso.

L’utente Entra manca o ha il gruppo errato

Se l’heartbeat è verde ma manca l’identità corretta, verificare prima la versione di Endpoint e l’UPN effettivamente segnalato. Controllare quindi che l’account Entra esista e sia attivo, che i servizi del firewall possano raggiungere Entra e che la configurazione Entra sia stata completata correttamente. In Authentication > Servers, eseguire nuovamente Test connection. Un test di connessione riuscito da solo non dimostra né l’UPN dell’endpoint né l’autorizzazione tramite gruppo.

Se l’identità è visibile ma il gruppo o la regola sono errati, confrontare appartenenza Entra, gruppo importato nel firewall, associazione utente e ordine delle regole. Conservare il flusso interessato con Rule ID e ora. Non ampliare le regole, eliminare oggetti utente o riavviare servizi in via precauzionale. Per un’escalation, conservare build SFOS, versione di Endpoint, UPN anonimizzato, stato dell’heartbeat, IP client, intervallo di tempo e nodo HA che elabora il traffico, insieme ai log indicati più avanti.

HA e percorso di ripristino per il pilota Entra

Anche la guida di SFOS 23 descrive Synchronized User ID come attivo per impostazione predefinita e richiede l’attivazione o la disattivazione su entrambi i dispositivi HA. La modifica dello stato non viene salvata nel backup. I comandi shell mantenuti più avanti sono documentati anche in SFOS 23; modificano lo stato dell’intera funzione, non solo di Entra. Un simile riavvio del servizio non è quindi un rollback innocuo del pilota.

Testare il failover solo in una finestra di manutenzione approvata, con accesso amministrativo indipendente. Sul nodo che elabora il traffico dopo il failover, convalidare nuovamente heartbeat, nuovo accesso Entra, Live users, regola di gruppo e nuovo flusso di test. Non presumere un trasferimento senza interruzioni dello stato utente o delle sessioni; le correzioni di SFOS 22 indicate più avanti non costituiscono una nuova garanzia di failover per SFOS 23.

Per il percorso di ripristino, riportare prima la regola pilota e le associazioni pilota allo stato precedente documentato e verificare il percorso di autenticazione utilizzato in precedenza con un nuovo accesso e traffico reale. Non eliminare né disattivare globalmente, come pulizia del test, app Entra, server, autorizzazioni e gruppi condivisi con VPN, portale o WebAdmin. Se durante la finestra di manutenzione è stato modificato anche lo stato globale di Synchronized User ID, ripristinare esplicitamente lo stato desiderato su entrambi i nodi e verificarlo separatamente dopo un ripristino. Riattivare un percorso di ripristino AD solo dopo aver terminato in modo controllato la sincronizzazione Entra dello stesso dominio.

I passaggi e gli esempi AD seguenti vengono mantenuti come percorso separato e precedente per SFOS 22. La risoluzione dell’identità AD è descritta anche nella guida di SFOS 23, ma in quella versione non sostituisce la verifica Entra.

SFOS 22 con AD: Synchronized User ID in otto passaggi

1. Scegliere come pilota un client di dominio Windows 10 con Sophos Endpoint.
2. Verificare Sophos Fusion (in precedenza Sophos Central), Security Heartbeat e la licenza del firewall.
3. Collegare Active Directory come server di autenticazione del firewall.
4. Confrontare il dominio UPN, sAMAccountName, l’indirizzo e-mail e il profilo utente tra AD, Sophos Fusion e firewall.
5. Preparare una regola utente con ambito ristretto e logging per un gruppo pilota.
6. Eseguire un nuovo accesso a Windows sul pilota e confermare un heartbeat verde.
7. Verificare utente, indirizzo IP e Client Type in Current activities > Live users, oltre al traffico reale in Log Viewer.
8. Testare la perdita dell’heartbeat, il comportamento HA e un percorso di ripristino controllato prima di aggiungere altri endpoint.

Quando è adatto Synchronized User ID

Synchronized User ID non sostituisce in generale tutti i metodi di autenticazione Sophos. Il percorso AD per SFOS 22 mantenuto qui è adatto quando un endpoint Windows 10 gestito appartiene normalmente a un solo utente AD e Sophos Endpoint invia già un Security Heartbeat. Per gli utenti Entra su SFOS 23 si applicano i prerequisiti e la convalida del percorso specifico descritto sopra.

Altri modelli operativi richiedono altri metodi:

• STAS su Sophos Firewall associa a un IP client gli accessi Windows provenienti da domain controller, STA Agent e Collector.
• SATC per Remote Desktop Services distingue più sessioni dietro lo stesso IP RDS o Citrix.
• Per-Connection AD SSO distingue le connessioni HTTP e HTTPS di più utenti tramite Direct Web Proxy.
• Captive Portal o Client Authentication Agent sono adatti quando è necessario un accesso interattivo.

Non forzare uno scenario server o terminal server con Synchronized User ID. Sophos indica esplicitamente Server Protection come non supportato. Se più utenti condividono lo stesso IP o le connessioni non web devono essere associate per sessione, SATC è più appropriato.

Se Synchronized User ID e STAS sono configurati contemporaneamente, Sophos indica che il server di autenticazione usa il meccanismo la cui richiesta di accesso arriva per prima. Non trattare questa coesistenza come una priorità fissa. Delimitare chiaramente il pilota e controllare Client Type a ogni convalida.

Come funziona l’associazione AD

Il processo è composto da quattro livelli separati:

1. L’utente accede al client di dominio Windows.
2. Sophos Endpoint trasmette l’utente di dominio al firewall tramite Security Heartbeat.
3. Il firewall ricava il dominio dall’UPN e il nome utente da sAMAccountName.
4. Il firewall convalida l’utente tramite il server Active Directory corrispondente e lo attiva per le regole basate sugli utenti.

La funzione non autentica gli utenti Windows locali e non sostituisce una connessione AD. Se il dominio UPN, il server di directory o il profilo utente non corrispondono, un endpoint verde può comunque rimanere senza un’identità utente utilizzabile.

Sophos Firewall non condivide né utilizza informazioni sulle password in questo processo. L’heartbeat trasporta i dati di dominio e utente necessari per l’associazione, mentre la convalida avviene sul server AD configurato.

Esempio AD e valori sostituibili

Il processo utilizza questi valori di documentazione:

• Firewall: fw01.example.com
• Dominio AD e suffisso UPN: example.com
• Client Windows: WS-101
• IP client: 10.20.30.101
• Nome utente: anna.muster
• UPN: anna.muster@example.com
• sAMAccountName: anna.muster
• Gruppo AD: SFOS-Internet-Users
• Regola pilota: LAN_User_Internet

example.com, WS-101, 10.20.30.101, l’utente e il gruppo sono esempi e devono essere sostituiti con i valori reali. Il nome dell’oggetto non è l’elemento decisivo. Sophos Fusion, Windows, Active Directory e il firewall devono associare senza ambiguità lo stesso utente.

Preparare i prerequisiti

Verificare Sophos Fusion e Security Heartbeat

Il firewall deve essere collegato a Sophos Fusion e disporre di una sottoscrizione Network Protection valida. Il pilota richiede Sophos Central Endpoint Protection con licenza di prova o completa. Questi requisiti di licenza provengono dalla guida SFOS 22 a Security Heartbeat; la registrazione e la baseline dell’heartbeat sono descritte in Collegare Sophos Firewall a Sophos Fusion.

In System > Sophos Fusion, la registrazione e Security Heartbeat devono essere attivi. Il pilota deve comparire con uno stato plausibile in Control Center e Sophos Fusion. Stabilire prima questa baseline, quindi verificare l’associazione dell’identità.

Secondo la guida di SFOS 22 su Security Heartbeat, endpoint e firewall scambiano i dati heartbeat tramite una connessione TLS cifrata verso 52.5.76.173 sulla porta TCP 8347. Uno stato verde indica che la protezione Sophos funziona correttamente e che non sono stati rilevati malware attivi o inattivi né PUA. Non dimostra ancora che AD abbia convalidato l’utente. In caso di problemi di connessione, verificare separatamente trasporto, tenant Fusion e certificato dell’endpoint, quindi l’associazione utente.

Synchronized User ID è attivo per impostazione predefinita. Non esiste quindi un normale interruttore WebAdmin da attivare prima per il pilota. I comandi shell descritti più avanti servono solo a disattivare o riattivare la funzione in modo controllato.

Confrontare Active Directory e gli attributi utente (percorso AD)

In Authentication > Servers deve essere presente e raggiungibile un server Active Directory appropriato. Collegare Active Directory a Sophos Firewall descrive LDAPS, base di ricerca, importazione dei gruppi e ordine dei server.

Passare quindi a Authentication > Services > Firewall authentication methods e spostare il server AD in Selected authentication server. La guida di SFOS 22 su Authentication Services conferma che deve essere selezionato almeno un server; se ne sono selezionati diversi, il firewall li elabora nell’ordine visualizzato. La sola aggiunta del server in Servers non è sufficiente per l’autenticazione del firewall.

Per il pilota devono corrispondere almeno questi valori:

• Il dominio nell’UPN corrisponde al dominio del server AD utilizzato dal firewall.
• sAMAccountName è univoco in Active Directory e può essere trovato dal firewall.
• Il profilo utente e l’indirizzo e-mail corrispondono tra AD, Sophos Fusion e il record utente locale del firewall.
• Il gruppo AD necessario è importato e associato al profilo utente corretto del firewall.

Un suffisso UPN diverso, valori sAMAccountName duplicati in ambiti di ricerca inappropriati o un server AD non corrispondente sono segnali di arresto. Non compensare con una regola utente più ampia.

Preparare la regola pilota

In Rules and policies > Firewall rules, fare clic su Add firewall rule > New firewall rule e creare una regola con ambito ristretto per il gruppo pilota, oppure utilizzare in modo controllato una regola utente esistente. Nella sezione dell’identità utente, attivare Match known users prima di selezionare Users or groups:

• Source zones: zona client effettiva
• Source networks and devices: rete pilota o intervallo sorgente più ristretto
• Users or groups: SFOS-Internet-Users
• Destination zones: solo il percorso di destinazione necessario
• Services: solo i servizi necessari per il test
• Log firewall traffic: attivo

L’ordine delle regole, il logging e il test negativo sono più importanti di una regola di autorizzazione ampia. Creare correttamente le regole di Sophos Firewall descrive la configurazione.

Accedere e convalidare il pilota AD

1. Disconnettere completamente l’utente esistente dal client pilota.
2. Eseguire un nuovo accesso a Windows come anna.muster@example.com.
3. Verificare un heartbeat verde in Sophos Fusion e sul firewall.
4. Cercare anna.muster e 10.20.30.101 in Current activities > Live users.
5. Confermare che siano visualizzati utente, indirizzo IP e Client Type: Heartbeat.
6. Generare un test di traffico consentito tramite LAN_User_Internet.
7. Aprire Log viewer in alto a destra, selezionare il modulo firewall e confrontare nome utente, origine, destinazione, servizio, Firewall Rule ID, azione e ora.
8. Eseguire un test negativo con un utente esterno al gruppo pilota.

Una voce in Live users dimostra solo l’associazione dell’identità. Solo il flusso di test registrato dimostra che viene applicata anche la regola utente corretta. Se il log del traffico mostra solo l’indirizzo IP o il flusso raggiunge un’altra Rule ID, non ampliare la regola. Verificare l’associazione e l’ordine.

Testare deliberatamente la perdita dell’heartbeat

Se Security Heartbeat manca o viene perso durante una sospensione o una riattivazione, il firewall disconnette l’utente rilevato tramite Synchronized User ID. Altri metodi di autenticazione configurati possono continuare ad applicarsi, ma il traffico basato sugli utenti può interrompersi fino all’accesso successivo.

Per un test controllato:

1. Documentare prima l’utente attivo, l’IP, lo stato dell’heartbeat e la regola.
2. Sospendere il pilota e riattivarlo.
3. Verificare nuovamente lo stato dell’heartbeat e Live users.
4. Generare un nuovo test di traffico e confermare l’utente e la Rule ID effettivamente utilizzati.
5. In caso di differenze, verificare endpoint, percorso e log invece di disattivare globalmente Synchronized User ID in via precauzionale.

Un Missing Heartbeat non indica automaticamente malware. Analizzare sistematicamente gli avvisi Missing Heartbeat descrive l’intero percorso diagnostico.

Interpretare le Release Notes di SFOS 22 e i limiti noti

La convalida deve considerare il Maintenance Release installato, non soltanto “SFOS 22”. Questo articolo aggiornato su Synchronized User ID documenta direttamente le due affermazioni NC concrete. La verifica prima dell’upgrade a SFOS 22 gestisce qui soltanto la verifica di versione e build, il percorso di upgrade approvato e la preparazione della modifica. Le correzioni del prodotto sono: MR1 Build 490 corregge il ritardo nell’accesso a Internet dopo un failover HA attivato manualmente con autenticazione heartbeat (NC-165361); MR2 Build 546 corregge le segnalazioni Missing Heartbeat errate quando due endpoint condividono la stessa docking station o interfaccia USB (NC-176012). Se uno di questi sintomi compare su una build 22.0 precedente, registrare prima la build esatta e valutare un percorso di aggiornamento approvato.

Il runbook per diagnosticare gli avvisi Missing Heartbeat tratta inoltre NC-147863: con lo split tunneling SSL VPN verso un firewall esterno, un nuovo adattatore VPN può interrompere la connessione heartbeat. L’utente perde quindi l’autenticazione heartbeat e può entrare in un ciclo di connessione e disconnessione. Se il pilota include questo scenario, testarlo in modo specifico. Come soluzione alternativa, Sophos indica di disattivare Match known users nella regola VPN del firewall locale oppure di utilizzare Captive Portal per l’autenticazione. Limitare inizialmente la modifica alla regola VPN interessata e documentarne l’effetto e il ripristino.

Circoscrivere sistematicamente gli errori

L’endpoint non compare con un heartbeat verde

Verificare prima registrazione Fusion, licenza endpoint, licenza Network Protection, associazione del firewall, DNS, ora e percorso di rete. Senza un Security Heartbeat funzionante, Synchronized User ID non può trasmettere un’identità.

L’utente non compare in Live users

Per il percorso AD, verificare insieme accesso Windows, UPN, sAMAccountName, server AD, ambito di ricerca e profilo utente. Un heartbeat verde conferma la connessione dell’endpoint, non automaticamente una convalida AD riuscita. Per gli utenti Entra su SFOS 23, utilizzare invece le verifiche di UPN, account e raggiungibilità del percorso Entra.

Utente o gruppo errato

Per AD, confrontare dominio UPN, ambito di ricerca AD, gruppo importato, Main Group e oggetti utente locali. Per Entra su SFOS 23 si applicano inoltre l’appartenenza Entra e l’associazione UPN del percorso specifico. Non eliminare oggetti utente prima di aver verificato le dipendenze da VPN, portale, regole, quote e reporting.

L’utente è visibile, ma la regola non viene applicata

Verificare zona e rete sorgente, utente o gruppo, servizio, destinazione e ordine delle regole. In Log Viewer il flusso reale deve mostrare la Firewall Rule ID prevista. Un’identità visibile da sola non conferma l’autorizzazione.

Server o versione Windows non confermata

Server Protection non è supportato per entrambi i percorsi. La guida di SFOS 22 cita esplicitamente Windows 10 per AD; la pagina di SFOS 23 non specifica una versione del sistema operativo. Non dedurre il supporto in produzione per altri sistemi operativi, modelli di join o tipi di endpoint sconosciuti dalla disponibilità della documentazione o dal comportamento di un singolo pilota.

Leggere i log rilevanti

Questi controlli in sola lettura sono utili in Advanced Shell:

cd /log
tail -n 200 heartbeatd.log
tail -n 200 access_server.log
tail -n 200 hbtrust.log

heartbeatd.log mostra gli eventi dell’heartbeat, access_server.log aiuta con autenticazione e autorizzazione e hbtrust.log con la relazione di attendibilità con Sophos Fusion. Un solo log non costituisce una prova completa. Conservare insieme intervallo di tempo, utente, endpoint, IP, Rule ID e nodo HA interessato. File di log e servizi di Sophos Firewall descrive altri percorsi.

Se non è ancora chiaro se l’errore riguarda directory, metodo, record utente locale o regola, Risolvere sistematicamente gli errori di autenticazione fornisce una sequenza diagnostica trasversale ai metodi.

Disattivare la funzione in modo controllato

⚠️ I comandi seguenti modificano lo stato dell’autenticazione e riavviano access_server. Documentare prima utenti attivi, regole interessate, metodo di accesso alternativo e percorso di ripristino. In HA, entrambi i nodi devono essere gestiti deliberatamente.

Le istruzioni ufficiali di SFOS 22 e SFOS 23 indicano questi comandi per una disattivazione persistente:

touch /content/no_userid
service access_server:restart -ds nosync

Questa variante disattiva la funzione solo fino al successivo riavvio del firewall:

touch /tmp/no_userid
service access_server:restart -ds nosync

Per riattivare la funzione, rimuovere il file persistente e riavviare il servizio:

rm /content/no_userid
service access_server:restart -ds nosync

Dopo ogni modifica, verificare un nuovo accesso a Windows, Live users, il traffico reale e i log. Lo stato disattivato non viene archiviato nei backup di configurazione. Dopo un ripristino, controllare nuovamente lo stato desiderato e impostarlo su entrambi i nodi HA, se necessario.

HA, backup e gestione

In un cluster HA, Synchronized User ID viene attivato o disattivato su entrambi i dispositivi. Ogni nodo archivia solo i log del traffico e degli eventi che elabora. Per un incidente, verificare quindi il nodo che era attivo o elaborava il traffico in quel momento.

Un test HA controllato richiede un nuovo accesso a Windows e un nuovo flusso di traffico. Non presumere che lo stato utente o le sessioni attive proseguano senza interruzioni. Dopo il failover, convalidare nuovamente almeno heartbeat, Live users, regola utente e log.

Lo stato di /content/no_userid non è incluso in un backup. Questa eccezione deve essere documentata esplicitamente nelle procedure operative, nei test di ripristino e nel processo RMA.

Rollback

1. Documentare lo stato attuale di heartbeat, utente, regola e HA.
2. Disattivare la regola pilota o ripristinare lo stato precedente documentato.
3. Solo se lo stato globale della funzione è stato modificato durante il test, ripristinare in modo controllato lo stato precedente documentato. Per una riattivazione intenzionale dopo una disattivazione persistente, rimuovere /content/no_userid e riavviare access_server; non attivare indiscriminatamente una funzione che era disattivata in precedenza. Secondo Sophos, la variante temporanea termina al successivo riavvio del firewall. Non eseguire un riavvio esclusivamente per la pulizia del test al di fuori di una finestra di manutenzione approvata.
4. Stabilire lo stesso stato previsto su entrambi i nodi HA.
5. Eseguire un nuovo accesso a Windows sul pilota e verificare heartbeat e Live users.
6. Testare nuovamente la regola utente e il percorso di autenticazione alternativo con traffico reale.
7. Solo allora rimuovere gli oggetti di test temporanei o le assegnazioni pilota.

Checklist per il percorso AD di SFOS 22

• Il pilota è un client di dominio Windows 10 supportato con Sophos Endpoint.
• Firewall, endpoint e Security Heartbeat sono visibili in Sophos Fusion.
• Le licenze Network Protection ed endpoint sono valide.
• Server AD, dominio UPN, sAMAccountName, indirizzo e-mail e profilo utente corrispondono.
• Il gruppo pilota è importato e la regola utente ha un ambito ristretto e il logging attivo.
• Live users mostra l’utente previsto e l’IP client corretto.
• Il traffico reale raggiunge la Firewall Rule ID prevista.
• La perdita dell’heartbeat e la sospensione o riattivazione sono state testate in modo controllato.
• Nodi HA, log, limite di ripristino e percorso di ritorno sono documentati.
• Synchronized User ID non è stato esteso impropriamente come sostituto di SATC, STAS o altri servizi di directory.

Domande frequenti