Sincronizzare Active Directory con Sophos Central

Sophos Central può importare utenti e gruppi da un Active Directory locale. Queste identità servono, tra l’altro, per assegnare Policy e dispositivi. Una sincronizzazione incontrollata può tuttavia creare account superflui, oggetti duplicati o eliminazioni inattese.

Microsoft Entra ID viene sincronizzato mediante un connettore separato. La procedura è descritta in Sincronizzare Microsoft Entra ID con Sophos Central.

Definire il modello delle fonti prima dell’installazione

Central può gestire fino a 25 fonti directory per tenant; per quantità maggiori è prevista una struttura Central Enterprise. Utenti e indirizzi e-mail devono restare univoci nel tenant e lo stesso dominio non deve fornire utenti contemporaneamente tramite più fonti AD, Entra ID o Google Directory.

In un Trial, Sophos limita inoltre il numero di Directory Object che possono essere creati o utilizzati, inclusi utenti, dispositivi e gruppi. Un’importazione incompleta non è quindi automaticamente un errore di filtro: nel pilota vanno verificati insieme limiti Trial, numero atteso di oggetti e licenza.

All’interno di un Forest si possono selezionare più Child Domain e un tenant può sincronizzare più Forest. Sophos raccomanda tuttavia di collegare ogni Forest a un solo tenant Central. Se lo stesso Forest alimenta più tenant, oppure più Forest contengono gli stessi utenti o indirizzi, le esecuzioni possono aggiornare alternativamente la stessa identità apparente senza unire i record, rendendo incoerenti nomi, attributi e gruppi.

È invece supportato un modello ibrido chiaramente separato: AD fornisce computer e gruppi di computer, mentre Entra ID fornisce utenti e gruppi utenti dello stesso dominio. Le Shared Mailbox in un gruppo Microsoft 365 richiedono Entra ID o Google Directory; una normale Shared Mailbox esterna a un gruppo Microsoft 365 può provenire da AD Sync.

Le Shared Mailbox e le Public Folder dello stesso dominio degli utenti richiedono AD Sync Utility insieme a Sync users and user groups. Le mailbox dei gruppi Microsoft 365 non vengono importate tramite AD Sync. Non viene sincronizzata neppure una Shared Mailbox priva di Delegate. Se una mailbox utente inattiva con delega della posta a una mailbox attiva continua a esistere, AD Sync non la elimina, ma può mantenerla in Central come Shared Mailbox.

Per lo stesso dominio o sottodominio deve funzionare un solo client AD Sync produttivo. Inoltre, più dispositivi AD non devono avere lo stesso hostname DNS, poiché altrimenti Central non può abbinarli in modo univoco. Durante la sostituzione del server, il vecchio schedule viene quindi arrestato prima che la nuova istanza inizi la sincronizzazione produttiva.

Se si intende utilizzare il Self Service Portal per Sophos Email, Device Encryption o Mobile, l’accesso utente viene attivato prima del primo Directory Sync. In questo modo, gli utenti nuovi ed esistenti ricevono l’invito previsto. La procedura è descritta in Configurare l’accesso al Sophos Central Self Service Portal.

Limiti di AD Sync e gruppi tra domini

AD Sync non riunisce i dati di più Forest o Directory Service in un record master. Lo stesso utente o indirizzo e-mail non deve quindi comparire in più di un Forest sincronizzato. Utenti, indirizzi e-mail o gruppi duplicati possono essere aggiornati alternativamente a ogni esecuzione con i dati della rispettiva fonte e perfino cambiare il Directory Owner visibile in Central. Utenti e indirizzi e-mail restano univoci per tenant; gli utenti dello stesso dominio non devono essere sincronizzati contemporaneamente da AD ed Entra ID né forniti in parallelo a più Central Admin Account.

Per un gruppo con membri di più domini, Central importa soltanto gli utenti del dominio al quale appartiene il gruppo. Preview and Sync può mostrare tutti i membri, ma durante il Sync produttivo gli utenti dell’altro dominio non vengono aggiunti al gruppo. Questo comportamento viene verificato per Universal Groups e Child Domains mediante un membro di test per ogni dominio.

Utenti e gruppi di utenti vengono sincronizzati o disattivati congiuntamente. Lo stesso vale per dispositivi e gruppi di dispositivi. Sono previsti al massimo 1'000 filtri per Directory Object; i filtri LDAP aggiuntivi possono contenere al massimo 5'000 caratteri. Non sono supportati componenti di dominio più lunghi di 63 caratteri o che iniziano o terminano con - o _.

Le mailbox dei gruppi Microsoft 365 richiedono Entra ID. AD Sync non supporta Shared Mailbox prive di Delegate, più client AD Sync produttivi dello stesso dominio o sottodominio né più dispositivi AD con hostname DNS identico. Una mailbox inattiva delegata a una mailbox attiva può invece essere mantenuta come Shared Mailbox. Questi limiti vengono trattati come decisioni di progettazione prima della prima esecuzione, non aggirati successivamente ampliando i filtri.

Ripulire gli oggetti AD inattivi prima del Sync

Account utente e dispositivi inattivi vanno controllati, disabilitati o rimossi direttamente in Active Directory. Oltre a essere un rischio nella fonte, aumentano il volume Central e la dimensione del file di sincronizzazione. La pulizia riduce inoltre il file di Sync trasmesso a Sophos Central e può accelerare l’esecuzione.

I filtri LDAP possono escludere utenti inattivi e ridurre la quantità di dati, ma non eliminano il rischio dell’account AD ancora esistente. Il processo combina quindi periodo di inattività documentato, approvazione dell’Owner, pulizia nella fonte e successivo Preview. Prima di rimuovere un account computer, per i dispositivi vanno valutati separatamente età, ultimo contatto con il dominio e stato della protezione.

Gestire le Directory Sources in Central

