Active Directory mit Sophos Central synchronisieren

Sophos Central kann Benutzer und Gruppen aus einem lokalen Active Directory übernehmen. Diese Identitäten dienen unter anderem der Policy-Zuweisung und Gerätezuordnung. Eine unkontrollierte Synchronisation kann jedoch unnötige Konten, doppelte Objekte oder unerwartete Löschungen erzeugen.

Microsoft Entra ID wird über einen eigenen Connector synchronisiert. Die Anleitung dazu steht unter Microsoft Entra ID mit Sophos Central synchronisieren.

Quellenmodell vor der Installation festlegen

Central kann bis zu 25 Verzeichnisquellen pro Tenant verwalten. Für mehr Quellen ist eine Central-Enterprise-Struktur vorgesehen. Benutzer und E-Mail-Adressen müssen innerhalb eines Central-Tenants eindeutig bleiben. Dieselbe Domain darf nicht gleichzeitig über mehrere AD-, Entra-ID- oder Google-Directory-Quellen Benutzer liefern.

Bei einem Trial begrenzt Sophos zusätzlich die Zahl der Directory Objects, die erstellt oder verwendet werden können, darunter Benutzer, Geräte und Gruppen. Ein unvollständiger Testimport ist deshalb nicht automatisch ein Filterfehler. Vor einem Pilot werden Trial-Umfang, erwartete Objektzahl und Lizenzstatus gemeinsam geprüft.

Innerhalb eines Forests lassen sich mehrere Child Domains auswählen; ein Tenant kann auch mehrere Forests synchronisieren. Sophos empfiehlt trotzdem, jeden Forest nur mit einem Central-Tenant zu verbinden. Wird derselbe Forest in mehrere Tenants übernommen oder enthalten mehrere Forests dieselben Benutzer beziehungsweise E-Mail-Adressen, aktualisieren die Läufe dieselben scheinbaren Identitäten wechselweise. Central führt diese Datensätze nicht zusammen, wodurch Namen, Attribute und Gruppenzuordnungen inkonsistent werden können.

Eine unterstützte Mischform ist hingegen sinnvoll: AD synchronisiert Computer und Computergruppen, während Entra ID für dieselbe Domain Benutzer und Benutzergruppen liefert. Shared Mailboxes in einer Microsoft-365-Gruppe benötigen Entra ID oder Google Directory. Eine normale Shared Mailbox ausserhalb einer Microsoft-365-Gruppe kann über AD Sync übernommen werden.

Shared Mailboxes und Public Folders aus derselben Domain wie die Benutzer benötigen die AD Sync Utility zusammen mit Sync users and user groups. Microsoft-365-Gruppenmailboxen werden nicht per AD Sync übernommen. Eine Shared Mailbox ohne Delegate wird ebenfalls nicht synchronisiert. Bleibt ein inaktives Benutzerpostfach mit Maildelegation an ein aktives Postfach bestehen, löscht AD Sync es nicht, sondern kann es in Central als Shared Mailbox weiterführen.

Für dieselbe Domain oder Subdomain läuft nur ein produktiver AD-Sync-Client. Ausserdem dürfen nicht mehrere AD-Geräte denselben DNS-Hostnamen besitzen, weil Central diese Geräte sonst nicht eindeutig matchen kann. Beim Serverwechsel wird deshalb der alte Zeitplan gestoppt, bevor die neue Instanz produktiv synchronisiert.

Soll das Self Service Portal für Sophos Email, Device Encryption oder Mobile verwendet werden, wird der Benutzerzugriff vor dem ersten Directory Sync aktiviert. Dadurch erhalten neue und bestehende Benutzer die vorgesehene Einladung. Der Ablauf steht unter Sophos Central Self Service Portal Zugriff einrichten.

AD-Sync-Grenzen und domänenübergreifende Gruppen

AD Sync führt Daten aus mehreren Forests oder Directory Services nicht zu einem Masterdatensatz zusammen. Derselbe Benutzer oder dieselbe E-Mail-Adresse darf deshalb nicht in mehr als einem synchronisierten Forest vorkommen. Doppelte Benutzer, E-Mail-Adressen oder Gruppen können bei jedem Lauf abwechselnd mit den Angaben ihrer Quelle aktualisiert werden und sogar den in Central sichtbaren Directory Owner wechseln. Pro Tenant bleiben Benutzer und E-Mail-Adressen eindeutig; Benutzer derselben Domain dürfen nicht gleichzeitig aus AD und Entra ID synchronisiert und nicht parallel an mehrere Central Admin Accounts geliefert werden.

Bei einer Gruppe mit Mitgliedern aus mehreren Domains übernimmt Central nur Benutzer aus der Domain, zu der die Gruppe gehört. Preview and Sync kann zwar alle Mitglieder anzeigen, Benutzer aus der anderen Domain werden der Gruppe beim produktiven Sync aber nicht hinzugefügt. Dieses Verhalten wird bei Universal Groups und Child Domains mit einem Testmitglied pro Domain geprüft.

Benutzer und Benutzergruppen werden gemeinsam synchronisiert oder gemeinsam ausgeschaltet. Dasselbe gilt für Geräte und Gerätegruppen. Pro Directory Object sind höchstens 1'000 Filter vorgesehen; zusätzliche LDAP-Filter dürfen maximal 5'000 Zeichen lang sein. Domainbestandteile mit mehr als 63 Zeichen oder einem führenden beziehungsweise abschliessenden - oder _ werden nicht unterstützt.

Microsoft-365-Gruppenmailboxen benötigen Entra ID. AD Sync übernimmt keine Shared Mailbox ohne Delegate, nicht mehrere produktive AD-Sync-Clients derselben Domain oder Subdomain und keine mehreren AD-Geräte mit identischem DNS-Hostnamen. Ein inaktives Postfach mit Delegation an ein aktives Postfach kann dagegen als Shared Mailbox erhalten bleiben. Solche Grenzen werden vor dem ersten Lauf als Designentscheidung behandelt, nicht nachher mit breiteren Filtern umgangen.

Inaktive AD-Objekte vor dem Sync bereinigen

Inaktive Benutzerkonten und Geräte werden möglichst direkt im Active Directory geprüft und entfernt oder deaktiviert. Sie vergrössern nicht nur den Central-Bestand, sondern bleiben ein Sicherheitsrisiko in der Quelle. Eine Bereinigung verkleinert zudem die an Sophos Central übertragene Sync-Datei und kann den Lauf beschleunigen.

