Synchroniser Active Directory avec Sophos Central

Sophos Central peut importer des utilisateurs et des groupes depuis un Active Directory local. Ces identités servent notamment à attribuer des policies et à associer des appareils. Une synchronisation non maîtrisée peut toutefois créer des comptes inutiles, des objets en double ou des suppressions inattendues.

Microsoft Entra ID se synchronise au moyen d’un connecteur distinct. La procédure correspondante est décrite dans Synchroniser Microsoft Entra ID avec Sophos Central.

Définir le modèle des sources avant l’installation

Central peut gérer jusqu’à 25 sources d’annuaire par tenant. Au-delà, une structure Central Enterprise est prévue. Les utilisateurs et les adresses e-mail doivent rester uniques au sein d’un tenant Central. Un même domaine ne doit pas fournir simultanément des utilisateurs par l’intermédiaire de plusieurs sources AD, Entra ID ou Google Directory.

Lors d’un Trial, Sophos limite en outre le nombre de Directory Objects qui peuvent être créés ou utilisés, notamment les utilisateurs, les appareils et les groupes. Un import de test incomplet n’est donc pas nécessairement dû à une erreur de filtre. Avant un pilote, il faut vérifier conjointement l’étendue du Trial, le nombre d’objets attendu et l’état de la licence.

Plusieurs Child Domains peuvent être sélectionnés au sein d’un Forest, et un tenant peut également synchroniser plusieurs Forests. Sophos recommande néanmoins de ne relier chaque Forest qu’à un seul tenant Central. Si le même Forest est importé dans plusieurs tenants, ou si plusieurs Forests contiennent les mêmes utilisateurs ou adresses e-mail, les cycles mettent tour à tour à jour les mêmes identités apparentes avec les informations de leur source. Central ne fusionne pas ces enregistrements, ce qui peut rendre les noms, attributs et appartenances aux groupes incohérents.

Une configuration mixte prise en charge est en revanche pertinente : AD synchronise les ordinateurs et les groupes d’ordinateurs, tandis qu’Entra ID fournit les utilisateurs et les groupes d’utilisateurs du même domaine. Les Shared Mailboxes d’un groupe Microsoft 365 nécessitent Entra ID ou Google Directory. Une Shared Mailbox normale située hors d’un groupe Microsoft 365 peut être importée avec AD Sync.

Les Shared Mailboxes et les Public Folders du même domaine que les utilisateurs nécessitent AD Sync Utility avec Sync users and user groups. Les boîtes aux lettres de groupes Microsoft 365 ne sont pas importées par AD Sync. Une Shared Mailbox sans Delegate n’est pas non plus synchronisée. Si une boîte aux lettres utilisateur inactive avec une délégation vers une boîte active est conservée, AD Sync ne la supprime pas et peut continuer à la gérer dans Central comme Shared Mailbox.

Un seul client AD Sync de production fonctionne pour un même domaine ou sous-domaine. En outre, plusieurs appareils AD ne doivent pas posséder le même DNS Hostname, faute de quoi Central ne peut pas les faire correspondre de manière univoque. Lors d’un remplacement de serveur, l’ancien calendrier est donc arrêté avant que la nouvelle instance ne commence la synchronisation de production.

Si le Self Service Portal doit être utilisé pour Sophos Email, Device Encryption ou Mobile, l’accès utilisateur doit être activé avant le premier Directory Sync. Les utilisateurs nouveaux et existants reçoivent ainsi l’invitation prévue. La procédure est décrite dans Configurer l’accès au Self Service Portal de Sophos Central.

Limites d’AD Sync et groupes multidomaines

AD Sync ne fusionne pas les données de plusieurs Forests ou Directory Services dans un enregistrement maître. Un même utilisateur ou une même adresse e-mail ne doit donc pas apparaître dans plusieurs Forests synchronisés. Les utilisateurs, adresses e-mail ou groupes en double peuvent être actualisés à chaque cycle, tour à tour, avec les informations de leur source, et même changer de Directory Owner visible dans Central. Les utilisateurs et adresses e-mail restent uniques par tenant. Les utilisateurs d’un même domaine ne doivent pas être synchronisés simultanément depuis AD et Entra ID, ni fournis en parallèle à plusieurs Central Admin Accounts.

Pour un groupe dont les membres appartiennent à plusieurs domaines, Central importe uniquement les utilisateurs du domaine auquel le groupe appartient. Preview and Sync peut afficher tous les membres, mais les utilisateurs de l’autre domaine ne sont pas ajoutés au groupe pendant le Sync de production. Ce comportement est vérifié pour les Universal Groups et les Child Domains à l’aide d’un membre de test par domaine.

Les utilisateurs et les groupes d’utilisateurs sont synchronisés ensemble ou désactivés ensemble. Il en va de même pour les appareils et les groupes d’appareils. Un maximum de 1'000 filtres est prévu par Directory Object et les filtres LDAP supplémentaires ne doivent pas dépasser 5'000 caractères. Les composants de domaine comportant plus de 63 caractères ou commençant ou se terminant par - ou _ ne sont pas pris en charge.

Les boîtes aux lettres de groupes Microsoft 365 nécessitent Entra ID. AD Sync ne prend en charge ni les Shared Mailboxes sans Delegate, ni plusieurs clients AD Sync de production pour un même domaine ou sous-domaine, ni plusieurs appareils AD avec un DNS Hostname identique. En revanche, une boîte aux lettres inactive avec une délégation vers une boîte active peut être conservée comme Shared Mailbox. Ces limites sont traitées comme des décisions de conception avant le premier cycle, et non contournées ultérieurement au moyen de filtres plus larges.

Nettoyer les objets AD inactifs avant la synchronisation

Dans la mesure du possible, les comptes utilisateur et appareils inactifs sont contrôlés, puis supprimés ou désactivés directement dans Active Directory. Ils ne font pas qu’augmenter le nombre d’objets Central, ils restent également un risque de sécurité dans la source. Un nettoyage réduit en outre le fichier de synchronisation transmis à Sophos Central et peut accélérer le cycle.