La panoramica centrale si trova in Global Settings > Platform > Directory service. Per configurare e gestire una fonte è necessario un ruolo Central Admin appropriato. A seconda della fonte desiderata, la pagina offre Add Active Directory, Add Microsoft Entra ID e Add directory service for Google. Per AD locale si scarica da qui il software di setup corrente; Entra ID e Google vengono autorizzati tramite i rispettivi connettori cloud.

L’elenco mostra nome, tipo, dominio, pianificazione e stato. Errori e warning vanno controllati anche in Alerts and Reports > Logs > General Logs > Events. Un indicatore verde non basta se l’ultimo Sync è vecchio o il numero di oggetti non corrisponde.

Un clic sul nome apre la pagina dei dettagli. Per AD si verificano in particolare il numero di utenti, gruppi, dispositivi, gruppi di dispositivi, Public Folder e Shared Mailbox, oltre a hostname, versione del client, dominio, stato e ora dell’ultimo Sync. Per Entra ID e Google sono centrali il numero di utenti e gruppi, lo stato, l’ultima esecuzione e la pianificazione. Dopo la configurazione iniziale e ogni modifica della fonte o dei filtri, questi valori vanno confrontati con una popolazione di riferimento nota.

In base al tipo di fonte, nella pagina dei dettagli è anche possibile modificare configurazione e filtri, eseguire il Purge dei dati sincronizzati ed eliminare la fonte. Si tratta di operazioni diverse: Purge rimuove i dati directory importati da questa fonte, mentre Delete elimina anche la Directory Source. Per AD si arrestano prima le opzioni di Sync e i client in esecuzione; per Entra ID e Google si utilizzano le rispettive finestre di dialogo per filtri, Purge e Delete. Prima di ogni variante si esportano utenti, gruppi, dispositivi, Policies e mailbox interessati e si leggono le conseguenze indicate in Central. Purge e Delete non sono test di connessione senza conseguenze e non vengono confermati senza un piano di ripristino.

Nome e descrizione si modificano soltanto dopo aver disattivato la fonte con Turn off. Dopo il salvataggio si riattiva con Turn on e si verifica il risultato. La disattivazione interrompe gli aggiornamenti e non viene quindi eseguita durante una modifica della directory non ancora verificata. Una volta attivata in produzione la sincronizzazione di una fonte, questo passaggio non può essere semplicemente annullato. Per un’esecuzione manuale, aprire la fonte, scegliere Synchronize e controllare stato, timestamp e modifiche agli oggetti.

Pianificare Self Service e Shared Mailbox prima del Sync

Se un utente deve usare il Self Service Portal, User Access va attivato prima del primo Directory Sync. Così Central può inviare gli inviti nel flusso previsto. Un accesso attivato successivamente non corregge automaticamente ogni consegna mancata in precedenza; utenti pilota, consegna della posta e accesso al portale vengono pertanto testati già prima dell’importazione estesa.

Le Shared Mailbox non possiedono necessariamente tutti gli attributi utente in Central. Gli utenti delegati ottengono l’accesso Self Service per la Shared Mailbox assegnata e, a seconda del prodotto con licenza, vi vedono ad esempio Emergency Inbox e Quarantine Summary. Un Delegate può quindi ricevere riepiloghi per la propria mailbox e, in aggiunta, per la Shared Mailbox. Dopo il Sync, deleghe e indirizzi di consegna vengono pertanto testati nella pratica e non accettati soltanto in base al numero di oggetti.

Una Shared Mailbox in un gruppo Microsoft 365 non può essere sincronizzata tramite AD locale; a tale scopo si utilizza Microsoft Entra ID o Google Directory. Una normale Shared Mailbox esterna a un gruppo Microsoft 365 può invece essere importata da AD Sync. Prima di una successiva migrazione a Entra ID si inventaria da quale tipo di oggetto proviene ogni mailbox. In caso contrario, la continuazione di AD Sync dopo il cambio di fonte può rimuovere mailbox oppure lasciarle con dati obsoleti.

Prima della prima sincronizzazione

Si stabilisce innanzitutto quale directory è autorevole per ciascun insieme di utenti e gruppi. Le stesse persone non devono essere create contemporaneamente in modo manuale, da AD e da Entra ID.

Per la prima esecuzione è consigliabile una piccola OU di test con utenti e gruppi rappresentativi. Si verificano:

• indirizzi e-mail e User Principal Name,
• gruppi annidati e appartenenze,
• account disattivati o obsoleti,
• account di servizio e tecnici,
• conflitti di nome con oggetti Central esistenti.

Ogni utente da sincronizzare necessita di un indirizzo e-mail univoco. Molti processi Central lo utilizzano come identità e destinazione di consegna; con Sophos Email, un messaggio inviato a un indirizzo privo di utente associato può perfino risultare non recapitabile. Inoltre, il firewall o il proxy devono poter raggiungere i domini e le porte documentati per Central. Un test LDAP riuscito, da solo, non conferma questo percorso verso il cloud.

Installare AD Sync Utility

Il software di sincronizzazione corrente viene scaricato direttamente da Sophos Central e installato su un sistema Windows permanentemente disponibile. Il sistema necessita di accesso di rete al Domain Controller e ai servizi Sophos richiesti.

La versione corrente di Active Directory Synchronization Setup funziona soltanto su un sistema Windows a 64 bit e richiede .NET Framework 4.6.2. Sophos elenca Windows 7, 8.1, 10 e 11, nonché Windows Server 2008 R2, 2012, 2012 R2, 2016, 2019, 2022 e 2025. Come Domain Controller, Sophos indica Windows Server da 2008 R2 a 2025. Questa compatibilità del produttore non sostituisce il ciclo di vita Microsoft: per una nuova installazione produttiva si utilizza un sistema operativo server attualmente supportato e aggiornato, non Windows 7 o una versione Windows Server fuori supporto.

