ADSync User Matching

ADSync pflegt für jedes Objekt des lokalen Active Directory Forest ein Konto in der Cloud. Oft startet eine Firma aber erst einmal mit einem "Test" oder "Piloten" in der Cloud und möchte erst später diesen dann produktiv nehmen. Diese Seite beschreibt, wie ADSync auf bestehende Objekte reagiert. Beachten Sie dazu auch die Seite Office 365 SourceAnchor und ADMT

Ausgangssituation

Wir nehmen an, dass ein Office 365 Kunde folgende Schritte durchgeführt hat:

  • Office 365 Tenant gekauft
    Damit kann er die entsprechende Anzahl an Benutzer in der Cloud mit Exchange Postfächern, Skype for Business Konten, SharePoint, Yammer etc. versorgen
  • Offizielle Domain
    Da die Nutzung der "%tenantname%.onmicrosoft.com"-Adresse nicht gerade schick ist, kann der Kunde auch schon eine öffentliche DNS-Domäne für Office 365 registriert haben. Das ist auch nur ein Eintrag in der Cloud und ein DNS-Eintrag. Schon können Sie den Anwender in der Cloud einen "schönen" Anmeldenamen verpassen. Wenn der Name dann schon mit dem lokalen UPN übereinstimmt, fällt dem Anwender der Zugang gleich einfacher.
  • Optional ADFS
    Der Kunde könnte sogar schon ADFS installiert haben. Allein der richtige UPN in der Cloud reicht dazu aus. Das ist dann aber schon eher eine Ausnahme. Bei den meisten Installationen ist ADFS eher das Ende.

Das Ergebnis könnte sich im Admin Center dann wie folgt darstellen:

Es gibt in der Cloud einen User mit einem Benutzernamen und ggfls. einem Postfach.

Weiter unten komme ich auf das Feld "ImmutableID" zu sprechen. Das normale Matching erfolgt nur , wenn die Zielobjekte nicht durch einen früheren DirSync mit einer ImmutableID versehen sind.

Kein Match per UPN (Bis Feb 2015)

Mittlerweile wird auch der UPN  zum Matching genutzt. Dies muss aber für alte Tenants ggfls. aktiviert werden. Kontrollieren Sie besser die Einstellung, ehe Sie ADSync das erste Mail laufen lassen.

Wenn der Wert auf "false" stehen sollte, dann können Sie ihn so schnell ändern. Die Konfiguration steht in der Cloud und nicht auf dem lokalen ADSync-Server, da die Cloud das Matching übernimmt.

Set-MsolDirSyncFeature `
   -Feature EnableSoftMatchOnUpn `
   -Enable $True

Mittlerweile ist dieses Feature per Default "aktiv"

Die Beschreibung gilt daher für ältere Tenants oder solche, wo diese Einstellung nicht aktiv ist. In meinem Beispiel habe ich natürlich im lokalen Active Directory ebenfalls einen Benutzer angelegt, der den gleichen UPN hatte. Der Import gelingt noch aber beim Export gibt es einen Fehler "AttributeValueMustbeUnique".

Bleibt als "Pending Export" stehen:

Die Fehlermeldung war:

Das Objekt kann nicht aktualisiert werden, weil die folgenden dem Objekt zugeordneten Attribute Werte
aufweisen, die möglicherweise bereits einem anderen Objekt in Ihren lokalen Verzeichnisdiensten zugeordnet 
sind: "UserPrincipalName frank@cariusxxx.de;". Korrigieren oder entfernen Sie die doppelt vorhandenen Werte 
in Ihrem lokalen Verzeichnis. Weitere Informationen zur Erkennung von Objekten mit doppelt vorhandenen 
Attributwerten finden Sie unter http://support.microsoft.com/kb/2647098.

Tracking Id: 571fb5c0-0a20-4d31-af1a-c3dfd75cfd94

ADSync und das Azure-AD beschweren sich zurecht, dass es im Ziel schon ein "anderes" Objekt gibt, welches diesen UPN hat.

  • 3164442 How to use UPN matching for identity synchronization in Office 365, Azure, or Intune

Soft-Match für Adminkonten

Standardmäßig matched ADSync keine CloudOnly-Benutzer, die eine administrativ Rolle haben!

