Generelles zu Identitäten

Die Nutzung von Office 365- oder Azure-Diensten basiert auf Identitäten und Benutzer können sich damit authentifizieren bzw. autorisieren. Der häufigste «Identity Provider» ist Microsoft Active Directory. So kann man sich an lokalen Ressourcen, wie z.B. File- oder Mail-Servern anmelden. Ähnlich verbreitet ist der Synchronisations-Mechanismus vom Active Directory (ADS) ins Azure Active Directory (AAD) mit Azure Active Directory Connect (AADC). Implementation und Nutzung von AADC erfordert keinen Doktortitel und selbst komplexere AD-Strukturen lassen sich mit AADC in einen Azure AD Tennant synchronisieren. Haupt-Voraussetzung dazu sind Netzwerk-Konnektivität:

• vom AADC-Server ins Internet via Port 443
• zwischen dem AADC-Server und den jeweiligen Active Directory Forest(s)

Wir leben in einer Welt, in welcher Firmenübernahmen an der Tagesordnung stehen. «Mergers & Acquisitions» beschreiben das bunte Treiben im Fachenglisch. Aus IT-Sicht generieren die Einkaufstouren der Unternehmen stets Integrations- oder Migrations-Projekte und auch hier stehen die Identitäten im Zentrum.

Azure AD Connect Cloud Provisioning

Mit der Einführung des Azure AD Connect Cloud Provisioning wird die Provisionierung von Identitäten aus losgelösten AD-Forests stark vereinfacht. Was heisst «losgelöster» AD-Forest? Ein Beispiel:

• Firma A übernimmt Firma B
• Beide Firmen betreiben je ein lokales Active Directory, welches weder über eine Netzwerkverbindung noch über einen AD-Trust verbunden ist (-> losgelöster AD-Forest 😊)
• Firma A nutzt Office 365-Dienste und möchte diese Dienste der Firma B zur Verfügung stellenAus der Microsoft «Fantasie-Firmen-Terminologie» frei übersetzt
  • Firma A (contoso.com) betreibt eine AD Connect Instanz, welche die Identitäten der lokalen AD ins Azure AD synchronisiert um z.B. Office 365 zu nutzen
  • Firma B (fabrikam.com) kann, ohne ihr Active Directory mit Firma B zu verbinden mit «Azure AD Connect Cloud Provisioning» ihre Identitäten in den Azure AD-Tenant von Firma A synchronisieren. So können die Office 365-Dienste aus demselben Tenant genutzt werden.

  Die Integration von «AD Connect Cloud Provisioning» ist denkbar einfach (MS-Guidelines):

  • Auf einem Domain-joined Server von Firma B wird der «Azure AD Connect Provisioning Agent» aus dem Azure AD-Portal von Firma A heruntergeladen, installiert und konfiguriert
  • Im Azure Active Directory-Portal von Firma A, wird der installierte Agent verifiziert und danach wird die Konfiguration von «AD Connect Cloud Provisioning» aus dem Azure AD-Portal abgeschlossen (dieser Schritt beinhaltet auch das Filtering auf bestimme AD-Objekte)
  • Nach erfolgter Konfiguration, werden die Konten im Azure AD-Tennant von Firma A erstellt. Die Benutzer von Firma B können basierend auf der Office 365-Lizenzierung die Dienste nutzen und selbstverständlich innerhalb der Dienste mit den Mitarbeitern von Firma A kollaborieren

  Fazit & Limitationen

  • Azure AD Connect Cloud Provisioning eignet sich hervorragend zur Integration eigenständiger AD Forests. Dies ohne eine AD-Verbindung oder eine AD-Migration oder eine AADC-Re-Konfiguration.
  • Bestehende Azure AD Connect-Konfigurationen können parallel genutzt werden und müssen in der Regel nicht angepasst werden
  • Folgendes wird (Stand 12/2019) durch «Azure AD Connect Cloud Provisioning» nicht unterstützt (vollständige Liste)
    • Account- /Resource-Forest-Topologien – konkret / unser obiges Beispiel: besteht zwischen Firma A & Firma B ein AD-Trust und Firma B nutzt z.B. MS Exchange aus Firma A, kann «Azure AD Connect Cloud Provisioning» nicht eingesetzt werden
    • Exchange Hybrid – konkret / unser obiges Beispiel: nutzt Firma B Mailboxen unter MS Exchange, welche mit migriert werden sollen, so ist dies in Kombination mit «Azure AD Connect Cloud Provisioning» vorläufig nicht realisierbar
    • Write-Back-Funktionen (wird im Q1 oder Q2 2020 ins Produkt einfliessen)
    • Passthrough Authentication