Les filtres LDAP peuvent empêcher l’importation d’utilisateurs inactifs dans Central et réduire également le fichier de synchronisation. Ils ne corrigent toutefois pas le risque que représente un compte AD inactif encore présent. Le processus d’exploitation combine donc une période d’inactivité traçable, la validation du propriétaire, le nettoyage de la source et un cycle Preview ultérieur. Avant de supprimer un compte ordinateur, les appareils sont contrôlés séparément selon leur âge, leur dernier contact avec le domaine et leur état de protection.

Administrer les Directory Sources dans Central

La vue centrale se trouve sous Global Settings > Platform > Directory service. Une Central Admin Role appropriée est nécessaire pour configurer et administrer une source. Selon la source souhaitée, la page propose Add Active Directory, Add Microsoft Entra ID et Add directory service for Google. Pour l’AD local, le logiciel Setup actuel est téléchargé depuis cette page. Entra ID et Google sont autorisés par l’intermédiaire de leurs connecteurs cloud respectifs.

Pour chaque entrée, la liste des sources affiche le nom, le type, le domaine, le calendrier et l’état. Les avertissements et erreurs sont contrôlés non seulement dans cette vue, mais aussi sous Alerts and Reports > Logs > General Logs > Events. Un état de source vert ne suffit pas si le dernier cycle est ancien ou si le nombre d’objets attendu est incorrect.

Un clic sur le nom ouvre les détails. Pour AD, il faut notamment vérifier le nombre d’utilisateurs, de groupes, d’appareils, de groupes d’appareils, de Public Folders et de Shared Mailboxes, ainsi que le Hostname, la version du client, le domaine, l’état et l’heure du dernier Sync. Pour Entra ID et Google, le contrôle porte surtout sur le nombre d’utilisateurs et de groupes, l’état, le dernier cycle et le calendrier. Après la configuration initiale et après chaque modification de filtre ou de source, ces valeurs sont comparées à un ensemble de référence connu.

Selon le type de source, il est également possible de modifier la configuration et les filtres, de purger les données synchronisées et de supprimer la source. Il s’agit d’interventions différentes : Purge supprime les données d’annuaire importées depuis cette source, tandis que Delete supprime en plus la Directory Source. Pour AD, les options Sync et les clients actifs sont arrêtés au préalable. Pour Entra ID et Google, leurs boîtes de dialogue Filter, Purge et Delete respectives sont utilisées. Avant chaque opération, il faut exporter les utilisateurs, groupes, appareils, policies et boîtes aux lettres concernés, puis lire les conséquences annoncées dans Central. Un Purge ou un Delete n’est pas un simple test de connexion et ne doit pas être confirmé sans plan de retour arrière.

Le nom et la description d’une source ne peuvent être modifiés qu’après sa désactivation avec Turn off. Une fois enregistrée, elle est réactivée avec Turn on, puis contrôlée. La désactivation interrompt l’actualisation et ne doit donc pas être effectuée pendant une modification d’annuaire non vérifiée. Une fois la synchronisation de production activée pour une source, cette étape ne peut pas être simplement annulée. Pour un cycle manuel, il faut ouvrir la source et sélectionner Synchronize, puis vérifier l’état, l’heure et les modifications des objets.

Planifier le Self Service et les Shared Mailboxes avant la synchronisation

Si un utilisateur doit employer le Self Service Portal, User Access doit être activé avant le premier Directory Sync. Central peut ainsi envoyer les invitations selon le processus prévu. L’activation ultérieure de l’accès ne corrige pas automatiquement tous les envois manqués. Les utilisateurs pilotes, la remise des e-mails et l’accès au portail doivent donc être testés avant l’import à grande échelle.

Dans Central, les Shared Mailboxes ne possèdent pas nécessairement tous les attributs d’un utilisateur. Les utilisateurs délégués obtiennent l’accès Self Service pour la Shared Mailbox qui leur est attribuée et y voient, selon le produit sous licence, par exemple Emergency Inbox et Quarantine Summary. Un Delegate peut ainsi recevoir des résumés pour sa propre boîte aux lettres et pour la Shared Mailbox. Après le Sync, les délégations et adresses de remise doivent donc être testées en pratique, et non validées uniquement à partir du nombre d’objets.

Une Shared Mailbox appartenant à un groupe Microsoft 365 ne peut pas être synchronisée depuis l’AD local. Microsoft Entra ID ou Google Directory doit être utilisé. Une Shared Mailbox normale située hors d’un groupe Microsoft 365 peut être importée par AD Sync. Avant une migration ultérieure vers Entra ID, il faut inventorier de quel type d’objet provient chaque boîte aux lettres. Sinon, la poursuite d’AD Sync après le changement de source peut supprimer des boîtes aux lettres ou les conserver avec des données obsolètes.

Avant le premier Sync

Il faut d’abord déterminer quel annuaire fait autorité pour quels utilisateurs et groupes. Les mêmes personnes ne doivent pas être créées simultanément de façon manuelle, depuis AD et depuis Entra ID.

Pour le premier cycle, il est recommandé d’utiliser une petite OU de test contenant des utilisateurs et groupes représentatifs. Les points suivants sont vérifiés :

• adresses e-mail et User Principal Names,
• groupes imbriqués et appartenances,
• comptes désactivés ou obsolètes,
• comptes de service et comptes techniques,
• conflits de noms avec des objets Central existants.

Chaque utilisateur à synchroniser doit posséder une adresse e-mail unique. De nombreux processus Central l’utilisent comme identité et comme destination. Avec Sophos Email, un message envoyé à une adresse sans utilisateur associé peut même être impossible à remettre. En outre, le firewall ou le proxy doit pouvoir joindre les domaines et ports documentés pour Central. Un test LDAP réussi ne confirme pas à lui seul ce chemin vers le cloud.

Installer AD Sync Utility

Le logiciel de synchronisation actuel est téléchargé directement depuis Sophos Central et installé sur un système Windows disponible en permanence. Ce système doit disposer d’un accès réseau au Domain Controller et aux services Sophos requis.