Per l’accesso a Central si usano API Credentials con il ruolo Service Principal Active Directory Sync, non credenziali Super Admin generiche.

L’account di servizio AD utilizzato riceve soltanto i diritti necessari per leggere i Forest e gli oggetti directory selezionati. Scadenza password, avvio del servizio e responsabilità vengono documentati. Un account amministrativo personale non è adatto.

La Utility non può elaborare un dominio se un singolo componente del nome supera 63 caratteri oppure inizia o termina con - o _. Questo limite viene verificato prima dell’installazione, poiché un Display Name abbreviato o un UPN diverso non correggono un nome di dominio AD non valido.

Sophos ha testato fino a 30'000 oggetti AD. Oltre 40'000 voci utente, l’interfaccia può reagire più lentamente. Gli ambienti più grandi vengono quindi filtrati in modo particolarmente rigoroso e testati con tempi di esecuzione realistici.

A ogni esecuzione della sincronizzazione, la Utility verifica se è disponibile una versione più recente e normalmente esegue automaticamente gli upgrade successivi. Le prime versioni di AD Sync non supportano più l’autenticazione Central attuale e possono smettere completamente di funzionare se questo upgrade automatico non riesce. In tal caso si scarica l’installer corrente da Global Settings > Platform > Directory service e lo si esegue sopra l’installazione esistente. Successivamente si creano nuove API Credentials con il ruolo Service Principal Active Directory Sync e si inseriscono nella Utility come Client ID e Client Secret. Ogni istanza di Sync produttiva riceve un’identità tecnica tracciabile, una responsabilità documentata e una propria rotazione del Secret.

Client ID e Client Secret si verificano con Validate credentials. Se la Utility deve comunicare tramite un proxy, si attiva Configure proxy manually e si inserisce l’indirizzo del proxy. Se il proxy richiede l’autenticazione, si aggiungono Enable proxy authentication, utente proxy e password proxy. Soltanto un secondo test delle credenziali riuscito conferma che funzionano sia i dati API sia il percorso proxy.

Questa maschera proxy appartiene a Active Directory Synchronization Setup 4.0. Un tenant Trial può invece ricevere ancora la precedente Sophos Central AD Sync Utility 3.5.4, nella quale non è possibile inserire dati proxy nell’interfaccia. Per impostazione predefinita, il servizio viene eseguito come Local Service e, con un proxy autenticato, spesso non riesce con Failed active directory synchronization, una System.Net.Http.HttpRequestException e CommandLib.HttpRequestCommand+HttpStatusException. Un account di servizio alternativo utilizzato a tale scopo necessita di Log on as a service, accesso interattivo e batch, diritti di lettura sulle OU interessate e accesso completo a C:\ProgramData\Sophos\Sophos Cloud AD Sync. Dopo ogni cambio di tale account, la vecchia Utility viene riconfigurata. Negli ambienti produttivi si utilizza, ove possibile, il software 4.0 corrente.

Per LDAP va usato un account di sola lettura dell’intero Forest selezionato. Use LDAP over an SSL connection resta attivo quando possibile. LDAPS usa normalmente TCP 636, mentre LDAP non cifrato usa TCP 389. A causa di LDAP Signing e Channel Binding, la porta 389 non rappresenta un’alternativa affidabile negli ambienti Active Directory attuali. Per LDAPS, il Domain Controller necessita di un certificato valido e considerato attendibile dal sistema di Sync.

Se è dimostrato che lo specifico ambiente LDAP non supporta SSL, si può disattivare Use Secure LDAP e impostare la porta sul servizio LDAP non cifrato appropriato. Si tratta di un fallback documentato, non di una Best Practice. Credenziali e dati della directory non sono quindi protetti da TLS durante il trasporto; segmentazione, percorso di rete e passaggio tempestivo a LDAPS vengono pertanto trattati come rischi.

Cosa si aspetta la Utility nel Forest

Per un Forest completo, alla radice dell’albero della directory AD Sync legge rootDomainNamingContext con il Distinguished Name del dominio root del Forest e defaultNamingContext con il Distinguished Name del server utilizzato. In CN=Partitions,CN=Configuration,<rootDomainNamingContext>, la Utility si aspetta per i Naming Context rilevanti voci con netBiosName, dnsRoot e nCName. Il valore di nCName determina gli ulteriori ambiti di ricerca, a condizione che non sia un Distinguished Name sovraordinato del server indicato nella maschera di setup.

Se manca uno di questi attributi o l’account di servizio non può leggere la Configuration Partition, il test di login può riuscire mentre il riconoscimento del Forest o il Sync successivo falliscono. In tal caso, prima di modificare filtri o oggetti Central, i valori vengono controllati con LDP.exe usando lo stesso account di servizio.

Filtrare OU e oggetti

I filtri limitano l’ambito della sincronizzazione. Vengono inclusi soltanto OU, utenti e gruppi realmente necessari a Sophos Central. Un’importazione estesa dalla root raramente è utile.

Prima dell’importazione, l’anteprima mostra quali oggetti verrebbero aggiunti, modificati o rimossi. In particolare, le eliminazioni non vengono confermate senza verifica. La vista Preview o Pending Changes può non rappresentare correttamente caratteri UTF-16 o Double Byte e visualizzare, ad esempio, ???. I dati vengono comunque trasmessi a Sophos Central e lì visualizzati. Nomi in cinese, giapponese o coreano vengono pertanto controllati anche direttamente in Active Directory e, dopo un Pilot Sync controllato, in Central.

Sophos descrive questo problema dell’anteprima come una limitazione che dovrebbe essere corretta in una versione futura di AD Sync Utility. Finché la versione utilizzata non risolve il problema in modo dimostrabile, restano necessari il controllo nella directory di origine e quello successivo al Sync.