Dies ist von Microsoft auch dokumentiert:

Aber auch hier können Sie per "Hard Match" arbeiten oder temporär die Adminrollen entfernen. Siehe dazu auch ADSync Softmatch Adminkonten.

Match mit ProxyAddresses

ADSync kann Objekte "Matchen", aber dazu muss die SMTP-Adresse übereinstimmen. Genaugenommen prüft ADSync die primäre SMTP-Adresse unter ProxyAddresses.

When you install Azure AD Connect and you start synchronizing, the Azure AD sync service (in Azure AD) does a check on every new object and tries to find an existing object to match. There are three attributes used for this process: userPrincipalName, proxyAddresses, and sourceAnchor/immutableID. A match on userPrincipalName and proxyAddresses is known as a soft match. A match on sourceAnchor is known as hard match. For the proxyAddresses attribute only the value with SMTP:, that is the primary email address, is used for the evaluation.
Quelle: Azure AD Connect: When you already have Azure AD | Microsoft Docs
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-install-existing-tenant

Das Feld "mail" im lokalen AD muss mit der primären Mailadresse in den Cloud übereinstimmen.

Das ist aber nicht alles, denn auf "Custom installation of Azure AD Connect" (https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-get-started-custom/) steht noch etwas mehr.

SourceAnchor / ImmutableID
Wenn Objekte im Ziel schon eine ImmutableID haben, dann geht ADSync davon aus, dass das Objekt bereits mit einem On-Prem-Objekte verbunden ist. Damit ist auch ein "Hard Match" möglich um. z.B. eine Bindung zu erzwingen. Das ist nützlich, wenn Sie ADSync im Rahmen eines Recovery neu installieren müssen.

Entsprechend habe ich nun auf dem "On-Premises-Objekt" einfach eine SMTP-Adresse addiert und den DirSync erneut laufen lassen. Schon in der Listenansicht fallen zwei Änderungen auf. Einmal der neue Synchronisationstyp und auch der Anzeigename wurde aus dem lokalen AD übernommen

Beim Blick in den ADSync sind auch die Änderungen beim Schreiben zu sehen.

Sie sehen aber hier, dass von der On-Premises-Umgebung keine Exchange Properties geschrieben wurden. Der Benutzer war bisher On-Premises nicht für Exchange aktiviert aber hat ein Postfach in der Cloud. Da ADSync hier aber nur unidirektional arbeitet. sind diese Daten nicht aus der Cloud in das On-Prem Directory abgebildet worden. Das ist verständlich, da es in diesem Forest noch keine Exchange Erweiterungen gibt.

Ich wollte nun eigentlich sehen, was nun beim "Change" des UPN passiert. Dabei habe ich übersehen, dass bislang nur ein DirSync-Lauf passiert war. Zuerst komm ein DeltaImport aus beiden Connectoren, dann die Zusammenführung und erst dann der Export in die Ziele. Insofern konnte der Import noch gar nicht wissen, dass beim Export der User "Matched" und zusammen geführt wird.

Der nächste Lauf startet wieder mit einem Delta Import und hier "erkennt" ADSync nun das Objekt im Ziel und dass es noch eine ganze Menge weiterer Felder gibt, die sich da ändern müssen:

Neben dem "Modify" auf den UPN entfernt ADSync im Azure AD nun aber auch all die in der Cloud bislang manuell gepflegte Felder. Ich habe diese Felder aktuell noch nicht On-Premises gepflegt und daher müssen Sie auch in der Cloud raus. Auch hier ist aber sichtbar, dass keine Exchange Properties aus der Cloud in die lokale Umgebung repliziert werden. Das ist aber einzig der Tatsache zu verdanken, dass das Objekt im lokalen AD aus Sicht von ADSync gar nicht als "Exchange relevant" angesehen wird.

Störender finde ich hier aber die Tatsache, dass der geändert UPN, weswegen ich hier nachgeschaut habe, als "Change" auftaucht.

Hardmatch ImmutableID

