Einrichtung

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

Migration Migration von ADSync

Wenn Sie heute schon ADSync im Betrieb haben, dann müssen Sie vor der Konfiguration und Inbetriebnahme von AzureAD Cloud Provisioning 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 Provisioning" 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 Provisioning", 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 Provisioning 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:

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 kann und fordert Sie auch auf die lokalen AD-Domänen zu konfigurieren. Hierbei wird dann auch ein Dienstkonto angelegt, welches später provisioniert. Die Zusammenfassung ist aber übersichtlich

Die gesamte Installation landete bei mir in "C:\Program Files\Microsoft Azure AD Connect Provisioning Agent" und ist ca. 33 Megabyte groß. Installiert wurden neben dem eigentlichen Connector noch ein Updater und ein Telemetrie-Modul, die aber allesamt kleiner sind als der volle ADSync und die 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:

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:

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 Provisioning 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. Wobei die Optionen hier noch sehr übersichtlich sind:

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.

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 Provisioning noch nicht eingerichtet habe, konnte ich sogar die Exchange Properties verwalten. Ich wollte ja sehen, was durch die Einrichtung von AzureAD Cloud Provisioning 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 Provisioning 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 Provisioning wieder samt der Eigenschaften wieder "hergestellt" wird, hat in meinem Fall AzureAD Cloud Provisioning 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 Provisioning 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 OnPremises Felder die Cloud-Felder "überschreiben" oder zusammengeführt werden. Da es OnPremises 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 Provisioning 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

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

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