LDAP-Filter können verhindern, dass inaktive Benutzer nach Central gelangen, und ebenfalls die Sync-Datei reduzieren. Sie beheben jedoch nicht das Risiko eines weiterhin vorhandenen inaktiven AD-Kontos. Der Betriebsprozess kombiniert deshalb einen nachvollziehbaren Inaktivitätszeitraum, Owner-Freigabe, Quellbereinigung und anschliessenden Preview-Lauf. Geräte werden getrennt auf Alter, letzten Domainkontakt und Schutzstatus geprüft, bevor ein Computerkonto entfernt wird.

Directory Sources in Central verwalten

Die zentrale Übersicht liegt unter Global Settings > Platform > Directory service. Für das Einrichten und Verwalten einer Quelle ist eine passende Central-Adminrolle erforderlich. Die Seite bietet je nach gewünschter Quelle Add Active Directory, Add Microsoft Entra ID und Add directory service for Google. Für lokales AD wird von hier die aktuelle Setup-Software geladen; Entra ID und Google werden über ihre jeweiligen Cloud-Connectoren autorisiert.

Die Quellenliste zeigt pro Eintrag Name, Typ, Domain, Zeitplan und Status. Warnungen oder Fehler werden nicht nur in dieser Übersicht, sondern auch unter Alerts and Reports > Logs > General Logs > Events kontrolliert. Ein grüner Quellenstatus allein reicht nicht, wenn der letzte Lauf veraltet ist oder die erwartete Objektzahl nicht stimmt.

Ein Klick auf den Namen öffnet die Details. Bei AD werden insbesondere Anzahl Benutzer, Gruppen, Geräte, Gerätegruppen, Public Folders und Shared Mailboxes sowie Hostname, Clientversion, Domain, Status und Zeitpunkt des letzten Syncs geprüft. Bei Entra ID und Google stehen Benutzer- und Gruppenzahlen, Status, letzter Lauf und Zeitplan im Vordergrund. Diese Werte werden nach der Ersteinrichtung und nach jeder Filter- oder Quellenänderung gegen eine bekannte Referenzmenge verglichen.

Je nach Quellentyp lassen sich dort auch Konfiguration und Filter ändern, synchronisierte Daten purgen und die Quelle löschen. Das sind unterschiedliche Eingriffe: Purge entfernt die aus dieser Quelle übernommenen Verzeichnisdaten, während Delete zusätzlich die Directory Source beseitigt. Für AD werden zuvor Sync-Optionen und laufende Clients gestoppt; bei Entra ID und Google werden deren jeweilige Filter-, Purge- und Delete-Dialoge verwendet. Vor jeder Variante werden betroffene Benutzer, Gruppen, Geräte, Policies und Mailboxen exportiert und die in Central angekündigten Folgen gelesen. Ein Purge oder Delete ist kein unverbindlicher Verbindungstest und wird nicht ohne Rückbauplan bestätigt.

Name und Beschreibung einer Quelle lassen sich erst ändern, nachdem sie mit Turn off deaktiviert wurde. Nach dem Speichern wird sie mit Turn on wieder aktiviert und kontrolliert. Das Abschalten unterbricht die Aktualisierung; es wird daher nicht während einer ungeprüften Verzeichnisänderung durchgeführt. Sobald für eine Quelle die Synchronisation produktiv aktiviert wurde, lässt sich dieser Schritt nicht einfach rückgängig machen. Für einen manuellen Lauf wird die Quelle geöffnet und Synchronize gewählt; anschliessend werden Status, Zeitpunkt und Objektänderungen geprüft.

Self Service und Shared Mailboxes vor dem Sync planen

Soll ein Benutzer das Self Service Portal verwenden, wird User Access vor dem ersten Directory Sync eingeschaltet. So kann Central die Einladungen im vorgesehenen Ablauf versenden. Ein später aktivierter Zugriff korrigiert nicht automatisch jede zuvor verpasste Zustellung; deshalb werden Pilotbenutzer, Mailzustellung und Portalzugriff bereits vor dem breiten Import getestet.

Shared Mailboxes besitzen in Central nicht zwingend vollständige Benutzerattribute. Delegierte Benutzer erhalten den Self-Service-Zugriff für die ihnen zugewiesene Shared Mailbox und sehen dort je nach lizenziertem Produkt etwa Emergency Inbox und Quarantine Summary. Ein Delegate kann dadurch Zusammenfassungen für das eigene Postfach und zusätzlich für die Shared Mailbox erhalten. Delegationen und Zustelladressen werden deshalb nach dem Sync praktisch getestet, nicht nur anhand der Objektzahl abgenommen.

Eine Shared Mailbox innerhalb einer Microsoft-365-Gruppe lässt sich nicht über lokales AD synchronisieren; dafür wird Microsoft Entra ID oder Google Directory verwendet. Eine normale Shared Mailbox ausserhalb einer Microsoft-365-Gruppe kann AD Sync übernehmen. Vor einer späteren Migration zu Entra ID wird inventarisiert, welche Mailboxen aus welchem Objekttyp stammen. Andernfalls kann ein fortgesetzter AD-Sync nach dem Quellenwechsel Mailboxen entfernen oder mit einem veralteten Datenstand stehen lassen.

Vor dem ersten Sync

Zuerst wird festgelegt, welches Verzeichnis für welche Benutzer und Gruppen führend ist. Dieselben Personen sollten nicht gleichzeitig manuell, aus AD und aus Entra ID erzeugt werden.

Für den ersten Lauf empfiehlt sich eine kleine Test-OU mit repräsentativen Benutzern und Gruppen. Geprüft werden:

• E-Mail-Adressen und User Principal Names,
• verschachtelte Gruppen und Mitgliedschaften,
• deaktivierte oder veraltete Konten,
• Service- und technische Konten,
• Namenskonflikte mit vorhandenen Central-Objekten.

Jeder zu synchronisierende Benutzer benötigt eine eindeutige E-Mail-Adresse. Viele Central-Abläufe verwenden sie als Identität und Zustellziel; bei Sophos Email kann eine Nachricht an eine Adresse ohne zugeordneten Benutzer sogar unzustellbar sein. Zusätzlich müssen Firewall oder Proxy die für Central dokumentierten Domains und Ports erreichen. Ein erfolgreicher LDAP-Test allein bestätigt diesen Cloud-Pfad nicht.

AD Sync Utility installieren

Die aktuelle Synchronisationssoftware wird direkt aus Sophos Central geladen und auf einem dauerhaft verfügbaren Windows-System installiert. Das System benötigt Netzwerkzugriff zum Domain Controller und zu den erforderlichen Sophos-Diensten.