Le logiciel Active Directory Synchronization Setup actuel fonctionne uniquement sur un système Windows 64 bits et exige .NET Framework 4.6.2. Sophos répertorie Windows 7, 8.1, 10 et 11, ainsi que Windows Server 2008 R2, 2012, 2012 R2, 2016, 2019, 2022 et 2025. Pour le Domain Controller, Sophos mentionne Windows Server 2008 R2 à 2025. Cette compatibilité du fabricant ne remplace pas le cycle de vie Microsoft. Une nouvelle installation de production doit utiliser un système d’exploitation serveur actuellement pris en charge et corrigé, et non Windows 7 ou une version de Windows Server arrivée en fin de vie.

L’accès à Central utilise des API Credentials avec le rôle Service Principal Active Directory Sync, pas des Super Admin Credentials génériques.

Le compte de service AD utilisé reçoit uniquement les droits nécessaires pour lire les Forests et objets d’annuaire sélectionnés. L’expiration du mot de passe, le démarrage du service et la responsabilité sont documentés. Un compte administrateur personnel ne convient pas.

Utility ne peut pas traiter un domaine si un composant de son nom comporte plus de 63 caractères ou commence ou se termine par - ou _. Cette limite doit être vérifiée avant l’installation, car un Display Name raccourci ou un autre UPN ne corrige pas un nom de domaine AD non valide.

Sophos a testé jusqu’à 30'000 objets AD. Au-delà de 40'000 entrées utilisateur, l’interface peut réagir plus lentement. Les grands environnements sont donc filtrés avec une rigueur particulière et testés avec des durées réalistes.

À chaque cycle de synchronisation, Utility vérifie si une version plus récente est disponible et effectue normalement les mises à niveau suivantes automatiquement. Les premières versions d’AD Sync ne prennent plus en charge l’authentification Central actuelle et peuvent échouer entièrement si cette mise à niveau automatique ne fonctionne pas. Dans ce cas, il faut télécharger l’Installer actuel sous Global Settings > Platform > Directory service et l’exécuter par-dessus l’installation existante. Ensuite, de nouveaux API Credentials sont créés avec le rôle Service Principal Active Directory Sync et enregistrés dans Utility comme Client ID et Client Secret. Chaque instance Sync de production reçoit une identité technique traçable, une responsabilité documentée et sa propre rotation des secrets.

Au démarrage, le Client ID et le Client Secret sont vérifiés avec Validate credentials. Si Utility doit communiquer par l’intermédiaire d’un proxy, il faut activer Configure proxy manually et saisir l’adresse du proxy. Si le proxy exige une authentification, il faut en plus renseigner Enable proxy authentication, l’utilisateur du proxy et son mot de passe. Seul un deuxième test réussi des Credentials confirme que les données API et le chemin par le proxy fonctionnent.

Cette interface de proxy appartient à Active Directory Synchronization Setup 4.0. Un tenant Trial peut encore recevoir l’ancienne version Sophos Central AD Sync Utility 3.5.4, qui ne permet pas de saisir les données du proxy dans l’interface. Par défaut, le service s’exécute comme Local Service et échoue souvent avec un proxy authentifiant en affichant Failed active directory synchronization, une System.Net.Http.HttpRequestException et CommandLib.HttpRequestCommand+HttpStatusException. Un autre compte de service utilisé à cette fin nécessite Log on as a service, les ouvertures de session interactive et Batch, des droits de lecture sur les OU concernées et un contrôle total sur C:\ProgramData\Sophos\Sophos Cloud AD Sync. Après chaque changement de ce compte de service, l’ancienne Utility doit être reconfigurée. Dans la mesure du possible, la version 4.0 actuelle doit être utilisée pour les environnements de production.

Pour l’accès LDAP, un compte en lecture est utilisé pour l’ensemble du Forest sélectionné. Use LDAP over an SSL connection reste activé dans la mesure du possible. LDAPS utilise généralement TCP 636 et LDAP non chiffré TCP 389. En raison de LDAP Signing et de Channel Binding, le port 389 ne constitue pas une solution de repli fiable dans les environnements Active Directory actuels. Pour LDAPS, le Domain Controller doit disposer d’un certificat valide et approuvé par le système Sync.

S’il est démontré que l’environnement LDAP concerné ne prend pas en charge SSL, Use Secure LDAP peut être désactivé et le port adapté au service LDAP non chiffré. Il s’agit d’une solution de repli documentée, et non d’une Best Practice. Les Credentials et les données d’annuaire ne sont alors pas protégés par TLS pendant le transport. La segmentation, le chemin réseau et le passage rapide à LDAPS doivent donc être traités comme un risque.

Ce qu’Utility attend dans le Forest

Pour un Forest complet, AD Sync lit à la racine de l’arborescence d’annuaire rootDomainNamingContext avec le Distinguished Name du Forest Root Domain et defaultNamingContext avec le Distinguished Name du serveur utilisé. Sous CN=Partitions,CN=Configuration,<rootDomainNamingContext>, Utility attend pour les Naming Contexts pertinents des entrées contenant netBiosName, dnsRoot et nCName. La valeur de nCName détermine les zones de recherche supplémentaires, à moins qu’elle ne soit un Distinguished Name parent du serveur indiqué dans l’interface Setup.

Si l’un de ces attributs est absent ou si le compte de service ne peut pas lire la Configuration Partition, un test Login peut fonctionner alors que la détection du Forest ou le Sync ultérieur échoue quand même. Dans ce cas, les valeurs sont vérifiées avec LDP.exe sous le même compte de service avant toute modification des filtres ou des objets Central.

Filtrer les OU et les objets

Les filtres limitent l’étendue de la synchronisation. Seuls les OU, utilisateurs et groupes réellement nécessaires à Sophos Central sont inclus. Un import étendu depuis la racine est rarement pertinent.

