Microsoft Entra Connect Sync — ImmutableID & SourceAnchor

Was ist die ImmutableID?

Die ImmutableID ist ein Base64-kodierter Wert, der ein On-Premises-AD-Objekt dauerhaft und eindeutig mit seinem Entra-ID-Gegenstück verknüpft. Während sich Benutzernamen, E-Mail-Adressen und sogar UPNs ändern können, bleibt die ImmutableID — wie der Name sagt — unveränderlich. Sie ist der einzige zuverlässige Identifikator für die Zuordnung zwischen den beiden Verzeichnisdiensten.

• Technischer Name in Entra ID: onPremisesImmutableId — sichtbar über Microsoft Graph API, Entra-Admin-Portal und PowerShell. Dieser Wert wird bei der ersten Synchronisation gesetzt und sollte sich danach niemals ändern.
• Quelle im On-Premises AD: Der Wert wird aus dem ms-DS-ConsistencyGuid-Attribut (oder objectGUID als Fallback) gelesen und als Base64-String in Entra ID gespeichert. Beispiel: Die GUID {3F2504E0-4F89-11D3-9A0C-0305E82C3301} wird zu 4AQl////E9OaDMA14CwzAQ==.
• Warum „immutable“? Einmal gesetzt, wird dieser Wert zur dauerhaften Brücke zwischen On-Prem und Cloud. Ändert sich der Wert im AD (z. B. durch Forest-Migration, Objekt-Neuerstellung oder manuelle Manipulation), erkennt Entra Connect das Objekt nicht mehr — es entsteht ein Duplikat oder ein Sync-Fehler.
• Unterschied zu objectId: Die objectId in Entra ID ist die Cloud-seitige eindeutige Kennung. Sie hat nichts mit der ImmutableID zu tun. Ein Benutzer hat also zwei verschiedene eindeutige Kennungen: objectId (Cloud) und onPremisesImmutableId (Brücke zum On-Prem-AD).

sourceAnchor-Evolution: Von ObjectGUID zu ms-DS-ConsistencyGuid

Die Wahl des sourceAnchor-Attributs hat sich im Laufe der Jahre grundlegend geändert. Diese Änderung ist die Hauptursache für viele ImmutableID-Probleme in Umgebungen, die über Jahre gewachsen sind.

• Phase 1 — ObjectGUID (bis Version 1.1.486.0): Ältere Versionen von Azure AD Connect verwendeten standardmäßig das objectGUID-Attribut als sourceAnchor. Problem: Die objectGUID ist an das AD-Objekt gebunden und ändert sich bei Cross-Forest-Migration, Objekt-Verschiebung zwischen Domänen oder AD-Wiederherstellung aus Backup. Nach einer Migration hat der Benutzer eine neue objectGUID → die ImmutableID in Entra ID stimmt nicht mehr überein → Sync-Fehler.
• Phase 2 — ms-DS-ConsistencyGuid (ab Version 1.1.524.0): Microsoft führte ms-DS-ConsistencyGuid als bevorzugtes sourceAnchor-Attribut ein. Vorteil: Dieses Attribut wird vom Administrator kontrolliert und bleibt bei Cross-Forest-Migrationen erhalten, da es manuell oder per Skript in die neue Domäne übertragen werden kann. Beim ersten Sync schreibt Entra Connect automatisch die objectGUID in das ms-DS-ConsistencyGuid-Attribut zurück, wenn es leer ist.
• Auto-Upgrade-Verhalten: Wenn Sie Entra Connect auf eine neuere Version aktualisieren, ändert sich der sourceAnchor nicht automatisch. Bestehende Installationen, die objectGUID verwenden, behalten diese Einstellung bei. Nur bei einer Neuinstallation wird ms-DS-ConsistencyGuid als Standard verwendet. Das bedeutet: Viele Unternehmen verwenden noch objectGUID, ohne es zu wissen.
• So prüfen Sie Ihren sourceAnchor: Öffnen Sie den Synchronization Service Manager → Connectors → Properties des AD-Connectors. Unter „Configure Source Anchor“ sehen Sie, welches Attribut verwendet wird. Alternativ im Entra Connect Wizard unter „Identifying users“.

Hard Match vs. Soft Match

Entra Connect verwendet zwei Mechanismen, um On-Premises-Objekte ihren Cloud-Gegenstücken zuzuordnen. Das Verständnis dieser Mechanismen ist entscheidend für die Fehlerdiagnose.

