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, ObjectGUID, 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.

Achtung: Diese neue Logik wird nur aktiviert, wenn das Feld ms-DS-ConsistencyGUID noch nicht in einem lokalen AD belegt ist. Ansonsten bleibt es bei der objectGUID.

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 und 3rd Party IDM

Sie müssen ja nicht mit ADSync die Objekte aus einem lokalen AD in die Cloud synchronisieren. Es gibt durchaus 3rd-Party Produkte, die Objekte im AzureAD verwalten und aus einer lokalen Identity-Quelle beziehen. Da diese Produkte meist nicht die "Microsoft DirSync API" ansprechen können, die ADSync nutzt, kommt hier dann die AzureAD-PowerShell oder Graph API zum Einsatz. Damit scheint das Feld "ImmutableID" erst einmal obsolet, wenn die IDM-Lösung eine eigene Logik nutzt.

Dennoch sollten Sie darauf achten, dass ihr IDM auch das Feld "ImmutableID" befüllt, da damit das AzureAD diese Objekt den Status "DirSynced" verpasst und damit bestimmte Veränderung z.B. durch die Admin Portals der Cloud blockiert werden und damit das IDM führend bleibt,

ADSync generiert die ImmutabeID ausgehend von der ObjectGUID des lokalen AD-Objekts, was damit automatisch die Voraussetzungen erfüllt. Wenn Sie oder ihr IDM das Feld selbst generieren, dann gebe ich ihnen ein paar Hinweise mit auf den Weg:

  • Die ImmutableID ist der primäre Schlüssel für ADSync
    Meines Wissens hat es sonst keine Funktion, d.h. der Anwender sieht es nicht und selbst eine Änderung ist möglich, solange das IDM die Objekte korrekt zuordnen ann
  • Die ImmutableID kennzeichnet das Objekte als „DirSync“ Objekt
    d.h. einige Funktionen im AzureAD/ExchangeOnline sind dann blockiert. Die Cloud geht davon aus, dass ein DirSync-Prozess (nicht zwingend ADSync) das Objekt verwaltet
  • Die Immutable ID ist bei Microsoft eine „UTF8zuHEX-codierte ObjectGUID aus dem lokalen AD.
    Ich würde mich ebenfalls daran halten und binäre Werte oder GUIDs in ein HEXSTRING konvertieren.
  • Die ImmutableID sollte „ewig" und "weltweit eindeutig sein“
    Genaugenommen muss eine ImmutableID nur innerhalb des Tenant eindeutig sein. Aber selbst da scheiterten schon Kunden. Auch wenn Objekte gelöscht und später neue Objekte angelegt werden, sollten Sie die ImmutableID nicht erneut verwenden. Auch Abhängigkeiten von der Person (Vorname, Nachname, Personalnummer etc.) sind unglücklich, da sich diese ändern und eine Änderung der ImmutableID nicht davon abhängig sein sollte
  • Wenn ein CloudUser gelöscht wird, und sie einen gleichnamigen Benutzer mit der gleichen ImmutableID anlegen, dann hat er NICHT den Zugriff auf die bisherigen Daten. Die Verbindung einer Identität zu den Daten erfolgt über eine ObjectID in Azure, die sie NICHT setzen können.
    Ein gelöschter Benutzer kann bis zu 30 Tage samt Daten wieder aus dem AzureAD Papierkorb „zurückgeholt“ werden.

Die ImmutableID ist also ein „Systemfeld“, welches einzig das IDM nutzen sollte, um den Link zwischen dem AzureAD-Objekt und der eigenen Identity Datenbank zu pflegen.

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-Premises 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.

Dies ist insbesondere eine Falle, wenn Sie eine Forest2Forest-Migration durchführen und in der Quelle schon ein neuer ADSync aktiv ist und ADMT diese Attribute mit kopiert.

Sollte das Feld mS-DS-ConsistencyGuid bereits von einer alten ADSync-Installation gefüllt sein, die aber nicht mehr aktiv ist, dann können Sie das Feld recht einfach leeren.

