Konfigurieren von Microsoft Entra Connect für einen vorhandenen Mandanten

In den meisten Artikeln zur Verwendung von Microsoft Entra Connect wird davon ausgegangen, dass Sie mit einem neuen Microsoft Entra Mandanten beginnen, der keine Benutzer oder andere Objekte enthält. Wenn Sie jedoch mit einem Microsoft Entra Mandanten begonnen haben, es mit Benutzern und anderen Objekten aufgefüllt haben und jetzt Connect verwenden möchten, ist dieser Artikel für Sie vorgesehen.

Grundlagen

Ein Objekt in Microsoft Entra ID wird entweder in der Cloud oder lokal verwaltet. Für ein einzelnes Objekt können Sie einige Attribute nicht lokal und einige andere Attribute in Microsoft Entra ID nicht verwalten. Jedes Objekt verfügt über ein Flag, das angibt, wo das Objekt verwaltet wird.

Sie können einige Benutzer lokal und andere in der Cloud verwalten. Ein gängiges Szenario für diese Konfiguration ist eine Organisation mit einer Mischung aus Buchhaltungsmitarbeitern und Vertriebsmitarbeitern. Die Buchhaltungsmitarbeiter haben ein lokales Active Directory -Konto (AD), und die Vertriebsmitarbeiter haben keine, aber beide haben ein Konto in Microsoft Entra ID. Sie würden einige Benutzer lokal und andere in Microsoft Entra ID verwalten.

Es gibt einige zusätzliche Bedenken, die Sie berücksichtigen müssen, wenn Sie mit der Verwaltung von Benutzern in Microsoft Entra ID begonnen haben, die auch lokal vorhanden sind und später Microsoft Entra Connect verwenden möchten.

Synchronisieren mit vorhandenen Benutzern in Microsoft Entra ID

Wenn Sie die Synchronisierung mit Microsoft Entra Connect starten, überprüft die Microsoft Entra Service-API jedes neue eingehende Objekt und versucht, ein vorhandenes Objekt zu finden, das übereinstimmt. Für diesen Prozess werden drei Attribute verwendet: userPrincipalName, proxyAddresses und sourceAnchor/immutableID. Eine Übereinstimmung für "userPrincipalName " oder "proxyAddresses " wird als "weiche Übereinstimmung" bezeichnet. Eine Übereinstimmung für sourceAnchor wird als "harte Übereinstimmung" bezeichnet. Für das Attribut proxyAddresses wird nur der Wert mit SMTP:, d. h. die primäre E-Mail-Adresse, für die Auswertung verwendet.

Die Übereinstimmung wird nur für neue Objekte ausgewertet, die aus dem lokalen AD stammen. Wenn Sie ein vorhandenes Objekt so ändern, dass es mit einem dieser Attribute übereinstimmt, wird stattdessen ein Fehler angezeigt.

Wenn Microsoft Entra ID ein Objekt findet, bei dem die Attributwerte mit denen des neuen eingehenden Objekts von Microsoft Entra Connect identisch sind, übernimmt es das Objekt in Microsoft Entra ID, und das zuvor in der Cloud verwaltete Objekt wird in lokal verwaltet konvertiert. Alle Attribute in Microsoft Entra ID, die in on-premises AD einen Wert haben, werden mit dem jeweiligen lokalen Wert überschrieben.

Warnung

Da alle Attribute in Microsoft Entra ID durch den lokalen Wert überschrieben werden, stellen Sie sicher, dass Sie über gute lokale Daten verfügen. Wenn Sie beispielsweise nur die E-Mail-Adresse in Microsoft 365 verwalten und sie nicht in lokalen Active Directory Domain Services (AD DS) aktualisiert haben, gehen alle Werte in Microsoft Entra ID/Microsoft 365 verloren, die in AD DS nicht vorhanden sind.

Von Bedeutung

Wenn Sie die Kennworthashsynchronisierung verwenden, die immer mit Express-Installation aktiviert ist, wird der Kennworthash in der Microsoft Entra-ID mit dem Kennworthash von lokalem AD überschrieben. Wenn Ihre Benutzer es gewohnt sind, unterschiedliche Kennwörter zu verwalten, müssen Sie sie darüber informieren, dass sie das lokale AD-Kennwort verwenden sollten.

