SourceAnchor Gruppen

Neben den Benutzern synchronisiert ADSync auch Gruppen. Bei Benutzern gibt es eine "ImmutableID" aber bei Gruppen gibt es dieses Feld anscheinend nicht. Wie findet dann hier das "Matching" statt?

Zum Verständnis sollen Sie die Seite SourceAnchor vorab lesen. Für Benutzer gibt es eine eigene Seite auf SourceAnchor User.

Source Anchor für Gruppen

Anders als eine Mailbox sind Gruppen 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, z.B.

Gruppen und Verteiler mit Mitgliedern können theoretisch ebenfalls gelöscht und wieder angelegt werden. Microsoft 365 Groups werden vom ADSync sowieso ignoriert. Dennoch sind Gruppen mit Mailadresse nicht nur Verteiler in Exchange. Gruppen werden auch von Anwender genutzt, um diese z.B. auf Datenbereich in SharePoint oder auf Postfächer zu berechtigen. Da käme ein "Löschen und neu Anlegen" nicht so gut.

Also muss ADSync auch hierfür eine Lösung haben.

Keine ImmutableID sichtbar

Wenn ich mir aber die Kontakte und Gruppen 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
Gruppe 
PS C:\> Get-MsolGroup -SearchString 'ADGroup-SG' | fl *

ExtensionData                : System.Runtime.Serialization.ExtensionDataObject
AssignedLicenses             : {}
CommonName                   : ADGroup-SG
Description                  :
DirSyncProvisioningErrors    :
DisplayName                  : ADGroup-SG
EmailAddress                 :
Errors                       :
GroupLicenseProcessingDetail :
GroupType                    : Security
IsSystem                     : False
LastDirSyncTime              : 02.02.2021 23:32:05
Licenses                     : {}
ManagedBy                    :
ObjectId                     : b7e6ab72-2694-42b6-9421-9e8e948d17fb
ProxyAddresses               : {}
ValidationStatus             : Healthy
 
PS C:\> Get-AzureADGroup -Filter "Displayname eq 'ADGroup-SG'" | fl

DeletionTimestamp            :
ObjectId                     : b7e6ab72-2694-42b6-9421-9e8e948d17fb
ObjectType                   : Group
Description                  :
DirSyncEnabled               : True
DisplayName                  : ADGroup-SG
LastDirSyncTime              : 02.02.2021 23:32:05
Mail                         :
MailEnabled                  : False
MailNickName                 : ADGroup-SG
On-PremisesSecurityIdentifier : S-1-5-21-1343410112-1294273473-3016097062-1110
ProvisioningErrors           : {}
ProxyAddresses               : {}
SecurityEnabled              : True

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

Felder in ADSync

Ein Blick in ADSync zeigt dann aber schon weitere Details. Der Source Anchor wird wieder aus der ObjectGUID oder ersatzweise aus dem Feld ms-DS-ConsistencyGuid gebildet. Zusätzlich wird der SourceAnchor aber noch per UTF8HEX-Konvertierung zum CN des DistinguishedName. Interessant ist hier, dass der "CN" im AzureAD anhand des SourceAnchor gebildet wird.

Auch hier wird der CN in der Cloud von dem SourceAnchor abgeleitet und der stammt ursprünglich von der ObjectGUID ab, die dann aber zumindest bei der Gruppe von ADSync wieder in den ms-DS-ConsistencyGuid zurückgeschrieben wird.

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

Wenn eine Gruppe daher das Feld "ms-DS-ConsistencyGUID" enthält , dann können sie diese Gruppe später auch in andere Forests verschoben werden. Sie müssen nur drauf achten, dass der Inhalt von "ms-DS-ConsistencyGUID" sauber mitkommt.

Leider ist der CN als auch der DN nicht über die AzureAD PowerShell oder MSOnline PowerShell zu sehen. Schaut man noch etwas weiter in ADSync nach, dann findet sich im Connectorspace der Gruppe zum AzureAD auch ein CloudSourceAnchor und einen SourceAnchor:

Bei einem Benutzer ist der SourceAnchor" über die AzureAD-PowerShell bzw. MSOnline-PowerShell sichtbar und zum Teil auch änderbar.

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/groups kann ich mir mit dem Graph Explorer ganz schnell die Gruppen anzeigen lassen. Ich finde hier auch die Gruppe ADGroupSG, die aus dem lokalen Active Directory repliziert wird.

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

ms-DS-ConsistencyGUID

Seit der ADSync Version 1.5.18.0 wertet ADSync auch das Feld ms-DS-ConsistencyGUID aus, wenn es um das Matching von Gruppen geht. Allerdings gibt es einen wesentlichen Unterschied zu "Benutzern"

Starting in version 1.5.18.0, Azure AD Connect supports the use of the mS-DS-ConsistencyGuid attribute for groups. If you choose mS-DS-ConsistencyGuid as the source anchor attribute and the value is populated in Active Directory, Azure AD Connect uses the value of mS-DS-ConsistencyGuid as the immutableId. Otherwise, it falls back to using objectGUID. 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

Wichtig ist die Information, dass ADSync das Feld ms-DS-ConsitencyGuid nicht selbst beschreibt. Das können sie aber schnell selbst nachholen.

Diese Aktion ist nur erforderlich, wenn Sie Gruppen wirklich "Cross Forest" in einen anderen Forest migrieren wollen, bei der die ObjectGUID nicht erhalten bleibt.
Ansonsten können Sie sich diese Zusatzfunktion sparen.

get-adgroup `
   -filter * `
| %{`
      Write-Host "Update Group $($_.distinguishedname)"
      Set-ADGroup `
         -Identity $_.distinguishedname `
         -Replace @{"ms-DS-ConsistencyGUID"=$_.ObjectGUID}`
}

Damit bekommen dann alle Gruppen die objectGUID übertragen und können dann auch "CrossForest" migriert werden. In ADSync sehen Sie dann auch, dass das geänderte Feld eingelesen wurde

Diese Feld ist übrigens auch ein gutes Hilfsmittel, um das Verhalten einer Migration zu beobachten. Sie können ja einfach den Inhalt von ms-DS-ConsisencyGuid ändern und die Reaktion von ADSync darauf beobachten. Ich habe einfach mal die ms-DS-ConsistencyGuid geändert.

ADSync hat dies aber "gemerkt" und einen "Synchronization Error" geworfen.

 Error in evaluation of expression: 
   IIF(IsPresent([cloudSourceAnchor]),
      IIF([cloudSourceAnchor] = [sourceAnchor],
         [sourceAnchor],
         Error("SourceAnchor attribute has changed.")
      ),
   [sourceAnchor]
   )
. Sync Rule: Out to AAD - Group Join 
 Destination: sourceAnchor

Ich hatte erwartet, dass ADSync ein neues Objekt erkennt und das "alte" löscht. Aber da habe ich mich getäuscht. So einfach lässt sich ADSync nicht ein bestehendes Objekt kaputt machen. Es muss schon ein "neues Objekt" sein, welches gleich mit dem ms-DS-ConsistencyGuid gelesen und imporiert wird.

Das Feld ms-DS-ConsistencyGuid kann natürlich auch genauso einfach wieder geleert werden:

get-adgroup `
   -filter * `
| %{`
      Write-Host "Update Group $($_.distinguishedname)"
      Set-ADGroup `
         -Identity $_.distinguishedname `
          -clear "ms-DS-ConsistencyGUID" `
}

Der "Cleanup" ist aber nicht ratsam, wenn in ihrem Forest bereits aus anderen Forests migrierte Konten sind, denn dann würde ADSync die Verbindung verlieren, die AzureAD-Gruppe löschen und mit der ObjectGUID neu anlegen.

Zwischenstand

Anhand der Daten aus ADSync kann ich erkennen, dass ADSync für Gruppen sehr wohl 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 verwendet, 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, eine Gruppe ü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