Azure AD - Ein Verzeichnisdienst, oder zwei oder mehr

Für jede Firma mit einem Office 36 Tenant oder Azure Diensten muss Microsoft eine Identitätsverwaltung bereitstellen. Dazu dienen Verzeichnisdienste. Aber hinter Office 365 steckt nicht ein großese 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 Topologien ü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,OnPremisesSecurityIdentifier,ObjectId UserPrincipalName : fctest1@UCLABOR.DE
OnPremisesSecurityIdentifier : 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 OnPremises-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 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 distiguishedname, SID und ObjectID. Anscheinend nutzt auch Skype for Business Online eigene Forests
Get-CsOnlineUSER 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 Azuer

Vermutungen

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 Forest s 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. Exchange Forests
    Ich bin ziemlich sicher, dass die Exchange Server und damit auch die Empfänger nicht im AzureAD-Forest liegen. 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.
  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.
    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.

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

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.

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