• Hard Match (sourceAnchor-basiert): Die zuverlässigste Zuordnungsmethode. Entra Connect vergleicht den Base64-kodierten sourceAnchor-Wert des On-Premises-Objekts mit dem onPremisesImmutableId-Attribut in Entra ID. Stimmen beide Werte überein, ist das Objekt eindeutig zugeordnet. Dies ist die Methode, die bei normaler Synchronisation verwendet wird.
• Soft Match (Attribut-basiert): Wird verwendet, wenn kein Hard Match gefunden wird — typischerweise bei der Ersteinrichtung oder wenn Cloud-Objekte bereits vor der Sync-Einrichtung existieren. Entra Connect vergleicht userPrincipalName (UPN) oder proxyAddresses (primäre SMTP-Adresse). Findet es eine Übereinstimmung, wird das Cloud-Objekt mit dem On-Premises-Objekt verknüpft und die ImmutableID wird gesetzt.
• Reihenfolge: Hard Match wird immer zuerst versucht. Nur wenn kein Hard Match gefunden wird, fällt Entra Connect auf Soft Match zurück. Wird auch kein Soft Match gefunden, wird ein neues Cloud-Objekt erstellt.
• InvalidSoftMatch-Fehler: Dieser häufige Fehler tritt auf, wenn der Soft Match ein Cloud-Objekt findet, das bereits eine andere ImmutableID hat (d. h. es wurde zuvor per Hard Match einem anderen On-Premises-Objekt zugeordnet). Die UPN/SMTP stimmt überein, aber die ImmutableID nicht → Entra Connect kann das Objekt nicht sicher zuordnen und meldet einen Fehler.
• Wichtig ab Juni 2026: Microsoft blockiert Hard-Match-Zuordnungen für privilegierte Cloud-Konten (Global Admin, Privileged Role Admin etc.). Diese Änderung schützt vor SyncJacking-Angriffen, bedeutet aber auch, dass die manuelle Zuordnung privilegierter Konten andere Wege erfordert.

Häufige Sync-Fehler und ihre Ursachen

Die folgenden Fehler treten in der Praxis am häufigsten auf und sind fast immer auf ImmutableID/sourceAnchor-Probleme zurückzuführen.

• InvalidSoftMatch: „Unable to update this object because the following attributes associated with this object have values that may already be associated with another object in your local directory services.“ — Ursache: Ein On-Premises-Objekt hat denselben UPN oder dieselbe SMTP-Adresse wie ein Cloud-Objekt, aber die ImmutableIDs stimmen nicht überein. Typisches Szenario: Ein Benutzer wurde in Entra ID manuell angelegt, bevor Entra Connect eingerichtet wurde. Das Cloud-Objekt hat keine oder eine andere ImmutableID.
• ObjectTypeMismatch: „Unable to update this object because the object type is different.“ — Ursache: Ein Benutzerobjekt im AD soll mit einem Kontaktobjekt in Entra ID synchronisiert werden (oder umgekehrt). Dies passiert häufig, wenn ein Benutzer zuerst als Mail-Kontakt in Exchange Online angelegt wurde und später als AD-Benutzer synchronisiert werden soll.
• AttributeValueMustBeUnique: „The specified attribute value is already in use.“ — Ursache: Zwei verschiedene On-Premises-Objekte versuchen, mit derselben proxyAddresses- oder userPrincipalName-Adresse zu synchronisieren. Häufig bei: Shared Mailboxes, Distribution Groups und Benutzern, die dieselbe SMTP-Domäne teilen.
• IdentityDataValidationFailed: „Data validation for sourceAnchor (ImmutableId) failed.“ — Ursache: Der sourceAnchor-Wert enthält ungültige Zeichen oder hat ein falsches Format. Tritt auf, wenn das ms-DS-ConsistencyGuid-Attribut manuell mit einem falschen Wert beschrieben wurde.
• FederatedDomainChangeError: — Ursache: Der UPN eines Benutzers wurde auf eine federierte Domäne geändert, während das Objekt nicht korrekt synchronisiert ist. Bei federierten Domänen muss die ImmutableID exakt mit dem Claim im SAML-Token übereinstimmen, da der Identity Provider (ADFS/PingFederate) diesen Wert zur Authentifizierung verwendet.
• Verwaiste Objekte (Orphaned Objects): Objekte, die in Entra ID als „synced“ markiert sind, aber kein On-Premises-Gegenstück mehr haben. Ursache: Das AD-Objekt wurde gelöscht oder verschoben, ohne die Sync-Scope-Filter anzupassen. Diese Objekte können nicht über das Entra-Portal bearbeitet werden, da sie als „source of authority: On-Premises“ markiert sind.
• Source Anchor Has Changed: „The source anchor value has changed for this object.“ — Ursache: Das ms-DS-ConsistencyGuid oder objectGUID des On-Premises-Objekts hat sich geändert (z. B. nach einem Cross-Forest-Move oder einer AD-Wiederherstellung). Seit Entra Connect Version 2.3.20.0 gibt es spezielle Cmdlets (Get-ADSyncToolsDuplicateUsersSourceAnchor und Set-ADSyncToolsDuplicateUsersSourceAnchor) für Bulk-Reparaturen.

