CloudSync Einrichtung

Diese Seite behandelt nicht nur die Installation von AzureAD Cloud Sync sondern auch meine Erfahrungen bei der Umstellung vom klassischen ADSync zu AzureAD Cloud Sync.

Migration von ADSync

Wenn Sie heute schon ADSync im Betrieb haben, dann müssen Sie vor der Konfiguration und Inbetriebnahme von AzureAD Cloud Sync die ADSync Konfiguration anpassen. Sie können und müssen sehr wohl beide Systeme nebeneinander installieren aber ein AD-Objekt darf dabei nur von einem der beiden Prozesse gesehen und synchronisiert werden. Das bedeutet z.B., dass Sie für Pilot und Testphasen bestimmt OUs in ADSync aus der Replikation ausnehmen, weil Sie diese dann durch "AzureAD Cloud Sync" abgleichen lassen.

Bei dieser Umstellung werden die User-Objekte beim Ausschließen aus ADSync natürlich im Office 365 Tenant erst einmal "Soft Deleted". Es liegt dann am "AzureAD Cloud Sync", diese Objekte wieder zurück zu holen. Daher gibt es einige Voraussetzungen:

  • ADSync Version 1.4.32.0 oder neuer
    Laut der Versionsliste https://docs.microsoft.com/de-de/azure/active-directory/hybrid/reference-connect-version-history#14320 wurde diese Version im November 2019 veröffentlicht und wird nicht automatisch installiert. Prüfen Sie daher manuell ihre aktuelle ADSync-Version und aktualisieren diese vorab
  • Source Anchor objectGuid or ms-ds-consistencyGUID
    Nur diese beiden Felder des lokalen Active Directory werden bei dem Matching durch AzureAD Cloud Sync unterstützt
  • Keine Koexistenz mit dem AzureADSync Server
    Die beiden Tools können nicht nebeneinander auf dem gleichen Server installiert werden. Allerdings überprüft dies das Setup nicht, d.h. sie müssen schon selbst darauf achten, dass es hier keinen Konflikt gibt.

Ich habe meine kleine Demo-Umgebung mit einem kleinen Domain Controller ohne Exchange Schema daher "unsanft" umgestellt.

Mit der Erfahrung aus dieser hier dokumentierten Umstellung würde ich produktiv diesen Weg nicht gehen sondern mich an die Microsoft Beschreibung halten.

  • Deinstallation ADSync
    Ich habe einfach das ADSync Setup auf dem ADSync Server gestartet und alles deinstalliert. In der Cloud wurde ADSync deswegen aber nicht abgeschaltet. Alle Konten sind also vorhanden geblieben

Hinweis: Es ist nicht mit der "Deinstallation" von ADSync getan. Berechtigungen auf dem lokalen AD, ADSync Role-Gruppen und das Dienstkonto werden so nicht zurück gebaut. Auch lokal bleiben Dateien z.B. in "C:\ProgramData\AADConnect" und anderen Stellen. Darauf gehe ich hier nicht weiter ein.

  • Abschalten des DirSync
    Dann habe ich zur Sicherheit in der Cloud die Funktion "DirSync" deaktiviert. Die Authentifizierung wird davon ja aber nicht gestört und die "ImmutableID" bleibt ja erhalten.
Connect-MSOLService
Set-MsolDirSyncEnabled -EnableDirSync $false
  • Warten
    Ich bin auch manchmal ungeduldig aber hier habe ich es nun doch vorgezogen zu warten, bis AzureAD diese Änderung erkannt und die Benutzer auf "Cloud Only" konvertiert hat. Eventuell muss man das nicht mal, wenn AAD Cloud Provisioning einfach die vorhandene Identität weiter benutzt. Ich wollte aber auch sehen, wie ein "Matching" funktioniert.

Wichtig: Dieser Prozess kann bis zu 72h dauern.
Quelle: https://support.microsoft.com/en-us/help/2654338/directory-synchronization-for-office-365-azure-or-intune-can-t-be-acti

  • AD Cloud Provisioning einrichten
    Und dann habe ich darauf vertraut, dass AD Cloud Provisioning die Verbindung zu den Konten wieder herstellt.