Berücksichtigen Sie beim Planen der Bereitstellung die vorstehende Warnung zum Datenverlust. Wenn Sie viele Änderungen in Microsoft Entra ID vorgenommen haben, die im lokalen AD DS nicht widergespiegelt wurden, sollten Sie zur Vermeidung von Datenverlust planen, wie Sie AD DS mit den aktualisierten Werten aus Microsoft Entra ID befüllen, bevor Sie Ihre Objekte mit Microsoft Entra Connect synchronisieren.

Wenn Sie Ihre Objekte mit einem weichen Abgleich abgeglichen haben, wird dem Objekt in Microsoft Entra ID ein sourceAnchor hinzugefügt, sodass später eine harte Übereinstimmung verwendet werden kann.

Von Bedeutung

Microsoft rät dringend davon ab, lokale Konten mit bereits vorhandenen Administratorkonten in Microsoft Entra ID zu synchronisieren.

Harder Ableich im Vergleich zu weicher Abgleich

Standardmäßig ist der SourceAnchor-Wert eines Objekts, z. B. "abcdefghijklmnopqrstuv==", die Base64-Zeichenfolgendarstellung des mS-Ds-ConsistencyGUID-Attributs (oder ObjectGUID, je nach Konfiguration) aus dem lokalen Active Directory-Objekt. Dieser Wert wird als entsprechende ImmutableId in Microsoft Entra ID festgelegt.

Wenn Microsoft Entra Connect oder Cloud Sync neue Objekte hinzufügt, versucht der Microsoft Entra ID-Dienst, das eingehende Objekt abzugleichen, indem er den sourceAnchor-Wert verwendet, der dem ImmutableId-Attribut vorhandener Objekte in Microsoft Entra ID entspricht. Wenn es eine Übereinstimmung gibt, übernimmt Microsoft Entra Connect die Quellautorität (SoA) für dieses Objekt und aktualisiert es mit den Eigenschaften des eingehenden lokalen Active Directory-Objekts, in einem Vorgang, der als hard match bezeichnet wird. Wenn Microsoft Entra ID kein Objekt mit einer Unveränderlichen ID finden kann, die dem SourceAnchor-Wert entspricht, versucht es, die userPrincipalName- oder primäre SMTP-Adresse des eingehenden Objekts zu verwenden, um eine Übereinstimmung in der sogenannten weichen Übereinstimmung zu finden.

Sowohl hard match als auch soft match versuchen, bereits in Microsoft Entra ID vorhandene und verwaltete Objekte mit den neu eingehenden Objekten abzugleichen, die hinzugefügt werden und dieselbe lokale Entität darstellen. Wenn Microsoft Entra ID keine harte Übereinstimmung oder weiche Übereinstimmung für das eingehende Objekt finden kann, stellt es ein neues Objekt im Microsoft Entra ID Verzeichnis bereit.

Wenn Microsoft Entra ID das neue eingehende Objekt weich abgleichen kann, basierend auf der primären SMTP-Adresse mit einem vorhandenen Objekt, das in Microsoft Entra ID verwaltet wird, aber dieses neue Objekt einen anderen sourceAnchor-Wert aufweist, dann versucht Microsoft Entra ID, ein neues Objekt bereitzustellen. Der Bereitstellungsversuch führt normalerweise zu einem Konflikt, in dem Microsoft Entra ID das neue Objekt nicht erstellen kann. Dieser Konflikt tritt in Situationen auf wie:

  • Ein anderer sourceAnchor-Wert wurde im mS-Ds-ConsistencyGuid Attribut für den ursprünglichen lokalen AD-Benutzer festgelegt, der bereits mit der Entra ID synchronisiert wurde.

  • Ein neuer lokaler AD-Benutzer wurde mit demselben UPN und derselben primären SMTP-Adresse erstellt, verfügt jedoch über einen anderen sourceAnchor und eine andere SID.

In solchen Fällen wird ein AttributeValueMustBeUnique Exportfehler in Microsoft Entra Connect oder Cloud Sync ausgelöst. Abhängig von den Eigenschaften des eingehenden Benutzers kann sich dieser Fehler auf einen der folgenden Attributkonflikte beziehen:

  • AttributeConflictName = OnPremiseSecurityIdentifier: Das neue eingehende Objekt hat einen anderen sourceAnchor, aber dieselbe OnPremiseSecurityIdentifier (SID) und primäre SMTP-Adresse wie der vorhandene Benutzer im Entra ID-Verzeichnis.

  • AttributeConflictName = ProxyAddresses: Das neue eingehende Objekt hat einen anderen sourceAnchor und eine andere SID, aber dieselbe primäre SMTP-Adresse wie der vorhandene Benutzer im Entra ID-Verzeichnis.