Diagnose mit PowerShell

Die folgenden PowerShell-Befehle helfen bei der Identifizierung und Analyse von ImmutableID-Problemen. Alle Befehle verwenden das aktuelle Microsoft Graph PowerShell SDK (das ältere AzureAD-Modul ist seit 30. März 2024 offiziell deprecated).

• ImmutableID eines Cloud-Benutzers abfragen:

  # Microsoft Graph PowerShell
  Connect-MgGraph -Scopes "User.Read.All"
  Get-MgUser -UserId "[email protected]" -Property OnPremisesImmutableId,OnPremisesSyncEnabled,UserPrincipalName | Select-Object UserPrincipalName, OnPremisesImmutableId, OnPremisesSyncEnabled

• sourceAnchor im On-Premises AD prüfen:

  # On-Premises Active Directory
  $user = Get-ADUser -Identity "benutzername" -Properties ms-DS-ConsistencyGuid, objectGUID
  
  # ms-DS-ConsistencyGuid als Base64 (= ImmutableID)
  [System.Convert]::ToBase64String($user.'ms-DS-ConsistencyGuid')
  
  # objectGUID als Base64 (Fallback-sourceAnchor)
  [System.Convert]::ToBase64String($user.objectGUID.ToByteArray())

• Alle Benutzer mit ImmutableID-Mismatch finden:

  # Alle synced Users aus Entra ID holen
  $cloudUsers = Get-MgUser -All -Filter "onPremisesSyncEnabled eq true" -Property UserPrincipalName,OnPremisesImmutableId
  
  # Pro Benutzer den On-Prem-Wert vergleichen
  foreach ($cu in $cloudUsers) {
      $adUser = Get-ADUser -Filter "UserPrincipalName -eq '$($cu.UserPrincipalName)'" -Properties ms-DS-ConsistencyGuid
      if ($adUser) {
          $onPremId = [System.Convert]::ToBase64String($adUser.'ms-DS-ConsistencyGuid')
          if ($onPremId -ne $cu.OnPremisesImmutableId) {
              Write-Warning "MISMATCH: $($cu.UserPrincipalName) | Cloud: $($cu.OnPremisesImmutableId) | OnPrem: $onPremId"
          }
      }
  }

• Verwaiste Objekte identifizieren:

  # Cloud-Benutzer, die als synced markiert sind, aber kein AD-Gegenstück haben
  $syncedUsers = Get-MgUser -All -Filter "onPremisesSyncEnabled eq true" -Property UserPrincipalName,OnPremisesImmutableId
  foreach ($su in $syncedUsers) {
      $adUser = Get-ADUser -Filter "UserPrincipalName -eq '$($su.UserPrincipalName)'" -ErrorAction SilentlyContinue
      if (-not $adUser) {
          Write-Warning "ORPHANED: $($su.UserPrincipalName) | ImmutableId: $($su.OnPremisesImmutableId)"
      }
  }

• Entra Connect Sync-Status prüfen:

  # Auf dem Entra Connect Server
  Import-Module ADSync
  Get-ADSyncConnectorRunStatus
  Get-ADSyncScheduler
  
  # Letzte Sync-Fehler anzeigen
  Get-ADSyncRunProfileResult -ConnectorName "IhreDomain.local" | Where-Object {$_.Result -ne "success"} | Select-Object -First 20

Lösungen & Reparatur

Je nach Fehlerbild gibt es unterschiedliche Lösungsansätze. Die folgenden Methoden decken die häufigsten Szenarien ab.