Base DN e LDAP filter svolgono due compiti diversi. Base DN limita la ricerca alle OU selezionate; in Active Directory, l’appartenenza a una OU non può essere espressa in modo affidabile soltanto mediante un normale filtro LDAP. LDAP filter limita attributi o appartenenze a gruppi all’interno di tale ambito di ricerca. Entrambi i filtri vengono gestiti per ogni Domain, poiché i Child Domain non ereditano l’impostazione del Parent Domain. Anche i filtri di utenti e gruppi funzionano indipendentemente.

Nella scheda AD Filters, Search Bases e LDAP Query Filters vengono inseriti separatamente per Domain e, se necessario, separatamente per utenti e gruppi. Una Search Base per una OU Finance può essere, ad esempio:

OU=Finance,DC=myCompany,DC=com

Un filtro utenti per i membri di un gruppo può essere, ad esempio:

memberOf=CN=testGroup,DC=myCompany,DC=com

Senza un filtro gruppi aggiuntivo, Central continua a individuare tutti i gruppi ai quali appartengono tali utenti. Se si vuole limitare anche la selezione dei gruppi a questo unico gruppo, si aggiunge, ad esempio, CN=testGroup come filtro gruppi. La modifica di un filtro può escludere dall’ambito utenti e gruppi sincronizzati in precedenza e quindi eliminarli da Central; per questo viene sempre eseguita un’anteprima completa.

Sophos usa come punto di partenza i seguenti filtri:

Utenti: (&(objectCategory=person)(objectClass=user)(!sAMAccountType=805306370)(!userAccountControl:1.2.840.113556.1.4.803:=2))
Gruppi: (&(objectCategory=group)(objectClass=group))

Il filtro utenti seleziona persone con classe user, esclude computer tramite sAMAccountType=805306370 e account disabilitati tramite il relativo bit userAccountControl. I filtri aggiuntivi vengono combinati per dominio con queste condizioni di base e testati prima in LDP.exe.

Sophos limita la configurazione a 1'000 filtri per oggetto directory e a 5'000 caratteri per ogni filtro LDAP aggiuntivo. Gli utenti possono essere sincronizzati soltanto insieme ai gruppi di utenti e i dispositivi soltanto insieme ai gruppi di dispositivi. Per i gruppi tra domini, l’anteprima mostra tutti i membri, ma Central importa soltanto gli utenti del dominio a cui appartiene il gruppo. Questi gruppi vanno quindi testati esplicitamente prima della sincronizzazione in produzione.

Il risultato atteso viene verificato con Microsoft LDP.exe: Search Base di AD Sync corrisponde a Base DN, mentre l’espressione LDAP di AD Sync corrisponde a Filter. In questo modo si distingue se l’oggetto non viene fornito da Sophos oppure già dalla query alla directory. Alcuni confronti tra attributi possono essere case-sensitive.

I filtri con lastLogon o lastLogonTimestamp vengono usati con cautela. lastLogon è in genere più aggiornato, ma non viene replicato tra Domain Controller; per ottenere un valore affidabile occorrerebbe quindi interrogare tutti i Domain Controller. lastLogonTimestamp viene replicato, ma può essere obsoleto. Sophos raccomanda di rimuovere account e dispositivi inattivi alla fonte invece di affidarsi soltanto a un filtro temporale.

Se lastLogonTimestamp viene comunque utilizzato come filtro transitorio, si definisce dapprima una data limite UTC e la si converte in Windows FILETIME con un convertitore LDAP o Active Directory FILETIME attendibile. La data di esempio Sophos, 1 dicembre 2020 alle 00:01, produce 132581431640000000. In Active Directory Synchronization Setup > AD Filters, nel campo Custom Filters si inserisce l’espressione LDAP aggiuntiva:

(lastLogonTimestamp>=132581431640000000)

Il valore di esempio non viene riutilizzato senza modifiche. La propria data limite viene scelta consapevolmente, convertita correttamente e documentata insieme al fuso orario e all’approvazione della modifica. Seguono Preview and Sync, la verifica degli utenti inclusi ed esclusi e soltanto dopo l’autorizzazione dell’esecuzione produttiva.

AD Sync crea soltanto gruppi con più di un membro. Un gruppo vuoto o con un solo membro non compare quindi come oggetto Central atteso. Utenti o indirizzi e-mail duplicati in più Forest non vengono uniti; la fonte di un oggetto può così cambiare tra le esecuzioni. Per quanto possibile, un Forest viene sincronizzato con un solo tenant Central.

Exclude disabled user accounts è attivo per impostazione predefinita. Per la sincronizzazione delle Shared Mailbox, questa opzione deve restare attiva. Se viene disattivata, Central può creare oggetti mailbox duplicati per le Shared Mailbox. Indipendentemente da ciò, i normali account utente disabilitati vanno ripuliti nella fonte e non reintrodotti mediante un Sync più ampio.

Gli switch dei tipi di dati hanno dipendenze specifiche:

• Sync users and user groups sincronizza congiuntamente entrambi e include anche le normali Shared Mailbox. Se lo switch viene disattivato, tramite questa fonte AD non è possibile sincronizzare né Shared Mailbox né Public Folder.
• Sync public folders richiede inoltre Sync users and user groups, poiché le Public Folder vengono trattate come oggetti mailbox.
• Per i dispositivi, durante il normale funzionamento Sync devices e Sync organizational units vengono attivati insieme. Durante la configurazione iniziale si possono importare dapprima soltanto le OU, affinché le Policies siano disponibili prima dei dispositivi.
• Se in seguito si disattiva soltanto Sync organizational units, i dispositivi restano attivi, ma le OU precedenti compaiono come Custom Groups. Se resta attiva soltanto la sincronizzazione delle OU, i dispositivi non vengono più assegnati ai gruppi Central.

