SourceAnchor

Diese Seite beschreibt, wie ADSync die Objekte aus den lokalen Active Directory Domänen und Forests mit den korrespondierenden Objekten im AzureAD verknüpft. Dazu bildet ADSync aus konfigurierten Quellen einen "Sourceanchor", der bei Benutzern als "ImmutableID" in de Cloud erscheint und bei Gruppen und Kontakten als CN.

Herausforderung DirSync

Jeder Verzeichnisabgleich hat nicht nur die Aufgabe, neue Objekte in der Quelle auch im Ziel anzulegen und die Inhalte zu übertragen, sondern muss die Objekte dauerhaft verwalten. Dazu gehören auch Sonderfälle wie:

  • Objekt wird gelöscht
    Dann muss der DirSync das fehlende Objekt erkennen und auch im Ziel deprovisionieren
  • Unterschiedliche Verzeichnisdienste verwalten
    In einem lokale Active Directory gibt es z.B. eine SID, die sie so im AzureAD nicht finden.
  • Objekt wird umbenannt oder verlagert
    Das ist der spannende Teil, denn die Zuordnung von Quelle und Ziel muss dennoch erhalten bleiben. Damit scheiden auch anscheinend stabile Felder wie SID, Object, CN, DistinguishedName aber auch Mail, Displayname u.a. aus.
  • Bidirektional
    Dann werden die Herausforderungen noch einmal komplexer, da Felder auf beiden Seiten geändert werden können.
  • Mehrwertige Felder
    Bei einer Windows Gruppe enthält das Feld "member" mehrere Einträge. Beim ersten Sync können Sie die komplett kopieren aber wenn später nur ein Objekt geändert wird, dann sollte auch nur das "Delta" übertragen werden.
  • Feldumschreibungen
    Einige Feldinhalte müssen übersetzt werden. So enthält das Feld "Member" einer Gruppe oder auch der "Manager" eines Objekts einen Verweis zum "distinguishedname". Diesen Wert gibt es so auf der anderen Seite nicht immer und daher muss der DirSync schauen, dass er im Ziel dann die Liste mit den im Ziel gültigen Inhalten füllt.

Das ist nur ein Auszug aber sie sehen schon sehr schnell.

Ein Verzeichnisabgleich braucht irgendwo etwas Platz, um die Zuordnung der Objekte zu speichern, welches eindeutig und unveränderlich ist und idealweise von Administratoren nicht gesehen wird

In der Vergangenheit habe ich schon mehrfach eigene "Synchronisationsroutinen" bei Kunden entwickelt und erweitert. Einige habe ich auf den folgenden Seiten dokumentiert:

Source Anchor nach Objekt und Version

Damit ADSync die Verbindung zwischen lokalen Objekten und AzureAD-Objekten halten kann, muss es eine Information aus dem lokalen AD zum primären Schlüssel umfunktionieren. ADSync nutzte dazu am Anfang ausschließlich die ObjectGUID oder ein vom Administrator bei der Ersteinrichtung von ADSync vorgegebene eindeutiges Feld.

Irgendwann ist dann aufgefallen, dass die ObjectGUID bei Migrationen in einen anderen Forest nicht beibehalten werden kann und dies ein kniffliges "Matching" mit sich bringt. Daher hat ADSync ab Version 1.1.552.0 sein Verhalten erweitert und prüft erst das seit Windows 2000 vorhandene Feld "ms-DS-ConsistencyGUID", welches auch übertragen werden kann. ADSync schreibt auch das Feld, wenn es noch nicht belegt ist. Normalerweise ist dann die ObjectGUID auch noch mal in ms-DS-ConsistencyGUID. Schauen wir uns erst einmal an, welches Felder welche ADSync-Version mit welchem Objekte nutzt nutzt.

ADSync Version ReleaseDate User Group Computer

DirSync

2007?

ObjectGUID

ObjectGUID

ObjectGUID

Azure ADSync

September 2014

ObjectGUID

ObjectGUID

ObjectGUID

Azure AD Connect 1.1.524.0 und früher

Mai 2017

ObjectGUID

ObjectGUID

ObjectGUID

Azure AD Connect ab 1.1.553.0

Juni 2017