• Lösung 1 — ImmutableID zurücksetzen (Cloud-Objekt freigeben):

  Wenn ein Cloud-Objekt eine falsche ImmutableID hat, kann diese auf $null gesetzt werden. Dadurch wird das Objekt für einen neuen Soft Match freigegeben.

  # ImmutableID löschen (Graph PowerShell)
  Connect-MgGraph -Scopes "User.ReadWrite.All"
  Update-MgUser -UserId "[email protected]" -OnPremisesImmutableId ""
  
  # Danach: Delta-Sync auslösen
  Start-ADSyncSyncCycle -PolicyType Delta

  Wichtig: Dies funktioniert nur bei Cloud-managed Objekten oder bei Objekten, deren Sync deaktiviert wurde. Bei aktiv synchronisierten Objekten muss zuerst DirSync auf Tenant-Ebene oder der Connector-Filter angepasst werden.

• Lösung 2 — Hard Match erzwingen (ImmutableID manuell setzen):

  Wenn Sie wissen, welches On-Premises-Objekt welchem Cloud-Objekt zugeordnet werden soll, können Sie die ImmutableID manuell setzen.

  # 1. sourceAnchor des AD-Benutzers ermitteln
  $adUser = Get-ADUser -Identity "benutzername" -Properties ms-DS-ConsistencyGuid
  $immutableId = [System.Convert]::ToBase64String($adUser.'ms-DS-ConsistencyGuid')
  
  # 2. ImmutableID im Cloud-Objekt setzen
  Update-MgUser -UserId "[email protected]" -OnPremisesImmutableId $immutableId
  
  # 3. Delta-Sync starten
  Start-ADSyncSyncCycle -PolicyType Delta

• Lösung 3 — ObjectTypeMismatch beheben (Kontakt → Benutzer):

  Wenn ein Mail-Kontakt in Entra ID existiert und ein Benutzer aus dem AD synchronisiert werden soll:

  # 1. Mail-Kontakt in Exchange Online entfernen
  Remove-MailContact -Identity "[email protected]" -Confirm:$false
  
  # 2. Soft-deleted Object endgültig löschen
  Remove-MgDirectoryDeletedItem -DirectoryObjectId "<objectId>"
  
  # 3. Delta-Sync starten – erstellt den Benutzer neu
  Start-ADSyncSyncCycle -PolicyType Delta

• Lösung 4 — Verwaiste Objekte bereinigen:

  Für Objekte, die als „synced“ markiert sind, aber kein On-Prem-Gegenstück haben:

  # Option A: DirSync für den Benutzer deaktivieren (macht ihn cloud-managed)
  # Dazu: Benutzer aus dem Sync-Scope entfernen (OU-Filter oder Attribut-Filter)
  # und einen Full Sync durchführen:
  Start-ADSyncSyncCycle -PolicyType Initial
  
  # Option B: Benutzer in Entra ID löschen (nur wenn wirklich nicht mehr benötigt)
  Remove-MgUser -UserId "[email protected]"

• Lösung 5 — Bulk-Reparatur mit ADSync-Tools (ab Version 2.3.20.0):

  Für Massenprobleme nach Forest-Migrationen:

  # Duplikate finden
  Get-ADSyncToolsDuplicateUsersSourceAnchor -ForestFQDN "neuedomain.local"
  
  # sourceAnchor-Werte korrigieren
  Set-ADSyncToolsDuplicateUsersSourceAnchor -ForestFQDN "neuedomain.local" -Fix

Migrations-Szenarien

Die häufigsten ImmutableID-Probleme entstehen bei Migrationen. Hier sind die typischen Szenarien und wie man sie sauber löst.

• Szenario 1 — Cross-Forest-Migration (ADMT):

  Wenn Benutzer mit dem Active Directory Migration Tool (ADMT) von Forest A nach Forest B migriert werden, erhalten sie eine neue objectGUID. Wenn objectGUID als sourceAnchor verwendet wird, bricht der Sync.

  Lösung: Vor der Migration das ms-DS-ConsistencyGuid-Attribut im Quell-Forest auslesen und im Ziel-Forest setzen:

  # Im Quell-Forest: ms-DS-ConsistencyGuid exportieren
  Get-ADUser -Filter * -SearchBase "OU=Benutzer,DC=alt,DC=local" -Properties ms-DS-ConsistencyGuid | ForEach-Object {
      [PSCustomObject]@{
          SamAccountName = $_.SamAccountName
          ConsistencyGuid = [System.Convert]::ToBase64String($_.'ms-DS-ConsistencyGuid')
      }
  } | Export-Csv -Path "C:\Migration\ConsistencyGuids.csv" -NoTypeInformation
  
  # Im Ziel-Forest: ms-DS-ConsistencyGuid importieren
  Import-Csv "C:\Migration\ConsistencyGuids.csv" | ForEach-Object {
      $guidBytes = [System.Convert]::FromBase64String($_.ConsistencyGuid)
      Set-ADUser -Identity $_.SamAccountName -Replace @{'ms-DS-ConsistencyGuid' = $guidBytes}
  }