Die aktuelle Active Directory Synchronization Setup Software läuft nur auf einem 64-Bit-Windows-System und benötigt .NET Framework 4.6.2. Sophos führt dafür Windows 7, 8.1, 10 und 11 sowie Windows Server 2008 R2, 2012, 2012 R2, 2016, 2019, 2022 und 2025 auf. Als Domain Controller nennt Sophos Windows Server 2008 R2 bis 2025. Diese Herstellerkompatibilität ersetzt nicht den Microsoft-Lifecycle: Für eine neue produktive Installation wird ein aktuell unterstütztes und gepatchtes Serverbetriebssystem verwendet, nicht Windows 7 oder ein abgekündigter Windows Server.

Für den Central-Zugriff werden API Credentials mit der Rolle Service Principal Active Directory Sync verwendet, nicht pauschal Super-Admin-Credentials.

Das verwendete AD-Dienstkonto erhält nur die für das Lesen der ausgewählten Forests und Verzeichnisobjekte nötigen Rechte. Kennwortablauf, Dienststart und Verantwortlichkeit werden dokumentiert. Ein persönliches Admin-Konto ist ungeeignet.

Die Utility kann eine Domain nicht verarbeiten, wenn ein einzelner Bestandteil ihres Namens länger als 63 Zeichen ist oder mit - beziehungsweise _ beginnt oder endet. Diese Grenze wird vor der Installation geprüft, denn ein gekürzter Anzeigename oder ein anderer UPN behebt keinen ungültigen AD-Domainnamen.

Sophos hat bis zu 30'000 AD-Objekte getestet. Oberhalb von 40'000 Benutzereinträgen kann die Oberfläche langsamer reagieren. Grössere Umgebungen werden deshalb besonders streng gefiltert und mit realistischen Laufzeiten getestet.

Bei jedem Synchronisationslauf prüft die Utility, ob eine neuere Version verfügbar ist, und führt Folge-Upgrades normalerweise automatisch aus. Frühe AD-Sync-Versionen unterstützen die aktuelle Central-Authentisierung nicht mehr und können vollständig ausfallen, wenn dieses automatische Upgrade nicht funktioniert. In diesem Fall wird der aktuelle Installer unter Global Settings > Platform > Directory service geladen und über die bestehende Installation ausgeführt. Danach werden neue API Credentials mit der Rolle Service Principal Active Directory Sync erstellt und als Client ID sowie Client Secret in der Utility hinterlegt. Jede produktive Sync-Instanz erhält eine nachvollziehbare technische Identität, dokumentierte Zuständigkeit und eigene Secret-Rotation.

Beim Start werden Client ID und Client Secret mit Validate credentials geprüft. Muss die Utility über einen Proxy kommunizieren, wird Configure proxy manually aktiviert und die Proxy-Adresse erfasst. Benötigt der Proxy eine Anmeldung, kommen Enable proxy authentication, Proxy-Benutzer und Proxy-Kennwort hinzu. Erst ein erfolgreicher zweiter Credential-Test bestätigt, dass nicht nur die API-Daten, sondern auch der Proxy-Pfad funktioniert.

Diese Proxy-Maske gehört zu Active Directory Synchronization Setup 4.0. Ein Trial-Tenant kann stattdessen noch die ältere Sophos Central AD Sync Utility 3.5.4 erhalten; dort lassen sich keine Proxy-Daten in der Oberfläche erfassen. Der Dienst läuft standardmässig als Local Service und scheitert an einem authentifizierenden Proxy häufig mit Failed active directory synchronization, einer System.Net.Http.HttpRequestException und CommandLib.HttpRequestCommand+HttpStatusException. Ein dafür verwendetes alternatives Dienstkonto benötigt Log on as a service, interaktive und Batch-Anmeldung, Leserechte auf die betroffenen OUs sowie Vollzugriff auf C:\ProgramData\Sophos\Sophos Cloud AD Sync. Nach jedem Wechsel dieses Dienstkontos wird die alte Utility neu konfiguriert. Für produktive Umgebungen wird nach Möglichkeit die aktuelle 4.0-Software eingesetzt.

Für den LDAP-Zugriff wird ein lesendes Konto für den gesamten ausgewählten Forest verwendet. Use LDAP over an SSL connection bleibt nach Möglichkeit eingeschaltet. LDAPS verwendet üblicherweise TCP 636, unverschlüsseltes LDAP TCP 389. Port 389 ist aufgrund von LDAP Signing und Channel Binding in aktuellen Active-Directory-Umgebungen kein verlässlicher Ausweg. Der Domain Controller braucht für LDAPS ein gültiges und vom Sync-System vertrauenswürdiges Zertifikat.

Unterstützt die konkrete LDAP-Umgebung nachweislich kein SSL, kann Use Secure LDAP ausgeschaltet und der Port passend auf den unverschlüsselten LDAP-Dienst geändert werden. Das ist ein dokumentierter Fallback, keine Best Practice. Zugangsdaten und Verzeichnisdaten sind dann auf dem Transportweg nicht durch TLS geschützt; deshalb werden Segmentierung, Netzpfad und ein zeitnaher Wechsel zu LDAPS als Risiko behandelt.

Was die Utility im Forest erwartet

Für einen vollständigen Forest liest AD Sync an der Wurzel des Verzeichnisbaums rootDomainNamingContext mit dem Distinguished Name der Forest-Root-Domain und defaultNamingContext mit dem Distinguished Name des verwendeten Servers. Unter CN=Partitions,CN=Configuration,<rootDomainNamingContext> erwartet die Utility für die relevanten Namenskontexte Einträge mit netBiosName, dnsRoot und nCName. Der Wert von nCName bestimmt die zusätzlichen Suchbereiche, sofern er kein übergeordneter Distinguished Name des in der Setup-Maske angegebenen Servers ist.

Fehlt eines dieser Attribute oder darf das Dienstkonto die Configuration-Partition nicht lesen, kann ein Login-Test funktionieren, während die Forest-Erkennung oder der spätere Sync trotzdem scheitert. In diesem Fall werden die Werte mit LDP.exe unter demselben Dienstkonto geprüft, bevor Filter oder Central-Objekte geändert werden.

OUs und Objekte filtern

Filter begrenzen den Umfang der Synchronisation. Es werden nur OUs, Benutzer und Gruppen aufgenommen, die Sophos Central tatsächlich benötigt. Ein breiter Root-Import ist selten sinnvoll.

Vor der Übernahme prüft die Vorschau, welche Objekte hinzugefügt, geändert oder entfernt würden. Insbesondere Löschungen werden nicht ungeprüft bestätigt. Die Preview- beziehungsweise Pending-Changes-Ansicht kann UTF-16- oder Double-Byte-Zeichen nicht korrekt darstellen und zeigt stattdessen beispielsweise ???. Die Daten werden trotzdem an Sophos Central übertragen und dort dargestellt. Namen etwa in Chinesisch, Japanisch oder Koreanisch werden deshalb zusätzlich direkt im Active Directory und nach einem kontrollierten Pilot-Sync in Central geprüft.