Avant l’import, l’aperçu indique quels objets seraient ajoutés, modifiés ou supprimés. Les suppressions, en particulier, ne sont jamais validées sans contrôle. La vue Preview ou Pending Changes peut ne pas afficher correctement les caractères UTF-16 ou Double-Byte et présenter par exemple ??? à leur place. Les données sont néanmoins transmises à Sophos Central et y sont affichées. Les noms en chinois, japonais ou coréen, par exemple, doivent donc aussi être contrôlés directement dans Active Directory, puis dans Central après un Pilot Sync maîtrisé.

Sophos qualifie ce problème d’aperçu de limitation qui doit être corrigée dans une future version d’AD Sync Utility. Tant que la version utilisée ne corrige pas ce comportement de manière avérée, le contrôle dans l’annuaire source et après le Sync reste nécessaire.

Base DN et LDAP filter remplissent deux fonctions différentes. Base DN limite la recherche aux OU sélectionnées. L’appartenance à une OU ne peut pas être exprimée de manière fiable dans Active Directory par un simple filtre LDAP. LDAP filter restreint les attributs ou appartenances aux groupes au sein de cet espace de recherche. Les deux filtres sont gérés par domaine, car les Child Domains n’héritent pas du paramètre de leur Parent Domain. Les filtres d’utilisateurs et de groupes fonctionnent également indépendamment.

Dans l’onglet AD Filters, les Search Bases et LDAP Query Filters sont enregistrés séparément pour chaque domaine et, si nécessaire, séparément pour les utilisateurs et les groupes. Une Search Base pour une OU Finance peut par exemple prendre la forme suivante :

OU=Finance,DC=myCompany,DC=com

Un filtre utilisateur pour les membres d’un groupe peut par exemple être :

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

Sans filtre de groupe supplémentaire, Central continue à découvrir tous les groupes auxquels ces utilisateurs appartiennent. Si la sélection des groupes doit également être limitée à ce seul groupe, un filtre de groupe comme CN=testGroup doit être ajouté. Une modification de filtre peut faire sortir du périmètre des utilisateurs et groupes précédemment synchronisés et les supprimer de Central. Un aperçu complet doit donc toujours suivre.

Sophos utilise les filtres suivants comme point de départ :

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

Le filtre utilisateur sélectionne les personnes avec la classe user, mais exclut les objets ordinateur au moyen de sAMAccountType=805306370 et les comptes désactivés au moyen du bit userAccountControl correspondant. Les filtres supplémentaires sont combinés avec ces conditions de base pour chaque domaine et testés d’abord avec LDP.exe.

Sophos limite la configuration à 1'000 filtres par objet d’annuaire et à 5'000 caractères par filtre LDAP supplémentaire. Les utilisateurs ne peuvent être synchronisés qu’avec les groupes d’utilisateurs, et les appareils qu’avec les groupes d’appareils. Pour les groupes multidomaines, l’aperçu affiche tous les membres, mais Central importe uniquement les utilisateurs du domaine auquel le groupe appartient. Ces groupes doivent donc être testés explicitement avant le Sync de production.

Le résultat attendu est contrôlé avec Microsoft LDP.exe : Search Base d’AD Sync correspond à Base DN, et l’expression LDAP d’AD Sync à Filter. Cela permet de distinguer un objet omis par Sophos d’un objet déjà absent de la requête d’annuaire. Certaines comparaisons d’attributs peuvent être sensibles à la casse.

Les filtres utilisant lastLogon ou lastLogonTimestamp sont employés avec prudence. lastLogon est généralement plus récent, mais il n’est pas répliqué entre les Domain Controllers. Il faudrait donc interroger tous les Domain Controllers pour obtenir une valeur fiable. lastLogonTimestamp est répliqué, mais peut être obsolète. Sophos recommande de supprimer les comptes et appareils inactifs à la source plutôt que de se fier uniquement à un filtre temporel.

Si lastLogonTimestamp doit néanmoins servir de filtre transitoire, une date limite UTC est d’abord définie, puis convertie en Windows FILETIME avec un convertisseur LDAP ou Active Directory fiable. L’exemple Sophos du 1er décembre 2020 à 00 h 01 donne 132581431640000000. Dans le champ Custom Filters sous Active Directory Synchronization Setup > AD Filters, il faut saisir l’expression LDAP supplémentaire :

(lastLogonTimestamp>=132581431640000000)

La valeur d’exemple ne doit pas être reprise telle quelle. La date limite doit être choisie consciemment, convertie correctement et documentée avec le fuseau horaire et la validation du changement. Il faut ensuite effectuer Preview and Sync, contrôler les utilisateurs inclus et exclus, puis seulement autoriser le cycle de production.

AD Sync crée uniquement les groupes comptant plus d’un membre. Un groupe vide ou qui ne compte qu’un seul membre n’apparaît donc pas comme objet Central attendu. Les utilisateurs ou adresses e-mail en double dans plusieurs Forests ne sont pas fusionnés. La source d’un objet peut ainsi changer entre les cycles. Dans la mesure du possible, un Forest n’est donc synchronisé qu’avec un seul tenant Central.

Exclude disabled user accounts est activé par défaut. Cette option doit rester activée pour la synchronisation des Shared Mailboxes. Si elle est désactivée, Central peut créer des objets boîte aux lettres en double pour les Shared Mailboxes. Indépendamment de cela, les comptes utilisateur normaux désactivés doivent être nettoyés à la source et ne pas être réintroduits par un Sync plus large.

Les commutateurs des types de données ont des dépendances précises :

• Sync users and user groups synchronise les deux ensemble et inclut également les Shared Mailboxes normales. Si ce commutateur est désactivé, ni les Shared Mailboxes ni les Public Folders ne peuvent être synchronisés par cette source AD.
• Sync public folders nécessite en plus Sync users and user groups, car les Public Folders sont traités comme des objets boîte aux lettres.
• Pour les appareils, Sync devices et Sync organizational units sont activés ensemble en fonctionnement normal. Lors de la configuration initiale, seules les OU peuvent être importées dans un premier temps afin que les policies soient prêtes avant les appareils.
• Si seule l’option Sync organizational units est désactivée ultérieurement, les appareils restent actifs, mais les OU précédentes apparaissent comme Custom Groups. Si seule la synchronisation des OU reste active, les appareils ne sont plus associés aux groupes Central.