• Szenario 2 — Domänenkonsolidierung (mehrere AD-Domänen → eine):

  Beim Zusammenführen mehrerer Domänen müssen die sourceAnchor-Werte aller Benutzer erhalten bleiben. Wichtig: Konfigurieren Sie den neuen Entra Connect Server so, dass er ms-DS-ConsistencyGuid als sourceAnchor verwendet, und übertragen Sie die Werte aus allen Quell-Domänen.

• Szenario 3 — Swing Migration (Entra Connect Server-Wechsel):

  Beim Wechsel auf einen neuen Entra Connect Server im Staging Mode: Stellen Sie sicher, dass der neue Server dasselbe sourceAnchor-Attribut verwendet wie der alte. Mischen Sie nicht objectGUID und ms-DS-ConsistencyGuid. Prüfen Sie die Konfiguration im Wizard unter „Identifying users“.

• Szenario 4 — Wechsel von objectGUID auf ms-DS-ConsistencyGuid:

  Ein nachträglicher Wechsel des sourceAnchor-Attributs erfordert eine Neuinstallation von Entra Connect. Der Prozess:

  # 1. Staging-Server mit ms-DS-ConsistencyGuid einrichten
  # 2. Sicherstellen, dass alle AD-Objekte ms-DS-ConsistencyGuid gefüllt haben
  #    (Entra Connect füllt es automatisch beim ersten Sync)
  # 3. Export aller Connector-Space-Objekte vom alten Server
  # 4. Alten Server deaktivieren
  # 5. Staging-Server aktivieren (Full Sync)

• Szenario 5 — Migration zu Entra Cloud Sync:

  Microsoft empfiehlt für neue Installationen zunehmend Entra Cloud Sync (Agent-basiert, kein Server erforderlich) statt Entra Connect Sync. Cloud Sync verwendet immer ms-DS-ConsistencyGuid als sourceAnchor. Bei der Migration von Entra Connect zu Cloud Sync müssen die sourceAnchor-Werte identisch sein.

SyncJacking-Schutz 2026 — Neue Sicherheitsmaßnahmen

Im Januar 2026 veröffentlichte das Sicherheitsunternehmen Semperis die SyncJacking-Schwachstelle: Ein Angreifer mit Zugriff auf einen Entra Connect Server konnte durch Manipulation des Hard Match jeden beliebigen Cloud-Account übernehmen — einschließlich Global Administrator. Microsoft hat daraufhin mehrere Schutzmaßnahmen implementiert.

• Was ist SyncJacking? Ein Angreifer erstellt ein neues On-Premises-AD-Objekt mit einem gezielt gewählten sourceAnchor (ImmutableID), der dem eines privilegierten Cloud-Benutzers entspricht. Beim nächsten Sync übernimmt das neue On-Premises-Objekt die Kontrolle über den Cloud-Account — der Angreifer kann sich nun mit den On-Premises-Anmeldedaten als Global Admin anmelden. MSRC hat dies als „Important“ Privilege Escalation eingestuft.
• Neue Schutzregel (ab 01.06.2026): Entra ID blockiert jeden Versuch, ein neues On-Premises-Objekt per Hard Match mit einem bestehenden privilegierten Cloud-Benutzer zu verknüpfen. Betroffen sind Rollen wie Global Administrator, Privileged Role Administrator, Exchange Administrator, SharePoint Administrator und weitere administrative Rollen.
• Erweiterter Schutz für bestehende Zuordnungen: Wenn ein cloud-managed Benutzer bereits ein onPremisesImmutableId gesetzt hat und eine privilegierte Rolle besitzt, kann Entra Connect die Source of Authority dieses Benutzers nicht mehr ändern. Das verhindert die Übernahme bereits zugeordneter privilegierter Konten.
• Neue Audit-Logs: Änderungen an OnPremisesObjectIdentifier und DirSyncEnabled werden jetzt explizit in den Entra ID Audit Logs erfasst. Admins können über Entra ID → Monitoring → Audit logs nach diesen Änderungen filtern.
• Ausnahme für legitime Szenarien: Administratoren können den OnPremisesObjectIdentifier manuell zurücksetzen, wenn eine legitime Neuzuordnung erforderlich ist (z. B. nach einer geplanten Migration). Dies erfordert die Rolle Hybrid Identity Administrator oder Global Administrator.
• Nicht-privilegierte Konten: Hard-Match-Operationen für Benutzer ohne privilegierte Rollen sind nicht betroffen. Soft-Match-Verhalten bleibt ebenfalls unverändert.
• Versions-Pflicht: Alle Entra Connect Sync-Dienste müssen bis zum 30. September 2026 mindestens auf Version 2.5.79.0 aktualisiert sein. Ältere Versionen werden ab diesem Datum nicht mehr funktionieren.