Get-ADObject `
   -LDAPFilter "(ms-ds-consistencyguid=*)" `
   -Properties "ms-ds-consistencyguid" `
| foreach {
   Set-ADObject `
      -identity $_.distinguishedname `
      -Remove @{"ms-ds-consistencyguid"=($_."ms-ds-consistencyguid")}
}

Nachdem dann das Feld "geleert" ist, kann ADSync umgestellt werden.

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.

Hinweis
Das ADSync-Setup kann die neue Einrichtung mit dem Hinweis blockieren, dass ms-ds-consitencyguid schon gefüllt wäre. Sie müssen ADSync dann mit der Option "/SkipLDAPSearch" starten:
Command-line switches for Azure AD Connect: https://dirteam.com/sander/2020/11/12/command-line-switches-for-azure-ad-connect/

ObjectGUID und msDSConsitencyGUID

Sie haben nun gelernt, dass ADSync das Feld msDSConsitencyGUID als Source Anchor nutzt, wenn es gefüllt ist aber initial den Inhalt aus der ObjectGUID befüllt. Das können Sie natürlich auch selbst vorab schon machen. Es hilft z.B. wenn Sie Benutzer aus einem Forest mit einem "alten ADSync" ohne die msDSConsitencyGUID-Logik in einen neuen Forest verschieben und die Konten neu matchen wollen. Wenn Sie dann vorba schon die ObjectGUID direkt in das Feld msDSConsistencyGUID kopieren, kann z.B. ADSync diese Daten direkt mit mit migrieren.

Da alte BLOG-Einträge bei Microsoft auch gerne mal verschwinden, habe ich die beiden Seiten von Chad Cox Seite (Powershell - Copy ObjectGuid to MS-DS-ConsistencyGuid - https://learn.microsoft.com/de-de/archive/blogs/chadcox/powershell-copy-objectguid-to-ms-ds-consistencygiud) übernommen.

# Eintrag kopieren
get-adobject `
   -ldapfilter "(&(|(objectClass=user)(objectClass=group))(!(IsCriticalSystemObject=TRUE))(!(mS-DS-ConsistencyGuid=*)))" `
   -Properties mail, userprincipalname, objectguid, 'mS-DS-ConsistencyGuid' `