Sans groupes d’OU préparés, les appareils nouvellement synchronisés reçoivent d’abord les Default Policies. Après le pilote OU, les deux commutateurs d’appareils sont donc activés ensemble, puis l’association et la policy réellement appliquée sont contrôlées.

Pour les très grands groupes, l’attribut AD member est également important. À partir de 1'500 entrées, Active Directory utilise Range Retrieval, par exemple member;range=0-1499, et vide l’attribut simple member. Un groupe qui comptait déjà plus de 1'500 objets avant le premier Sync peut donc manquer dans Central ou afficher un nombre de membres incorrect. Dans la mesure du possible, ces groupes sont limités à moins de 1'500 objets utilisateur et contrôlés avec LDP.exe.

Mise en correspondance des utilisateurs et alias d’e-mail

Central compare les utilisateurs AD aux utilisateurs existants au moyen du Domain Login au format DOMAIN\user ou de l’attribut mail. Le Display Name provient de Display name et les alias d’e-mail supplémentaires de proxyAddresses. En cas de correspondance, l’objet Central existant devient un objet administré par l’annuaire. Sans correspondance, un nouvel utilisateur est créé. Preview and Sync affiche les correspondances sous Users to Modify et les nouveaux objets sous Users to Add.

Lorsqu’un objet synchronisé par un autre Directory Service correspond, il n’est pas créé comme deuxième utilisateur, mais peut être complété avec une adresse e-mail issue d’AD. En revanche, un utilisateur créé manuellement et un utilisateur AD portant le même nom peuvent rester deux objets distincts si le Login et l’e-mail ne correspondent pas. Le Display Name seul n’est pas une clé de correspondance.

Dans Preview and Sync, les correspondances sous Users to Modify et les nouvelles identités sous Users to Add sont contrôlées individuellement. Une attribution incorrecte doit être refusée au lieu d’accepter l’ensemble de la proposition avec Approve Changes and Continue. Le passage d’un utilisateur manuel à un objet administré par AD est également visible à l’icône d’annuaire.

Lorsqu’un utilisateur est supprimé dans AD, le comportement de Central dépend de ses dépendances. Les administrateurs ainsi que les utilisateurs associés à un appareil ou à un Login restent des utilisateurs Central normaux. En revanche, un utilisateur sans appareil, Login ni rôle privilégié peut être supprimé automatiquement. Pour la même raison de protection, les modifications d’e-mail d’un administrateur Central ne sont pas reprises aveuglément depuis AD. Les Admin Roles et les associations aux appareils doivent donc être contrôlées séparément avant un Offboarding.

Pour modifier l’adresse e-mail principale d’un administrateur géré par l’annuaire ou supprimer son objet Central resté après sa suppression d’AD, son Admin Role doit être retiré de manière contrôlée avant le prochain Sync. Après la synchronisation, le rôle requis peut être réattribué. Cette opération prévoit toujours un deuxième Super Admin fonctionnel comme solution de récupération.

Nom incorrect en raison de Logins qui se chevauchent

Si l’utilisateur A possède par erreur également le Login appareil de l’utilisateur B, AD Sync peut d’abord attribuer les deux Logins à A, puis renommer l’enregistrement existant en B lors du traitement ultérieur de B. Dans l’utilisateur Central concerné, il faut donc supprimer toutes les associations étrangères sous Logins, puis relancer la synchronisation. Les noms ne doivent pas simplement être réécrits tant que le mauvais Login subsiste.

Impossible d’attribuer un rôle à un utilisateur AD

Il faut d’abord rechercher l’adresse e-mail sous My Environment > Users & Groups > Users. En cas de doublons, les Logins des objets à ne pas utiliser sont documentés, supprimés au moyen de Edit logins, puis ajoutés au bon utilisateur. Ce n’est qu’ensuite que le rôle est enregistré et que l’envoi du Setup est vérifié. Si l’adresse e-mail reste bloquée à l’échelle du tenant, il ne faut pas poursuivre les suppressions, mais résoudre le conflit par l’intermédiaire du Support.

Interpréter correctement les groupes imbriqués

En plus du groupe AD direct, la page de l’utilisateur peut afficher des groupes parents imbriqués comme linked groups. Cela ne fait pas automatiquement de l’utilisateur un membre direct de chaque groupe affiché. Pour analyser les autorisations et les policies, il faut contrôler séparément l’appartenance AD directe, l’imbrication et la policy Central réellement appliquée.

Associer un Login Mac à l’utilisateur synchronisé

AD Sync importe un Login sous la forme NETBIOSDOMAIN\user, tandis qu’un Mac le transmet souvent sous la forme MACNAME\user. Central peut alors créer automatiquement un deuxième objet utilisateur. Après contrôle des appareils concernés, cet objet doit être nettoyé et MACNAME\user associé à l’utilisateur synchronisé depuis AD. Pour un déploiement plus large, il convient de tester le Domain Override prévu par Sophos plutôt que d’effectuer une correction manuelle.

Synchroniser les ordinateurs et les groupes d’OU

La détection des appareils prend en charge les ordinateurs et serveurs Windows. Sophos associe un appareil protégé à l’objet AD au moyen du FQDN et du Hostname, puis le déplace dans le groupe d’OU synchronisé. Un ordinateur auparavant regroupé manuellement peut ainsi revenir dans la structure AD au prochain Sync.

Un nouvel objet appareil ou groupe est créé lorsque Central ne connaît encore aucune entrée avec la même ObjectGUID AD. Si le nom d’un nouveau groupe AD entre en conflit avec un groupe existant, Central utilise le Distinguished Name pour le nouveau groupe. Plusieurs enregistrements AD avec le même DN ne sont pas pris en charge.

Pour la mise en correspondance, le FQDN et le Hostname doivent correspondre. Si un appareil Central possède le domaine et le Hostname corrects, mais que ses détails enregistrés diffèrent, le Sync actualise ces informations et déplace l’appareil vers le groupe AD approprié. Si deux appareils possèdent le même FQDN, l’objet appareil précédemment associé est dissocié et le nouvel enregistrement est relié. Les Hostnames en double doivent donc être nettoyés avant le Sync au lieu de considérer la nouvelle association qui en résulte comme une perte aléatoire d’appareil.