Sophos bezeichnet dieses Preview-Problem als Einschränkung, die in einer künftigen Version der AD Sync Utility behoben werden soll. Bis die eingesetzte Version das nachweislich korrigiert, bleibt die Kontrolle im Quellverzeichnis und nach dem Sync erforderlich.

Base DN und LDAP filter lösen zwei verschiedene Aufgaben. Der Base DN begrenzt die Suche auf ausgewählte OUs; eine OU-Mitgliedschaft lässt sich in Active Directory nicht zuverlässig nur als normaler LDAP-Filter ausdrücken. Der LDAP-Filter grenzt Attribute oder Gruppenmitgliedschaften innerhalb dieses Suchraums ein. Beide Filter werden pro Domain gepflegt, denn Child Domains erben die Einstellung ihrer Parent Domain nicht. Benutzer- und Gruppenfilter arbeiten ebenfalls unabhängig voneinander.

Auf dem Tab AD Filters werden Search Bases und LDAP Query Filters getrennt pro Domain und bei Bedarf getrennt für Benutzer und Gruppen erfasst. Eine Search Base für eine Finance-OU kann beispielsweise so aussehen:

OU=Finance,DC=myCompany,DC=com

Ein Benutzerfilter für Mitglieder einer Gruppe lautet beispielsweise:

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

Ohne zusätzlichen Gruppenfilter entdeckt Central weiterhin alle Gruppen, zu denen diese Benutzer gehören. Soll auch die Gruppenauswahl auf diese eine Gruppe begrenzt werden, kommt als Gruppenfilter beispielsweise CN=testGroup hinzu. Eine Filteränderung kann zuvor synchronisierte Benutzer und Gruppen aus dem Scope schieben und in Central löschen; deshalb folgt immer eine vollständige Vorschau.

Sophos verwendet als Ausgangspunkt diese Filter:

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

Der Benutzerfilter nimmt Personen mit der Klasse user, schliesst jedoch Computerobjekte über sAMAccountType=805306370 und deaktivierte Konten über das entsprechende userAccountControl-Bit aus. Zusätzliche Filter werden pro Domain mit diesen Grundbedingungen kombiniert und zuerst mit LDP.exe getestet.

Sophos begrenzt die Konfiguration auf 1'000 Filter pro Verzeichnisobjekt und 5'000 Zeichen pro zusätzlichem LDAP-Filter. Benutzer lassen sich nur zusammen mit Benutzergruppen synchronisieren, Geräte nur zusammen mit Gerätegruppen. Bei domainübergreifenden Gruppen zeigt die Vorschau zwar alle Mitglieder, Central übernimmt aber nur Benutzer aus der Domain, zu der die Gruppe gehört. Solche Gruppen werden deshalb vor dem produktiven Sync ausdrücklich getestet.

Das erwartete Ergebnis wird mit Microsoft LDP.exe gegengeprüft: Search Base aus AD Sync entspricht dort Base DN, und der AD-Sync-LDAP-Ausdruck entspricht Filter. Dadurch lässt sich unterscheiden, ob Sophos oder bereits die Verzeichnisabfrage ein Objekt nicht liefert. Einige Attributvergleiche können case-sensitive sein.

Filter mit lastLogon oder lastLogonTimestamp werden vorsichtig verwendet. lastLogon ist zwar meist aktueller, wird aber nicht zwischen Domain Controllern repliziert; für einen belastbaren Wert müssten deshalb alle Domain Controller abgefragt werden. lastLogonTimestamp wird repliziert, kann jedoch veraltet sein. Sophos empfiehlt, inaktive Konten und Geräte an der Quelle zu entfernen, statt sich allein auf einen Zeitfilter zu verlassen.

Soll lastLogonTimestamp trotzdem als Übergangsfilter dienen, wird zuerst ein UTC-Stichtag festgelegt und mit einem vertrauenswürdigen LDAP-/Active-Directory-FILETIME-Konverter in Windows FILETIME umgerechnet. Der Sophos-Beispielstichtag 1. Dezember 2020 um 00:01 ergibt 132581431640000000. In Active Directory Synchronization Setup > AD Filters wird im Feld für Custom Filters der zusätzliche LDAP-Ausdruck eingetragen:

(lastLogonTimestamp>=132581431640000000)

Der Beispielwert wird nicht unverändert übernommen. Der eigene Stichtag wird bewusst gewählt, korrekt konvertiert und zusammen mit Zeitzone und Änderungsfreigabe dokumentiert. Danach folgen Preview and Sync, eine Kontrolle der einbezogenen und ausgeschlossenen Benutzer und erst dann die Freigabe des produktiven Laufs.

AD Sync erstellt nur Gruppen mit mehr als einem Mitglied. Eine leere Gruppe oder eine Gruppe mit genau einem Mitglied erscheint daher nicht als erwartetes Central-Objekt. Doppelte Benutzer oder E-Mail-Adressen über mehrere Forests werden nicht zusammengeführt; die Quelle eines Objekts kann dadurch zwischen Läufen wechseln. Ein Forest wird deshalb nach Möglichkeit nur mit einem Central-Tenant synchronisiert.

Exclude disabled user accounts ist standardmässig aktiviert. Für die Synchronisation von Shared Mailboxes muss diese Option eingeschaltet bleiben. Wird sie deaktiviert, kann Central für Shared Mailboxes doppelte Mailboxobjekte erzeugen. Deaktivierte normale Benutzerkonten gehören unabhängig davon an der Quelle bereinigt und nicht über einen breiteren Sync wieder eingeführt.

Die Datentyp-Schalter besitzen konkrete Abhängigkeiten:

• Sync users and user groups synchronisiert beide gemeinsam und umfasst auch normale Shared Mailboxes. Wird der Schalter ausgeschaltet, lassen sich über diese AD-Quelle weder Shared Mailboxes noch Public Folders synchronisieren.
• Sync public folders setzt zusätzlich Sync users and user groups voraus, weil Public Folders als Mailboxobjekte behandelt werden.
• Für Geräte werden Sync devices und Sync organizational units beim normalen Betrieb gemeinsam eingeschaltet. Beim Erstaufbau können zunächst nur die OUs übernommen werden, damit Policies vor den Geräten bereitstehen.
• Wird später nur Sync organizational units ausgeschaltet, bleiben die Geräte aktiv, die bisherigen OUs erscheinen jedoch als Custom Groups. Bleibt nur die OU-Synchronisation aktiv, werden Geräte nicht mehr den Central-Gruppen zugeordnet.