Senza gruppi OU preparati, i dispositivi appena sincronizzati ricevono inizialmente le Default Policies. Dopo il Pilot delle OU si attivano quindi congiuntamente entrambi gli switch dei dispositivi e si controllano l’assegnazione e la Policy effettivamente applicata.

Per gruppi molto grandi conta anche l’attributo AD member. Da 1'500 voci, Active Directory usa Range Retrieval come member;range=0-1499 e svuota il semplice attributo member. Un gruppo già popolato con più di 1'500 oggetti prima del primo Sync può mancare in Central o mostrare un numero errato di membri. Se possibile, tali gruppi vengono limitati a meno di 1'500 oggetti utente e controllati con LDP.exe.

Matching degli utenti e alias e-mail

Central abbina gli utenti AD agli utenti esistenti tramite il Domain Login nel formato DOMAIN\user oppure tramite l’attributo mail. Il Display Name proviene da Display name, mentre gli indirizzi e-mail alias aggiuntivi provengono da proxyAddresses. In caso di corrispondenza, l’oggetto Central esistente diventa un oggetto gestito dalla directory; senza corrispondenza viene creato un nuovo utente. Preview and Sync mostra le corrispondenze in Users to Modify e i nuovi oggetti in Users to Add.

Un oggetto sincronizzato da un altro Directory Service non viene creato come secondo nuovo utente in caso di corrispondenza, ma può ricevere un ulteriore indirizzo e-mail da AD. Un utente creato manualmente e un utente AD con lo stesso nome possono invece restare due oggetti separati se login e indirizzo e-mail non corrispondono. Il Display Name, da solo, non è una chiave di matching.

In Preview and Sync, le corrispondenze in Users to Modify e le nuove identità in Users to Add vengono controllate singolarmente. Un’assegnazione errata viene rifiutata invece di accettare l’intera proposta con Approve Changes and Continue. Il passaggio di un utente manuale a un oggetto gestito da AD è riconoscibile anche dall’icona della directory.

Se un utente viene rimosso da AD, il comportamento di Central dipende dalle sue relazioni. Gli amministratori e gli utenti con un dispositivo o un login associato restano normali utenti Central. Un utente senza dispositivo, login o ruolo privilegiato può invece essere rimosso automaticamente. Per lo stesso motivo di protezione, le modifiche all’indirizzo e-mail di un amministratore Central non vengono importate indiscriminatamente da AD. Prima dell’Offboarding si controllano quindi separatamente ruoli amministrativi e associazioni ai dispositivi.

Per cambiare l’indirizzo e-mail principale di un amministratore gestito dalla directory o rimuovere il relativo oggetto Central rimasto dopo l’eliminazione in AD, il ruolo amministrativo va revocato in modo controllato prima del Sync successivo. Dopo la sincronizzazione, il ruolo necessario può essere riassegnato. Durante questa procedura si mantiene sempre un secondo Super Admin funzionante come percorso di Recovery.

Nome errato dovuto a login sovrapposti

Se l’utente A possiede per errore anche il login dispositivo dell’utente B, AD Sync può dapprima assegnare entrambi i login ad A e, elaborando successivamente B, rinominare in B il record esistente. Nell’utente Central interessato si rimuovono pertanto tutte le associazioni estranee in Logins, quindi si esegue nuovamente la sincronizzazione. Finché il login errato continua a esistere, il nome non viene semplicemente riscritto.

Impossibile assegnare un ruolo a un utente AD

Si cerca dapprima l’indirizzo e-mail in My Environment > Users & Groups > Users. In caso di duplicati si documentano i login degli oggetti da non utilizzare, li si rimuove da tali oggetti tramite Edit logins e li si aggiunge all’utente corretto. Soltanto dopo si salva il ruolo e si verifica l’invio del setup. Se l’indirizzo e-mail resta bloccato a livello di tenant, non si eseguono ulteriori eliminazioni, ma si risolve il conflitto tramite il supporto.

Interpretare correttamente i gruppi nidificati

La pagina utente può mostrare sia il gruppo AD diretto sia gruppi superiori come linked groups. Ciò non significa che l’utente sia membro diretto di ciascun gruppo. Per analisi di autorizzazioni e policy vanno distinte appartenenza diretta, nidificazione e policy Central realmente applicata.

Assegnare un login Mac all’utente sincronizzato

AD Sync importa un login come NETBIOSDOMAIN\user, mentre un Mac lo comunica spesso come MACNAME\user. Central può quindi creare un secondo oggetto utente automatico. Dopo aver controllato i dispositivi interessati, si ripulisce tale oggetto e si assegna MACNAME\user all’utente sincronizzato da AD. Per un rollout più ampio, invece di intervenire manualmente a posteriori, si testa il Domain Override previsto da Sophos.

Sincronizzare computer e gruppi OU

Il rilevamento dei dispositivi supporta computer e server Windows. Sophos associa un dispositivo protetto all’oggetto AD mediante FQDN e hostname e lo sposta nel gruppo OU sincronizzato. Un computer prima raggruppato manualmente può quindi tornare nella struttura AD al Sync successivo.

Un nuovo oggetto dispositivo o gruppo viene creato quando Central non conosce ancora la stessa AD ObjectGUID. Se il nome di un nuovo gruppo AD collide con un gruppo esistente, Central usa il Distinguished Name. Più record AD con lo stesso DN non sono supportati.

Nel matching devono corrispondere FQDN e hostname. Se un dispositivo Central possiede dominio e hostname corretti ma dettagli memorizzati differenti, il Sync aggiorna i dati e lo sposta nel gruppo AD appropriato. Se esistono due dispositivi con lo stesso FQDN, il collegamento precedente viene sciolto e viene associato il nuovo record. Gli hostname duplicati vanno quindi corretti prima del Sync, invece di interpretare la conseguente nuova associazione come una perdita casuale del dispositivo.