ms-DS-consistencyGuid

ObjectGUID

ObjectGUID

Azure AD Connect ab 1.5.18.0 und neuer

2. April 2020

ms-DS-consistencyGuid

ms-DS-ConsistencyGuid

ObjectGUID

Sie sehen aber auch, dass Computerobjekte weiterhin auf der ObjectGUID basieren. Das ist aber nicht weiter tragisch, denn wenn ein Computer in einen anderen Forest verschoben wird, dann bekommt er ja auch komplett neue Einstellungen und sollte daher im AzureAD dann auch gelöscht und neu angemeldet werden. Siehe auch ADSync mit Devices. Der Wechsel von ObjectGUID auf ms-DS-ConsistencyGuid passiert aber nicht automatisch. Sie müssen schon schon selbst Hand anlegen und Sie benötigen mindestens ADSync Version 1.1.552.0 um das Verhalten zu aktivieren.

... Azure AD Connect uses the value of mS-DS-ConsistencyGuid as the immutableId. Otherwise, it falls back to using objectGUID....
Quelle https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-migrate-groups

Für Gruppen gibt es noch eine Besonderheit, auf die ich aber auch der Seite SourceAnchor Gruppen noch weiter eingehe:

... But note that Azure AD Connect doesn't write the value back to the mS-DS-ConsistencyGuid attribute in Active Directory...
Quelle https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-migrate-groups

Das Thema ADSync kann also durchaus knifflig sein.

ImmutableID Encoding und Decoding

Der Sourceanchor aus dem lokalen Active Directory ist nicht immer ein String. Die ObjectGUID und ms-DS-ConsistencyGUID sind z.B. Byte-Arrays. Im AzureAD wird das Feld "ImmutableID" bei Benutzern verwendet. Dies ist aber ein String. daher ist ggfls. eine Konvertierung der Inhalte erforderlich. Wenn die ObjectGUID bzw. ms-DS-ConsistencyGUID aus dem lokalen AD genutzt wird, dann kommt eine BASE64-Umwandung zum Einsatz. Wenn Sie ein eigenes "Text-String"-Feld nutzen, dann wird nichts konvertiert. Folgenden Ablauf habe ich ermittelt.

Interessant ist hier, dass das Rückschreiben des ms-DS-ConsistencyGuid aus dem SourceAnchorBinary erfolgt, wenn das Feld "CloudSourceAnchor" gesetzt ist.

Die Anweisung findet sich in der Regel "Out to AD - User ImmutableID".

Es gibt Problemlösungen, bei denen Sie den SourceAnchor in der Cloud ändern müssen, um eine Lösung herbei zu führen, z.B. bei größeren Migrationen. Dann müssen Sie natürlich die Werte untereinander umrechnen. Die Konvertierung eines Bytearray zu einem BASE64-String und zurück ist recht einfach

PS C:\> [system.convert]::ToBase64String(@(0x00,0x01,0x02,0x03,0x04))
AAECAwQ=

PS C:\> [system.convert]::FromBase64String("AAECAwQ=")
0
1
2
3
4

In der MMC für Active Directory Benutzer und Computer können Sie aber kein Bytearray mal so einfach in ein Feld schreiben. Da darf es z.B. ein Hex-Array sein. Mit wenig Mehraufwand können Sie das Byte-Array zu einem Hex-Array umformatieren:

$a=""
[system.convert]::FromBase64String(“kKfL2wwI+0W+rN0kfeaboA==”) `
| %{ `
   $a += [System.String]::Format("{0:X}", $_) + " "`
   };`
$result = $null;`
$result = $a.trimend();`
$result

Ein Beispielcode, mit dem sie z.B. eine ImmutableID für das AzureAD aus einer lokalen ObjectGUID errechnen können, sieht dann so aus:

$userUPN = "testuser@msxfaq.de" 
$guid = [guid]((Get-ADUser -LdapFilter "(userPrincipalName=$userUPN)").objectGuid) 
$immutableId = [System.Convert]::ToBase64String($guid.ToByteArray())

Dieser Fall tritt ein, wenn Sie eine ADSync-Installation von einer "Custom Installation" mit einem StringFeld als Anchor auf den Microsoft-Standard umstellen wollen und sich nicht auf ein "Soft Match" über das Feld Mail einlassen wollen.

