AzureAD ohne ADSync

Ohne die genauen Zahlen zu kennen, dürften die meisten Microsoft 365-Kunden auch ein lokales Active Directory betreiben und synchronisieren die Identitäten mit ADSync / AADConnect oder AzureAD Cloud Sync. Das ist schnell installiert, bequem, einfach und mit Password Hash Sync (PHS) und Seamless Single Sign On ist die Nutzung sehr einfach. Aber es kann durchaus Umgebungen und Gründe geben, den Tenant ohne ADSync zu betreiben. Für Firmen mit Exchange On-Premises und Exchange Online stellt sich die Frage schon gar nicht erst, wenn Exchange Hybrid benötigt zwingend einen ADSync oder zumindest etwas "Gleichwertiges". Das ist das Thema dieser Seite.

Ich entschuldige mich schon mal vorab für die lange und textlastige Seite. Ich wollte Sie aber nicht auf mehrere Seiten verteilen und soll sie nicht abschrecken.

Warum kein ADSync?

Wenn ADSync denn so einfach ist, dann werden Sie sich die Frage stellen, warum jemand einen Tenant ohne aktivierten DirSync betreiben möchte. Dann denken Sie einmal über folgende Umgebungen nach.

  • Active Directory nur eingeschränkt oder nicht vorhanden
    Es gibt durchaus Firmen und Institutionen, bei denen es kein Active Directory gibt oder diese nicht das führende System ist. Das sind beileibe nicht alles "Windows-Hasser" und "Samba-Freunde" und lässt sic auch nicht mit "historisch gewachsen" beschreiben. Vielleicht gibt es auch ein Active Directory in dem aber vielleicht nicht alle Identitäten vorhanden sind. Hier würde ADSync maximal eine Teilmenge der Identitäten erhalten.
    Es gibt natürlich auch die Firmen, die lokal mit einer SAMBA/OpenLDAP/Shibboleth oder vielleicht noch Novell-NDS ihren Verzeichnisdienst betreiben. Das könne ja sogar "ganz kleine" Firmen sein, die lokal nur eine kleine NAS-Box (Synology, QNAP, OpenFiler, o.ä.) nutzen und ihre Webseite und Postfächer bei einem POP3/IMAP4-Provider hosten. Da geht dann kein ADSync (Siehe auch ADSync mit Samba)
  • 3rd Party IDM
    Auf der Seite Provisioning habe ich beschrieben, dass mit der Anzahl der "Changes/Zeit" oder höheren Anforderungen an Qualität, Nachvollziehbarkeit und Automatisierung deine Verwaltung mit "Active Directory Users&Computers" nicht mehr zielführend ist. Es muss ja nicht gleich ein umfassendes Identity Management System sein, welches ich die Mitarbeiterdaten aus dem HR-System holt und über ein Metaverzeichnis dann die verschiedenen Ziele (AD, TK-Anlage, Türsteuerung, Kantinenkarte, SQL-Datenbanken PC-Berechtigungen, Exchange Postfach etc.) synchronisiert. Manchmal reicht eine halbautomatische Lösung, bei der sie häufige "Änderungen" per Skript umsetzen. Dann können Sie auch AzureAD/Microsoft 365 einfach als weiteres Zielsystem betrachten.
  • Exchange Online Only
    Wer heute Exchange Online in Verbindung mit einem lokalen Active Directory und ADSync nutzt, muss zwingend auch lokal das AD-Schema um Exchange erweitern und die Empfänger mittels Exchange PowerShell und einem Hybrid Connector Server lokal verwalten. Seit vielen Jahren verspricht Microsoft hier eine Lösung aber aktuell blockiert ein aktiviert "DirSyncEnabled:$true" im Tenant die Verwaltung der Exchange Online Empfänger in der Cloud. Siehe dazu auch Exchange Online Provisioning. Ohne ADSync sind sie hier frei.
  • Security/Test/Extern
    Dann gibt es natürlich auch Anforderungen bestimmter Firmen die nur eine "lockere" Kopplung erlauben. Das ADSync-Dienstkonto hat ja durchaus umfangreiche Berechtigungen auf ihren lokalen Forest, was in einigen Umgebung einfach nicht geht. Über einen eigenen Abgleich oder Prozess haben sie natürlich mehr Kontrolle.