Ohne vorbereitete OU-Gruppen erhalten neu synchronisierte Geräte zunächst die Default Policies. Nach dem OU-Pilot werden deshalb beide Geräteschalter gemeinsam aktiviert und Zuordnung sowie tatsächlich angewendete Policy kontrolliert.

Für sehr grosse Gruppen ist zusätzlich das AD-Attribut member relevant. Ab 1'500 Einträgen verwendet Active Directory Range Retrieval wie member;range=0-1499 und leert das einfache member-Attribut. Wurde die Gruppe bereits vor dem ersten Sync mit mehr als 1'500 Objekten gefüllt, kann sie dadurch in Central fehlen oder eine falsche Mitgliederzahl zeigen. Solche Gruppen werden möglichst auf weniger als 1'500 Benutzerobjekte begrenzt und mit LDP.exe kontrolliert.

Benutzer-Matching und E-Mail-Aliase

Central gleicht AD-Benutzer über den Domain Login im Format DOMAIN\user oder über das Attribut mail mit bestehenden Benutzern ab. Der Anzeigename stammt aus Display name, zusätzliche E-Mail-Aliase aus proxyAddresses. Bei einem Treffer wird das bestehende Central-Objekt zum verzeichnisverwalteten Objekt; ohne Treffer entsteht ein neuer Benutzer. Preview and Sync zeigt Treffer unter Users to Modify und neue Objekte unter Users to Add.

Ein von einem anderen Directory Service synchronisiertes Objekt wird bei einem Treffer nicht als zweiter neuer Benutzer erzeugt, kann aber um eine E-Mail-Adresse aus AD ergänzt werden. Ein manuell angelegter Benutzer und ein gleichnamiger AD-Benutzer können dagegen als zwei getrennte Objekte bestehen bleiben, wenn Login und E-Mail nicht übereinstimmen. Der Anzeigename allein ist kein Matching-Schlüssel.

In Preview and Sync werden Treffer unter Users to Modify und neue Identitäten unter Users to Add einzeln geprüft. Eine falsche Zuordnung wird abgelehnt, statt den gesamten Vorschlag mit Approve Changes and Continue zu übernehmen. Der Wechsel eines manuellen Benutzers zum AD-verwalteten Objekt ist zusätzlich am Verzeichnis-Icon sichtbar.

Wird ein Benutzer in AD entfernt, hängt das Central-Verhalten von seinen Abhängigkeiten ab. Administratoren sowie Benutzer mit zugeordnetem Gerät oder Login bleiben als normale Central-Benutzer bestehen. Ein reiner Benutzer ohne Gerät, Login oder privilegierte Rolle kann dagegen automatisch entfernt werden. E-Mail-Änderungen eines Central-Administrators werden aus demselben Schutzgrund nicht blind aus AD übernommen. Deshalb werden Adminrollen und Gerätebindungen vor einem Offboarding separat geprüft.

Soll die primäre E-Mail-Adresse eines verzeichnisverwalteten Administrators geändert oder sein nach AD-Löschung verbliebenes Central-Objekt entfernt werden, wird seine Adminrolle vor dem nächsten Sync kontrolliert entzogen. Nach der Synchronisation kann die benötigte Rolle erneut zugewiesen werden. Dieser Vorgang erhält immer einen zweiten funktionsfähigen Super Admin als Recovery-Weg.

Falscher Name durch überlappende Logins

Besitzt Benutzer A versehentlich auch den Gerätelogin von Benutzer B, kann AD Sync zunächst beide Logins A zuordnen und beim späteren Verarbeiten von B den bestehenden Datensatz auf B umbenennen. Im betroffenen Central-Benutzer werden deshalb unter Logins alle fremden Zuordnungen entfernt und danach erneut synchronisiert. Namen werden nicht einfach zurückgeschrieben, solange der falsche Login bestehen bleibt.

Rolle lässt sich einem AD-Benutzer nicht zuweisen

Zuerst wird unter My Environment > Users & Groups > Users nach der E-Mail-Adresse gesucht. Bei Dubletten werden die Logins der nicht zu verwendenden Objekte dokumentiert, dort über Edit logins entfernt und beim richtigen Benutzer hinzugefügt. Erst danach wird die Rolle gespeichert und der Setup-Versand geprüft. Bleibt die E-Mail-Adresse tenantweit blockiert, wird nicht weiter gelöscht, sondern der Konflikt über den Supportweg bereinigt.

Verschachtelte Gruppen richtig lesen

Die Benutzerseite kann neben der direkten AD-Gruppe auch übergeordnete, verschachtelte Gruppen als linked groups anzeigen. Der Benutzer ist dadurch nicht automatisch direktes Mitglied jeder angezeigten Gruppe. Für Berechtigungs- und Policy-Analysen werden direkte AD-Mitgliedschaft, Verschachtelung und die tatsächlich angewendete Central-Policy getrennt geprüft.

Mac-Login dem synchronisierten Benutzer zuordnen

AD Sync importiert einen Login als NETBIOSDOMAIN\user, ein Mac meldet ihn dagegen häufig als MACNAME\user. Central kann deshalb ein zweites, automatisch erzeugtes Benutzerobjekt anlegen. Nach Prüfung der betroffenen Geräte wird dieses Objekt bereinigt und MACNAME\user dem AD-synchronisierten Benutzer zugeordnet. Für einen grösseren Rollout wird statt manueller Nacharbeit der von Sophos vorgesehene Domain-Override getestet.

Computer und OU-Gruppen synchronisieren

Die Geräteerkennung unterstützt Windows-Computer und -Server. Sophos ordnet ein geschütztes Gerät anhand von FQDN und Hostname dem AD-Objekt zu und verschiebt es in die synchronisierte OU-Gruppe. Ein zuvor manuell gruppierter Computer kann dadurch beim nächsten Sync in die AD-Struktur zurückkehren.

Ein neues Geräte- oder Gruppenobjekt entsteht, wenn Central noch keinen Eintrag mit derselben AD-ObjectGUID kennt. Kollidiert der Name einer neuen AD-Gruppe mit einer vorhandenen Gruppe, verwendet Central für die neue Gruppe den Distinguished Name. Mehrere AD-Datensätze mit demselben DN werden nicht unterstützt.

Beim Matching müssen FQDN und Hostname passen. Existiert ein Central-Gerät mit Domain und Hostname, aber abweichenden gespeicherten Details, aktualisiert der Sync diese Informationen und verschiebt das Gerät in die passende AD-Gruppe. Bei zwei Geräten mit demselben FQDN wird das bisher verknüpfte Geräteobjekt gelöst und der neue Datensatz verbunden. Doppelte Hostnamen werden deshalb vor dem Sync bereinigt, statt die resultierende Neuverknüpfung als zufälligen Geräteverlust zu behandeln.