Les OU sont synchronisées avant les appareils afin que les policies puissent d’abord être préparées dans les groupes prévus. Les appareils et groupes synchronisés ne peuvent pas être réorganisés durablement dans Central à l’encontre de la structure AD. Une hiérarchie de plus de 40 niveaux est fusionnée à partir du niveau 40.

Les appareils et groupes synchronisés peuvent être déplacés ou supprimés dans Central, mais pas modifiés comme des objets locaux. Ces modifications manuelles ne sont pas durables. Le prochain Sync restaure la structure AD ou recrée l’objet. Si un appareil protégé est supprimé dans AD, Central le déplace lors du prochain cycle vers un groupe non structuré et retire son marquage d’appareil administré par AD. Les modifications apportées aux noms, aux informations du système d’exploitation ou à la structure des OU sont également reprises au prochain Sync, y compris les déplacements et suppressions de groupes.

Les policies des groupes créés manuellement sont conservées. Toutefois, les appareils administrés par AD sont déplacés de ces groupes vers le groupe synchronisé et y reçoivent d’abord les Default Policies si aucune policy appropriée n’a été attribuée au préalable. Une policy d’un groupe Top-Level est héritée par un groupe imbriqué tant qu’aucune policy propre n’y est attribuée. Il faut donc synchroniser les OU, attribuer les policies, puis seulement importer les appareils.

Sophos ne fournit actuellement aucune API pour les Directory Devices et Device Groups synchronisés depuis AD. Les automatisations ne doivent donc pas supposer que cette structure peut être administrée entièrement par API comme les groupes Central normaux.

Sous My Environment > Unmanaged devices, les ordinateurs et serveurs connus d’AD dépourvus de Sophos Agent apparaissent dans des vues distinctes. Les packages de protection requis sont disponibles sous My Environment > Installers. Cette vue d’inventaire n’installe toutefois aucune protection. Chaque appareil attendu reste dans le processus de Rollout ou d’exception jusqu’à l’installation de l’agent ou l’approbation d’une exception documentée.

Calendrier et surveillance

Le calendrier Sync doit correspondre au rythme des changements dans l’entreprise. Après chaque cycle, l’état, les erreurs et les modifications d’objets sont contrôlés. Un service démarré avec succès ne prouve pas que tous les objets ont été correctement synchronisés.

Les avertissements relatifs aux Credentials, à la connexion, aux attributs manquants ou aux conflits d’objets sont corrigés rapidement. L’exploitation nécessite un propriétaire et un remplaçant.

Lors du premier cycle et après chaque modification de filtre, Preview and Sync est lancé manuellement. L’aperçu est contrôlé pour les objets nouveaux, modifiés et à supprimer, puis seulement confirmé avec Approve Changes and Continue. Un cycle manuel peut durer jusqu’à 15 minutes. Pour n’effectuer que des cycles manuels contrôlés, il faut sélectionner Never. Only sync when manually initiated dans le calendrier.

Les Runtime Logs se trouvent sous :

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

Ils tournent sur sept fichiers quotidiens. Un Log nécessaire à l’analyse est donc copié ou renommé avant la rotation suivante. Un Email Alert Medium ne contient souvent que le résumé. La cause concrète doit être recherchée dans le Log de la même période.

Lors du remplacement du serveur AD Sync, une deuxième instance non contrôlée ne doit jamais fonctionner en parallèle. Le calendrier est d’abord arrêté sur l’ancien serveur. Ensuite, Utility actuelle est configurée sur le nouveau serveur, la configuration de filtre existante est comparée et vérifiée avec Preview and Sync. Le calendrier n’y est activé et l’ancienne installation supprimée qu’après un cycle manuel réussi.

Suppression et reconstruction

La suppression d’un objet dans l’annuaire source ou son retrait du filtre peut avoir des conséquences sur l’objet Central correspondant et sur l’attribution de ses policies. Avant une modification massive, les actions annoncées dans l’interface sont lues et documentées.

La suppression de la configuration Sync ou des données synchronisées n’est pas une étape normale de Troubleshooting. Il faut d’abord vérifier l’association des appareils, l’appartenance aux groupes et les doublons éventuels. Une reconstruction sans analyse peut recréer les mêmes problèmes.

Avant Purge data, toutes les instances AD Sync actives ou copiées sont arrêtées et les filtres sont contrôlés, sinon les données réapparaissent. Le Purge est irréversible. Les appareils administrés et les utilisateurs qui leur sont associés, ainsi que les administrateurs, ne sont pas supprimés même s’ils proviennent initialement d’AD.

Purger les données AD synchronisées

La procédure commence sous Global Settings > Platform > Directory service. Il faut y ouvrir le nom de la source AD, l’arrêter avec Turn off, puis sélectionner Purge data. Dans la boîte de dialogue, l’étendue des données à supprimer est choisie consciemment :

• Users and user groups supprime également les Shared Mailboxes et Public Folders synchronisés.
• Devices and device groups supprime les appareils et groupes synchronisés, à l’exception des objets protégés mentionnés par Sophos.

Après confirmation du caractère irréversible, il faut sélectionner une nouvelle fois Purge data. Central supprime les objets sélectionnés et ne synchronise plus ce type de données depuis la source arrêtée. Si toutes les données AD ont été supprimées, les utilisateurs, appareils et groupes doivent désormais être administrés manuellement ou par une nouvelle source clairement délimitée. Microsoft Entra ID peut par exemple prendre le relais pour les utilisateurs et groupes d’utilisateurs.

Avant le Purge, toutes les copies d’AD Sync Utility et leurs calendriers sont recherchés et arrêtés. Les filtres seuls n’empêchent pas le retour des données si une deuxième instance continue à synchroniser. Après l’opération, les administrateurs restants ainsi que les appareils administrés et leurs utilisateurs associés doivent être contrôlés, car Central ne supprime pas ces exceptions.