Dieses Verfahren ist nur für "Benutzer" erforderlich, denn Kontakte und Gruppen nutzen sowieso die ObjectGUID

Mit dem Wissen können Sie nun natürlich auch eigene Skripte bauen, die anhand der lokalen ms-DS-ConsistencyGuid oder ObjkectGUID sich eine ImmutableID errechnen und die Objekte in der Cloud damit suchen.

Wechsel zu ms-DS-ConsistencyGuid

Wie ich am Anfang schon beschrieben habe, sollten alle Neuinstallationen von ADSync nach dem Juni 2017 automatisch das Feld "ms-DS-ConsistencyGuid" nutzen, wenn es gefüllt ist und es nach dem Abgleich mit der ImmutableID aus der Cloud beschreiben .

The Azure AD Connect Team has decided to move Azure AD Connect’s default source anchor attribute in On-Prems Active Directory Domain Services (AD DS) environments from objectGUID to mS-DS-ConsistencyGuid for User objects in Azure AD Connect version 1.1.553.0, and up.
Quelle: https://dirteam.com/sander/series/azure-ad-connect-objectguid-vs-ms-ds-consistencyGuid/

Wenn Sie aber eine ältere Version aktualisieren, dann werden Sie Installation des Updates auch darauf hingewiesen:

Der Link geht dabei auf folgende Seite:

Über den Wizard können sie den SourceAnchor ändern und dafür sorgen, dass ADSync auch das Feld ms-DS-ConsistencyGUID beschreibt

Achtung:
Wenn der AzureADConnect-Serviceaccount kein DomainAdmin ist, dann müssen Sie die erforderlichen Rechte zuerst an das Dienstkonto vergeben:

Hier die passende Kommandozeile:

dsacls 'dc=msxfaq,dc=net' /I:S /G 'msxfaq\svcaadconnect:WP;ms-ds-consistencyGuid;User'
dsacls 'cn=AdminADHolder,cn=System,dc=msxfaq,dc=net' /I:S /G 'msxfaq\svcaadconnect:WP;ms-ds-consistencyGuid;User'

REM Optional um die AD-Replikation zu triggern
repadmin /syncall

Das geht natürlich auch per PowerShell.

Install-WindowsFeature RSAT-AD-Tools 
Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\AdSyncConfig\AdSyncConfig.psm1"

$account = (Get-ADSyncADConnectorAccount).ADConnectorAccountName 
$Domain = (Get-ADSyncADConnectorAccount).ADConnectorAccountDomain
Set-ADSyncMsDsConsistencyGuidPermissions -ADConnectorAccountName $account -ADConnectorAccountDomain $Domain -confirm:$false

Wenn Sie die Rechte gegeben haben, dann können Sie den SourceAnchor umstellen. Stellen Sie den Source Anchor vorher um, passiert kein Schaden, aber das Zurückschreiben des Felds durch ADSync ist nicht möglich und gibt entsprechende Warnungen/Fehler. Sobald Sie die Berechtigungen korrekt gesetzt wird, wird ADSync beim nächsten Export die anstehenden Updates nachholen.

Der Eintrag "Configure Source Anchor" ist aber etwas hochtrabend, denn frei konfigurieren können Sie hier nichts. Über den Eintrag wird einfach der SourceAnchor von der ObjectGUID auf das neue Feld ms-DS-ConsistencyGuid umgestellt. Es gibt keine Auswahlmöglichkeit des Feldes. Darauf weist aber das nächste Fenster noch einmal genau hin:

Das Feld ms-DS-ConsistencyGuid darf im Forest noch nicht gefüllt sein. ADSync verhindert ansonsten die Einrichtung.

Sie können dann nur das Feld bei allen Objekten in dem AD-Forest entfernen oder den Assistenten mit "/SkipLdapSearch" starten.

"C:\Program Files\Microsoft Azure Active Directory Connect\AzureADConnect.exe" /skipldapsearch

Früher war es über die GUI übrigens nicht möglich, den SourceAnchor nach der Installation bei einer bestehenden Instanz ohne Neuinstallation zu ändern. Das war aber erst mal nicht so kritisch, da bei einer Neuinstallation ein "Matching" (ADSync Matching) versucht wurde. Die neue Version von AADConnect macht das nun direkt.

