Azure AD - Ein Verzeichnisdienst, oder zwei oder mehr

Für jede Firma mit einem Office 365 Tenant oder Azure Diensten muss Microsoft eine Identitätsverwaltung bereitstellen. Dazu dienen Verzeichnisdienste. Aber hinter Office 365 steckt nicht ein großes Active Directory sondern mehrere Forests. Aber es ich sicher auch kein Active Directory im klassischen Sinn. Aber doch nahe dran. Ein Versuch einer Remote Analyse.

Die erste Näherung

Seit Exchange 4.x gibt es schon ein "Directory" und der Verdacht ist nahe, dass das Active Directory wie wir es seit Windows 2000 kennen, durchaus eine Weiterentwicklung des Exchange Directory Service war. Die Fehlermeldungen im Eventlog waren sich doch zu ähnlich um ihre Abstammung verleugnen zu können. Heute würde ich behaupten, dass das Active Directory in fast jeder Firma seinen festen Platz hat und andere Verzeichnisdienste wie Novell NDS, NIS mittlerweile eine Randerscheinung sind. Es mag sie geben, aber meist ist das Active Directory führend. In den vielen Jahren hat Microsoft auch viele sinnvolle Erweiterungen und Korrekturen eingebracht, so dass ich heute bei Fehlern "im Active Directory" immer erst einmal bei mir oder der Umgebung suche, ehe ich einen Fehler bei Microsoft vermute.

Da liegt es natürlich auch auf der Hand, dass die Office 365 und Azure Plattform irgendwie auf einer vergleichbaren Basis aufsetzt. Auch der Name "AzureAD" suggeriert ein Active Directory dahinter. Allerdings muss Microsoft hier sicher ein anderes Kaliber auffahren, denn die Anzahl der Objekte und Menge an Änderungen wird alle bislang "On-Premises" installierte Topologie übersteigen. Auf der anderen Seite gibt es Funktionen ihres lokalen Active Directory wie z.B. NETLOGIN/SYSVOL-Freigaben, Gruppenrichtlinien, Kerberos Distribution Server und LDAP-Zugriffe, die in der Cloud zumindest nicht nach extern bereitgestellt werden. Ich vermute mal, dass es diese in Office 365 auch nicht gibt.

Ein weiterer Aspekt ist die Verteilung der Daten. Eine komplette Replikation aller Identitäten aller Tenants auf alle Office 365 Zugangspunkte würde die Anmeldung vor Ort natürlich beschleunigen. Da allerdings die meisten Anwender immer am gleichen Standort arbeiten, hätten Sie ja nichts davon. Microsoft würde nur viele Gigabytes sinnlos replizieren. Und dann haben wir ja noch das Thema Datenschutz, die bestimmte Daten eben auf eine Region begrenzen müssen. Ein globales Active Directory, in dem jeder Tenant eine OU darstellt und in der dann alle Objekte (Benutzer, Gruppen, Computer) liegen, ist wohl nicht praktikabel.

Vier mal Powershell

Ich habe mir einfach mal einen Benutzer in meinem lokalen AD angelegt und per AADConnect in die Cloud repliziert. Zudem hat der Benutzer über eine Office 365 E5-Lizenz auch ein Postfach und Skype Online Konto bekommen. Dann habe ich über die verschiedenen PowerShell-Commandlets die Details dazu ausgelesen. Die Ergebnisse sind schon interessant.

  • AzureAD
    Dieses Commandlets greifen auf das AzureAD direkt zu, welche hinter Office 365 zum Einsatz kommt. Hier ist gut zu sehen, dass das Objekt erst mal eine ObjectID in Form einer GUID enthält und sogar ein Verweis auf die On-Premises-SID mitgeführt wird. Aber ich habe zumindest keinen DN oder eine OU gefunden.
get-azureadUser `
   -SearchString fctest1@uclabor.de `
| fl UserPrincipalName,On-PremisesSecurityIdentifier,ObjectId 

UserPrincipalName            : fctest1@UCLABOR.DE
On-PremisesSecurityIdentifier : S-1-5-21-4124281298-819535733-1525930181-1901
ObjectId                     : 17857064-d5b5-458f-b99d-af90dad7a298
  • MSOLUser
    Die kleine Variante nutzt die Office 365 API zur Verwaltung der Benutzer. Es ist "nur" eine andere API für den Zugang zum AzureAD. Insofern sind auch die gelieferten Daten gleich aber enthalten z.B. die On-Premises-SID nicht