Le OU vengono sincronizzate prima dei dispositivi, affinché le Policies possano essere preparate sui gruppi previsti. Dispositivi e gruppi sincronizzati non possono essere riorganizzati in modo permanente in Central contro la struttura AD. Una gerarchia con più di 40 livelli viene consolidata a partire dal livello 40.

Dispositivi e gruppi sincronizzati possono essere spostati o eliminati in Central, ma non modificati come oggetti locali. Queste modifiche manuali non sono permanenti: il Sync successivo ripristina la struttura AD o ricrea l’oggetto. Se un dispositivo protetto viene eliminato da AD, al ciclo successivo Central lo sposta in un gruppo non strutturato e rimuove il contrassegno di gestione AD. Anche le modifiche a nome, dettagli del sistema operativo o struttura OU vengono applicate al ciclo successivo, inclusi lo spostamento e la rimozione di gruppi.

Le Policy dei gruppi creati manualmente restano disponibili. I dispositivi gestiti da AD vengono tuttavia spostati da tali gruppi al gruppo sincronizzato e ricevono inizialmente le Default Policies, se non è stata assegnata in precedenza una Policy appropriata. Una Policy assegnata a un gruppo Top Level viene ereditata da un gruppo nidificato finché quest’ultimo non dispone di un’assegnazione propria. Per questo si sincronizzano prima le OU, poi si assegnano le Policy e infine si importano i dispositivi.

Sophos non offre attualmente un’API per Directory Device e Device Group sincronizzati da AD. Le automazioni non devono quindi presumere di poter gestire completamente questa struttura tramite API come i normali gruppi Central.

In My Environment > Unmanaged devices, i computer e i server noti da AD compaiono in viste separate senza Sophos Agent. I pacchetti di protezione necessari sono disponibili in My Environment > Installers. Questa vista inventario non installa tuttavia alcuna protezione; ogni dispositivo atteso resta nel processo di rollout o di eccezione finché l’agent non viene installato oppure viene approvata un’eccezione documentata.

Pianificazione e monitoraggio

La pianificazione del Sync deve corrispondere alla frequenza delle modifiche aziendali. Dopo ogni esecuzione si controllano stato, errori e modifiche degli oggetti. Un servizio avviato correttamente non dimostra che tutti gli oggetti siano stati sincronizzati senza errori.

Gli avvisi relativi a credenziali, connessione, attributi mancanti o conflitti di oggetti vengono risolti tempestivamente. L’operatività richiede un Owner e un sostituto.

Alla prima esecuzione e dopo ogni modifica filtro si avvia manualmente Preview and Sync. La preview va controllata per oggetti nuovi, modificati e da eliminare e soltanto dopo confermata con Approve Changes and Continue. Un ciclo manuale può richiedere fino a 15 minuti. Per usare esclusivamente esecuzioni controllate, scegliere Never. Only sync when manually initiated.

I Runtime Log si trovano in:

C:\ProgramData\Sophos\Sophos Cloud AD Sync\Logs\

Ruotano su sette file giornalieri. Copiare o rinominare un log necessario prima della rotazione successiva. Un Email Alert Medium contiene spesso solo il riepilogo; cercare la causa concreta nel log dello stesso intervallo.

Quando il server AD Sync viene sostituito, non devono mai funzionare contemporaneamente due istanze non controllate. Arrestare dapprima lo schedule sul vecchio server, installare la Utility corrente sul nuovo, confrontare i filtri e verificare con Preview and Sync. Attivare lo schedule e rimuovere la vecchia installazione soltanto dopo un ciclo manuale riuscito.

Eliminazione e ricostruzione

La rimozione di un oggetto dalla directory di origine o dal filtro può influire sul corrispondente oggetto Central e sulla sua assegnazione Policy. Prima di una modifica di massa si leggono e documentano le azioni annunciate dall’interfaccia.

Eliminare la configurazione Sync o i dati sincronizzati non è una normale misura di troubleshooting. Prima si verificano assegnazioni dei dispositivi, appartenenze ai gruppi e possibili duplicati. Una ricostruzione senza analisi può riprodurre gli stessi problemi.

Prima di Purge data vengono arrestate tutte le istanze AD Sync in esecuzione o copiate e vengono controllati i filtri, altrimenti i dati ricompaiono. Il Purge è irreversibile. Dispositivi gestiti e utenti associati, nonché amministratori, non vengono rimossi nemmeno se originariamente provenivano da AD.

Eseguire il Purge dei dati AD sincronizzati

La procedura inizia in Global Settings > Platform > Directory service. Qui si apre il nome della fonte AD, la si arresta con Turn off e si seleziona Purge data. Nella finestra di dialogo si sceglie consapevolmente l’ambito dei dati da rimuovere:

• Users and user groups rimuove anche le Shared Mailbox e le Public Folder sincronizzate.
• Devices and device groups rimuove l’insieme sincronizzato di dispositivi e gruppi, ad eccezione degli oggetti protetti indicati da Sophos.

Dopo avere confermato l’irreversibilità, si seleziona nuovamente Purge data. Central elimina l’insieme selezionato e non sincronizza più questo tipo di dati dalla fonte arrestata. Se sono stati rimossi tutti i dati AD, utenti, dispositivi e gruppi devono essere gestiti da quel momento manualmente oppure tramite una fonte nuova e chiaramente delimitata. Per utenti e gruppi di utenti può subentrare, ad esempio, Microsoft Entra ID.

Prima del Purge si individuano e si arrestano tutte le copie di AD Sync Utility e i relativi schedule. I filtri, da soli, non impediscono la ricomparsa dei dati se una seconda istanza continua a sincronizzare. In seguito si controllano gli amministratori rimasti, i dispositivi gestiti e i rispettivi utenti associati, poiché Central non elimina queste eccezioni.