Hinweis

In einigen seltenen Situationen tritt ein OnPremiseSecurityIdentifier Konflikt aufgrund eines Problems mit dem lokalen AD-RID-Pool auf (z. B. ein Domänencontroller, der aus der Sicherung wiederhergestellt wurde), der einen neuen Benutzer mit derselben SID generieren kann. In solchen Fällen wird beim Versuch, den Benutzer zu provisionieren, ein AttributeValueMustBeUnique-Fehler ausgelöst, und zwar nicht aufgrund von Soft-Match-Versuchen, sondern weil OnPremiseSecurityIdentifier im Entra ID-Verzeichnis eindeutig sein muss.

Diese Szenarien bedeuten in der Regel, dass Sie versuchen, denselben Benutzer erneut bereitzustellen. Um den Konflikt zu lösen, sollten Sie das mS-Ds-ConsistencyGuid Attribut des lokalen Benutzers so aktualisieren, dass es mit dem gleichen Wert wie die ImmutableID des vorhandenen Cloudbenutzers übereinstimmt. Diese Änderung ermöglicht es Microsoft Entra ID, den korrekten Hard Match durchzuführen.

Blockieren von harten Abgleichen in Microsoft Entra ID

Wir haben eine Konfigurationsoption hinzugefügt, um die Hard-Matching-Funktion in Microsoft Entra ID zu deaktivieren. Wir empfehlen unseren Kunden, Hard Matching zu deaktivieren, es sei denn, sie benötigen dieses Verfahren, um reine Cloudkonten zu übernehmen.

Verwenden Sie zum Deaktivieren des harten Abgleichs das Microsoft Graph PowerShell-Cmdlet Update-MgDirectoryOnPremiseSynchronization :

Connect-MgGraph -Scopes "OnPremDirectorySynchronization.ReadWrite.All"

$OnPremSync = Get-MgDirectoryOnPremiseSynchronization
$OnPremSync.Features.BlockCloudObjectTakeoverThroughHardMatchEnabled = $true
Update-MgDirectoryOnPremiseSynchronization `
    -OnPremisesDirectorySynchronizationId $OnPremSync.Id `
    -Features $OnPremSync.Features

Blockieren von weichen Abgleichen in Microsoft Entra ID

Auf ähnliche Weise haben wir eine Konfigurationsoption hinzugefügt, um die Option für den Soft-Matching in Microsoft Entra ID zu deaktivieren. Wir empfehlen Kunden, Soft Matching zu deaktivieren, es sei denn, sie benötigen es, um ausschließlich in der Cloud vorhandene Konten zu übernehmen.

Um den weichen Abgleich zu deaktivieren, verwenden Sie das Microsoft Graph PowerShell-Cmdlet Update-MgDirectoryOnPremiseSynchronization :

Connect-MgGraph -Scopes "OnPremDirectorySynchronization.ReadWrite.All"

$OnPremSync = Get-MgDirectoryOnPremiseSynchronization
$OnPremSync.Features.BlockSoftMatchEnabled = $true
Update-MgDirectoryOnPremiseSynchronization `
    -OnPremisesDirectorySynchronizationId $OnPremSync.Id `
    -Features $OnPremSync.Features

Hinweis

BlockCloudObjectTakeoverThroughHardMatchEnabled und BlockSoftMatchEnabled werden zum Blockieren der Zuordnung für alle Objekte verwendet, sofern die Option für den Mandanten aktiviert ist. Kunden wird empfohlen, diese Funktionen nur während des Zeitraums zu deaktivieren, in dem ein Abgleichsverfahren für ihren Mietvertrag erforderlich ist. Dieses Flag sollte nach Abschluss des Abgleichs wieder auf True gesetzt werden und wird nicht mehr benötigt.

Sicherheitsschutz für harte Abgleiche