In den meisten Fällen dürfte es sich aber um Umgebungen handeln, wo es kein Active Directory gibt oder ein andere System "führend" ist. Hier können Sie durchaus auch Schulen und Universitäten zählen, die zu jedem Schuljahreswechsel oder Semester eine sehr hohe Fluktuation von Benutzerkonten haben. Hier kommen fast immer eigene Schüler-Verwaltungsprogramme zum Einsatz. Auch für diesen Einsatzbereich hat Microsoft extra mit School Data Sync (SDS) eine Lösung geschaffen.

Es geht als ohne ADSync aber es sind eher wenige Firmen und entsprechend ist die Anzahl der Dienstleister, die sich mit solchen Betriebsarten, Umgebungen und den Besonderheiten auskennen, geringer.

Daher finden Sie unabhängige Beschreibungen zu solchen Herausforderungen deutlich seltener im Internet. Aber vielleicht ist dieser Artikel ja der Trigger sich bei Net at Work mit ihrem Problem zu melden.

Die Beschäftigung mit dem Provisioning von Objekten im AzureAD/Microsoft 365 ohne ADSync ist aber auch in Umgebungen mit mehreren Tenants und mit ADSync relevant. Es gibt ja Firmen, die ihre eigenen Anwender per ADSync verwalten lassen aber zusätzlich noch externe Personen, Gäste oder Kontakte in Exchange Online benötigen, für die es keine Gegenstücke im lokalen Active Directory gibt.

Provisioning

Sie können natürlich ein AzureAD/Microsoft 365 Tenant komplett ohne eine Kopplung an das lokale AD betreiben. Aber wenn Sie nicht eine Kleinfirma sind, die von Hand die Identitäten in der Cloud verwaltet, dann werden Sie das ein oder andere Betriebsmodell umsetzen. Hier ein paar Beispiele:

Modell Beschreibung

Klassische AD und ADSync

Zum Vergleich erst noch einmal die klassische Variante, bei der die Identitäten wie auch immer in einem lokalen AD verwaltet und durch ADSync übertragen werden. Für die Authentifizierung habe ich PHS vorgesehen. PTA oder Federation ist natürlich auch möglich.

Externes Provisioning mit ADFS

Wenn ich keinen ADSync habe und etwas größer bin, dann mus sich anderweitig die Identitten in der Cloud verwalten. Das kann ein Provisioning-System machen und die Authentifizierung übernimmt ein lokaler SAML-Token Server. Wer ein lokale AD hat, kann das mit ADFS machen aber es gibt auch andere Produkte, die ich weiter unten aufführe

Externes Provisioning mit Password Schreiben

Dieses Modell ist mit dem vorherigen dahingehend vergleichbar, dass die Identitäten durch ein Provisioning im AzureAD verwaltet werden aber der Anwender auch über das Provisioning sein Kennwort ändert und entsprechend das Provisioning das Kennwort in der Cloud setzt. Ich möchte ja schon das gleiche Kennwort in allen Diensten haben. Nur wenn es lokal keine Dienste gibt, dann kann ich den Anwender das Kennwort auch in der Cloud selbst ändern lassen.

Es steht nirgendwo geschrieben, dass das Provisioning ein lokales On-Premises-System sein muss. Auch Personalverwaltung gibt es schon aus der Cloud, z.B. SAP Success Factors oder Workday.

Also sollten wir uns nun die Details zu den Optionen und APIs anschauen.

Authentication