In der Zeit, in der ADSync nicht mehr aktiv ist aber AD Cloud Provisioning noch nicht funktioniert, werden natürlich Änderungen u.a. nicht übertragen.

AD Cloud Provisioning Download und Installation

Bei der klassischen Installation von ADSync laden Sie die Software über den Microsoft Download Service herunter und starten die Installation. Bei AD Cloud Provisioningor starten Sie diesmal im Azure-Portal:

https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/AzureADConnect

Die Schritte sind dann schnell erklärt. In dem nächsten Fenster gibt es eine Downloadmöglichkeit, über die Sie nach Zustimmung der Lizenzbedingungen dann die Installationsquelle (ca. 11 MB) erhalten. Diesen Agenten installieren Sie auf einem oder auch mehreren Servern. Ggfls. müssen das passende NET-Framework installieren. Im Apr 2020 war das noch Version 4.7.1).

 Die Installation frage auch ein Admin-Konto der Cloud ab, damit der Agent registriert werden und erlaubt die Konfiguration eines Dienstkontos, welches später provisioniert. Wenn ihre Windows Umgebung aktuell für "Group Managed Service Account" (gMSA) ist, dann würde ich immer diesen "managed Account" nutzen. Zur Einrichtung müssen Sie natürlich ein Adminkonto angeben. Das Setup nutzt nicht die Credentials des Benutzers, welcher das Setup gestartet hat.

Mittlerweilen kann der Agent auch mehrere Domains und Forests bedienen. Ich belasse es hier bei meiner "Small Business Testumgebung".

Die Zusammenfassung ist aber übersichtlich:

Mit einem Druck auf "Confirm" wird der Agent installiert, der Group Managed Service Account angelegt, der Agent registriert, die Zugangsdaten auf dem Computer installiert und danach der Agent gestartet.

Wenn Sie in ihrer AD-Umgebung die Nutzung von RC4 mit Kerberos abgeschaltet haben, kann die Anlage des gMSA-Kontos scheitern. Siehe dazu auch Kerberos RC4 Abschaltung

Das Abschlussbild enthält einen Link auf "https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/AzureADConnect", um die weitere Funktion zu konfigurieren.

Die gesamte Installation landete bei mir in "C:\Program Files\Microsoft Azure AD Connect Provisioning Agent" und ist ca. 65 Megabyte groß. Installiert wurden neben dem eigentlichen Connector noch ein Updater, ein Telemetrie-Modul und VC Runtime, die aber allesamt kleiner sind als der volle ADSync samt SQL-Instanz.

Den Assistenten zur Konfiguration der Domains finden Sie unter "C:\Program Files\Microsoft Azure AD Connect Provisioning Agent\AADConnectProvisioningAgentWizard.exe" und bei den Diensten in der Systemsteuerung finden Sie zwei Dienste. Hier sehen Sie auch, dass der Dienst mit einem Service Konto läuft:

Neben den Programmen in "C:\Program Files" gibt es auch in "C:\ProgramData" entsprechende Protokolle, die im Fehlerfall hilfreich sein können

Kontrolle im Azure Portal

Auf der Seite Monitoring gehe ich noch auf erweiterte Möglichkeiten ein. Sie sollten aber nach der Installation dennoch im Azure Portal einmal schauen, dass der Agent sich dort auch korrekt eingetragen hat und aktiv ist. Sie gehen dazu unter https://portal.azure.com erst auf ihre Azure AD Directory und dann links auf AzureAD Connect. Die Seite war im Sep 2021 noch stark "ADSync-lastig". Der Link zu "Azure AD Cloud Sync" fällt nicht sofort auf:

Damit ist die eigentliche Installation schon abgeschlossen. Die hier sichtbare IP-Adresse gehört zu einem einfachen Privatkunden DSL-Anschluss und ist dynamisch. Das ist für den AzureAD Cloud Sync Agent aber kein Problem, da er ja von sich aus die Verbindung zur Cloud aufbaut. Sie können aus Überlegungen zur Ausfallsicherheit natürlich noch weitere Agenten installieren