Ab dem 1. Juli 2026 führt Microsoft Entra ID zusätzliche Schutzmaßnahmen für harte Abgleichsvorgänge ein. Diese Schutzmaßnahmen helfen zu verhindern, dass ein lokales Active Directory-Objekt fälschlicherweise dem falschen Cloudkonto zugeordnet wird, wenn eine erneute Zuordnung zum Zielkonto riskant ist.

Ein Hard Match kann verhindert werden, wenn das Cloud-Zielkonto eine oder mehrere dieser Bedingungen erfüllt:

  • Für das Cloudkonto ist onPremisesObjectIdentifier bereits konfiguriert.
  • Dem Cloudkonto wird eine privilegierte Microsoft Entra Rolle zugewiesen.
  • Das Cloudkonto ist für eine privilegierte Microsoft Entra Rolle berechtigt.

Diese Sicherheitsmechanismen deaktivieren den harten Abgleich nicht. Der anfängliche Hard Match für sichere Zielobjekte funktioniert weiterhin, und die laufende Synchronisierung für Benutzer, die bereits korrekt zugeordnet sind, ist nicht betroffen. Cloudverwaltete Konten mit aktiviertem Rückschreiben werden von dieser Erzwingung ausgeschlossen. Die Überprüfung wird in der Cloud erzwungen, sodass sie unabhängig von der Clientversion sowohl für Microsoft Entra Connect Sync als auch für Microsoft Entra Cloud Sync gilt. Verhalten bei weichen Übereinstimmungen bleibt unverändert und wird weiterhin separat durch die BlockSoftMatchEnabled-Funktion gesteuert.

Die genauen Fehlermeldungen und fehlerspezifischen Korrekturen finden Sie unter "Problembehandlung für InvalidHardMatch"-Fehler.

Caution

Verwenden Sie Hard Match nicht als allgemeinen Mechanismus zur Fehlerbehebung für privilegierte Konten oder für Konten, die bereits einem lokalen Verzeichnisobjekt zugeordnet sind. Wenn das falsche lokale Objekt mit einem Cloudkonto verknüpft ist, kann das Konto die falsche Autoritätsquelle erben. Bestätigen Sie die beabsichtigte Zuordnung, bevor Sie die Synchronisierung wiederholen.

Bevor Sie einen Hard Match durchführen, stellen Sie sicher, dass der Cloud-Zielbenutzer alle folgenden Anforderungen erfüllt:

  • Er stellt denselben Benutzer wie das lokale Objekt dar.

  • Der lokale Quellankerwert stimmt exakt mit dem Wert onPremisesImmutableId des Benutzers überein.

  • Es ist weder zugewiesen noch für eine privilegierte Microsoft Entra-Rolle geeignet. Entfernen Sie alle privilegierten Rollenzuweisungen oder Berechtigungen, bevor Sie fortfahren.

  • Das Cloudkonto verfügt noch nicht über eine andere onPremisesObjectIdentifier Auffüllung. Löschen Sie den Wert, falls erforderlich, bevor Sie den Vorgang wiederholen.

Hard-Match-Szenarien und Wiederherstellungspfade

In der folgenden Tabelle werden allgemeine Szenarien für harte Übereinstimmungen zusammengefasst, unabhängig davon, ob Microsoft Entra ID die einzelnen Szenarien zulässt oder blockiert und wie Sie wiederherstellen können.

Scenario Result Wiederherstellung
Ein neuer lokaler Benutzer stimmt schwer mit einem nicht privilegierten Cloudbenutzer überein, der noch nicht zugeordnet ist. Der harte Abgleich wird fortgesetzt Keine Maßnahme nötig, wenn der harte Abgleich beabsichtigt ist.
Dem Benutzer der Ziel-Cloud ist eine privilegierte Rolle zugewiesen. Harter Abgleich blockiert Entfernen Sie die Rolle vorübergehend, führen Sie dann den Hard Match durch und weisen Sie sie anschließend erneut zu.
Der Zielcloudbenutzer ist für eine privilegierte Rolle berechtigt. Harter Abgleich blockiert Entfernen Sie die Berechtigung vorübergehend, führen Sie den Hard Match durch und stellen Sie die Berechtigung dann wieder her.
Der Ziel-Cloudbenutzer ist vorläufig gelöscht und privilegiert Harter Abgleich blockiert Stellen Sie den Benutzer bei Bedarf wieder her, und wenden Sie dann die Wiederherstellung privilegierter Rollen an.
Der Cloudzielbenutzer hat onPremisesObjectIdentifier bereits festgelegt (z. B. nachdem ein AD-Benutzer neu erstellt wurde, eine Gesamtstruktur- oder Domänenverschiebung erfolgt ist oder eine Fusion stattgefunden hat) Neuzuordnung blockiert (AttributeUpdateNotAllowed) Überprüfen Sie das vorgesehene Quellobjekt, leeren Sie onPremisesObjectIdentifier bis null, und führen Sie dann die Synchronisierung erneut aus.
Sie können vor der Erzwingung keine Korrekturen ausführen. Vorübergehende Umgehung Aktivieren Sie allowOnPremUpdateOfOnPremisesObjectIdentifierEnabled, beheben Sie das Problem, und deaktivieren Sie es.
Einen Hard Match beheben, der von einer privilegierten Rolle blockiert wird