Passer d’AD à Microsoft Entra ID

Sophos permet de transférer la synchronisation des utilisateurs et groupes d’un domaine d’AD vers Entra ID. Avant cela, une source AD et une source Entra appropriées doivent exister pour le même domaine, et les utilisateurs des deux sources doivent correspondre de manière fiable. Les utilisateurs AD sans correspondance peuvent être supprimés de Central lors du changement.

Entra ID ne synchronise ni les ordinateurs ni les groupes d’ordinateurs. S’ils restent nécessaires, AD demeure actif pour les appareils, tandis qu’Entra ID fournit les utilisateurs et groupes d’utilisateurs du même domaine. Les Public Folders et les associations existantes de Shared Mailboxes présentent d’autres restrictions qui doivent être vérifiées séparément avant la migration.

La migration commence par une liste d’exportation et de comparaison, et non directement par le changement de source. Si les utilisateurs correspondent entre AD et Entra ID, Central actualise l’objet existant et conserve les boîtes aux lettres associées. Les utilisateurs sans correspondance peuvent être supprimés avec leur association de boîte aux lettres. Les nouveaux utilisateurs Entra sont créés. Les groupes d’utilisateurs sans correspondance restent certes présents, mais ne sont plus actualisés.

Les Shared Mailboxes et les Public Folders nécessitent une attention particulière. Central conserve les Shared Mailboxes AD existantes avec le dernier état des données AD, mais AD ne les actualise plus. De nouvelles Shared Mailboxes Entra peuvent apparaître en plus. Les Public Folders restent également présents avec leur dernier état. Si l’ancienne synchronisation AD On-Premises continue à être utilisée pour ces objets après la migration, les Shared Mailboxes peuvent être supprimées de manière inattendue en raison des différents types d’objets.

Après la migration, il faut contrôler les utilisateurs, groupes, policies, associations d’appareils, Shared Mailboxes, Public Folders et doublons. Si AD reste actif pour les appareils, Sync devices et Sync organizational units continuent à y être utilisés ensemble.

Prérequis et décision de migration

AD et Entra ID doivent représenter le même domaine. Avant le changement, les utilisateurs sont comparés au moyen d’adresses e-mail uniques et d’autres caractéristiques d’identité correspondantes afin que Central actualise les comptes existants au lieu de les supprimer et de les recréer. Le connecteur Entra et ses App Permissions doivent être entièrement préparés avant la désactivation de la source AD.

Les Public Folders ainsi que les ordinateurs et groupes d’ordinateurs proviennent toujours uniquement d’AD. Pour chaque domaine, il faut donc décider si Entra ID seul suffit ou si AD doit continuer à fonctionner en parallèle pour les appareils et les structures d’OU. Les Shared Mailboxes sont en outre inventoriées séparément selon qu’elles proviennent d’objets AD, Entra ou de groupes Microsoft 365.

Utiliser uniquement Microsoft Entra ID

Cette solution convient lorsque Central ne doit plus actualiser les appareils, les groupes d’appareils ni les Public Folders depuis l’AD local.

1. Effectuer le dernier AD Sync et contrôler les utilisateurs, groupes, boîtes aux lettres et erreurs.
2. Sous Global Settings > Platform > Directory service, ouvrir la source AD et la désactiver avec Turn off.
3. Configurer la source Entra pour le même domaine avec Add Microsoft Entra ID et accorder les App Permissions requises.
4. Démarrer la synchronisation Entra et contrôler les utilisateurs, groupes et Shared Mailboxes par rapport à la liste d’exportation et de comparaison.
5. Une fois seulement la validation terminée, désinstaller le logiciel local AD Sync Setup et révoquer ses API Credentials après un contrôle documenté.

La désactivation de l’ancienne source est une migration contrôlée, et non une réinitialisation de Troubleshooting. En cas de suppressions inattendues, il ne faut pas continuer la synchronisation en activant et désactivant plusieurs fois la source, mais d’abord analyser le rapport de correspondance.

Utiliser Microsoft Entra ID et AD en parallèle

Cette variante utilise Entra ID pour les utilisateurs, les groupes d’utilisateurs et les Shared Mailboxes modernes, tandis qu’AD fournit les appareils et les groupes d’appareils.

1. Exécuter entièrement l’AD Sync existant et valider l’état initial.
2. Dans AD Sync Utility, limiter la sélection à Sync devices et Sync organizational units. À l’avenir, les utilisateurs et groupes d’utilisateurs ne seront plus fournis par AD.
3. Désactiver temporairement la source AD dans Central avec Turn off.
4. Ajouter Microsoft Entra ID pour le même domaine, synchroniser, puis valider les utilisateurs, groupes et Shared Mailboxes.
5. Réactiver la source AD avec Turn on, lancer une synchronisation manuelle et vérifier que les appareils et groupes d’appareils continuent à être actualisés sans réimporter les utilisateurs depuis AD.

Les deux sources reçoivent chacune leurs propres propriétaires, calendriers et critères de validation. Un état vert pour les deux connecteurs ne prouve pas encore que leurs périmètres d’objets sont correctement séparés.

Conséquences pour les utilisateurs, groupes, boîtes aux lettres et appareils

Pour les utilisateurs correspondants, Entra ID actualise l’objet Central existant et les informations de boîte aux lettres associées sont conservées. Un utilisateur AD sans enregistrement Entra correspondant peut être supprimé de Central avec son association de boîte aux lettres. Les nouveaux utilisateurs Entra sont créés comme nouveaux utilisateurs Central avec les données de boîte aux lettres disponibles.

Les groupes d’utilisateurs correspondants sont actualisés. Les groupes AD sans équivalent Entra restent visibles dans Central, mais ne reçoivent plus de modifications d’AD. De nouveaux groupes Entra sont créés. Ces groupes restés en place ne prouvent pas que la synchronisation fonctionne encore. Les attributions de policies et les appartenances doivent donc être contrôlées séparément.