Best Practices

• Immer ms-DS-ConsistencyGuid verwenden: Prüfen Sie Ihre Entra Connect Konfiguration. Wenn Sie noch objectGUID verwenden, planen Sie eine Swing Migration auf ms-DS-ConsistencyGuid. Dies ist die einzige zukunftssichere Konfiguration.
• Vor jeder Migration: sourceAnchor exportieren: Bevor Sie Benutzer zwischen Forests, Domänen oder OUs verschieben, exportieren Sie immer die ms-DS-ConsistencyGuid-Werte. Erstellen Sie ein Rollback-Skript für den Notfall.
• Keine Benutzer manuell in Entra ID anlegen: Wenn Sie Hybrid Identity verwenden, erstellen Sie Benutzer ausschließlich im On-Premises AD und lassen Sie Entra Connect die Synchronisation übernehmen. Manuell angelegte Cloud-Benutzer führen fast immer zu Soft-Match-Konflikten.
• OU-Filter sauber halten: Stellen Sie sicher, dass Ihre OU-Filter in Entra Connect aktuell sind. Nicht synchronisierte OUs, die versehentlich Benutzerobjekte enthalten, führen zu verwaisten Cloud-Objekten.
• Staging Server bereithalten: Betreiben Sie immer einen zweiten Entra Connect Server im Staging Mode. Dies ermöglicht schnelle Failover und sichere Konfigurationsänderungen.
• Regelmäßige Sync-Health-Prüfung: Überwachen Sie den Entra Connect Health Service im Entra Admin Center. Richten Sie E-Mail-Benachrichtigungen für Sync-Fehler ein. Reagieren Sie auf Fehler innerhalb von 24 Stunden — je länger ein Sync-Fehler besteht, desto schwieriger wird die Reparatur.
• Version aktuell halten: Aktualisieren Sie Entra Connect regelmäßig. Die Auto-Upgrade-Funktion funktioniert nur bei Express-Installationen. Bei Custom-Installationen müssen Sie manuell aktualisieren. Deadline: Version 2.5.79.0 bis 30.09.2026.
• Privilegierte Konten schützen: Erstellen Sie dedizierte Cloud-only Admin-Konten für privilegierte Rollen (Global Admin, Exchange Admin etc.). Diese sollten nicht mit dem On-Premises AD synchronisiert werden. Verwenden Sie für diese Konten MFA, Conditional Access und Privileged Identity Management (PIM).

IT-ZU Unterstützung

Die Diagnose und Reparatur von ImmutableID-Problemen erfordert tiefes Verständnis der Entra Connect Architektur, Active Directory Internals und der Microsoft Graph API. Als Hybrid-Identity-Spezialisten unterstützen wir Sie bei:

• Sync-Fehler-Analyse: Systematische Identifizierung aller ImmutableID-Mismatches, verwaisten Objekte und Duplikate in Ihrer Umgebung.
• Cross-Forest-Migration: Planung und Durchführung von sourceAnchor-erhaltenden Migrationen zwischen AD-Forests.
• Entra Connect Health Check: Überprüfung Ihrer aktuellen Konfiguration, sourceAnchor-Einstellungen, OU-Filter und Sync-Regeln.
• SyncJacking-Audit: Überprüfung Ihrer privilegierten Cloud-Konten auf potenzielle Übernahmevektoren und Implementierung der neuen Schutzmaßnahmen.
• Migration auf Entra Cloud Sync: Bewertung, ob ein Wechsel von Entra Connect Sync auf Cloud Sync für Ihre Umgebung sinnvoll ist.