Mit einer Identity alleine ist es nicht getan. Der Anwender muss sich natürlich authentifizieren und wenn ein Password Hash Sync (PHS) mittels ADSync nicht möglich ist, dann müssen andere Optionen genutzt werden. Auch hier gibt es verschiedene Ansätze.

  • Federation mit ADFS
    Sie müssen nicht ADSync installieren, um eine Federated Authentication mit einem lokalen Active Directory Federation Service zu nutzen. Allerdings muss der Anwender natürlich ein Konto im AD haben und sie müssen ADFS aufbauen. Gerade ADFS ist nicht ganz einfach und seit PHS/PTA auch aus Sicht von Microsoft nicht mehr das bevorzugte Anmeldeverfahren. Siehe auch ADFS zu PHS/SSO
  • Federation mit Shibboleth
    AzureAD/Microsoft 365 erlaubt auch andere SAML 2.0-Provider als Aussteller der Tokens. Sie können also 3rd Party-Produkte wie z.B. Shibboleth selbst hosten und ihre Domains als "federated" konfigurieren. So können Sie bei einem passenden lokalen Setup auch Single Sign-on für die Cloud umsetzen.
  • Password setzen
    Ein sehr einfacher und auch robuster Weg dürfte aber das Setzen des Kennworts durch das IDM sein. Das bedeutet für den Anwender aber, dass er sein Kennwort über eine eigene Plattform ändert und durch das IDM in alle verbundenen Systeme geschrieben wird. Das IDM hat temporär dann das Kennwort im Klartext.

Allerdings gibt es meines Wissens keine andere Option, eine Anmeldung an der Cloud z.B. über einen WebService oder LDAP-Proxy gegen eine lokale Anmeldeinstanz durchzuführen. Wer nicht die Kennworte in der Cloud setzt, muss mit Federation in der ein oder anderen Version arbeiten.

Denken Sie aber auch daran, dass die Anwender auch in der Cloud direkt über ihr Portal das Kennwort ändern können. Sie können es dem Anwender natürlich erschweren, indem Sie z.B. in OWA das Menü abschalten:

Aber verhindert haben Sie es damit nicht und damit kann das Kennwort eines lokalen Anmeldediensts und der Cloud unterschiedlich sein. Ein "Password Writeback" gibt es ohne ADSync meines Wissens nicht und das vom Anwender in der Cloud geänderte Kennwort wird hoffentlich nicht irgendwo reversibel verschlüsselt erreichbar sein, so dass Sie einen Writeback selbst schreiben könnten. Daher müssen Sie ihre Anwender auf jeden Fall informieren, wie sie ihre Kennworte zu ändern haben. Idealerweise über ein Portal, welches dann da Kennwort auf allen Systemen entsprechend neu setzt. Diese Probleme sprechen dann wieder für "Federation", damit das Cloud-Kennwort gar nicht erst zum Tragen kommt.

Wenn ein Anwender in einem System sein Konto z.B. aufgrund zu vieler Fehlversuche sperrt oder ein Administrator den Zugang sperrt, dann muss das Provisioning ebenfalls dafür sorgen, dass das Cloud-Konto ebenfalls gesperrt oder deaktiviert wird. Auch hier ist Federation dann die sicherere Wahl. Ganz generell sollten Sie immer darauf achten, dass es eine zentrale autoritative Authentifizierungsinstanz gibt, egal ob das nun ein Windows ADFS-Service oder ein anderer SAML-Service ist.

Allerdings listet Microsoft auch einige Einschränkungen beim Einsatz eines 3rd Party SAML 2.0 Providers:


Quelle: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-saml-idp

Aus all diesen Gründen und Einschränkungen würde ich statt SAML mit einem 3rd Party Server eher prüfen, ob ihre Anwender nicht besser ihr Kennwort über einen Password-Service ihres IDM ändern und das IDM das Kennwort in die verschiedenen Systeme überträgt.

Azure AD Identity Provider Compatibility Docs
https://www.microsoft.com/en-us/download/details.aspx?id=56843
3rd Party Identity Providers Compatibility with AAD as of May 2018.pdf (240kB) Download
Azure Active Directory federation compatibility list Program Description July 2015.pdf (617 KB) Download
STS Integration Interoperability Scenario Requirements Mar 2018.docx (36 KB) Download
STS Integration Paper using WS Protocols Feb 2017.docx (210 KB) Download

Aus dem Dokument "3rd Party Identity Providers Compatibility with AAD as of May 2018.pdf" bekommen Sie eine gute Liste von Produkten, die Microsoft früher einmal zertifiziert hat.

In the past Microsoft had certified non-Microsoft identity providers by validating federation functionality and single sign-on experiences with these providers. This certification program is no longer available for new providers. Microsoft encourages all identity providers to self-certify themselves by validating compatibility with Azure Active Directory.
Quelle 3rd Party Identity Providers Compatibility with AAD as of May 2018.pdf (240kB) Download

