SourceAnchor Kontakt

Neben den Benutzern synchronisiert ADSync auch Kontakte. Bei Benutzern gibt es eine "ImmutableID" aber bei Kontakten scheint es das Feld nicht zu geben. Wie findet dann hier das "Matching" statt?

Source Anchor für Kontakte

Anders als eine Mailbox sind Kontakte nicht mit einem Datenspeicher verbunden. Theoretisch wäre es gar nicht schlimm, wenn die Objekte bei einer Umorganisation im lokalen Active Directory gelöscht und wieder neu angelegt werden. Wobei das auf der anderen Seite doch nicht so schön wäre.

Kontakte sind nicht nur Objekte, die im Exchange Adressbuch oder Teams Adressbuch erscheinen. Die Exchange Objekte haben auch einen LegacyExchangeDN und Kontakte können Mitglied in einer Gruppe sein. Wenn Sie den Kontakt löschen und neu anlegen, dann kann dies zu Falschadressierungen in Outlook führen, z.B. wenn der Anwender auf eine Mail des Kontakts antwortet. Also muss ADSync auch hierfür eine Lösung haben.

Keine ImmutableID sichtbar

Wenn ich mir aber die Kontakte mit den unterschiedlichen Powershell-Befehlen in der Cloud anschaue, dann finde ich hier kein Feld namens "ImmutableID", wie die bei den Benutzern (Siehe SourceAnchor User) vorhanden ist.

Objekt AzureAD MSOL
Kontakt
PS C:\> Get-AzureADContact -Filter "mail eq 'adcontact1@msxfaq.net'" | fl *


DeletionTimestamp          :
ObjectId                   : 24745a53-1419-440f-9bd8-7699ad876d94
ObjectType                 : Contact
City                       :
CompanyName                :
Country                    :
Department                 :
DirSyncEnabled             : True
DisplayName                : ADContact1
FacsimileTelephoneNumber   :
GivenName                  : ADContact1
JobTitle                   :
LastDirSyncTime            : 02.02.2021 23:32:05
Mail                       : adcontact1@msxfaq.net
MailNickName               : ADContact1
Mobile                     :
PhysicalDeliveryOfficeName :
PostalCode                 :
ProvisioningErrors         : {}
ProxyAddresses             : {SMTP:adcontact1@msxfaq.net}
SipProxyAddress            :
State                      :
StreetAddress              :
Surname                    : ADContact1 Last
TelephoneNumber            :
PS C:\> Get-MsolContact -SearchString "adcontact1@msxfaq.net" | fl


ExtensionData             : System.Runtime.Serialization.ExtensionDataObject
City                      :
CompanyName               :
Country                   :
Department                :
DirSyncProvisioningErrors :
DisplayName               : ADContact1
EmailAddress              : adcontact1@msxfaq.net
Errors                    :
Fax                       :
FirstName                 : ADContact1
LastDirSyncTime           : 02.02.2021 23:32:05
LastName                  : ADContact1 Last
MobilePhone               :
ObjectId                  : 24745a53-1419-440f-9bd8-7699ad876d94
Office                    :
PhoneNumber               :
PostalCode                :
ProxyAddresses            :
State                     :
StreetAddress             :
Title                     :
ValidationStatus          : Healthy

Ohne ImmutableID müsste ein anderes Feld der primäre Schlüssel sein.

Felder in ADSync

Ein Blick in ADSync zeigt weitere Details. Für Kontakte kann über ADSync nachgeschaut werden, welche Felder aus dem lokalen AD gewonnen werden:

Hier wird aktuell nur die ObjectGUID genutzt, um einen Sourceanchor zu gewinnen. Beim Export Flow in die Cloud ist dann zu sehen, dass der DN CloudSourceAnchor zum "Join" genutzt wird

Das hat natürlich Auswirkungen, wenn Sie das Objekt in einen anderen Forest verschieben. Es wird dann zwingend gelöscht und neu angelegt, es sei denn Sie sorgen für ein "Soft-Match" über das Feld Mail. Das geht aber nur, wenn die per PowerShell nicht erreichbare ImmutabeID in der Cloud leer wäre.

Ich finde es sehr schade, dass Microsoft diese Information in der Cloud nicht zumindest lesbar macht.

Test mit Graph

Vielleicht ist über die GraphAPI mehr zu sehen unter der URL https://graph.microsoft.com/v1.0/contacts kann ich mir mit dem Graph Explorer ganz schnell die Kontakte im AzureAD anzeigen lassen. Ich finde hier auch den Beispielkontakt, der aus dem lokalen Active Directory repliziert wird.

Allerdings ist auch hier nur eine ID zu sehen aber keine CN oder DN.

ms-DS-ConsistencyGUID

Anders als bei Benutzern und optional bei Gruppen unterstützt ADSync im Feb 2021 noch nicht ein zusätzliches "Matching" über das Feld "ms-DS-ConsistencyGUID". Wird ein Kontakt tatsächlich einmal in einen anderen Forest verschoben, dann wird er aus Sicht von ADSync in der Quelle und damit auch im Tenant erst mal gelöscht und später wieder neu angelegt.

Zwischenstand

Anhand der Daten aus ADSync kann ich erkennen, dass ADSync für Kontakte ein Feld "SourceAnchor " im AzureAD befüllt, aber zusätzlich auch aus dem Sourceanchor anscheinend den CN des LDAP-Pfad des Objekte generiert. Ich finde das ungewöhnlich aber es sollte kein Problem darstellen, da der CN ja "nur" ein relativer Teil des gesamten LDAP-Pfads ist. Sollte also wirklich einmal ein anderer Tenant die gleiche ObjectGUID im lokalen Active Directory verwenden, stört dies nicht weiter.

Mich stört aber schon, dass ich weder den CN noch die ImmutableID des Objekt in der Cloud auslesen oder sogar setzen kann. Das nimmt mit natürlich die Möglichkeit, einen Kontakt über ein "Hard-Match" wieder zu verbinden. Ich muss in dem Fall ein unwiederbringlich gelöschtes Objekte im lokalen Active Directory neu anlegen, das passende Objekt in der Cloud aus dem dortigen Papierkorb extrahieren und dann ein Soft-Match über das Feld "Mail" machen. Wobei dazu die ImmutableID im AzureAD erst gelöscht werden müsste.

Also müsste man zuerst das Objekt im AzureAD wiederherstellen und sich über ADSync den SourceAnchor in der Cloud auslesen und davon abgeleitet dann das Feld ms-DS-ConsistencyGuid füllen.

Hier gibt es also noch einige Fragen zu beantworten, wenn der erste Kunde mit solchen Problemen bei mir anruft.

Weitere Links