ADSync Bidirektional

Die Kopplung von Office 365 mit einem On-Prem Active Directory über einen Verzeichnisabgleich ist immer ein Gewinn. Um es einfach zu halten, repliziert ADSync laut den meisten Informationen dazu Informationen aus dem lokalen Active Directory in die Cloud. Das ist aber nur die halbe Wahrheit, denn einige Felder und Objekte werden auch zurück repliziert. Diese Seite beschreibt die Hintergründe

Warum nicht generell bidirektional ?

Die Frage ist durchaus berechtigt, denn wenn ADSync heute schon das lokale AD liest und Elemente in die Cloud überträgt dann könnte man doch auch Änderungen in der Cloud wieder zurück übertragen. Und tatsächlich gibt es sogar eine Betriebsart, bei der ADSync auch solche Funktionen bietet. Allerdings nicht im Standard und ich bezweifle auch, dass die meisten Kunden damit glücklich werden würden. Ein bidirektionaler Abgleich ist nämlich keineswegs so "einfach" wie dies gerne dargestellt wird. Insbesondere die möglichen Konflikte sind nicht zu unterschätzen, wenn Objekte in der Cloud angelegt oder geändert werden aber so nicht On-Prem nachgepflegt werden können.

Daher sind die meisten "WriteBack"-Optionen bei ADConnect als "Optional". Wenn Sie weniger Optionen haben, dann prüfen Sie bitte ihre ADConnect Version.

 

Eventuell sind nicht alle Optionen anwählbar. So funktioniert "Passwort Writeback" nur, wenn Sie in Azure ihr Kennwort ändern können wozu eine Azure AD Premium-Lizenz erforderlich ist.

WriteBack und AdminCount

Auch mit ADSync kommt wieder das altbekannte Problem des AdminSDHolder nach vorne. Wenn OnPrem Benutzer, die mit ADSync in die Cloud repliziert werden, lokal in administrativen Gruppen enthalten sind, dann unterbricht Windows die Vererbung von Rechten. Die Folge ist, dass das ADSync-Dienstkonto in der Regel nicht die wenigen Felder in das OnPrem-Konto zurückschreiben kann. Es gelten auch hier wieder die Regeln:

  • Administratoren sind keine Benutzer mit Postfächern o.ä.
  • Benutzer sind keine Administratoren mit erweiterten Rechten

Beachten Sie dies bitte bei der Nutzung von Konten. Sie erkennen dies aber an entsprechenden Einträgen im ADSync Eventlog, wenn Sie diese denn überwachen.

Bidirektional mit Augenmaß

Aber auch wenn Sie nur Exchange Hybrid einrichten oder auch nur einen einfachen DirSync für Benutzer, Gruppen und Kontakte, so schreibt AADConnect mittlerweile auch munter in ihr Active Directory. Die Aussage, dass AADConnect nur OneWay in die Cloud synchronisiert und das lokale AD immer der Master ist, stimmt so nicht. Sie können dazu einfach den "Synchronization Rules Editor" starten, der mit installiert wurde und die Regeln mit der Direction "Outbound" betrachten. Neben viele anderen Regeln gibt es hier auch einige die mit "Out to AD" beginnen

Sie können sogar noch weiter in die Regeln hinein schauen und so erfahren, welche Felder in ihrem "On-Prem"-Active Directory durch Einträge aus dem Metaverse gepflegt werden. Einige Inhalte im MetaVerse werden durch eingehenden Synchronisationsregeln aus dem AzureAD gefüllt. Aber nicht alle Regeln enthalten "Transformations". Einige sind nur als "Join Rule" vorhanden um die Zuordnung von Objekten zu regeln.

Wenn Sie eine Regel nur Anzeigen wollen, dann drücken Sie nach dem "EDIT" bitte auf "NEIN", damit Sie die bestehende Regeln anzeigen und nicht eine Kopie anlegen. Das folgende Fenster sollten Sie dann natürlich mit "Cancel" am Ende wieder verlassen.

Hier einmal die Regel "Out to AD - Contact Exchange Hybrid":

 

Damit das "Zurückschreiben" auch funktioniert, muss das Dienstkonto natürlich entsprechenden Berechtigungen haben. In kleineren Umgebungen können Sie das Konto einfach zum "Domänen Administrator" machen. In größeren Umgebungen wird man eher ein Dienstkonto mit den "notwendigen" Rechten ausstatten.

Auch dabei unterstützt AADConnect durch entsprechende Commandlets

Import-Module ‘C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1

Initialize-ADSyncDomainJoinedComputerSync
Initialize-ADSyncDeviceWriteBack
Initialize-ADSyncGroupWriteBack 
Initialize-ADSyncNGCKeysWriteBack
Initialize-ADSyncUserWriteBack

AADConnect msDS-ConsistencyGuid in „sourceAnchor

Seit der Version Azure AD Connect (Version 1.1.524.0 und höher) nutzt ADSync nicht mehr die objectGUID als Default für den SourceAnchor sondern das Feld msDS-ConsistencyGuid. Dieses ist On-Prem aber in der Regel leer. ADSync liest daher Initial weiterhin die objectGUID aus um dann aber den Wert in das Feld msDS-ConsistencyGuid zurück zu schreiben. Das Wie hat Microsoft dokumentiert:

msDS-ConsistencyGuid“ wird als „sourceAnchor“-Attribut für Benutzerobjekte verwendet. „objectGUID“ wird für andere Objekttypen verwendet.