Die geänderte Konfiguration können Sie in ADSync selbst beim "Import Attribute Flow" sehen,

Im Synchronization Service Manager finden Sie auf dem Connector zum Office 365 Tenant ebenfalls Informationen zum CloudAnchor

Allerdings sollten Sie hier jede Veränderung unterlassen.

Rule Editor

Auch im "Rule Editor können Sie schon vorher oder auf einem Staging Server den gleichen Code sehen.

In den "Transformations" steht dann der Ausdruck:

IIF(IsPresent([mS-DS-ConsistencyGuid]),[mS-DS-ConsistencyGuid],[objectGUID])

Das Feld landet erst einmal in "sourceAnchorBinary". Erst in der Regel "In from AD - User Common" ist dann das Mapping auf den SourceAnchor hinterlegt.

Das sind ziemlich viele "If-Then-Else"-Konstruktionen, die aber eher wie eine Excel-Formel zu lesen sind:

IIF (Bedingungen, THEN-teil, Else-Teil)

Ich habe es mal versucht aufzuschlüsseln:

IIF(IsPresent([msExchRecipientTypeDetails]),
   IIF([msExchRecipientTypeDetails]=2,NULL,
      IIF("mS-DS-ConsistencyGuid"="mS-DS-ConsistencyGuid",
         IIF(IsPresent([mS-DS-ConsistencyGuid]),
            IIF(IsString([mS-DS-ConsistencyGuid]),CStr([mS-DS-ConsistencyGuid]),ConvertToBase64([mS-DS-ConsistencyGuid])
         ), IIF(IsString([objectGUID]),
               CStr([objectGUID]),
               ConvertToBase64([objectGUID])
            )
         ),IIF(IsString([mS-DS-ConsistencyGuid]),
               CStr([mS-DS-ConsistencyGuid]),
               ConvertToBase64([mS-DS-ConsistencyGuid])
            )
         )
      ),
      IIF("mS-DS-ConsistencyGuid"="mS-DS-ConsistencyGuid",
         IIF(IsPresent([mS-DS-ConsistencyGuid]),
            IIF(IsString([mS-DS-ConsistencyGuid]),
               CStr([mS-DS-ConsistencyGuid]),
               ConvertToBase64([mS-DS-ConsistencyGuid])
            ),
         IIF(IsString([objectGUID]),
            CStr([objectGUID]),
            ConvertToBase64([objectGUID])
         )
      ),
      IIF(IsString([mS-DS-ConsistencyGuid]),
         CStr([mS-DS-ConsistencyGuid]),
         ConvertToBase64([mS-DS-ConsistencyGuid])
      )
   )
)

Im Grunde wird noch nach dem "msExchRecipientTypeDetails" unterschieden und geprüft, ob das Feld ein String ist. Aber die Logik ist wie beschrieben: Nutze das Feld "ms-DS-ConsistencyGuid" als Quelle, wenn es da ist, ansonsten die "ObjectGUID". In der Regel "Out to AD - User ImmutableId" steht dann die Anweisung, dass das Feld "CloudsourceAnchor" dann wieder zu "ms-DS-ConsistencyGuid" geschrieben wird.

IIF(IsPresent([cloudSourceAnchor]),
   IIF(IsPresent([sourceAnchorBinary]),
      [sourceAnchorBinary],
      IgnoreThisFlow),
   IgnoreThisFlow
)

Wie das alles bei der Anlage eines neuen Benutzers zusammengreift, habe ich auf der Seite SourceAnchor User beschrieben.

Ich denke Microsoft möchte gerne alle Installationen auf dieses Feld für Benutzer umstellen. Der große Vorteil dabei ist, dass für ein "Undelete" neue Optionen bestehen. Wird ein AD-Konto gelöscht, kann es nicht einfach wieder mit der gleichen ObjectGUID wieder hergestellt werden. Wenn aber nun dieses neue Feld genutzt ist, ist man hier flexibler und kann sogar ein komplett anderes Objekt so einrichten, dass es zu einem in Office 365 noch gelöschten Objekt passt und so dieses wieder aktivieren.