Passare da AD a Microsoft Entra ID

Sophos supporta il passaggio della sincronizzazione di utenti e gruppi di un dominio da AD a Entra ID. Devono prima esistere origini AD ed Entra adeguate per lo stesso dominio e gli utenti devono corrispondere in modo affidabile nelle due origini. Gli utenti AD non corrispondenti possono essere rimossi da Central durante il passaggio.

Entra ID non sincronizza computer e gruppi di computer. Se sono ancora necessari, AD resta attivo per i dispositivi, mentre Entra ID fornisce utenti e gruppi di utenti dello stesso dominio. Public Folder e assegnazioni esistenti di Shared Mailbox presentano ulteriori limitazioni da verificare separatamente prima della migrazione.

Il passaggio inizia con un elenco di esportazione e confronto, non direttamente modificando l’origine. Se gli utenti corrispondono tra AD ed Entra ID, Central aggiorna l’oggetto esistente e conserva le mailbox collegate. Gli utenti non corrispondenti possono essere eliminati con l’associazione mailbox; i nuovi utenti Entra vengono creati. I gruppi di utenti non corrispondenti restano, ma non vengono più aggiornati.

Shared Mailbox e Public Folder richiedono particolare attenzione. Central conserva le Shared Mailbox AD precedenti con l’ultimo stato dei dati AD, ma non le aggiorna più tramite AD. Nuove Shared Mailbox Entra possono comparire in aggiunta. Anche le Public Folder restano con il loro ultimo stato. Se dopo la migrazione si continua a utilizzare la vecchia sincronizzazione AD on-premises per questi oggetti, tipi di oggetto differenti possono rimuovere inaspettatamente Shared Mailbox esistenti.

In seguito si controllano utenti, gruppi, Policies, assegnazioni dei dispositivi, Shared Mailbox, Public Folder e duplicati. Se AD resta attivo per i dispositivi, Sync devices e Sync organizational units continuano a essere utilizzati congiuntamente.

Requisiti e decisione di migrazione

AD ed Entra ID devono rappresentare lo stesso dominio. Prima del cambio si confrontano gli utenti mediante indirizzi e-mail univoci e altri attributi identificativi corrispondenti, affinché Central aggiorni gli account esistenti invece di eliminarli e ricrearli. Il connettore Entra e le autorizzazioni dell’app vanno configurati completamente prima di disattivare la fonte AD.

Public Folder, computer e gruppi di computer continuano a provenire solo da AD. Per ogni dominio si decide quindi se Entra ID da solo è sufficiente o se AD deve restare parallelo per dispositivi e OU. Le Shared Mailbox vanno inventariate separando oggetti AD, Entra e gruppi Microsoft 365.

Utilizzare soltanto Microsoft Entra ID

Questo percorso è adatto se Central non deve più aggiornare dispositivi, gruppi di dispositivi o Public Folder da AD.

1. Eseguire l’ultimo AD Sync e verificare utenti, gruppi, mailbox ed errori.
2. In Global Settings > Platform > Directory service, aprire la fonte AD e disattivarla con Turn off.
3. Con Add Microsoft Entra ID, configurare la fonte Entra per lo stesso dominio e concedere le autorizzazioni dell’app richieste.
4. Avviare la sincronizzazione Entra e verificare utenti, gruppi e Shared Mailbox rispetto all’elenco di esportazione e confronto.
5. Soltanto dopo l’accettazione, disinstallare il software locale AD Sync Setup e revocare le relative API Credentials dopo un controllo documentato.

La disattivazione della vecchia fonte è una migrazione controllata, non un reset di troubleshooting. In caso di eliminazioni inattese, non si continua a sincronizzare mediante ripetute attivazioni e disattivazioni, ma si valuta dapprima il report di matching.

Utilizzare Microsoft Entra ID e AD in parallelo

Questa variante utilizza Entra ID per utenti, gruppi di utenti e Shared Mailbox moderne, mentre AD fornisce dispositivi e gruppi di dispositivi.

1. Eseguire completamente l’AD Sync esistente e convalidare l’inventario iniziale.
2. In AD Sync Utility, limitare la selezione a Sync devices e Sync organizational units; in futuro, utenti e gruppi di utenti non saranno più forniti da AD.
3. Disattivare temporaneamente la fonte AD in Central con Turn off.
4. Aggiungere Microsoft Entra ID per lo stesso dominio, sincronizzare e convalidare utenti, gruppi e Shared Mailbox.
5. Riattivare la fonte AD con Turn on, sincronizzarla manualmente e verificare che dispositivi e gruppi di dispositivi continuino a essere aggiornati senza importare nuovamente gli utenti da AD.

Entrambe le fonti ricevono Owner, schedule e criteri di accettazione propri. Lo stato verde di entrambi i connettori non dimostra che i rispettivi ambiti di oggetti siano separati correttamente.

Effetti su utenti, gruppi, mailbox e dispositivi

Per gli utenti corrispondenti, Entra ID aggiorna l’oggetto Central esistente e conserva le informazioni mailbox associate. Un utente AD senza un record Entra corrispondente può essere eliminato da Central insieme alla relativa associazione mailbox. I nuovi utenti Entra vengono creati come nuovi utenti Central con i dati mailbox disponibili.

I gruppi di utenti corrispondenti vengono aggiornati. I gruppi AD privi di controparte Entra restano visibili in Central, ma non ricevono più modifiche da AD. Vengono creati nuovi gruppi Entra. La presenza di questi gruppi non aggiornati non dimostra che la sincronizzazione sia ancora operativa; assegnazioni delle Policy e appartenenze vengono quindi controllate separatamente.