Diese Dokument führt für jeden Service auch die damaligen Einschränkungen auf.

Die Produkte mit Links auf deren Seiten sind neben dem obligatorischen Azure Active Directory:

Leider habe ich den Open Source Shibboleth-Code hier nicht in der Liste gefunden. Das bedeutet aber nicht, dass es nicht doch gehen würde.

Achtung:
Viele Hinweise zur Integration von SAML-Diensten beschreiben den umgekehrten Weg, d.h. wie Benutzer sich an deren Apps anmelden können, indem Sie den AzureAD-SAML-Service nutzen, d.h. Single Sign-On.

Varianten

Selbst beim Einsatz von ADSync gibt es nicht die eine Konstellation sondern unterschiedliche ADSync - Topologien. Die einfache Konfiguration besteht aus einem AD-Forest, einem Tenant und einem ADSync, der alle Objekte repliziert und die Kennworte per Password Hash Sync (PHS) überträgt und die Anmeldung mittels Seamless Single Sign On für den Anwender transparent macht. Varianten haben dann mehrere Forests, mehrere Tenants und unterschiedliche Anmeldeverfahren.

Genauso gibt es beim Betrieb ohne ADSync unzählige Varianten, von denen ich hier nur eine Teilmenge exemplarisch eingehend kann. Ich habe drei Varianten anhand einiger Kriterien nebeneinander gestellt. IDM steht dabei für ihre Provisioning Lösung oder Skripte. Es muss kein "großes IDM" sein.

  • Variante1: IDM Only
    Dies erscheint mir die einfachste Variante, bei der es weder ADSync noch Federation gibt. Das IDM/Provisioning muss die Objekte in der Cloud komplett verwalten und auch die Kennworte setzen.
  • Variante2: IDM + Federation
    Um die Verwaltung der Kennworte aus der Cloud wegzunehmen, können Sie mittels "Federation" die Ausstellung von SAML-Tokens an einen eigenen Federation Server delegieren. Das muss nicht einmal ein Windows ADFS-Server sein.
  • Variante3: Hybrid
    Dies dürfte eine kniffligere Option sein, denn es gibt schon Firmen, die beide Systeme parallel nutzen, d.h. ADSync ist mit im Bild. Das passt zwar nicht genau zum Titel der Seite aber werde ich weiter untern noch etwas erläutern.
Kriterium 1 2 3

Anlegen von Benutzern und Gruppen

IDM

IDM

ADSync

Lizenzen zuweisen

IDM
Groups
IDM
Groups
IDM
Groups

Konfiguration, z.B. z.B. Teams-Policies, Rufnummern

IDM

IDM

IDM

Exchange Online Recipient Management

IDM gegen EXO

IDM gegen EXO

IDM gegen OnPrem

Exchange Hybrid

Manuell/IDM

Manuell/IDM

Supported

Exchange Schema im lokalen AD

Nicht erforderlich

Nicht erforderlich

Erforderlich

Kennwort/Federation

IDM

3rdParty/ADFS

PHS/PTA möglich

PasswordChange

IDM

IDM

Lokales AD

Provisioning APIs