Wenn der Cloudbenutzer über eine privilegierte Rollenzuweisung oder Berechtigung verfügt:

  1. Vergewissern Sie sich, dass das lokale Objekt mit dem vorhandenen Cloudbenutzer verknüpft werden soll.
  2. Wenn der Benutzer vorläufig gelöscht wird, stellen Sie ihn aus dem Microsoft Entra ID Papierkorb wieder her.
  3. Entfernen Sie vorübergehend die Zuweisung privilegierter Rollen oder die Berechtigung vom Cloudbenutzer.
  4. Führen Sie die Synchronisierung erneut aus, um den Hard Match abzuschließen.
  5. Weisen Sie die privilegierte Rolle neu zu, oder stellen Sie die Berechtigung wieder her.

Von Bedeutung

Lassen Sie privilegierten Zugriff nicht länger als nötig deaktiviert. Stellen Sie die Rollenzuweisung oder Berechtigung wieder her, nachdem der harte Abgleich erfolgreich durchgeführt wurde.

OnPremisesObjectIdentifier löschen

Wenn der Hard Match blockiert ist, weil onPremisesObjectIdentifier bereits festgelegt ist, setzen Sie den Wert auf null zurück und führen Sie die Synchronisierung anschließend erneut aus. Verwenden Sie Microsoft Graph oder ADSyncTools.

Um mit Microsoft Graph zu löschenonPremisesObjectIdentifier, damit die Synchronisierung fortgesetzt werden kann, senden Sie die folgende Anforderung:

PATCH https://graph.microsoft.com/beta/users/{userId}
Content-Type: application/json

{
  "onPremisesObjectIdentifier": null
}

Diese PATCH-Anfrage erfordert die Berechtigung User-OnPremisesSyncBehavior.ReadWrite.All Microsoft Graph sowie die Rolle „Global Administrator“ oder „Hybrid Identity-Administrator“.

Hinweis

Sie können onPremisesObjectIdentifier nur löschen, indem Sie es auf null setzen. Versuche, sie auf einen anderen Wert festzulegen, werden blockiert. Nachdem Sie den Wert gelöscht und die Synchronisierung erneut ausgeführt haben, wird beim nächsten erfolgreichen Synchronisierungsstempel ein neuer Wert angezeigt.

Führen Sie alternativ zum Löschen onPremisesObjectIdentifier mit ADSyncTools, Version 2.5.0 oder höher, die folgenden Befehle aus:

# Import ADSyncTools module
Import-Module ADSyncTools -MinimumVersion 2.5

# Provide the user's identity.
$userId = "<userId>"

# Review the current on-premises attributes.
Get-ADSyncToolsOnPremisesAttribute -Id $userId

# Optional: back up the current values before making changes.
Get-ADSyncToolsOnPremisesAttribute -Id $userId | Export-Clixml backupOnpremisesAttributes.Clixml

# Clear onPremisesObjectIdentifier.
Clear-ADSyncToolsOnPremisesAttribute -Id $userId -onPremisesObjectIdentifier

Nachdem Sie den Wert gelöscht haben, führen Sie die Synchronisierung erneut aus.

Vorübergehendes Zulassen von OnPremisesObjectIdentifier-Updates