OUs werden vor den Geräten synchronisiert, damit Policies zuerst an den vorgesehenen Gruppen vorbereitet werden können. Synchronisierte Geräte und Gruppen lassen sich in Central nicht dauerhaft gegen die AD-Struktur umorganisieren. Eine Hierarchie mit mehr als 40 Ebenen wird ab Ebene 40 zusammengeführt.

Synchronisierte Geräte und Gruppen können in Central verschoben oder gelöscht, aber nicht wie lokale Objekte editiert werden. Solche manuellen Änderungen sind nicht dauerhaft: Der nächste Sync stellt die AD-Struktur wieder her oder erzeugt das Objekt erneut. Wird ein geschütztes Gerät in AD gelöscht, verschiebt Central es beim nächsten Lauf in eine unstrukturierte Gruppe und entfernt die Kennzeichnung als AD-verwaltetes Gerät. Änderungen an Namen, Betriebssystemdetails oder OU-Struktur werden beim nächsten Sync ebenfalls übernommen, einschliesslich Verschieben und Entfernen von Gruppen.

Policies auf manuell erstellten Gruppen bleiben erhalten. AD-verwaltete Geräte werden jedoch aus diesen Gruppen in die synchronisierte Gruppe verschoben und erhalten dort zunächst die Default Policies, sofern vorab keine passende Policy zugewiesen wurde. Eine Policy auf einer Top-Level-Gruppe wird an eine verschachtelte Gruppe vererbt, solange dort keine eigene Policy-Zuweisung besteht. Deshalb werden OUs zuerst synchronisiert, Policies zugewiesen und erst danach die Geräte übernommen.

Eine API für AD-synchronisierte Directory Devices und Device Groups stellt Sophos derzeit nicht bereit. Automationen dürfen deshalb nicht davon ausgehen, diese Struktur wie normale Central-Gruppen vollständig per API verwalten zu können.

Unter My Environment > Unmanaged devices erscheinen aus AD bekannte Computer und Server in getrennten Ansichten ohne Sophos-Agent. Die benötigten Schutzpakete stehen unter My Environment > Installers bereit. Diese Inventarsicht installiert jedoch keinen Schutz; jedes erwartete Gerät bleibt im Rollout- oder Ausnahmeprozess, bis der Agent installiert oder eine dokumentierte Ausnahme genehmigt wurde.

Zeitplan und Überwachung

Der Sync-Zeitplan muss zur Änderungsfrequenz des Unternehmens passen. Nach jedem Lauf werden Status, Fehler und Objektänderungen kontrolliert. Ein erfolgreich gestarteter Dienst beweist nicht, dass alle Objekte korrekt synchronisiert wurden.

Warnungen zu Anmeldedaten, Verbindung, fehlenden Attributen oder Objektkonflikten werden zeitnah behoben. Für den Betrieb braucht es einen Owner und eine Vertretung.

Beim ersten Lauf und nach jeder Filteränderung wird Preview and Sync manuell gestartet. Die Vorschau wird auf neue, geänderte und zu löschende Objekte geprüft und erst danach mit Approve Changes and Continue bestätigt. Ein manueller Lauf kann bis zu 15 Minuten benötigen. Wer ausschliesslich kontrollierte manuelle Läufe möchte, wählt im Zeitplan Never. Only sync when manually initiated.

Die Laufzeitlogs liegen unter:

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

Sie rotieren über sieben Tagesdateien. Ein für die Analyse benötigtes Log wird deshalb vor der nächsten Rotation kopiert oder umbenannt. Ein Medium-E-Mail-Alert enthält oft nur die Zusammenfassung; die konkrete Ursache wird im Log desselben Zeitfensters gesucht.

Wird der AD-Sync-Server ersetzt, läuft nie gleichzeitig eine unkontrollierte zweite Instanz. Zuerst wird der Zeitplan auf dem bisherigen Server gestoppt. Danach wird die aktuelle Utility auf dem neuen Server eingerichtet, die bestehende Filterkonfiguration verglichen und mit Preview and Sync geprüft. Erst nach einem erfolgreichen manuellen Lauf wird dort der Zeitplan aktiviert und die alte Installation entfernt.

Löschen und Neuaufbau

Wird ein Objekt im Quellverzeichnis entfernt oder aus dem Filter genommen, kann dies Auswirkungen auf das entsprechende Central-Objekt und dessen Policy-Zuweisung haben. Vor einer Massenänderung werden die in der Oberfläche angekündigten Aktionen gelesen und dokumentiert.

Ein Löschen der Sync-Konfiguration oder synchronisierten Daten ist kein normaler Troubleshooting-Schritt. Vorher werden Gerätezuordnung, Gruppenmitgliedschaften und mögliche Duplikate geprüft. Ein Neuaufbau ohne Analyse kann dieselben Probleme erneut erzeugen.

Vor Purge data werden alle laufenden oder kopierten AD-Sync-Instanzen gestoppt und Filter kontrolliert, sonst erscheinen die Daten erneut. Der Purge ist nicht rückgängig zu machen. Verwaltete Geräte und ihre zugeordneten Benutzer sowie Administratoren werden auch dann nicht entfernt, wenn sie ursprünglich aus AD stammen.

Synchronisierte AD-Daten purgen

Der ausführbare Ablauf beginnt unter Global Settings > Platform > Directory service. Dort wird der Name der AD-Quelle geöffnet, mit Turn off gestoppt und Purge data gewählt. Im Dialog wird der zu entfernende Datenbereich bewusst ausgewählt:

• Users and user groups entfernt zusätzlich die synchronisierten Shared Mailboxes und Public Folders.
• Devices and device groups entfernt den synchronisierten Geräte- und Gruppenbestand, mit Ausnahme der von Sophos genannten geschützten Objekte.

Nach Bestätigung der Unumkehrbarkeit wird nochmals Purge data gewählt. Central löscht den ausgewählten Bestand und synchronisiert diesen Datentyp aus der gestoppten Quelle nicht erneut. Wurden sämtliche AD-Daten entfernt, müssen Benutzer, Geräte und Gruppen fortan manuell oder über eine neue, klar abgegrenzte Quelle verwaltet werden. Für Benutzer und Benutzergruppen kann beispielsweise Microsoft Entra ID übernehmen.

