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.

Achtung:
Für die bidirektionale Replikation einiger Fehler müssen Sie manuell dem ADSync-Dienstkonto entsprechende Berechtigungen zuweisen. Lesen Sie die Anleitungen genau und passen Sie die Aufrufe entsprechend an. Es kann zudem sein, dass Microsoft selbst entsprechende Tools mit einer aktuelleren Version des AADConnect mittlerweile mitliefert.

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 "Write-Back"-Optionen bei ADConnect als "Optional". Wenn Sie weniger Optionen haben, dann prüfen Sie bitte ihre AADConnect 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.

Wichtig: Die Funktion "Group Writeback" wird zum Sommer 2024 abgeschaltet und kann mittlerweile nicht mehr neu konfiguriert werden. Sie wird zukünftig über Cloud Connect (Siehe Group Writeback)

Service Konto und Rechte

Der AzureAD Connect-Dienst verbindet sich sowohl gegen das AzureAD aber auch gegen das lokale AD mit einem Dienstkonto. Es zählt also nicht das Konto, mit dem der Dienst selbst läuft. Diese Konto muss auf dem lokalen Active Directory entsprechende Rechte haben.
In kleineren Umgebungen wird dieses Connector-Konto auch in die gruppe DomänenAdministratoren addiert und sie umgehen damit alle Rechte-Probleme. Sicherer ist es aber, wenn das Konto genau die Rechte bekommt, die es für die Arbeit benötigt. Diese Rechte müssen Sie dann aber selbst hinzuweisen, denn als DomänenBenutzer kann das Konto nur Lesen. In einfachen Fällen reicht das sogar aus aber einige Felder sollte der AADConnect auch schreiben können. Wenn sie diese Berechtigungen vergessen, dann sehen sie im Protokoll natürlich die Fehler.

WriteBack und AdminCount

Auch mit ADSync kommt wieder das altbekannte Problem des AdminSDHolder nach vorne. Wenn On-Premises 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 On-Premises-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 One-Way 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-Premises-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 "Transformationen". 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":

 

Achtung
Aus der Cloud wird nur der CloudLegacyExchangeDN als X-500-Adresse in die lokalen ProxyAddresses geschrieben. SMTP-Adressen werden aber nicht aus der Cloud in das lokale Objekte übertragen.

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

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

Alternativ geht es auch klassische per DACLS.

dsacls 'dc=msxfaq,dc=net' /I:S /G 'msxfaq\svcaadconnect:WP;ms-ds-consistencyGuid;User'
dsacls 'cn=AdminADHolder,cn=System,dc=msxfaq,dc=net' /I:S /G 'msxfaq\svcaadconnect:WP;ms-ds-consistencyGuid;User'

REM Optional um die AD-Replikation zu triggern
repadmin /syncall

Die Anpassung des AdminSDHolder wirkt nicht sofort, sondern bis zu 45 Minuten später.

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 ADSync das Objekt wieder aus dem Scope verliert. Es ist also kein Indikator, welche Objekte aktuell repliziert sind.

Exchange Hybrid: "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. Eine SIP-Adresse in der Cloud wird z.B. nicht repliziert.

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-Premises angelegt und dann die Replikation nach Office 365 betrachtet. Die hier aufgeführten Felder werden alle nach Office 365 übertragen:

Interessanter werden nun die folgenden Felder für den Rückweg, die beim nächsten Lauf synchronisiert werden: Microsoft liefert dazu mittlerweile ein PowerShell-Skript mit aus.

Import-Module DirSync
Enable-MSOnlineRichCoexistence

Alternativ können Sie auch manuell die Rechte mit DACLS setzen.

dsacls 'dc=example,dc=com' /I:S /G "domain\serviceaccount:RPWP;proxyaddresses;User"
dsacls 'dc=example,dc=com' /I:S /G "domain\serviceaccount:RPWP;proxyaddresses;contact"
dsacls 'dc=example,dc=com' /I:S /G "domain\serviceaccount:RPWP;proxyaddresses;group"
dsacls 'dc=example,dc=com' /I:S /G "domain\serviceaccount:RPWP;msDS-ExternalDirectoryObjectID;User"
dsacls 'dc=example,dc=com' /I:S /G "domain\serviceaccount:RPWP;msExchArchiveStatus;User"
dsacls 'dc=example,dc=com' /I:S /G "domain\serviceaccount:RPWP;msExchBlockedSendersHash;User"
dsacls 'dc=example,dc=com' /I:S /G "domain\serviceaccount:RPWP;msExchSafeRecipientsHash;User"
dsacls 'dc=example,dc=com' /I:S /G "domain\serviceaccount:RPWP;msExchSafeSendersHash;User"
dsacls 'dc=example,dc=com' /I:S /G "domain\serviceaccount:RPWP;msExchUCVoiceMailSettings;User"
dsacls 'dc=example,dc=com' /I:S /G "domain\serviceaccount:RPWP;msExchUserHoldPolicies;User"

Details: Exchange ProxyAddresses

Wenn ein Benutzer On-Premises 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. Auch dazu muss das ADSync-Konto natürlich berechtigt werden.

Details: Exchange msDS-ExternalDirectoryObjectID

Mit ist aber nicht verborgen geblieben, dass mittlerweile noch ein weiteres Feld nach On-Premises repliziert wird. Dazu ist Exchange 2016 On-Premises 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. Auch hierfür muss der ADSync-Prozess natürlich die Rechte bekommen, wenn das Sync-Konto kein Domain Admin ist.

dsacls dc=uclabor,dc=de /I:S /G "domain\serviceaccount:RPWP;msDS-ExternalDirectoryObjectID;User"

Password Writeback und PasswordSync

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-Premises umgesetzt werden.

#Password Sync
dsacls dc=uclabor,dc=de /G "msxfaq\svcadsync:CA;Replicating Directory Changes"
dsacls dc=uclabor,dc=de /G "msxfaq\svcadsync:CA;Replicating Directory Changes All"

#Password WriteBack
dsacls dc=uclabor,dc=de /I:S /G "msxfaq\svcadsync:CA;Reset Password;User"
dsacls dc=uclabor,dc=de /I:S /G "msxfaq\svcadsync:CA;Change Password;User"
dsacls dc=uclabor,dc=de /I:S /G "msxfaq\svcadsync:WP;pwdlastset;User"
dsacls dc=uclabor,dc=de /I:S /G "msxfaq\svcadsync:WP;lockouttime;User"

Weitere Informationen finden Sie auf entsprechenden Blog-Artikeln:

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