get-msolUser `
   -UserPrincipalName fctest1@uclabor.de 
| fl UserPrincipalName,ObjectId 

UserPrincipalName `          : fctest1@UCLABOR.DE
ObjectId                     : 17857064-d5b5-458f-b99d-af90dad7a298
  • Exchange Online
    Das "Get-User"-Commandlet ist ein Exchange Commandlet, um Details zu dem Benutzer aus von Exchange zu erhalten. Interessant ist hier, dass das Objekt anscheinend eine andere GUID liefert. Der Verweis auf das AzureAD-Objekt findet sich hingegen im Feld "ExternalDirectoryObjectId". Das Konto hat auch eine SID und einen DistinguishedName. Ich würde sagen, dass es sich damit nicht um das gleiche Objekt handelt. Auch die OU zeigt hier deutlich auf einen Forest in Nord Amerika. Der gleiche Aufruf gegen einen Benutzer in einem europäischen Tenant liefert einen anderen Pfad. Diese Exchange Empfänger dürften also in einem eigenen oder mehreren eigenen AD-Forests geografisch verteilt sein.
get-User `
   -identity fctest1@uclabor.de 
| fl DistinguishedName,OrganizationalUnit,SamAccountName,sid,ExternalDirectoryObjectId,guid

DistinguishedName         : CN=fctest1,OU=fcarius.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=NAMPR20A001,DC=PROD,DC=OUTLOOK,DC=COM
OrganizationalUnit        : nampr20a001.prod.outlook.com/Microsoft Exchange Hosted Organizations/fcarius.onmicrosoft.com
SamAccountName            : fctest57896300481673
Sid                       : S-1-5-21-3773200467-1648347138-3333334462-13909961
ExternalDirectoryObjectId : 17857064-d5b5-458f-b99d-af90dad7a298
Guid                      : 5c66e511-9086-4505-af53-37c4c3bc80df
  • Skype for Business
    Auch das per Get-CSOnlineUser gemeldete Objekt hat einen komplett abweichenden Distinguishedname, SID und ObjectID. Anscheinend nutzt auch Skype for Business Online eigene Forests.
Get-CsOnlineUser `
   -identity fctest1@uclabor.de `
| fl DistinguishedName,Guid,Sid,UserPrincipalname,ObjectId,id

DistinguishedName   : CN=17857064-d5b5-458f-b99d-af90dad7a298,OU=3c6855ff-e39f-4d09-a473-33807598ce4b,OU=OCS Tenants,DC=lync2a001,DC=local
Guid                : 0c6e65e5-bebd-497d-b14b-e14258176629
Sid                 : S-1-5-21-782800828-1820537485-3938890916-176592378 
UserPrincipalName   : fctest1@uclabor.de
ObjectId            : 17857064-d5b5-458f-b99d-af90dad7a298
Id                  : CN=17857064-d5b5-458f-b99d-af90dad7a298,OU=3c6855ff-e39f-4d09-a473-33807598ce4b,OU=OCS Tenants,DC=lync2a001,DC=local

Schon allein diese oberflächliche Betrachtung verrät schon viel über die interne Struktur von Office 365 und Azure

Mehr als ein Container

Ich würde mich mal darauf festlegen, dass Office 365 und die Dienste mit sehr vielen Forests arbeiten und ein interner Verzeichnisabgleich und Provisioning-Prozess die Identitäten verwaltet. Damit erklärt sich für mich natürlich auch, wenn die ein oder anderen Änderungen etwas länger dauern. Für meinen Tenant behaupte ich, dass ich es mir mindestens vier Forests zu tun habe, in denen meine Benutzer auftauchen.

Solange aber Microsoft die reale Umgebung nicht wirklich öffentlich macht, sind die folgenden Aussagen nur Vermutungen.

  1. Lokales Active Directory
    Wenn Sie nicht gerade eine sehr kleine Firma sind, dann dürften Sie ein lokales Active Directory haben. Hier gibt es meine Anwender und AADConnect synchronisiert diese in meinem Tenant
  2. AzureAD des Tenant
    Ich habe vermutlich keinen eigenen AD-Forest sondern meine AzureAD-Identitäten sind eine Partition oder OU in einem Forest. Allerdings dürfte der Forest vermutlich geografisch beschränkt sein, z.B. EMEA. Daher wird es weitere Forests geben, die in anderen geografischen Regionen aufgebaut sind. Ich bin aber sicher, dass es Verweise oder Stub-Objekte gibt. Schließlich könnte ich ja beruflich in den USA sein. Mein Client trifft dann einen US-Server der zumindest rausfinden muss, wohin er meine Anfragen weiter reicht. Denkbar ist ein "Hint" basierend auf der UPN-Domain o.ä. Vielleicht sind aber auch teile meiner Identität wie bei einem Global Catalog weltweit verfügbar.
    Mittlerweile gibt es auch Multi Geo Tenants. Das könnte dann ein Forest sein, der weltweit repliziert wird.
  3. EXODS: Exchange Online Directory Service
    Auch die Exchange Server und damit auch die Empfänger liegen nicht im AzureAD-Forest. Die Verbindung von Berechtigungen und Schema-Erweiterungen lassen sich in einem Ressource Forest und dem Einsatz von Linked Mailboxen besser abbilden. Wenn das AzureAD aber keine SID hat und keine Trusts, dann dürfte Microsoft etwas anderes entwickelt haben, um die Verbindung herzustellen. Das Feld "ExternalDirectoryObjectId" ist hier ein gut sichtbarer Verweis und wenn man ein AzureAD-Objekte löscht und dann das noch nicht gelöschte EXODS-Objekt bearbeitet, dann sieht man etwas wie.
  4. Skype for Business
    Genau wie Exchange dürfte auch der UC-Teil in einem eigenen Forest installiert sein. Auch wenn das Feld "ObjectID" als Verweis auf das AzureAD-Konto dienen dürfte, scheint hier im Hintergrund das Produkt viel näher am klassischen Active Directory angelehnt zu sein. Der DN ist ein sehr klassischer LDAP-Pfad.
  5. Teams, SharePoint u.a.
    Ich gehe davon aus, dass Teams das gleiche AD-Backend nutzt, wie Skype for Business aber vermutlich selbst auch noch eine Datenbank hat. Im Vortrag "Ignite 2018: BRK3118 - Microsoft Teams Architecture update.pptx" ist auf Folie 8 zu sehen, dass es eine Replikation gibt, die in der Regel in 15 Min fertig ist aber ein SLA von 24h hat.
  6. BVD
    Eine besondere Rolle kommt dem BVD - Business Voice Directory zu. Das ist eine verteilte sehr schnelle Datenbank die allein eingehende Anrufe anhand der Rufnummer zum Endpunkt routet.
  7. Der gleiche Ansatz dürfte auch für SharePoint und vielleicht andere Dienste gelten, die das AzureAD als Quelle nutzen aber die Verwaltung in eigenen Datentöpfen machen.
  8. Enterprise Apps
    Es gibt eine API, über den weitere Apps aus AzureAD provisioniert werden können. Siehe dazu auch SCIM - System for Cross-Domain Identity Management

Wer mehrere Identitäten nutzen, muss diese auch untereinander abgleichen. Der Abgleich zwischen lokalen AD und AzureAD übernimmt natürlich AADConnect. Was hingegen im Innenverhältnis passiert, kann ich nicht sagen. Sie können aber wohl nun verstehen, warum Änderungen an einer Stelle manchmal etwas länger dauern und je nach Wahl des PowerShell-Befehls die Daten aus verschiedenen Quellen kommen.

Caching

Eine weitere Komponente, die sie stören könnte sind Metadaten, die im Hintergrund zwar eine der Abfrage an z.B. das AzureAD stellen aber komplexe Antworten an einen Cache stellen. Das gilt z.B. für Microsoft Graph:


Auszug aus dem Community Call am 19.5.2022

Das ist dann kein richtig eigenes "Directory" sondern ein Lookup-Cache. Wenn ich per Graph eine Objekt ändere, dann wird es oben über die REST Directory Services (RDS) direkt ins AzureAD geschrieben. Über den gleichen Weg kann ich das Objekt auch wieder lesen. Wenn ich aber umfangreiche Suchen nutze, dann nutzt Graph den "Advanced Query Service", der den "Advanced Query Store" liest. Für mich als Entwickler bedeutet das, dass ich beim schnelen Schreiben und wieder Lesen über eine Suche nicht immer die aktuellen Daten bekomme.

Weitere Datentöpfe

Wenn Sie nun die verschiedenen Produkte anschauen, dann ahnen sie nun schon, was kommt. Diverse Produkte führen ihre eigene Datenbanken mit. Exchange selbst nutzt schon primär das Active Directory aber für Skype for Business On-Premises ist das AD nur Datenlieferant. Hier werden die Daten immer in eine lokale SQL-Datenbank übertragen, damit der Zugriff auch möglich ist, wenn das Active Directory einmal unpässlich sein sollte.

Auch SharePoint nutzt das Active Directory zwar zur Authentifizierung und Quelle der Anwender aber hier gibt es

Ich kann aktuell auch gar nicht sagen, ob es in Office 365 nicht noch weitere Forests für andere Produkte gibt, z.B. CRM etc. Mit einem AzureAD Abonnement können Sie aber in Azure selbst auch noch selbst weitere AzureAD-Instanzen einrichten.

Das ist dann aber "nur" ein eigenes AzureAD, welches aber meines Wissens (noch) nicht mit Office 365 genutzt werden kann sondern für Applikationen geeignet ist.

Provisioning prüfen

Auch wenn Sie nicht so richtig prüfen können, ob Microsoft im Hintergrund alles richtig und aktuell umsetzt, so gibt es doch ein paar Commandlets, die sie kennen sollten:

# Microsoft Online PowerShell
Get-MsolUser -HasErrorsOnly
Get-MsolContact -HasErrorsOnly
Get-MsolGroup -HasErrorsOnly
Get-MsolDirSyncProvisioningError

Dies drei CMDLets zeigen die Objekte mit einem Fehler an und über das Property "Errors" sehen Sie auch die Details.

Interessant finde ich in dem Zuge auch die folgenden CMDlets:

#MSOnline PowerShell
Redo-MSOLProvisionUser
Redo-MsolProvisionContact
Redo-MsolProvisionGroup

Damit soll ein Admin ein erneutes Provisionieren eines Objekts anstoßen können. Viel mehr Details gibt es dazu aber nicht.

Ich interpretiere das aber so, dass es sogar zwischen ADSync und den nachgelagerten Verzeichnisdiensten noch ein Metadirectory gibt. Hinweise darauf glaube ich auf beim neuen AzureAD Cloud Sync gefunden zu haben.

Mehrere Cloud-Umgebungen

Bislang haben wir nur von "Office 365 Worldwide" gesprochen, d.h. das Microsoft Angebot für die Masse. Das ist aber nicht alles. Microsoft betreibt mittlerweile mehrere separate Office 365 Plattformen, von denen sich einige im Exchange Hybrid Wizard (HCW - Hybrid Configuration Wizard) verraten:

Dort müssen Sie nämlich das passende Backend auswählen, wenn Sie Hybrid einrichten. Neben "Office 365 Worldwide" gibt es hier die bekannte "Office 365 China"-Plattform und immer noch die sterbende "Office 365 Deutschland"-Umgebung. Aber auch U.S. Government hat zwei Umgebungen und was sich hinter "Office 365 Airgap" verbirgt, habe ich noch nicht in Erfahrung bringen können.

Zusammenfassung

Office 365 ist mehr als Exchange/Groups/Outlook, SharePoint/Teams/OneDrive und Skype for Business. Dahinter steht ein AzureAD-Directory für die Verwaltung der Identitäten und Authentifizierung. Technisch betreibt Microsoft ganz sicher aber sehr viel mehr Forests, die in enger Kopplung erst die Gesamtlösung darstellen. Ich wäre rein sportlich gesehen daran interessiert, wie Microsoft diese Umgebung geplant und entworfen hat. Es gibt ja wohl nichts vergleichbares. Leider dürfte es nur wenige Leute geben, die hier den großen Überblick haben und die haben wahrlich besseres zu tun, als darüber zu bloggen. Wobei das nicht ganz richtig ist. Manchmal gibt es Vorträge, wie ein Teilbereich in Office 365 betrieben wird.

Sobald ich Links zu anderen Vorträgen finde, werde ich die addieren

Weitere Links