Les Shared Mailboxes et Public Folders existants, précédemment fournis par AD, restent présents avec le dernier état des données AD, mais ne sont plus actualisés. Ces Shared Mailboxes continuent à apparaître sous Mailboxes, mais peuvent ne plus avoir d’utilisateurs associés après le changement. Les nouvelles Shared Mailboxes Entra peuvent apparaître à la fois comme objet utilisateur et sous Mailboxes, et arriver également sans l’association Delegate connue dans AD. Les accès délégués et les Quarantine Summaries doivent donc être revalidés. Si l’ancienne synchronisation AD continue à fonctionner sans contrôle après la migration, les différents types d’objets peuvent supprimer des Shared Mailboxes existantes.

Dans le modèle Entra-only, les appareils et groupes d’appareils AD existants restent d’abord présents dans Central, mais ne sont plus actualisés depuis l’annuaire. Dans le modèle parallèle, AD continue à synchroniser ces objets. Entra ID lui-même ne fournit ni ordinateurs, ni groupes d’ordinateurs, ni Public Folders. Cet effet doit être explicitement documenté dans la décision de migration afin qu’un inventaire resté en place ne soit pas interprété à tort comme une synchronisation actuelle.

Transférer des endpoints existants vers un nouveau domaine AD

Si seul le domaine AD change, tandis que le nom de l’ordinateur et le SID restent identiques, il n’est pas nécessaire de réinstaller le Sophos Agent. Sa machine_id reste inchangée. Il faut d’abord adapter la configuration AD Sync au nouveau domaine sous Global Settings > Platform > Directory service, valider les Credentials et synchroniser les utilisateurs, groupes, OU et appareils. Les endpoints peuvent ensuite se connecter à Central.

Avec le nouveau FQDN, Central dissocie l’ancienne association AD et recherche l’objet appareil correspondant dans le nouveau domaine. En cas de correspondance, le même objet Endpoint est relié de nouveau et, si la synchronisation des OU est active, déplacé vers le bon groupe. En revanche, les Logins utilisateur passent par exemple de OLDDOMAIN\jsmith à NEWDOMAIN\jsmith et peuvent créer des doublons.

La validation contrôle le nouveau domaine, le groupe d’OU, les policies appliquées et l’association utilisateur. Ce n’est qu’ensuite que les objets appareil, utilisateur, groupe ou Directory obsolètes de l’ancien domaine sont supprimés.

Problèmes fréquents

Un utilisateur apparaît en double

Comparer les sources, l’adresse e-mail, l’UPN et les objets manuels existants. Ne pas supprimer précipitamment l’un des objets tant que des appareils ou des policies y sont associés.

Un nouveau groupe est absent

Vérifier les filtres d’OU et de groupes, les appartenances imbriquées, la dernière synchronisation réussie et les attributs d’annuaire.

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

Cette erreur se produit généralement lorsqu’un Custom Filter fait encore référence à une OU qui a entre-temps été supprimée d’Active Directory. Le message d’erreur ne mentionne pas le nom de l’OU supprimée. Sous Define Filters, il faut donc vérifier tous les filtres AD par rapport à la structure actuelle de l’annuaire et supprimer uniquement les références à des objets qui n’existent plus. Un nouveau cycle Preview et le contrôle des suppressions prévues suivent ensuite.

0xFFFE ou 0xFFFF dans Preview and Sync

Si Active Directory contient des caractères dont les valeurs hexadécimales non valides sont 0xFFFE ou 0xFFFF, le cycle manuel peut échouer à l’étape Preview and Sync. Il faut d’abord rechercher l’attribut source concerné et le corriger à la source. Si cela n’est pas possible à court terme, Sophos indique Sync on Schedule - automatic (within next 2-3 minutes) comme solution de contournement ciblée, car ce cycle ignore l’aperçu. Il ne s’agit pas d’un nettoyage durable. L’étendue, le résultat et les objets nouveaux et supprimés doivent être contrôlés immédiatement après dans Central et dans le Log.

endpoint_user_sessions.user_match_id lors de la suppression d’un Login

Error syncing record: Error deleting login, accompagné d’une indication de Foreign Key sur endpoint_user_sessions.user_match_id, peut apparaître lorsqu’AD a supprimé ou désactivé un utilisateur, mais que Central ne peut pas supprimer le Login associé en raison d’une session existante. Le reste du Sync se poursuit et peut se terminer avec succès. Si l’entrée se répète, l’utilisateur, le Login et l’heure doivent être documentés, puis Sophos Support sollicité pour effectuer le nettoyage dans Central. Un Purge ou une reconstruction de l’ensemble du Sync serait disproportionné.

La synchronisation reste obsolète

Contrôler le service Windows, le compte de service, le mot de passe, DNS, le proxy, les règles du firewall et l’état Central Sync. Pour un ticket Support, joindre les Sync Logs et les horodatages.

Depuis AD Sync Client 5.x, l’Audit Log n’affiche plus le Client ID des API Credentials comme Modified by pour les actions Directory Sync, mais la GUID du client AD Sync enregistré auprès de Sophos. Cela vaut pour les actions Create, Update et Delete. Une GUID n’indique donc pas automatiquement un attaquant inconnu. Elle doit être corrélée avec l’instance Sync, le calendrier et l’horodatage du Log.

Les Credentials LDAP sont demandés sans cesse

NeedADCredsException avec The LDAP server is unavailable ne signifie pas forcément que le mot de passe est incorrect. Il faut contrôler le Domain Controller, le format du compte DOMAIN\username, les droits de lecture et le port choisi. Pour LDAPS, TCP 636 est prévu par défaut et le Domain Controller doit réellement y présenter un certificat approuvé. Un port à l’écoute ne prouve pas une configuration TLS fonctionnelle.

Escalade vers Sophos Support

Un cas reproductible contient la description de l’erreur, le tenant et la licence, la période exacte, la version AD Sync, tous les Logs, les captures d’écran pertinentes et l’IP publique du système au moment de la collecte. Les cas Partner exigent également l’attribution correcte du client MSP. Remote Assistance n’est activé que pour le cas concret et après validation interne.

Questions fréquentes