Nachdem der Connector umgestellt ist, werden alle OnPremises-Objekte, die im Scope sind, aktualisiert was zu einer AD-Replikationsspitze führen kann und auch abhängige Prozesse (Exchange OAB-Gen, andere DirSync-Prozesse etc.) belasten kann.

Da stellt sich natürlich die Frage, wie das Feld gefüllt wird. Auch dazu gibt es entsprechende Aussagen zum Feld "ms-DS-ConsistencyGuid".

msDS-ConsistencyGUID wird als „sourceAnchor“-Attribut für Benutzerobjekte verwendet. „objectGUID“ wird für andere Objekttypen verwendet.

Für jedes lokale AD-Benutzerobjekt, dessen „msDS-ConsistencyGuid“-Attribut nicht aufgefüllt ist, schreibt Azure AD Connect den zugehörigen Wert von „objectGUID“ in das Attribut „msDS-ConsistencyGuid“ im lokalen Active Directory zurück. Nachdem das Attribut „msDS-ConsistencyGuid“ aufgefüllt wurde, exportiert Azure AD Connect das Objekt nach Azure AD.
Quelle: Azure AD Connect: Designkonzepte (https://docs.microsoft.com/de-de/azure/active-directory/connect/active-directory-aadconnect-design-concepts#using-msds-consistencyGuid-as-sourceanchor)

The actively synchronizing Azure AD Connect installation is the service that writes values in the mS-DS-ConsistencyGuid attribute. As a Staging Mode Azure AD Connect installation doesn’t perform export actions, it does not actually write to the mS-DS-ConsistencyGuid attribute.  Therefore, the issue can be safely ignored, and Azure AD Connect can be instructed to do so.
Quelle https://dirteam.com/sander/2020/08/19/knowledgebase-you-receive-the-ms-ds-consistencyguid-attribute-is-already-in-use-when-you-change-the-source-anchor-on-a-staging-mode-azure-ad-connect-installation/

Dies ist also ein weiterer Fall, bei dem AADConnect in das On-Prem-AD zurückschreibt. Allerdings wird das Feld nicht mehr geleert, wenn ADSync das Objekt wieder aus dem Scope verliert. Es ist also kein Indikator, welche Objekte aktuell repliziert sind.

Bei der Nutzung mehrere Forests müssen Sie dem Dienstkonto ggfs. noch Berechtigungen geben. DSACLS übernimmt das:

dsacls 'dc=example,dc=com' /I:S /G "domain\serviceaccount:WP;ms-ds-consistencyGuid;User"

Sonderfall: Benutzerdefinierter Source Anchor

Auch wenn Microsoft immer wieder davon abrät, gibt es Firmen, die bei der ersten Einrichtung des ADSync auch ein ganz anderes Feld angegeben haben. Sie "müssen" also nicht die ObjectGUID oder ms-DS-consistencyGuid nutzen. Das ist möglich, wenn bei der Installation von ADSync die "Custom Installation" gewählt wird. Wenn Sie ADSync aber schon mal installiert haben, dann können Sie das Feld nicht mehr mit dieser Installation ändern. Die Einrichtung des Quellfelds für die "ImmutableID" ist beim "Custom Setup" des ADSync-Services hier möglich:

Achtung: Dieses Feld kann nur während der ersten Installation des ADSync konfiguriert werden und kann nachträglich nur durch eine Neuinstallation von ADSync geändert werden. Beachten Sie dann auch die Hinweise auf ADSync Matching. Wenn Sie weitere ADSync-Systeme als Staging Server einrichten, dann müssen Sie die Konfiguration identisch halten.

Die Einstellung ist auch genau dafür gedacht, wenn in einer Umgebung die ObjectGUID nicht das optimale Feld darstellt.

Source Anchor - The attribute sourceAnchor is an attribute that is immutable during the lifetime of a User object. It is the primary key linking the On-Prems User with the User in Azure AD. Since the attribute cannot be changed, you must plan for a good attribute to use. A good candidate is objectGUID. This attribute is not changed, unless the User account is moved between forests/domains. In a multi-forest environment where you move accounts between forests, another attribute must be used, such as an attribute with the employeeID. Avoid attributes that would change when a person marries or change assignments. You cannot use attributes with an @-sign, so email and UserPrincipalName cannot be used. The attribute is also case-sensitive so when you move an object between forests, make sure to preserve the upper/lower case. Binary attributes are base64-encoded, but other attribute types remain in its unencoded state. In federation scenarios and some Azure AD interfaces, this attribute is also known as immutableID. More information about the source anchor can be found in the design concepts.
Quelle: Custom Installation of Azure AD Connect" (https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-get-started-custom/)

Ehe Sie nun vorschnell hier etwas ändern, sollten Sie sich genau überlegen, welches Feld denn "geeignet" ist. Es gibt da nämlich durchaus einige Voraussetzungen, von denen Microsoft einige auf der Seite "Azure AD Connect: Design concepts" (https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-design-concepts/#sourceAnchor) beschreibt. Es sollte unter anderem folgende Voraussetzungen erfüllen:

Kriterium Erfüllt ?

In allen Forests vorhanden
Es darf nur eine ADSync Instanz pro Tenant geben, die aber mehrere Forests bedienen kann. Das von ihnen als "SourceAnchor" ausgewählte Feld muss also in allen Quellen vorhanden sein.

Typ: String, Integer oder Binary
Maximal 60 Zeichen lang
Keine Sonderzeichen wie ! # $ % & * + / = ? ^ ` { } | ~ < > ( ) ' ; : , [ ] " @ _
Achtung: Case-Sensibel, d.h. Groß/Kleinschreibung werden unterschieden.

Eineindeutig, d.h. es darf nie zwei Objekte mit dem gleichen Inhalt geben. Diese Eindeutigkeit muss über alle Forests gelten

Darf nicht leer sein, wenn das Objekt für Office 365 relevant ist

Muss auf allen relevanten Objekte vorhanden sein
Denken Sie dabei nicht nur an "Benutzer". Auch Gruppen und sogar Computerobjekte werden mit ADSync abgeglichen. Auch wenn vielerorts eine "EmployeeID" als alternatives Feld vorgeschlagen wird, müssen Sie dieses auch bei anderen Objekten pflegen.

Aber auch die Verwendung andere bekannter und naheliegender Felder wie UPN, Mail, TargetAddress etc. funktioniert nicht. Diese Felder haben z.B. ein "@" als Wert, was nicht erlaubt ist. Auch andere Felder können problematisch sein, weil diese vielleicht durch einen Synchronisationsprozess, z.B. GALSync, zwischen den Forests übertragen werden und damit nicht mehr "eineindeutig" sind.

Es gibt noch eine Besonderheit, wenn das lokale ADFeld ein "String" ist. In dem Fall wird der Inhalt nicht BASE64-codiert in die ImmutableID geschrieben sondern als 1:1 String. Das erschwert eine spätere Umstellung, da der Inhalt in der Cloud nicht mehr "BASE64-decoviert werden und in ms-DS-ConsistencyGuid eingetragen werden kann. Der Wechsel ist hier also deutlich aufwändiger, da Sie offiziell den DirSync deaktivieren, bis zu 72h warten und dann die ImmutableID löschen (-> Softmatch) oder auf die BASE64 codierte ObjectGUID (->Hardmatch) setzen müssen.

Die Wahl eines alternativen Feldes ist alles andere als einfach, da die eingebauten Vorkehrungen zur Eindeutigkeit (ObjectGUID) nicht genutzt werden können. Neben dem passenden LDAP-Feld ist es vielmehr eine Frage des Provisioning, dass dieses Feld auch immer in allen Forests korrekt gesetzt und fortlaufend gepflegt wird, aber bei AD-Migrationen eben nur einmal im Forest vorhanden ist.

Wechsel des SourceAnchor

Die Konfiguration von ADSync verbietet offiziell eine Änderung des SourceAnchor nach der Installation. Eine Konfiguration ist nur bei der ersten Installation selbst über ein "Custom Setup" möglich. Wenn Sie daher bereits ADSync mit einem eigenen Sourceanchor installiert haben und nun mit der Änderung des SourceAnchor liebäugeln, dann kommen Sie um eine Neuinstallation von ADSync nicht herum. Ehe Sie nun aber ADSync deinstallieren und gleich neu installieren müssen Sie im Tenant ggfls. noch etwas anpassen, Dort haben die die Objekte in der Cloud schon das Feld "ImmutableID", indem die ObjectGUID als BASE64-codierter String enthalten ist. ADSync macht dann keinen "Soft Match" mehr sondern versucht einen "Hard Match". Zurecht erwartet er ja dass aus dem lokalen AD ein Objekt mit einem passenden Feld kommt.

Wenn Sie als bisherigen Sourceanchor ein Feld genutzt haben, welches sie 1:1 in das Feld ms-DS-ConsistencyGUID kopieren können, dann wäre das ein Lösungsweg. Dazu muss aber ihr aktuelles Feld auch ein "Byte Array" sein, denn ADSync macht ja darauf ein BASE64-codiertes Textfeld für die Cloud. Wenn der bisherige Sourceanchor aber ein Textfeld ist, dass wurde die ImmutableID in der Cloud aus diesem Wert erstellt, der vermutlich kein BASE64-Wert ist und damit rückwärts nicht decodiert werden kann. Dann hilft nur das Löschen des Source Anchor in der Cloud was aber offiziell nur möglich ist, wenn der Tenant nicht mehr mit "Dirsync" konfiguriert ist. Der Prozess wäre dann

  1. DirSync für den Tenant abschalten
  2. bis zu 72 Stunden warten
    Solange kann es offiziell dauern, bis alle AzureAD-Objekte aus dem Status "managed" zu "Cloud Only" konvertiert wurden
  3. ImmutableID in der Cloud leeren
    Allein durch das Abschalten des Dirsync wird das Feld nicht gelöscht. Das müssen sie von Hand machen. Sie können aber auch den erwarteten zukünftigen Wert in das Feld schreiben. Damit ersparen Sie ADSync das "Soft-Match". Dazu würde ich die ObjectGUID und den alten SourceAnchor der Quelle exportieren und damit das Ziel aktualisieren.
  4. ADSync neu installieren
    Nun nutzen die die normale Funktion und "vertrauen" darauf, das beim initialen Full-Sync ein Soft-Match über die Mailadresse bei allen Objekten passt.

Eventuell können Sie noch weitere Optimierungen vornehmen, z.B. indem Sie schon vorab versuchen, die ImmutableID trotz aktiviertem Dirsync zu ändern. Das geht interessanterweise bei vielen Objekten aber nicht bei allem. Zum Support-Statement fragen sie besser nicht Microsoft.

Sie müssen aktiv bei einem Wechsel den neuen Source Anchor auswählen, da ADSync den initial genutzen SourceAnchor im Tenant hinterlegt hat

Only newer versions of Azure AD Connect (1.1.524.0 and after) store information in your Azure AD tenant about the sourceAnchor attribute used during installation. Older versions of Azure AD Connect do not.
Azure AD Connect: Design concepts https://docs.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-design-concepts#changing-the-sourceanchor-attribute

Im schlimmsten Fall sind sie also 72+ Stunden ohne Dirsync und Änderungen im lokalen Active Directory (Neue Benutzer, Gruppenmitgliedschaften, PasswordHashSync) finden nicht statt. Die bestehenden Benutzer können währenddessen natürlich in der Cloud weiter arbeiten.

Authentifizierung

Wenn sich die Anwender direkt an der Cloud anmelden, z.B. per Pass-Through Authentifizierung (PTA) oder Password Hash Sync (PHS), dann können die Anwender in der Regel weiter arbeiten. Selbst mit ADFS sollte dies funktionieren. Allerdings habe ich schon gesehen, dass die "ObjectGUID" auch hier eine Rolle spielt und bei der Verwendung alternativer Anmeldedaten die Claim-Rules im ADFS-Service erweitert werden.

Zudem habe ich bei Benutzern, deren UPN zu einer "federated Domain" gehörte, die ImmutableID nicht löschen können.

Ich denke nicht, dass eine Änderung der ImmutableID in der Cloud und des lokalen Sourceanchors hier einen Einfluss drauf haben. Ich habe es allerdings nicht getestet.

Weitere Links