Le Shared Mailbox e le Public Folder esistenti, precedentemente fornite da AD, restano con l’ultimo stato dei dati AD ma non vengono più aggiornate. Tali Shared Mailbox continuano a comparire in Mailboxes, ma dopo il passaggio possono non avere utenti associati. Le nuove Shared Mailbox Entra possono comparire sia come oggetti utente sia in Mailboxes e possono anch’esse arrivare senza l’associazione Delegate nota da AD. Per questo si convalidano nuovamente l’accesso delegato e i Quarantine Summary. Se la vecchia sincronizzazione AD continua senza controllo dopo la migrazione, tipi di oggetto differenti possono rimuovere Shared Mailbox esistenti.

Nel modello Entra-only, i dispositivi e i gruppi di dispositivi AD precedenti restano inizialmente visibili in Central, ma non vengono più aggiornati dalla directory. Nel modello parallelo, AD continua a sincronizzare questi oggetti. Entra ID non fornisce computer, gruppi di computer o Public Folder. Questa conseguenza viene documentata esplicitamente nella decisione di migrazione, affinché un inventario non più aggiornato non venga interpretato erroneamente come una sincronizzazione corrente.

Spostare Endpoint esistenti in un nuovo dominio AD

Se cambia soltanto il dominio AD mentre nome del computer e SID restano identici, Sophos Agent non deve essere reinstallato e conserva la machine_id. Dapprima, in Global Settings > Platform > Directory service, si converte la configurazione AD Sync al nuovo dominio, si convalidano le credenziali e si sincronizzano utenti, gruppi, OU e dispositivi. Soltanto dopo gli Endpoint possono effettuare il check-in in Central.

Con il nuovo FQDN, Central rimuove la precedente associazione AD e cerca l’oggetto dispositivo appropriato nel nuovo dominio. Se lo trova, ricollega lo stesso oggetto Endpoint e, quando la sincronizzazione delle OU è attiva, lo sposta nel gruppo corretto. I login utente cambiano invece, ad esempio, da OLDDOMAIN\jsmith a NEWDOMAIN\jsmith e possono generare duplicati.

La verifica finale controlla nuovo dominio, gruppo OU, Policies applicate e assegnazione utente. Soltanto dopo vengono rimossi gli oggetti dispositivo, utente, gruppo o directory obsoleti del vecchio dominio.

Errori frequenti

L’utente compare due volte

Confrontare origini, indirizzo e-mail, UPN e oggetti manuali esistenti. Non eliminare precipitosamente uno degli oggetti finché vi sono collegati dispositivi o Policies.

Manca un nuovo gruppo

Verificare filtri OU e gruppi, appartenenze annidate, ultima sincronizzazione riuscita e attributi directory.

0000208D, NO_OBJECT o «The object does not exist»

Questo errore si verifica in genere quando un Custom Filter fa ancora riferimento a una OU rimossa nel frattempo da Active Directory. Il messaggio di errore non indica il nome della OU eliminata. In Define Filters si confrontano quindi tutti i filtri AD con la struttura corrente della directory e si rimuovono soltanto i riferimenti a oggetti non più esistenti. Seguono una nuova esecuzione di Preview e il controllo delle eliminazioni pianificate.

0xFFFE o 0xFFFF in Preview and Sync

Se Active Directory contiene caratteri con i valori esadecimali non validi 0xFFFE o 0xFFFF, l’esecuzione manuale può interrompersi in Preview and Sync. Si individua dapprima l’attributo di origine interessato e lo si corregge alla fonte. Se ciò non è possibile a breve termine, Sophos indica come workaround mirato Sync on Schedule - automatic (within next 2-3 minutes), poiché questa esecuzione salta l’anteprima. Non si tratta di una correzione permanente: ambito, risultato e oggetti nuovi o rimossi vengono controllati immediatamente dopo in Central e nel log.

endpoint_user_sessions.user_match_id durante l’eliminazione di un login

Error syncing record: Error deleting login, insieme a un riferimento Foreign Key a endpoint_user_sessions.user_match_id, può comparire quando AD ha rimosso o disabilitato un utente, ma Central non può eliminare il login associato a causa di una sessione esistente. Il resto del Sync continua e può terminare correttamente. Se la voce si ripete, si documentano utente, login e timestamp e si coinvolge Sophos Support per la correzione in Central; un Purge o una ricostruzione dell’intero Sync sarebbero sproporzionati.

La sincronizzazione resta obsoleta

Controllare servizio Windows, account di servizio, password, DNS, proxy, autorizzazioni del firewall e stato del Central Sync. Un ticket di supporto deve includere Sync Logs e timestamp.

Dalla versione 5.x di AD Sync Client, per le azioni di Directory Sync l’Audit Log non mostra più il Client ID delle API Credentials come Modified by, ma la GUID dell’AD Sync Client registrato presso Sophos. Ciò vale per le azioni Create, Update e Delete. Una GUID non indica quindi automaticamente un attaccante sconosciuto: va correlata con istanza di Sync, schedule e timestamp del log.

Le credenziali LDAP vengono richieste ripetutamente

NeedADCredsException, insieme a The LDAP server is unavailable, non indica necessariamente una password errata. Si controllano Domain Controller, formato dell’account DOMAIN\username, diritti di lettura e porta selezionata. Per LDAPS si utilizza normalmente TCP 636 e il Domain Controller deve presentare effettivamente un certificato attendibile su tale porta. Una porta in ascolto, da sola, non dimostra che la configurazione TLS funzioni.

Escalation a Sophos Support

Un caso di supporto riproducibile contiene descrizione dell’errore, tenant e licenza, intervallo esatto, versione AD Sync, tutti i Logs, screenshot rilevanti e indirizzo IP pubblico del sistema di Sync al momento della raccolta. I casi Partner richiedono anche la corretta assegnazione del cliente MSP. Remote Assistance viene attivata soltanto per il caso concreto e dopo l’approvazione interna.

Domande frequenti