Wenn Sie betroffene Objekte vor der Erzwingung nicht beheben können, aktivieren Sie das Feature-Flag allowOnPremUpdateOfOnPremisesObjectIdentifierEnabledauf Mandantenebene. Dieser Flag ist standardmäßig deaktiviert. Lassen Sie die Kennzeichnung deaktiviert, es sei denn, Sie benötigen eine temporäre Umgehung, während Sie die Wartung abgeschlossen haben.

# Connect to Microsoft Graph.
Connect-MgGraph -Scopes "OnPremDirectorySynchronization.ReadWrite.All"

# Enable the temporary bypass.
$OnPremSync = Get-MgDirectoryOnPremiseSynchronization
$OnPremSync.Features.AllowOnPremUpdateOfOnPremisesObjectIdentifierEnabled = $true

Update-MgDirectoryOnPremiseSynchronization `
    -OnPremisesDirectorySynchronizationId $OnPremSync.Id `
    -Features $OnPremSync.Features

# Verify the current value.
$OnPremSync = Get-MgDirectoryOnPremiseSynchronization
$OnPremSync.Features.AllowOnPremUpdateOfOnPremisesObjectIdentifierEnabled

Um den Schutz für harte Übereinstimmungen nach der Korrektur erneut zu aktivieren, legen Sie das Flag auf $false:

$OnPremSync = Get-MgDirectoryOnPremiseSynchronization
$OnPremSync.Features.AllowOnPremUpdateOfOnPremisesObjectIdentifierEnabled = $false

Update-MgDirectoryOnPremiseSynchronization `
    -OnPremisesDirectorySynchronizationId $OnPremSync.Id `
    -Features $OnPremSync.Features

Warnung

Durch das Aktivieren dieses Feature-Flags wird der durch die Sicherheitserzwingung für genaue Übereinstimmungen gebotene Schutz verringert. Verwenden Sie sie nur als temporäre Umgehung für ein überprüftes Migrations-, Wiederherstellungs- oder Konsolidierungsszenario. Deaktivieren Sie die Umgehung nach Abschluss der Wartung.

Andere Objekte als Benutzer

Für E-Mail-aktivierte Gruppen und Kontakte können Sie ein Soft Match basierend auf proxyAddresses durchführen. Eine harte Übereinstimmung ist nicht möglich, da Sie sourceAnchor/immutableID bei Benutzern nur mit PowerShell aktualisieren können. Für nicht e-mail-aktivierte Gruppen gibt es weder übtersttzung für weichen Abgleich noch für harten Abgleich.

Überlegungen zum Soft Matching eines Benutzers mit Administratorrolle

Zum Schutz vor nicht vertrauenswürdigen lokalen Benutzern gleicht Microsoft Entra ID lokale Benutzer nicht mit Cloudbenutzern ab, die über eine Administratorrolle verfügen. Dies ist das Standardverhalten. Führen Sie die folgenden Schritte aus, um sie zu umgehen:

  1. Entfernen Sie die Verzeichnisrollen aus dem reinen Cloud-Benutzerobjekt.
  2. Löschen Sie das neue, in der Cloud erstellte Objekt, das unter Quarantäne gestellt wurde, endgültig.
  3. Lösen Sie einen neuen Synchronisierungszyklus aus.
  4. Fügen Sie optional die Verzeichnisrollen zurück zum Benutzerobjekt in der Cloud hinzu, nachdem der Abgleich abgeschlossen wurde.

Erstellen eines neuen lokalen Active Directory aus Daten in Microsoft Entra ID

Einige Kunden beginnen mit einer reinen Cloudlösung mit Microsoft Entra ID und verfügen nicht über ein lokales AD. Später möchten sie lokale Ressourcen nutzen und ein lokales AD basierend auf Microsoft Entra Daten erstellen. Microsoft Entra Connect kann diesem Szenario nicht helfen. Es werden keine Benutzer lokal erstellt, und es gibt keine Möglichkeit, das Kennwort lokal auf das gleiche wie in Microsoft Entra ID festzulegen.

Wenn Sie nur lokale AD hinzufügen möchten, um Branchen-Apps zu unterstützen, sollten Sie stattdessen Microsoft Entra Domain Services verwenden.

Verwandte Inhalte

Weitere Informationen finden Sie unter Integrieren Ihrer lokalen Identitäten in Microsoft Entra ID.

  • Zuletzt aktualisiert um