Konfiguration

Allein der installierte Agent auf einem oder mehreren Servern in ihrer lokalen Umgebung macht noch nichts. Sie müssen AzureAD entsprechend parametrisieren, damit der Agent genutzt wird. Es gibt aber keine lokale GU, um mehr einzustellen, als bei der Installation des Agenten schon durchgeführt wurde. Die komplette Konfiguration des Verzeichnisabgleichs erfolgt über das Azure AD Portal. Zuerst müssen wir eine Konfiguration erstellen:

Der nächste Dialog erlaubt nur die Auswahl der Domain und ob Password HashSync aktiv sein soll.

Erst nachdem ich eine Konfiguration angelegt habe, konnte ich auch den Agenten sehen.

Die soeben angelegte Konfiguration kann nur in wenigen Punkten angepasst werden.

Scope

Eventuell möchten Sie den Abgleich auf einige OUs oder Mitglieder eine Sicherheitsgruppe (nicht rekursiv) beschränken.

Attribute

Benutzer müssen sich natürlich auch an der Cloud anmelden. Wenn sie kein ADFS oder Pass Through Authentifizierung (PTA) nutzen, dann ist Password Hash Sync (PHS) sehr einfach zu konfigurieren. Einfach hier eine Checkbox setzen, damit Kennworte in der Cloud und lokal gleich sind.

Zusätzlich können sie die übertragenen Attribute konfigurieren. Wer nachschaut, sieht aber auch Felder die MSExchMailboxGUID u.a., selbst wenn diese im lokalen Schema gar nicht vorhanden sind.

Hier gilt: Änderungen gut dokumentiere, wenn einige Felder sind für die Funktion essentiell.

Validate

Bei Schritt 3 können Sie einen "Distinguishedname" eines lokalen AD-Kontos angeben, welches dann einmalig repliziert wird. Weiter unten Sehen Sie die Ausgabe einer solchen "einmaligen Synchronisation"

Settings

Ich würde auf jeden Fall eine "Notification email" hinterlegen, an die Cloud Sync auftretende Fehler melden kann. Es ist immer besser solche Probleme früh zu erfahren.

Auch den Schwellwert für "unbeabsichtigte Löschungen" sollten Sie an ihre lokalen Anforderungen anpassen. Kleinere Firmen könnte hier durchaus den Schwellwert niedriger setzen. Wenn Sie also nie erwarten, dass auf einen Schwung z.B. mehr als 10 Benutzer gelöscht werden, dann wäre das ein besserer Weg. Selbst eine größere mittelständische Firma wird vermutlich nicht über 50 Benutzer oder Gruppen auf einen Schlag entfernen.

Tipp: Verwenden Sie keine "Persönliche" Adresse eines Administrators sondern eine Funktionsadresse, z.B. Shared-Mailbox, notfalls ein Verteiler aber am besten ihr Ticketsystem.

Deploy

Standardmäßig ist ein neuer Job "aktiviert".

Wichtig: Sie müssen auch den letzten Schieber bei "Deploy" auf "Enable" stellen, damit die Synchronisation dieser Domain gestartet wird.

Sie legen pro Active Directory Forest eine Konfiguration an, in der Sie den Bereich filtern können und den Kennwortabgleich per PasswordHashSync aktivieren. ADFS oder PassThrough-Authentifizierung findet hier erst mal nicht mehr statt. Die einzelnen Schritte hat Microsoft hier ganz gut beschrieben.

Validierung

Sie können mit Cloud Sync auch bei der Einrichtung unter "3 Validate" ein einzelnes Objekt anhand des lokalen DistinguishedName angeben, welches dann vorab durch Azure AD Cloud Sync synchronisiert wird. Sie können auch mehrere Objekte nacheinander so prüfen, um die grundlegende Funktion zu verifizieren. Das ist insbesondere dann wichtig, wenn Sie z.B. von ADSync zu Cloud Sync wechseln und ein "Rematching" der Objekte erfolgen soll. Hier eine Beispielausgabe:

Es doch schon sehr beruhigend, dass hier der Wechsel geklappt hat.

Rematching

Durch die komplette Deaktivierung von ADSync wurden bei mir alle Objekte im Azure AD, d.h. die Benutzer, Gruppen von "DirSync" auf "Cloud" umgestellt. Alle Exchange Properties sind aber erhalten geblieben. Solange ich AzureAD Cloud Sync noch nicht eingerichtet habe, konnte ich sogar die Exchange Properties verwalten. Ich wollte ja sehen, was durch die Einrichtung von AzureAD Cloud Sync passiert.

  • Matching und Konvert
    Meine bestehenden "Cloud Only"-Konten wurde nicht gelöscht und es wurden auch keine zusätzlichen Konten angelegt. Die bestehenden "CloudOnly"-Konten wurden einfach wieder in "DirSync"-Benutzer konvertiert. Zuerst konnte ich das unter https://portal.azure.com/#blade/Microsoft_AAD_IAM/UsersManagementMenuBlade/AllUsers sehen und einige Zeit danach dann auch im Office 365 Portal https://admin.microsoft.com/Adminportal/Home?source=applauncher#/users. Geduld ist auch hier gefragt.
  • Exchange ProxyAddresses
    Nachdem die Objekte in der Cloud "frei" waren, aber ich die ProxyAddresses in Exchange Online geändert und im lokalen Active Directory einen Eintrag entfernt. Nach dem Abgleich durch AzureAD Cloud Sync waren alle Änderungen in Exchange Online auf die Werte des lokalen Active Directory zurück gesetzt. Aus meiner Sicht überschreibt ADSync Cloud Provisioning die Einstellungen in der Cloud anhand der lokalen Einstellungen

Während bei der Umstellung nach Microsoft-Vorgaben ein durch ADSync gelöschter Benutzer durch AzureAD Cloud Sync wieder samt der Eigenschaften wieder "hergestellt" wird, hat in meinem Fall AzureAD Cloud Sync die bereits vorhandenen Benutzer per Matching wieder zusammengeführt und anhand der Informationen im Active Directory aktualisiert.

Eine genaue Information, anhand welcher Kriterien AzureAD Cloud Sync die Objekte zuordnet, habe ich noch nicht dokumentiert gefunden. Ich tippe aber wie bei ADSync auf den vorhandenen SourceAnchor und ggfls. Mailadresse oder UPN.

Matching

Ich wollte natürlich etwas mehr über das "Matching" in Erfahrung bringen und habe geplant, zwei Benutzer mit abweichender UPN und Mailadresse anzulegen und so zu sehen, welche Objekte dann zugeordnet wird. Leider ist das zumindest in meinem Tenant nicht möglich gewesen, denn ich habe erst einmal einen User4 mit folgenden drei abweichenden Werten eingetragen:

  • UPN = "user4@msxfaq.net"
  • Primary Mail = user5@msxfaq.net
  • Alias = user6@msxfaq.net

Im Office 365 Portal war das dann auch noch gut sichtbar.

Aber nach einem Reload hat sich das Bild geändert

 

Ein Blick in die Exchange SMTP-ProxyAdresses in Exchange Online zeigte aber, dass alle drei Werte als SMTP-Adresse addiert wurden.

Jeder versuch nun noch einen weiteren Benutzer anzulegen, der auch nur einen von "user4@msxfaq.net" abweichen UPN mit user5 oder user6 hat, wurde umgehend vereitelt, da die Adresse schon belegt ist. Es ist in Office 365 also gar nicht möglich, hier absichtlich falsche Kreuzbezüge anzulegen. Ich habe es dann bei einem Benutzer im Tenant belassen aber im lokalen Active Directory drei Benutzer anlege

  Displayname LastName Firstname UPN Mail

1

User4a

<leer>

User4a

user4@msxfaq.net

user5@msxfaq.net