Für jedes lokale AD-Benutzerobjekt, dessen „msDS-ConsistencyGuid“-Attribut nicht aufgefüllt ist, schreibt Azure AD Connect den zugehörigen Wert von „objectGUID“ in das Attribut „msDS-ConsistencyGuid“ im lokalen Active Directory zurück. Nachdem das Attribut „msDS-ConsistencyGuid“ aufgefüllt wurde, exportiert Azure AD Connect das Objekt nach Azure AD.
Quelle: Azure AD Connect: Designkonzepte (https://docs.microsoft.com/de-de/azure/active-directory/connect/active-directory-aadconnect-design-concepts#using-msds-consistencyguid-as-sourceanchor)

Dies ist also ein weiterer Fall, bei dem AADConnect in das On-Prem-AD zurückschreibt. Allerdings wird das Feld nicht mehr geleert, wenn AADSync das Objekt wieder aus dem Scope verliert. Es ist also kein Indikator, welche Objekte aktuell repliziert sind.

Exchange: "Out to AD - User Exchange Hybrid"

Sehr viel Interessanter für Sie als Leser der MSXFAQ wird natürlich der Einfluss von AADConnect auf Exchange On-Prem sein. Microsoft selbst veröffentlicht eine Liste der geänderten Felder:

Nicht alle Felder sind bei allen Objekten von Belang: 

Attribut Benutzer Kontakt Gruppe Hinweise

msDS-ExternalDirectoryObjectID

Sobald Exchange 2016 im On-Prem-AD vorhanden ist, wird dieses Feld anhand des "cloudAnchor" aus dem Azure AD gefüllt und gepflegt.

msExchArchiveStatus

 

Wenn der Benutzer in Archiv in der Cloud hat, bekommt dieses Feld einen Wert

msExchBlockedSendersHash

Ich nehme an, dass über diesen Weg auch Spam-Einstellungen, Filter, die ein Anwender in der Cloud macht, zurückrepliziert werden. Das ist erforderlich, wenn Sie selbst die Mails über einen Edge-Server empfangen.

msExchSafeRecipientsHash

Ich nehme an, dass über diesen Weg auch Spam-Einstellungen, Filter, die ein Anwender in der Cloud macht, zurückrepliziert werden. Das ist erforderlich, wenn Sie selbst die Mails über einen Edge-Server empfangen.

msExchSafeSendersHash

Ich nehme an, dass über diesen Weg auch Spam-Einstellungen, Filter, die ein Anwender in der Cloud macht, zurückrepliziert werden. Das ist erforderlich, wenn Sie selbst die Mails über einen Edge-Server empfangen.

msExchUCVoiceMailSettings

Über dieses Feld kann Lync 20130/Skype for Business erkennen, dass der Benutzer "Voicemail" in Exchange Online hat.

msExchUserHoldPolicies

Mit dem Feld kann die Cloud angeblich erkennen, ob der Benutzer unter "Litigation Hold" ist. Ich kann mir aber noch nicht erklären, warum das dann zum lokalen AD repliziert werden müsste.

proxyAddresses

On-Prem wird nur der LegacyExchangeDN aus der Cloud als zusätzliche die x500 Adresse addiert.

Die entsprechende Regel im AADConnect lautet "Out to AD - User Exchange Hybrid und sieht wie folgt aus: 

Bei meinem Tests habe ich zuerst ein Postfach "On-Prem" angelegt und dann die Replikation nach Office 365 betrachtet. Die hier aufgeführten Felder werden alle nach Office 376 übertragen:

Interessanter werden nun die folgenden Felder für den Rückweg, die beim nächsten Lauf synchronisiert werden:

Exchange: ProxyAddresses

Wenn ein Benutzer "On-Prem" für Exchange On-Prem aktiviert wird, dann repliziert ADSync natürlich die relevanten Exchange-Informationen in die Cloud. Dies ist erforderlich, damit Exchange Online den Benutzer zum einen in der GAL anzeigen und Nachrichten routen kann. Zum anderen ist dieser Benutzer in der Cloud für eine spätere Migration erforderlich.

Es ist auch klar, dass hier beim Export in die Cloud keine Mailboxdaten mit übertragen wird. Aber beim nächsten Sync werden Informationen aus der Cloud eingelesen und dann wieder in das lokale AD zurückgeschrieben.

Dieser Eintrag zeigt sehr gut, dass zu dem Feld "ProxyAddresse" ein Eintrag addiert wird.

Exchange: msds-Externaldirectoryobjectid

Mit ist aber nicht verborgen geblieben, dass mittlerweile noch ein weiteres Feld nach On-Prem repliziert wird. Dazu ist Exchange 2016 "On-Prem" erforderlich und Sie müssen beim AADConnect einmal das Setup mit einem Neueinlesen des Schemas durchlaufen, damit die geänderten Regeln aktiv werden.

Dieses Fenster zeigt, dass das Feld im lokalen AD durch einen Wert aus Office 365 gefüllt wird.

Password Writeback

Relativ einfach die die Funktion "Password Writeback" zu lösen. Mit der passenden Lizenz in Office 365 und einigen Einrichtungen können Anwender über das Portal in der Cloud ihr Kennwort ändern. AADConnect sorgt dann dafür, dass diese Änderungen möglichst schnell auch "On-Prem" umgesetzt werden. Diese Konfiguration und Schritte beschreibe ich hier nicht weiter und verweise auf die entsprechenden Blog-Artikel

Device Writeback

Auch zum "Device Writeback" verliere ich hier keine Worte. Ich nutze das Feature aktuell in meinem MSXFAQ-Tenant nicht und es fällt auch nicht direkt in den Bereich Exchange oder Skype for Business. Es gibt umfangreiche Beschreibungen bei Microsoft und anderen Blogs

Weitere Links