| ForEach-Object {
      Set-adobject `
         -Identity $_.DistinguishedName `
         -Replace @{'mS-DS-ConsistencyGuid'=$($_.objectguid)} `
  }

# Kontrolle, ob es passt
get-adobject `
   -ldapfilter "(&(|(objectClass=user)(objectClass=group))(!(IsCriticalSystemObject=TRUE)))" `
   -Properties mail, userprincipalname, objectguid, 'mS-DS-ConsistencyGuid' `
| select samaccountname, mail, objectguid, @{name='ms-ds-consistencyguid';expression={[guid]$_.'ms-ds-consistencyguid'}} `
   -First 10

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 On-Premises-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"

ImmutableID ändern

Sie können das lokale AD-Konto nun gerne umbenennen, verschieben und sogar zwischen Domänen und Forests verschieben. Sie müssen nur dafür sorgen, dass der Inhalt von "ms-ds-consistencyGuid" oder der ObjectGUID in der Quelle erhalten bleibt und ADSync auch die Zielumgebung bearbeitet. Dann wird ADSync beim Import zwar erkennen, dass das Objekt an der einen Stelle verschwunden aber an anderer Stelle wieder aufgetaucht ist. Dennoch kann es Situationen geben, in denen dies nicht möglich ist.

Wenn ADSync das Objekt nicht mehr findet, dann ist das mit "Löschen" gleichzusetzen und das Konto in der Cloud wird wieder gelöscht. Wenn Sie das lokale Konto wieder herstellen, z.B. aus dem AD Papierkorb, dann findet ADSync wieder das Feld ms-ds-consitencyGuid und holt bis zu 60 Tage nach der Löschung auch das Konto aus dem AzureAD-Papierkorb.

Wenn Sie aber in der Quelle den den "SourceAnchor" ändern, dann ist das für ADSync ein neues Objekte, welche mit diesem SourceAnchor neu angelegt wird. Für das bisherige Konto im AzureAD bedeutet das, dass es keinen Partner mehr im lokalen AD gibt und ohne Rückfrage gelöscht wird. Es landet im Papierkorb des AzureAD.

Sie sollten daher nie die Inhalte des SourceAnchor-Felds ändern ohne die Folgen zu kennen

Das Feld ist auch relevant, wenn Sie ADSync neu installieren oder einen ADSync Staging Server aufbauen. Der muss ja die gleiche Zuordnung der Objekte durchführen. Es wäre durchaus interessant, die ImmutableID bei einem Benutzer zu ändern.

Ich habe keine dokumentiert Aussage gefunden, unter welchen Umständen die ImmutableID eines AzureAD-Benutzers geändert werden kann und darf. Nur wenn der Tenant nicht für DirSync aktiviert ist, können Sie das Feld sicher verändern. Ansonsten "kann es gehen"

Das "kann es gehen" ist durchaus wörtlich zu nehmen. Ich habe mehrfach die Situation gehabt, dass bei einem Tenant mit aktiviertem DirSync das Feld bei einigen Benutzern geändert werden konnte während bei anderen Benutzern eine Fehlermeldung aufgetreten ist. Es gibt Commandlets, die den Parameter ImmutableID kennen.

ImmutableID löschen

Die ImmutableID im AzureAD ist der Link zum Objekte im lokalen AD, bzw. dessen ObjectGUID und/oder ms-ds-consitencyGUID. Daher können Sie Objekt im lokalen AD umziehen und umbenennen, ohne dass der Link verloren geht. Aber es gibt Situationen, in denen diese Verknüpfung gelöst werden muss, z.B. Wenn Sie einen Tenant vom lokalen AD-Forest trennen und mit einem neuen AD-Forest neu verbinden wollen oder die ImmutableID mit einer anderen Quelle befüllen wollen. Das Löschen von ADSync stellt in dem Zuge die Objekte in der Cloud von "DirSync" auf "CloudOnly" zurück aber die ImmutableID bleiben erhalten und verhindert ein "Rematching".

Dies passiert auch, wenn Sie ein lokale AD-Objekt löschen, ADSync das Objekt im AzureAD in den Papierkorb verschiebt und sie es manuell dort wieder zurückholen. Auch dann ist das so wiederhergestellte Objekte ein "CloudOnly"-Objekt aber mit einer ImmutableID. Wenn wir in dem Fall ein "Rematching" mit einem anderen Objekt erreichen wollen, müssen wie die ImmutableID im AzreAD erst entfernen.

Das klingt einfacher als es ist, denn die dazu erforderlichen Commandlets und Methoden hat Microsoft mehrfach verändert.

Auch die Angabe von "$null" ist ein kleiner Stolperstein. Zuerst versuchen es wir mit der neueren AzureAD-PowerShell:

#Diese beiden Aufrufe liefern keinen Fehler aber die ImmutableID bleibt bestehen
get-azureaduser -SearchString test1@msxfaq.net | Set-AzureADUser -ImmutableId:$null
get-azureaduser -SearchString test1@msxfaq.net | Set-AzureADUser -ImmutableId $null

# Dieser Aufruf liefert aber einen Fehler
get-azureaduser -SearchString test1@msxfaq.net | Set-AzureADUser -ImmutableId ""
Set-AzureADUser : Error occurred while executing SetUser
Code: Request_BadRequest
Message: Invalid value specified for property 'immutableId' of resource 'User'.

# Auch die früher mögliche Schreibweise geht nicht mehr
Set-AzureADUser -UserPrincipalName user1@msxfaq.de -ImmutableId "$null"

Mit "Set-AzureADUser" kann ich die ImmutableID nur setzen aber nicht leeren.

Mittlerweile gibt es aber mit "Remove-AzureADUserExtension" einen weiteren Weg

Remove-AzureADUserExtension `
   -ObjectID $guest.ObjectId `
   -ExtensionName "ImmutableID"

Früher konnte ich noch mit "Set-MSOLUser" der alten Microsoft Online PowerShell die ImmutableID leeren. Aber auch hier war die Schreibweise "ungewöhmlich".

# Folgendes gesht nicht. Allerdings liefert der Aufruf auch keinen Fehler aber ändert auch nichts.
Set-MsolUser -UserPrincipalName user1@msxfaq.de -ImmutableId:$null
Set-MsolUser -UserPrincipalName user1@msxfaq.de -ImmutableId $null
# Allerdings ging folgende Schreibweise
Set-MsolUser -UserPrincipalName user1@msxfaq.de -ImmutableId "$null"

Achtung:
Set-MSOLUser nutzte damals anscheinend eine andere API als Set-AzureADUser. Wenn ich mit SetMSOLUser die ImmutableID geschrieben habe, dann dauerte es einige Sekunden, bis ich mit Get-AzureADUser auch die Änderung sehe. Set dem Wechsel auf Graph nud Abschaltung der MSOnline PowerShell scheint Set-MSOLUser zwar noch vorhanden zu sein, aber nutzt die gleichen API wie Set-AzureADUser und kann die ImmutableID nicht mehr löschen.

Das Schreiben einer anderen ImmutableID muss, wie schon geschrieben, nicht immer funktionieren.

PS C:\> Set-MsolUser -UserPrincipalName ADUser2@carius.de -ImmutableId "asd"
Set-MsolUser : Unable to update parameter. Parameter name: IMMUTABLEID.
...
FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.PropertyNotSettableException,
   Microsoft.Online.Administration.Automation.SetUser

Manchmal liegt es aber auch einfach an einer ADFS-Federation

"Set-msoluser : You must provide a required property: Parameter name: FederatedUser.SourceAnchor"

In dem Fall kann es helfen, den UPN des Objekts nur in der Cloud einmal auf die "<tenantname>.onmicrosoft.com"-Domain zu ändern, dann die ImmutableID zu setzen und den UPN wieder zurück zu drehen.

Set-MsolUserPrincipalName `
   -UserPrincipalName feduser1@federated.msxfaq.de `
   -NewUserPrincipalName feduser1@msxfaq.onmicrosoft.com
Set-MsolUser `
   -UserPrincipalName feduser1@msxfaq.onmicrosoft.com `
   -ImmutableId ""
Set-MsolUserPrincipalName `
   -UserPrincipalName feduser1@msxfaq.onmicrosoft.com `
   -NewUserPrincipalName feduser1@federated.msxfaq.de

Es gibt aber keine Garantie, dass diese Befehle immer mit allen Benutzern funktionieren, solange Dirsync aktiviert ist.
Den sicheren Weg funktioniert nur über die Deaktivierung des Dirsync und bis zu 72h Wartezeit.

Das Problem ist nur für Benutzer existent, denn Kontakte und Gruppen haben keine "ImmutableID". Siehe auch SourceAnchor Gruppen

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-Premises 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