SourceAnchor User
Diese Seite befasst sich mit den Details bei der Verwendung und Bestimmung des Sourceanchor, auch als ImmutableID oder ms-DS-ConsitencyGUID bezeichnet.
Lesen Sie dazu vorab die Seite SourceAnchor. Für Gruppen und Kontakte gibt es eine eigene Seite auf SourceAnchor Gruppen
Ablauf: Benutzer neu anlegen
Diese Beschreibung gilt für ADSync aber
nicht für
AzureAD Cloud
Sync, dieser das Feld "ms-ds-consistencyGUID" nicht
zurückschreibt.
Siehe
https://learn.microsoft.com/en-us/azure/active-directory/cloud-sync/reference-cloud-sync-faq#does-cloud-sync-support-writeback-of-ms-ds-consistencyguid-for-any-object-
Am einfachsten können Sie die Logik verstehen, wenn wir den Ablauf von ADSync analysieren, der bei der Neuanlage eines Benutzers erfolgt:
Schritt | Beschreibung | Details |
---|---|---|
1 |
Lokales AD-Objekte wird angelegtDas Feld "ms-DS-ConsitencyGuid" ist leer, da die lokalen Tools ja nichts davon wissen. |
Hier ein Auszug per LDIFDE. Das Feld "ms-DS-ConsistencyGuid" ist nicht gefüllt dn: CN=ADUser8,OU=Firma,DC=carius,DC=de changetype: add objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user cn: ADUser8 givenName: ADUser8 distinguishedName: CN=ADUser8,OU=Firma,DC=carius,DC=de instanceType: 4 whenCreated: 20210203221754.0Z whenChanged: 20210203221754.0Z displayName: ADUser8 uSNCreated: 1767140 uSNChanged: 1767145 name: ADUser8 objectGUID:: kZj7niGua0Gz92mIDCl+Tw== userAccountControl: 512 badPwdCount: 0 codePage: 0 countryCode: 0 badPasswordTime: 0 lastLogoff: 0 lastLogon: 0 pwdLastSet: 132568642745385468 primaryGroupID: 513 objectSid:: AQUAAAAAAAUVAAAAwM8SUMELJU0m/cWzfAQAAA== accountExpires: 9223372036854775807 logonCount: 0 sAMAccountName: ADUser8 sAMAccountType: 805306368 userPrincipalName: ADUser8@carius.de objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=carius,DC=de dSCorePropagationData: 16010101000000.0Z |
2 |
ADSync "Delta Import"Das Objekt landet über den "Delta Import" der lokalen Domäne im Connectorspace. Da sich im AzureAD nichts geändert hat, liefert der Import aus der Cloud keine Änderungen. Im Metaverse ist noch nichts von dem neuen Objekt zu sehen. |
![]() ![]() |
3 |
ADSync "Delta Sync"Der zweite Schritt ist der "DeltaSync" der lokalen Domäne um das Objekt ins Metaverse zu übertragen. |
![]() |
Info |
Durch den DeltaSync landet der Benutzer im Metaverse aber auch schon im Connectorspace zur Cloud und beide Objekte haben den SourceAnchor. Sie sehen schon hier, dass der Wert der ObjectGUID entspricht. |
![]() ![]() |
Info |
Die Syntaxregel ist hier nicht voll lesbar und auch sonst schwer zu lesen. Wenn das Feld ms-DS-ConsistencyGuid gefüllt ist, wird dieses Feld genutzt. Ansonsten wird die immer vorhandene ObjectGUID herangezogen. Dies gilt für Benutzer |
![]() |
Info |
Im Connectorspace zum Active Directory sind die Änderung natürlich noch nicht angekommen. |
Der erste Sync hat erst die Daten aus dem Connector Space des AD ins Metaverse übertragen und dabei wurde erst der SourceAnchor angelegt. |
4 |
ADSync ExportDer Export überträgt die Änderungen aus dem jeweiligen Connectorspace in das Zielsystem. Der Export in Richtung lokalem Active Diretory hat noch nichts zu schreiben |
![]() ![]() |
Info |
PauseDer ADSync Prozess synchronisiert in der Regel alle 30 Minuten. Das Provisioning ist aber noch nicht abgeschlossen |
PS C:\> Get-ADSyncScheduler AllowedSyncCycleInterval : 00:30:00 CurrentlyEffectiveSyncCycleInterval : 00:30:00 CustomizedSyncCycleInterval : NextSyncCyclePolicyType : Delta NextSyncCycleStartTimeInUTC : 03.02.2021 22:46:48 PurgeRunHistoryInterval : 7.00:00:00 SyncCycleEnabled : False MaintenanceEnabled : True StagingModeEnabled : False SchedulerSuspended : False SyncCycleInProgress : False |
5 |
Delta ImportBeim nächsten Import kommt nun aus dem AzureAD ein Update. Auf dem lokalen AD gibt es keine Änderungen |
![]() ![]() |
6 |
Delta SyncDie Änderungen aus dem Connector Space landen nun im Metaverse und im CS zum Active Directory. Hier sehen wir auch, dass der SourceAnchor aus dem AzureAD zurückgelesen und Richtung Active Directory repliziert wird, obwohl das Feld schon bei der ersten Synchronisation aus dem AD zur Cloud im Metaverse gefüllt wurde. Der DeltaSync zu Azure hat keine Änderungen zu übertragen |
![]() ![]() |
7 |
Export zum ADHier wird nun , wie erwartet, das Feld ms-DS-ConsistencyGuid aktualisiert |
![]() ![]() |
8 |
Export zum AzureADAber auch zum AzureAD gibt es noch ein Update. So richtig einordnen kann es aber nicht, warum hier ein Feld "OnPremisesUserPrincipalName" im Azure AD gelöscht wird, welches vorher noch nie erschienen ist. |
![]() ![]() |
Bleibt also festzuhalten:
- Bei neuen Objekten kommt die ObjectGUID als SourceAnchor zum Einsatz
- Bei bestehenden Objekten liest ADSync die ms-DS-ConsistencyGUID und ersatzweise die ObjektGUID.
- ADSync erstellt die BASE64-codierte ImmutableID
- ADSync schreibt die ImmutableID in der
Cloud
d.h. sie wird nicht von Azure erstellt oder bestimmt. - ADSync schreibt lokal das Feld "ms-DS-consistencyGUID
Bei der Umstellung wird das
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 auch zwei Commandlets, die beide den Parameter ImmutableID kennen. 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"
Aktuell kann man mit "Set-AzureADUser" die ImmutableID nur setzen aber nicht leeren. Allerdings geht es durchaus noch mit Set-MSOLUser.
Achtung: Set-MSOLUser nutze anscheinend eine andere API als Set-AzureADUser. Wenn ich mit SetMSOLUser die ImmutableID schreibe, dann dauert es einige Sekunden, bis ich die mit Get-AzureADUser auch sehe
# Folgendes geht nicht. Allerdings liefert der Aufruf auch keinen Fehler Set-MsolUser -UserPrincipalName user1@msxfaq.de -ImmutableId:$null Set-MsolUser -UserPrincipalName user1@msxfaq.de -ImmutableId $null Die ImmutableID bleibt einfach unverändert
# Allerdings ging folgende Schreibweise Set-MsolUser -UserPrincipalName user1@msxfaq.de -ImmutableId "$null"
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. Siehe dazu auch
SourceAnchor: Wechsel des Sourceanchor
Das Problem ist nur für Benutzer existent, denn Kontakte und Gruppen haben keine "ImmutableID". Siehe auch SourceAnchor Gruppen
- Set or clear immutable ID
https://www.2azure.nl/2019/04/01/set-or-clear-immutable-id/ - Setting the ImmutableID to $null
https://misstech.co.uk/2016/02/05/setting-the-immutableid-to-null/
Weitere Links
- SourceAnchor
- SourceAnchor Gruppen
- SourceAnchor und ADMT
- ADSync mit Devices
- ADSync - Objekte löschen und zurückholen
-
Q: Does cloud sync support writeback of ms-ds-consistencyGUID
for any object?
A: No, cloud sync does not support writeback of ms-ds-consistencyGUID for any object (including user objects).
https://learn.microsoft.com/en-us/azure/active-directory/cloud-sync/reference-cloud-sync-faq#does-cloud-sync-support-writeback-of-ms-ds-consistencyguid-for-any-object- -
Azure AD Connect: When you have an existing tenant
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-install-existing-tenant - [Powershell Script] Convert ImmutableID
https://blog.jumlin.com/2018/09/powershell-script-convert-immutableid/ - Batch convert immutableID into Hexadecimal for
ms-dS-ConsistencyGuid
https://www.reddit.com/r/PowerShell/comments/e6yg7h/batch_convert_immutableid_into_hexadecimal_for/ - 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
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/ -
Using ms-DS-ConsistencyGuid as sourceAnchor
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-design-concepts#using-ms-ds-consistencyGuid-as-sourceanchor -
Explained: User Hard Matching and Soft Matching in Azure AD
Connect
https://dirteam.com/sander/2020/03/27/explained-user-hard-matching-and-soft-matching-in-azure-ad-connect/ -
Azure AD Connect: objectGUID vs. mS-DS-ConsistencyGuid,
Part 1: https://dirteam.com/sander/2017/07/12/azure-ad-connect-objectguid-vs-ms-ds-consistencyGuid-part-1/
Part 2: https://dirteam.com/sander/2017/08/24/azure-ad-connect-objectguid-vs-ms-ds-consistencyGuid-part-2/
Part 3: https://dirteam.com/sander/2017/08/31/azure-ad-connect-objectguid-vs-ms-ds-consistencyGuid-part-3/ -
Azure AD Connect v1.5.18.0 brings mS-DS-ConsistencyGuid as
source anchor for Groups
https://dirteam.com/sander/2020/04/03/azure-ad-connect-v1-5-18-0-brings-ms-ds-consistencyGuid-als-source-anchor-for-groups/ - Azure AD Connect - procedure to change source of anchor from
ObjectSID to Ms-DS-ConsistencyGuid
https://docs.microsoft.com/en-us/answers/questions/124627/azure-ad-connect-procedure-to-change-source-of-anc.html