2

User4b

<leer>

User4b

user5@msxfaq.net

user4@msxfaq.net

Der Lastname ist beim Cloud-Objekt mit "User4" gefüllt während der Firstname leer ist. So kann ich beim Match auch sehen, ob die On-Premises Felder die Cloud-Felder "überschreiben" oder zusammengeführt werden. Da es On-Premises in diesem Forest keine Exchange Schema Erweiterung gibt, sind die Exchange Felder leer und ich bin gespannt, was der "ADSync Cloud Provisioningor" daraus macht.

Das Ergebnis war, dass der Benutzer 1 auf das Cloud-Objekte gebunden wurde.

Im Vergleich zu vorher sind aber einige Änderungen zu sehen, die durch dieses "Matching" mit erfolgt sind.

Feld Alt Neu Bemerkung

Username

user4@msxfaq.net

user4@msxfaq.net

Der UPN ist wie erwartet unverändert geblieben

ProxyAddresses

user4@msxfaq.net
user5@msxfaq.net
user6@msxfaq.net

user4@msxfaq.net
user5@msxfaq.net

Die ProxyAddresses wurden anscheinend neu anhand des lokalen UPN und der lokalen Mailadresse gebildet. Das lokale AD-Objekt hat gar keine ProxyAddresse und nur die Mailadresse user5@msxfaq.net. Hier muss ein Admin zukünftig aufpassen, dass der UPN nicht als Mailadresse eines anderen Benutzers genutzt wird.

Das ist ein weiteres deutliches Zeichen für UPN = MAIL

Firstname

<leer>

User4a

Der Vorname wurde durch den Wert des lokalen AD überschrieben.

Lastname

User4

User4

Im lokalen AD ist der LastName "leer". CloudConnect löscht also die Felder in der Cloud nicht, wenn sie lokal "null" sind.

Das können Sie auch wieder in den Bereitstellungsprotokollen sehen. Der User mit dem UPN "user5@msxfaq.net" wird im AzureAD Cloud Sync mit einem Fehler geblockt, dass Attribute einen Konflikt haben. 

Ich bin hin und her gerissen, wie ADSync Cloud Provisioning arbeitet. Wenn Felder im lokalen AD gepflegt sind, dann werden sie auf das Cloud-Konto übertragen. Leere Felder im lokalen AD führen aber nicht dazu, dass die Felder dann in der Cloud geleert werden.
Das Verhalten der ProxyAddress muss bekannt sein: AD Cloud Provisioning addiert auch den UPN in der Cloud als valide Mailadresse
Eine Rückreplikation findet im April 2020 gar nicht statt. ProxyAddresses im lokalen AD bleiben leer, auch wenn diese in der Cloud gesetzt wurden. Viel schlimmer finde ich noch, dass der Source Anchor

Nacharbeit SSO

Anders als der klassische ADSync können Sie mit CloudSync nicht per GUI die Seamless Single Sign On aktivieren. Sie müssen dazu auch im März 2023 immer noch die Installationsquellen des AzureAD Connect herunterladen und auspacken um dann per PowerShell die Funktion Seamless Single Sign On zu aktivieren.

Nacharbeit Password WritePack

Auch die Funktion "Password WriteBack" ist per Default nicht aktiv und muss per PowerShell konfiguriert werden, wenn dies in ihrer Umgebung erwünscht ist.

Berechtigungen

Noch nicht ganz verstanden habe ich, mit welchen Berechtigungen der Agent auf dem lokalen Computer den Zugriff auf das Active Directory betreibt. Die Dienste laufen als Managed Service Account. Ich habe aber nicht gesehen, dass dieses Konto irgendwo im Active Directory entsprechende Berechtigungen zum Lesen aller Objekte bekommen hat. Zudem muss der Dienst ja auch für PasswordHashSync einige erweiterte Berechtigungen bekommen und auch bei den synchronisierten Attributen muss er zumindest den SourceAnchor, ImmutableId schreiben können.

Hier sind noch weitere Analysen erforderlich.

Weitere Links