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 angelegt

Das 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 Export

Der 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

Pause

Der 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 Import

Beim nächsten Import kommt nun aus dem AzureAD ein Update.

Auf dem lokalen AD gibt es keine Änderungen

6

Delta Sync

Die Ä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 AD

Hier wird nun , wie erwartet, das Feld ms-DS-ConsistencyGuid aktualisiert

8

Export zum AzureAD

Aber 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

Weitere Links