Ohne ADSync muss ihre eigene "Identity-Lösung" natürlich irgendwie die Objekte in der Cloud verwalten. Sie muss Benutzer anlegen, ändern, löschen und das Kennwort setzen. Auch die verschiedenen Gruppen sind zu verwalten und es gibt durchaus besondere Objekte, wie z.B. Kontakte, die (noch) nicht durch alle APIs erreichbar sind. Ergänzend wollten Sie vielleicht noch weitere Einstellungen verwalten, z.B. ActiveSync Geräte, POP3-Berechtigungen, Teams Policies, die aber heute auch nicht durch ADSync verwaltet werden. Folgende APIs kenne ich bislang:

  • DirSyncAPI
    Diesen REST-Services nutzt ADSync. Meines Wissens ist diese API aber nicht "öffentlich" und steht damit 3rd Party Lösungen nicht zur Verfügung. Diese API ist aber auch nur nutzbar, wenn Sie den Tenant in "Dirsyncenabled:$true" setzen, wodurch sie viele Freiheiten verlieren, z.B. das direkte Management von Exchange Empfängern. Dann können sich auch gleiche wieder ADSync einsetzen
  • Microsoft Graph
    Dies ist Schnittstelle, die Microsoft propagiert, immer weiter entwickelt und immer mein erster Anlaufpunkt ist. Allerdings gibt es noch Einschränkungen, wie ich z.B. auf CSV2EXO beschrieben habe. Die Verwaltung von OrgwideContacts ist z.B. nicht möglich.
    Graph PowerShell
  • AzureAD PowerShell
    Sie können natürlich klassische PowerShell-Befehle absetzen, um Identitäten zu verwalten Aber auch hierbei gibt es Einschränkungen, die mit Graph ähnlich sind
  • Exchange Online PowerShell
    Exchange ist schon On-Premises ein Zwitter, der mehr macht, als nur Exchange verwalten. Ein "New-Mailbox" legt z.B. auch ein AD-Konto an und ein New-Mailcontact sowohl On-Premises als auch im AzureAD ein Kontaktobjekt. Aber für einige Aktionen muss es die Exchange PowerShell sein.
  • Microsoft Admin API
    Das Adminportal unter https://admin.microsoft.com nutzt eine eigene nicht veröffentlichte REST-API unter https://admin.microsoft.com/admin/api/, die aber meines Wissen auch nicht "öffentlich" ist. Das Portal unter https://portal.azure.com hingegen nutzt z.B. Microsoft Graph für die Verwaltung von Anwendern.
  • Weitere
    Genau genommen müsste ich hier noch APIs wie die Teams PowerShell u.a. aufführen, die für die Verwaltung von Applikationen erforderlich sein, weil Microsoft Graph noch nicht alles abdeckt. Wir haben hier ein sehr volatiles Umfeld

Achten Sie aber auf das Supportende einiger APIs:

... our goal is to also provide guidance and tools for migrating existing scripts and PowerShell processes, reliant on the Azure AD Graph API and MSOnline module, to the Microsoft Graph PowerShell SDK.
This is due to the planned deprecation of the two PowerShell modules (MSOL & AAD) after December 2022.
Quelle: Azure AD: Change Management Simplified
https://techcommunity.microsoft.com/t5/azure-active-directory-identity/azure-ad-change-management-simplified/ba-p/2967456

Also schauen wir uns die verschiedenen APIs für die Verwaltung von Identitäten einmal an.

Vorgang Graph AzureAD PowerShell Exchange Online PowerShell

Benutzer anlegen

Ja

Ja

Nein
New-Mailbox forder UPN an, den es aber Parameter aber nicht gibt.

Benutzer auflisten

Ja

Ja

Get-Mailbox

Benutzer ändern

Ja

Ja

Set-Mailbox

Benutzer löschen

Ja

Ja

Nein

Gäste anlegen

Ja

Ja

Nein

Gäste auflisten

Ja

Ja

Nein

Gäste ändern

ja

Ja

Nein

Gäste löschen

Ja

Ja

Nein

Gruppen anlegen

M365
Security

Ja

New-DistributionGroup

Gruppen auflisten

Ja

Ja

Get-DistributionGroup

Gruppen ändern

Ja

Ja

Set-DistributionGroup
Add-DistributionGroupMember
Remove-DistributionGroupMember

Gruppen löschen

Ja

Ja

Remove-DistributionGroup

Kontakte anlegen

Nein

Nein

New-Mailcontact

Kontakte auflisten

Ja

Ja

Get-Mailcontact

Kontakte ändern

Nein

Nein

Set-Mailcontact

Kontakte löschen

Nein

Ja

Remove-Mailcontact

Device anlegen

Beta

Nein

Nein

Device auflisten

Beta

Nein

Nein

Device ändern

Beta

Nein

Nein

Device löschen

Beta

Nein

Nein

Weitere....

TBD

TBD

TBD

Ich versuche die Liste aktuell zu halten aber bin für Hinweise dankbar, wenn Microsoft den Umfang der APIs verändert hat.

IDM Hybrid mit ADSync

Wenn Sie bei den verschiedenen IDM-Lösungen stöbern, dann finden Sie auch immer wieder Bilder, in denen dennoch ADSync vorkommt.

Die beiden folgenden Beispiele stammen von Microsoft und die Bilder sind bis auf den Produktnamen identisch.