Vor dem Purge werden alle Kopien der AD Sync Utility und ihre Zeitpläne gesucht und gestoppt. Filter allein verhindern keine Wiederkehr, wenn eine zweite Instanz weiter synchronisiert. Nachher werden die verbliebenen Administratoren sowie verwalteten Geräte und deren zugeordnete Benutzer kontrolliert, weil Central diese Ausnahmen nicht löscht.

Von AD zu Microsoft Entra ID wechseln

Sophos unterstützt den Wechsel der Benutzer- und Gruppensynchronisation einer Domain von AD zu Entra ID. Vorher müssen eine passende AD- und Entra-Quelle für dieselbe Domain vorhanden sein und die Benutzer in beiden Quellen zuverlässig übereinstimmen. Nicht passende AD-Benutzer können beim Wechsel aus Central entfernt werden.

Entra ID synchronisiert keine Computer und Computergruppen. Werden diese weiterhin benötigt, bleibt AD für Geräte aktiv, während Entra ID Benutzer und Benutzergruppen derselben Domain liefert. Public Folders und bestehende Shared-Mailbox-Zuordnungen besitzen weitere Einschränkungen und werden vor der Migration separat geprüft.

Der Wechsel beginnt mit einer Export- und Vergleichsliste, nicht direkt mit dem Umschalten der Quelle. Stimmen Benutzer zwischen AD und Entra ID überein, aktualisiert Central das vorhandene Objekt und behält zugehörige Mailboxen. Nicht übereinstimmende Benutzer können samt Mailbox-Zuordnung entfernt werden; neue Entra-Benutzer werden neu erstellt. Nicht passende Benutzergruppen bleiben zwar bestehen, werden aber nicht mehr aktualisiert.

Shared Mailboxes und Public Folders benötigen besondere Aufmerksamkeit. Central behält bisherige AD-Shared-Mailboxes mit dem letzten AD-Datenstand, aktualisiert sie aber nicht mehr über AD. Neue Entra-Shared-Mailboxes können zusätzlich erscheinen. Public Folders bleiben ebenfalls mit ihrem letzten Stand bestehen. Wird nach der Migration weiterhin die alte On-Premises-AD-Synchronisation für diese Objekte verwendet, können Shared Mailboxes aufgrund unterschiedlicher Objekttypen unerwartet entfernt werden.

Nachher werden Benutzer, Gruppen, Policies, Gerätezuordnung, Shared Mailboxes, Public Folders und Duplikate kontrolliert. Bleibt AD für Geräte aktiv, werden dort Sync devices und Sync organizational units weiterhin gemeinsam betrieben.

Voraussetzungen und Migrationsentscheid

AD und Entra ID müssen dieselbe Domain abbilden. Die Benutzer werden vor dem Wechsel über eindeutige E-Mail-Adressen und andere übereinstimmende Identitätsmerkmale verglichen, damit Central bestehende Konten aktualisiert statt sie zu löschen und neu anzulegen. Der Entra-Connector und seine App-Berechtigungen werden vollständig vorbereitet, bevor die AD-Quelle abgeschaltet wird.

Public Folders sowie Computer und Computergruppen stammen weiterhin nur aus AD. Für jede Domain wird deshalb entschieden, ob Entra ID allein genügt oder ob AD parallel für Geräte und OU-Strukturen weiterlaufen muss. Shared Mailboxes werden zusätzlich nach AD-, Entra- und Microsoft-365-Gruppenobjekten getrennt erfasst.

Nur Microsoft Entra ID verwenden

Dieser Weg passt, wenn Central aus dem lokalen AD weder Geräte und Gerätegruppen noch Public Folders weiter aktualisieren muss.

1. Den letzten AD-Sync durchführen und Benutzer, Gruppen, Mailboxen sowie Fehler kontrollieren.
2. Unter Global Settings > Platform > Directory service die AD-Quelle öffnen und mit Turn off deaktivieren.
3. Mit Add Microsoft Entra ID die Entra-Quelle für dieselbe Domain einrichten und die geforderten App-Berechtigungen erteilen.
4. Die Entra-Synchronisation starten und Benutzer, Gruppen sowie Shared Mailboxes gegen die Export- und Vergleichsliste prüfen.
5. Erst nach der Abnahme die lokale AD Sync Setup Software deinstallieren und ihre API Credentials nach dokumentierter Prüfung widerrufen.

Die Abschaltung der alten Quelle ist eine kontrollierte Migration, kein Troubleshooting-Reset. Bei unerwarteten Löschungen wird nicht durch wiederholtes Ein- und Ausschalten weiter synchronisiert, sondern zuerst der Matching-Bericht ausgewertet.

Microsoft Entra ID und AD parallel verwenden

Diese Variante verwendet Entra ID für Benutzer, Benutzergruppen und moderne Shared Mailboxes, während AD Geräte und Gerätegruppen liefert.

1. Den bestehenden AD-Sync vollständig ausführen und den Ausgangsbestand validieren.
2. In der AD Sync Utility die Auswahl auf Sync devices und Sync organizational units begrenzen; Benutzer und Benutzergruppen werden künftig nicht mehr aus AD geliefert.
3. Die AD-Quelle in Central vorübergehend mit Turn off deaktivieren.
4. Microsoft Entra ID für dieselbe Domain hinzufügen, synchronisieren und Benutzer, Gruppen sowie Shared Mailboxes validieren.
5. Die AD-Quelle wieder mit Turn on aktivieren, manuell synchronisieren und kontrollieren, dass Geräte und Gerätegruppen weiter aktualisiert werden, ohne Benutzer erneut aus AD einzuspielen.

Beide Quellen erhalten eigene Owner, Zeitpläne und Abnahmegrössen. Ein grüner Status beider Connectoren beweist noch nicht, dass ihre Objektbereiche sauber getrennt sind.

Auswirkungen auf Benutzer, Gruppen, Mailboxen und Geräte

Bei übereinstimmenden Benutzern aktualisiert Entra ID das bestehende Central-Objekt; zugehörige Mailboxinformationen bleiben erhalten. Ein AD-Benutzer ohne passenden Entra-Datensatz kann aus Central mitsamt seiner Mailboxzuordnung entfernt werden. Neue Entra-Benutzer werden als neue Central-Benutzer mit den verfügbaren Mailboxdaten angelegt.

Übereinstimmende Benutzergruppen werden aktualisiert. AD-Gruppen ohne Entra-Gegenstück bleiben zwar in Central sichtbar, erhalten aber keine weiteren Änderungen aus AD. Neue Entra-Gruppen werden angelegt. Diese stehen gebliebenen Gruppen sind kein Beweis einer weiterhin funktionierenden Synchronisation; Policy-Zuweisungen und Mitgliedschaften werden daher separat kontrolliert.