Fast alle Felder in einem AD können sich ändern. Selbst der SAMAccountName, der UPN und der DN und CN. Auch die ObjectSID ist nicht zuverlässig, da Objekte auch in andere Domänen des gleichen Forest verschoben werden können. Die Mailadresse ist zwar auch ein Feld, welches durch die Kombination von einmaliger Internet-Domäne und einem LocalPart nur einmal weltweit vergeben werden kann, aber auch eine Mailadresse kann sich ändern und kennzeichnet nicht zwingend das Objekt über die ganze Laufzeit.

Ein "Cloud"-Anwender, der noch nie synchronisiert war, hat keine ImmutableID. Die ImmutableID sagt Office 365, dass dieses Objekt "synchronisiert" wird.

Es gibt aber doch wenige Felder, die bei korrekten Migrationen beibehalten werden, solange das Objekt innerhalb des Forest existiert. Eines der Felder ist die ObjectGUID, welche jedes Objekt bei der Anlage bekommt und idealerweise weltweit einmalig und eindeutig ist. Daher nutzt auch ADSync diese Feld, um damit das Objekt im lokalen Active Directory und in der Cloud eindeutig miteinander zu verbinden. Die ObjectGUID wird während des Imports zu einem "SourceAnchor" der in der Cloud dann unter dem Namen "ImmutableID zu finden ist. Den Wert der ImmutableID können Sie sehr einfach per Powershell ermitteln:

# ObjectGUID eines Users holen
$guid = (get-AdUser frankcarius).ObjectGuid

# ObjectGUID in einen BASE64-String umrechnen.
$immutableID = [System.Convert]::ToBase64String($guid.tobytearray())

Das Feld ImmutableID kann mit der Office 365 Powershell sogar beschrieben und gesetzt werden und es gibt auch keinen Fehler, wenn das Feld auf "$null" gesetzt wird:

set-MsolUser `
   -UserPrincipalName User1@carius.de ' 
   -ImmutableId $null

# Hinweis: Auch wenn dies keinen Fehler gibt, so wird die ImmutableID nicht entfernt, solange der DirSync aktiv ist.

Alle anderen Schreibweisen mit "$null" oder '$null" oder "" o.ä. führen alle zu einem "set-MsolUser : Unable to Update parameter. Parameter name: SourceAnchor." Die ImmutableID bleibt weiterhin auf dem alten Wert. Es soll aber möglich sein, über den Weg ein Object in der Cloud auf ein anderes On-Prem-Objekt umzuhängen. Damit dies aber fehlerfrei abläuft, müssen Sie eine Abfolge einhalten:

  1. DirSync anhalten
    Microsoft meinst damit aber nicht das Pausieren des ADSync sondern die Abschaltung des DirSync im kompletten Tenant
    Deactivate directory synchronization
    https://msdn.microsoft.com/en-us/library/azure/dn144760.aspx
    Es soll angeblich auch reichen, wenn das Objekt in der Quelle nicht mehr im "Scope" des DirSync ist und daher "entsynched" wird.
  2. ImmutableID des Zielobjekts anpassen
    Das AD-Object hat selbst nach dem Abschalten des DirSync noch eine ImmutableID. Mit Set-MSOLUser können Sie die neue ImmutableID setzen
  3. DirSync wieder aktivieren
    Danach können Sie den DirSync wieder neu einrichten.
    Activate directory synchronization
    http://technet.microsoft.com/en-us/library/dn144766.aspx

Dazu suchen Sie sich zuerst die ObjectGUID des gewünschten Objects im AD und rechnen diese BASE64um. Dann soll es möglich sein, diese ID mit Set-MSOLUser in der Cloud zu setzen und damit die Verknüpfung umzuhängen.

Unmatching

Ein Konto, welches durch den DirSync angelegt oder bei einem Match konvertiert wurde, ist sehr eingeschränkt in der Cloud verwaltbar. Es kann bei der Zusammenführung von lokalen AD-Objekten mit bestehenden Cloud-Objekten aber durch passieren, dass eine falsche Zuordnung passiert. dann ist guter Rat teuer.

Ein radikaler aber meist überflüssiger Weg ist es, ADSync komplett zu deaktivieren, die msdsconsistencyGUID zu bereinigen, den Fehler zu beheben und neu zu matchen.

#DirSync für den Tenant deaktivieren
Set-MsolDirSyncEnabled -EnableDirSync $false
# kann bis zu 72h dauern

# Kontrolle, ob die Einstellunge schon umgesetzt ist
(Get-MSOLCompanyInformation).DirectorySynchronizationEnabled

Danach sind alle Objekte wieder "In der Cloud" und per Admin Center oder Powershell änderbar. Und natürlich durch einen neuen DirSync auch wieder "matchbar"

Es geht aber zumindest für Benutzer auch einfacher. Der Trick funktioniert nicht mit Gruppen und anderen Objekten, die nicht im AzureAD-Papierkorb landen.

  1. ADSync Exclude
    Sie schließen das AD-Objekte aus ADSync aus. Das kann über einen Filter gehen oder sie legen am einfachsten eine neue OU an, die von ADSync ausgeschlossen ist und in welche Sie das fragliche Objekt verlagern
  2. ADSync löscht in den Papierkorb
    Nun lassen Sie ADSync laufen, damit er das aus seiner Sicht "gelöschte Objekte" auch in der Cloud löscht. Der Benutzer in der Cloud landet aber im Papierkorb.
  3. Recover
    Nun holen Sie den Benutzer aus dem AzureAD-Papierkorb wieder heraus. Sie haben zwar 30 Tage dafür Zeit aber ich nehme an, dass Sie das lieber schnell machen, denn im Papierkorb kann der Anwender ja nicht arbeiten und bekommt auch keine Mails etc.
  4. Cleanup
    Das widerhergestellte Objekte hat zwar eine "ImmutableID" aber ist dennoch ein "CloudOnly" Konto, welches Sie direkt in der Cloud verwalten können. Nun sollten Sie das AzureAD-Konto bereinigen, indem sie die ImmutableID löschen oder auf den richtigen Wert setzen. Auch das AD-Objekte sollten Sie so einstellen, dass beim nächsten Sync die richtigen Objekte zueinander passen.
  5. ReSnyc
    Verschieben sie dann das AD-Objekte wieder an seine OU, damit ADSync beim nächsten Lauf wieder neu einen Match durchführt.

Diese Verfahren von Schritt 1-3 ist auch eine elegante Funktion, z.B. beim Rückbau eines lokalen Exchange Servers die Räume oder SharedMailboxen von ADSync zu entkoppeln um diese in der Cloud zu verwalten. Die müssen dann nur noch durch ADSync verwaltete Benutzer über die Exchange Management Rolle verwalten.

  • 2619062 You can't manage or remove objects that were synchronized through the Azure Active Directory Sync tool

Merging

Neben dem "Match" eines Objekts aus dem lokalen AD über das Metaverse zu einem Office 365 Konto gibt es noch einen zweiten Fall, wo Objekte zusammenfinden müssen. Das ist immer dann der Fall, wenn sie lokal zwei oder mehr Forests haben. Bei der Installation des ADSync können Sie hierzu die Regeln einstellen.

Wer also mit einem Ressource Forest arbeitet, sollte hier die richtige Option auswählen.

  • msExchMasterAccountSID
    Dieses Feld findet sich bei einem deaktivierten Benutzer mit Exchange Postfach und verweist auf das Anmeldekonto in einem anderen Forest. ADSync kann diese beide Objekten "verbinden", so dass vom Anmeldekonto z.B. der UPN kommt und von der LinkedMailbox dann die Exchange Informationen wie ProxyAddresses etc.
  • msrtcOriginatorSID
    Analog dazu gibt es auch bei Lync/Skype for Business die Möglichkeit eines Ressource Forests. Auch dieses Feld nutzt ADSync um mehrere Benutzerobjekte aus lokalen Forests zu einem Objekte mit Metaverse und folglich zu einem Office 365 Objekte zusammen zu fassen.

Achtung: Nachdem das Setup durchgelaufen ist, sollten Sie dennoch die JOIN-Regeln diesbezüglich kontrollieren. Einem Kollegen ist es passiert, dass trotz korrektem Setup (mit Screen Captures dokumentiert) der SAM-Accountname genutzt wurde.

Insofern muss ein "falscher Merge" nicht unbedingt an den Stammdaten liegen. Ein Blick in die "Synchronization Rules" bringt auch noch einmal Licht ins Dunkel.

Weitere Links