IIch bin sicher, dass es noch weitere Lösungen gibt, die nicht alle Felder im AzureAD/Exchange Online durch das IDM provisionieren, sondern auch weiterhin ein lokales AD verwalten und ADSync in den Prozess einbeziehen.

Wenn alles gut läuft, dann bekriegen sich die System nicht einmal, da die Inhalte gleich sein. Allerdings können Sie sich viel Arbeit im IDM sparen, wenn Sie Exchange Hybrid einsetzen müssen. Hier stört ADSync nicht, sondern ist quasi die beste Sync-Engine während der Koexistenz. Da es hier dann eh einen lokalen Exchange Server gibt, ist ADSync auch kein Nachteil

3rd Party IDM Produkte

Wenn Sie ein AzureAD/Office365/Microsoft365 Umgebung ohne Ankopplung an ein lokale Active Directory betreiben wollen, dann sind sie entweder eine sehr kleine Firma mit manueller Pflege oder Sie werden die Verwaltung mit einer Software durchführen. Das kann ein PowerShell-Skript sein aber sehr schnell werden Sie vielleicht ein kommerzielles Tool zum Provisioning oder sogar ein Identity Management System nutzen. In der Vergangenheit habe ich aber mit folgenden Programmen mehr oder minder Kontakt gehabt.

  • Schild.NRW
    Eine Schulverwaltungssoftware, welche Lehrer und Schüler verwaltet und ausgehend davon Listen für eine Verwaltung von AzureAD-Identitäten und vor allem Teams in Microsoft Teams möglich macht
  • Generischer LDAP-Service/SAMBA
    Dann gibt es mindestens eine Firma, die kein AD hat sondern OpenLDAP nutzt und dort alle Identitäten verwaltet. Auch diese Daten kann ich per LDAP auslesen und per AzureAD-PowerShell und Exchange Online PowerShell die Identitäten in der Cloud verwalten. Einige Informationen dazu finden Sie auch auf ADSync mit Samba..
  • NetIQ/Microfoxus eDirectory (vormals Novell NDS)
    Früher war die DNS der Verzeichnis-Service für Novell Dateiserver und darauf aufsetzende Lösungen (ZenDESK, GroupWise etc.). NetWare ist eigentlich Geschichte aber die NDS lebt auf Linux und Windows weiter und kann auch Microsoft 365 provisionieren.
  • Softerra Adaxes
    Zwischen Handarbeit und IDM finden sich einige Tools zum Provisioning wie z.B. Adaxes, welches zwischen Anwender oder Quelle und dem Backend positioniert ist. Anwender oder Administratoren können Aktionen ausführen, die vom Service dann in den verschiedenen Backends angelegt werden können.

 Eine richtige "Marktübersicht" möchte und kann ich nicht geben, denn es gibt eine Unmenge solcher Produkte und Tools. Schon die Liste der SAML-Services kann ein Ansatzpunkt für entsprechende Produkte sein und es gibt sicher weitere, die gar keinen Federation Service anbieten.

3rd Party und ADSync

Solange sie per Provisioning nur AzureAD verwalten oder nur das lokalen AD oder bei einer Doppelverwaltung nur ein einer Umgebung mit Exchange arbeiten, dann brauchen Sie ja keinen Exchange Hybrid Mode. Wenn Sie aber in mehreren Umgebungen Exchange betreiben, dann sollten die alles beachten, damit die Adressbücher (GAL) synchron sind, Gruppenmitgliedschaften von Verteilern passen und die Routingadresse (TargetAddress) korrekt verwaltet wird.

Vergessen Sie dabei auch nicht, dass jedes On-Premises Postfach auch in der Cloud das Feld "MailboxGUID" haben muss, da sie ansonsten mit einer Lizenz ein Doppelpostfach mit Exchange Online bekommen könnten. Auch sonst sollten Sie sich genau anschauen, welche Eigenschaften durch ADSync zwischen einem lokalen Active Directory und Exchange Online repliziert werden.

In Verbindung mit Exchange Hybrid würde ich immer den ADSync einsetzen und das eigene Provisioning in der Coud auf die Felder beschränken, die nicht schon über das lokale AD und ADSync in der Cloud gesetzt werden.

Weitere Links