Bestehende, zuvor aus AD gelieferte Shared Mailboxes und Public Folders bleiben mit dem letzten AD-Datenstand erhalten, werden aber nicht mehr aktualisiert. Solche Shared Mailboxes erscheinen weiterhin unter Mailboxes, besitzen nach dem Wechsel jedoch unter Umständen keine zugeordneten Benutzer. Neue Entra-Shared-Mailboxes können sowohl als Benutzerobjekt als auch unter Mailboxes erscheinen und ebenfalls ohne die aus AD bekannte Delegate-Zuordnung ankommen. Delegierte Zugriffe und Quarantäne-Zusammenfassungen werden deshalb neu validiert. Läuft die alte AD-Synchronisation nach der Migration unkontrolliert weiter, können unterschiedliche Objekttypen bestehende Shared Mailboxes entfernen.

Im Entra-only-Modell bleiben bisherige AD-Geräte und Gerätegruppen zwar zunächst in Central erhalten, werden aber nicht mehr aus dem Verzeichnis aktualisiert. Im Parallelmodell synchronisiert AD diese Objekte weiter. Entra ID selbst liefert keine Computer, Computergruppen oder Public Folders. Diese Wirkung wird im Migrationsentscheid ausdrücklich dokumentiert, damit ein stehen gebliebener Bestand nicht fälschlich als aktuelle Synchronisation interpretiert wird.

Bestehende Endpoints in eine neue AD-Domain übernehmen

Ändert sich nur die AD-Domain, während Computername und SID gleich bleiben, muss der Sophos-Agent nicht neu installiert werden. Seine machine_id bleibt erhalten. Zuerst wird unter Global Settings > Platform > Directory service die AD-Sync-Konfiguration auf die neue Domain umgestellt, die Credentials werden validiert und Benutzer, Gruppen, OUs sowie Geräte werden synchronisiert. Danach dürfen die Endpoints bei Central einchecken.

Durch den neuen FQDN löst Central die alte AD-Zuordnung und sucht das passende Geräteobjekt in der neuen Domain. Bei einem Treffer wird dasselbe Endpoint-Objekt neu verknüpft und bei aktiver OU-Synchronisation in die richtige Gruppe verschoben. Benutzerlogins wechseln dagegen beispielsweise von OLDDOMAIN\jsmith zu NEWDOMAIN\jsmith und können Dubletten erzeugen.

Die Abnahme kontrolliert neue Domain, OU-Gruppe, angewendete Policies und Benutzerzuordnung. Erst danach werden veraltete Geräte-, Benutzer-, Gruppen- oder Directory-Objekte der alten Domain entfernt.

Häufige Fehlerbilder

Benutzer erscheint doppelt

Quellen, E-Mail-Adresse, UPN und vorhandene manuelle Objekte vergleichen. Nicht vorschnell eines der Objekte löschen, solange Geräte oder Policies daran hängen.

Neue Gruppe fehlt

OU- und Gruppenfilter, verschachtelte Mitgliedschaft, letzte erfolgreiche Synchronisation und Verzeichnisattribute prüfen.

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

Dieser Fehler tritt typischerweise auf, wenn ein Custom Filter noch auf eine OU verweist, die inzwischen aus Active Directory entfernt wurde. Die Fehlermeldung nennt den gelöschten OU-Namen nicht. Unter Define Filters werden deshalb alle AD-Filter gegen die aktuelle Verzeichnisstruktur geprüft und nur die Verweise auf nicht mehr vorhandene Objekte entfernt. Danach folgen ein neuer Preview-Lauf und die Kontrolle der geplanten Löschungen.

0xFFFE oder 0xFFFF in Preview and Sync

Enthält Active Directory Zeichen mit den ungültigen Hexadezimalwerten 0xFFFE oder 0xFFFF, kann der manuelle Lauf bei Preview and Sync abbrechen. Zuerst wird das betroffene Quellattribut gesucht und an der Quelle korrigiert. Ist das kurzfristig nicht möglich, nennt Sophos Sync on Schedule - automatic (within next 2-3 minutes) als gezielten Workaround, weil dieser Lauf die Vorschau überspringt. Das ist keine dauerhafte Bereinigung: Umfang, Ergebnis, neue und entfernte Objekte werden unmittelbar danach in Central und im Log kontrolliert.

endpoint_user_sessions.user_match_id beim Löschen eines Logins

Error syncing record: Error deleting login zusammen mit einem Foreign-Key-Hinweis auf endpoint_user_sessions.user_match_id kann erscheinen, wenn AD einen Benutzer entfernt oder deaktiviert hat, Central den zugehörigen Login aber wegen einer vorhandenen Sitzung nicht löschen kann. Der übrige Sync läuft weiter und kann erfolgreich enden. Wiederholt sich der Eintrag, werden Benutzer, Login und Zeitpunkt dokumentiert und Sophos Support zur Bereinigung in Central eingeschaltet; ein Purge oder Neuaufbau des gesamten Syncs ist dafür unverhältnismässig.

Synchronisation bleibt veraltet

Windows-Dienst, Dienstkonto, Kennwort, DNS, Proxy, Firewall-Freigaben und Central-Sync-Status kontrollieren. Für ein Supportticket gehören Sync-Logs und Zeitstempel dazu.

Seit AD Sync Client 5.x zeigt das Audit Log bei Directory-Sync-Aktionen nicht mehr die Client-ID des API Credentials als Modified by, sondern die GUID des bei Sophos registrierten AD-Sync-Clients. Das gilt für Create-, Update- und Delete-Aktionen. Eine GUID ist daher nicht automatisch ein unbekannter Angreifer; sie wird mit Sync-Instanz, Zeitplan und Logzeitstempel korreliert.

LDAP-Anmeldedaten werden immer wieder verlangt

NeedADCredsException zusammen mit The LDAP server is unavailable ist nicht zwingend ein falsches Kennwort. Geprüft werden Domain Controller, Kontoformat DOMAIN\username, Leserechte und der gewählte Port. Für LDAPS ist standardmässig TCP 636 vorgesehen und der Domain Controller muss dort tatsächlich ein vertrauenswürdiges Zertifikat präsentieren. Ein lauschender Port allein beweist keine funktionierende TLS-Konfiguration.

Eskalation an Sophos Support

Ein reproduzierbarer Supportfall enthält Fehlerbeschreibung, Tenant und Lizenz, exakten Zeitraum, AD-Sync-Version, alle Logs, relevante Screenshots und die öffentliche IP des Sync-Systems zum Sammelzeitpunkt. Partnerfälle benötigen zusätzlich die korrekte Zuordnung des MSP-Kunden. Remote Assistance wird nur für den konkreten Fall und nach interner Freigabe aktiviert.

Häufige Fragen