Admin Scope

Der "Global Admin" eines Office365/Microsoft 365-Tenant kann in der Regel alle Belange eines Tenant verwalten. Aber viel Macht ist auch großes Risiko. Zudem gibt es speziell in größeren Umgebungen die Forderung nach beschränkte Berechtigungen auf Teilmengen von Objekten oder sogar über mehrere Tenants hinweg. Wie geht das mit der Cloud?

NT4 Domain vs. AD

Wenn Sie als Admin mal in ihre Azure Active Directory geschaut haben, dann sehen Sie eine Liste der Benutzer. Wer schon vor dem Jahr 2000 mit Windows Domänen zu tun hatte, fühlt sich direkt in NT4-Zeiten mit der flachen Domäne, in der alle Benutzer und Computer in einer Lise stehen. In der NT4-Domain gab es keine Organisationseinheiten zur Strukturierung.

Erst mit dem Active Directory können Sie ihre Verzeichnisdienste mit Domains und OUs strukturieren und damit nicht nur die Übersichtlichkeit verbessern, sondern z.B. Gruppenrichtlinien auf einzelne OUs statt der kompletten Domäne binden. Der wichtigste Aspekt ist aber die Möglichkeit, auf OUs die Berechtigungen zu erweitern und damit Konten bestimmte Rechte zu gewähren, für die bisher immer ein "Domain Admin" erforderlich war.

Die Vergabe von administrativen Berechtigungen ist aber keine Absicherung gegen den normalen "Lese-Zugriff" von Benutzern. Ihnen sollte bekannt sein, dass auch in einem Active Directory die Mitglieder von "Domänenbenutzer" und selbst Benutzer aus vertrauten Domänen des gleichen Forest oder per Trust angebundener externer Domänen durchaus umfangreiche "Leserechte" haben. Sie können als Anwender einfach mal mit LDIFDE einen Export der Domain-Partition ziehen und die Text-Datei betrachten. Mitarbeiternamen, Mailadressen, hinterlegte Mobilfunknummer, Gruppenmitgliedschaften und Vorgesetze sind quasi öffentlich.

AzureAD OUs

Im AzureAD und davon abgeleiteten Verzeichnisdiensten (Siehe auch Azure AD - Ein Verzeichnisdienst, oder zwei oder mehr) gibt es aber keine OUs. Eine Gruppierung von Anwendern muss anders erfolgen und auch eine Vergabe von Berechtigungen wird nicht über ACLs mit SIDs erreicht, sondern Berechtigungen und Administrative Rollen. Damit stellt sich aber die Frage, ob und wie die durch Rollen delegierte Berechtigungen auf Teilmengen beschränkt werden können.

Für das AzureAD gibt es tatsächlich so etwas wie OUs, auch wenn im Azure-Portal dies nicht direkt sichtbar ist. Vorher sollten Sie aber die Lizenzsituation klären:

Using administrative units requires an Azure AD Premium P1 license for each administrative unit administrator, and Azure AD Free licenses for administrative unit members.
Quelle: https://docs.microsoft.com/en-us/azure/active-directory/roles/administrative-units#license-requirements

Wie so oft sollte eine gute Planung am Anfang einer Einführung stehen. Bedenken Sie dabei auch immer die Einschränkungen:

Administrative unit-scoped admins can use the Microsoft 365 admin center for basic management of users in their administrative units. A group administrator with administrative unit scope can manage groups by using PowerShell, Microsoft Graph, and the Microsoft 365 admin centers.
Quelle: https://docs.microsoft.com/en-us/azure/active-directory/roles/administrative-units#currently-supported-scenarios

Auf der gleichen Seite gibt es dann eine Positivliste der unterstützten Szenarien. Im Umkehrschluss bedeutet dies, dass andere Verwendungen nicht testet und unterstützt sind. Im wesentlichen sind es die üblichen Verwaltungsfunktionen auf Benutzer (Benutzerstammdaten, Kennwort, Lizenzen, Entsperren, MFA-Einstellungen) und Gruppen (Mitglieder und Lizenzierung).

Rollen und PIM

Berechtigungen im AzureAD und Office 365 Tenant werden über administrative Rollen vergeben. Diese bündeln verschiedene Rechte, um unterschiedliche Aufgaben wahrnehmen zu können. Ein Konto hat üblicherweise ein oder mehrere Rollen oder hat sie nicht. In einem einfachen Tenant ist dies eine statische Zuweisung und Sie sind gut beraten, solche privilegierten Berechtigungen nicht ihren tagtäglich genutzten regulären Anmeldekonto zu geben. Stellen Sie sich vor, sie klicken doch einmal auf eine Phishing-Mail oder eine Anlage und eine Malware führt unter ihrem Namen ein paar Graph-Aufrufe gegen ihren Tenant aus. Solche Rechte sollten Sie nicht dauerhaft haben.

Sie können sich daher ein eigenes AzureAD-Konto oder ein synchronisiertes zweites lokales AD-Admin-Konto anlegen und per PowerShell oder als Gast-Browser getrennt anmelden. Mit AzureAD P2 können sie ein Konto nutzen, welches die Berechtigungen über die Funktion "Privileged Identity Management (PIM)" erst temporär anfordern muss. Sie ersparen sich so ein zweites Konto aber haben die Rechte nur kurzzeitig.

What is Azure Active Directory Privileged Identity Management?
https://www.youtube.com/watch?v=f-0K7mRUPpQ

Damit steuern sie aber nur, ob sie die Rolle innehaben. Sie legen damit aber nicht den Scope gesondert fest. Für die Nutzung von PIM brauchen Sie zudem "AzureAD P2"-Lizenzen.

Denken Sie daran, dass selbst kleine Rechte einige Nebenwirkungen haben können. Auch ohne besondere Rollen kann ein Benutzer, ähnlich wie im lokalen AD, schon Informationen aus dem AzureAD auslesen. Die Installation der AzureAD PowerShell und ein "Connect-AzureAD" mit nachfolgendem "Get-AzureADUser" ist per Default auch für Benutzer möglich. Kaum eine Firma beschränkt diese Zugriffe z.B. per Conditional Access. Es funktioniert auch nicht dauerhaft, denn auch Teams, Outlook und andere Applikationen müssen ja Benutzer suchen können.

Wenn Sie aber einem Anwender z.B. die Rolle "Messagecenter-Reader" geben, damit er Änderungen nachlesen kann, dann öffnet dies auch das Office 365 Admin Portal zum Lesezugriff, wo der Anwender ansonsten nicht einfach hinkommt.

Scopes in Teams

Die Steuerung von Berechtigungen im Azure Portal ist nur ein Teil. Für Microsoft Teams könnte es schon erforderlich sein, z.B. die Verwaltung auf Konferenzsysteme oder Telefone zu delegieren, ohne die Person gleich zum "Teams Admin" zu machen. Zum Teil ist dies durch entsprechende Rollen schon möglich:

Wenn Sie aber genau hinschauen, dann gibt es aktuell keine Rolle die für einen SIP-Trunk-Provider passen würde. Er sollte z.B.: Rufnummern provisionieren und Trunk-Konfigurationen pflegen können. So eine Rolle gibt es aktuell (Jan 2022) nicht. Auch kenne ich aktuell noch Möglichkeit, mit Bordmitteln die Verwaltung von Benutzereinstellungen auf die Admin-OUs des AzureAD zu beschränken. Hier sind aktuell 3rd Party Tools oder Eigenentwicklungen erforderlich, so dass eine Applikation die Rechte hat und ein passsendes Frontend durch den Helpdesk/Admin genutzt werden muss

Exchange RBAC

Exchange On-Premises kennt erstmals mit Exchange 2010 die Delegierung von Berechtigungen über "RBAC - Role Based Access Control". Der Administrator gibt seinen "Änderungswunsch" beim Exchange Server ab, der abhängig von den Rollen und Scopes dann die Änderungen durch das Konto des Exchange Server Computers umsetzt. Ein Exchange Admin kann idealerweise gar nichts im Active Directory ändern, sondern muss den Exchange Server als "Vermittler" nutzen.

Diese Funktion gibt es in Exchange in etwas abgeschwächter Form. Auch hier können Sie Personen in "Role Groups" aufnehmen. Über "Role assignment policies" können Sie jedem Postfach zuweisen, welche Einstellungen der Anwender selbst ändern darf. Das ist aber eher ein seltener Fall, speziell wenn die Stammdaten eh von ADSync aus dem lokalen Active Directory repliziert werden.

EWS/Graph

Eine ganz andere Funktion bezieht sich auf die Inhalte in Exchange. Per EWS oder Graph können Programme (Apps) eigenständig oder im Kontext des Benutzers aus die Daten in den Postfächern zugreifen. So ist es eine häufige Anforderung, dass z.B. ein ERP/CRM-System auch in den Kalender oder die Kontakte der Anwender zugreift. Allerdings soll die App diese Rechte natürlich nur z.B. auf die Mitarbeiter im Vertrieb haben.

So eine Segmentierung sieht Graph aktuell erst einmal nicht vor. Hier können Sie seitens der Rechte nur zwischen "ein User" oder "Alle User" unterscheiden. Allerdings ist Exchange hier doch etwas weiter und hat bei EWS-Impersonation eine Möglichkeit geschaffen, solche Berechtigungen auf Personenkreise einzugrenzen. Dies ist aber nur eine Exchange Funktion und nicht mit OneDrive, SharePoint u.a. zu verwechseln.

Microsoft Defender for Endpoint

Hier können Sie per RBAC den Zugriff auf das Portal steuern. Für die "globalen Administratoren" verweist Microsoft selbst auf PIM, damit dieser Personenkreis besser abgesichert ist. Füdie anderen Abstufungen müssen Sie RBAC Rollen anlegen, um vorzugeben, wer welche Aktionen auslösen kann und über eine zweite Einstellung bestimmen, welche Geräte die Personen sehen. Das sollte aber alles sauber geplant werden, denn Microsoft warnt selbst:

Before enabling the feature, it's important that you have a Global Administrator role or Security Administrator role in Azure AD and that you have your Azure AD groups ready to reduce the risk of being locked out of the portal.
Quelle: https://docs.microsoft.com/en-us/microsoft-365/security/defender-endpoint/rbac?view=o365-worldwide#before-you-begin

Intune

Die Verwaltung von Geräten kann über "Tags" geregelt werden. Zuerst wird ein "Tag" definiert, an welches dann Rollen gebunden werden können. Damit haben die Personen in der Rolle die Rechte auf alle Geräte, die auch das Tag bekommen haben.

Dynamische Gruppen

Mit AzureAD P1 gibt es die Möglichkeit, die Mitgliedschaft von Gruppen an bestimmten Properties, z.B. Abteilung o.ä. festzumachen. Das wäre aus meiner Sicht durchaus eine flexible und alternative Möglichkeit, einen Scope für die Anwendung von Berechtigungen zu setzen.

Leider habe ich noch keine entsprechende Umsetzung gefunden.

3rd Party

Ich kann verstehen, dass alle bislang gemachten Aussagen (Stand Jan 2022) sie vielleicht nicht zufriedenstellen. Speziell größere Firmen werden eine Delegierung von administrativen Berechtigungen als zwingend ansehen. In dem Zuge kommen wieder 3rd Party Programme ins Blickfeld, die es schon früher immer gegeben hat. Auch wenn es im lokalen Active Directory durchaus Möglichkeiten zur Delegierung gibt, kann immer noch zu viel schief gehen. Beim Provisioning denken wir in Prozess und Abläufen, bei denen nicht nur die Berechtigungen zu berücksichtigen sind, sondern auch der zeitliche Ablauf. Daher gibt es verschiedene Programme, die mit ihrem privilegierten Dienstkonto die gewünschten Aktionen in der richtigen Reihenfolge und vorher verifizierten Eingabedaten ausführen.

Das kann letztlich dazu führen, dass bei vollständiger Definition der administrativen Tätigkeiten mit entsprechenden Masken, keine reale Person mehr selbst mit administrativen Berechtigungen agieren muss. Sie müssen dazu allerdings festlegen, wie und mit welcher Software sie arbeiten wollen. Hier nur eine Auswahl

  • Eigenbau Azure Functions o.ä.
    Statt kaufen können Sie die privilegierten Aktionen z.B. als PowerShell-Skript mit einem Dienstkonto aufrufen. Das könnte auf ihrem eigenen Webserver oder als Azure Function umgesetzt werden. Für kleine einfache Prozesse reicht das vielleicht aus. Speziell wenn Sie so nur "Bausteine" bereitstellen, die z.B. von Flow oder anderen Agenten aufgerufen werden.
  • Provisining-Tools, z.B. Adaxes u.a.
    Es gibt einen ganzen Markt von Programme, die ein Provisioning abbilden und mittlerweile natürlich auch Office 365 erfüllen. Ein Admin oder Mitarbeiter startet einen Vorgang z.B. im Webbrowser, der dann von der Lösung umgesetzt wird.
  • Identity Management
    Die Oberklasse ist dann natürlich eine Lösung, bei der ein Agent sich die erforderlichen Stammdaten z.B. aus HR bezieht und Änderungen durch alle Systeme hindurch umsetzt. Microsoft Identity Manager, den es auch aus der Cloud gibt, ist hier nur ein Beispiel unter vielen.

Oft ist aber der Weg überein Drittprodukt sogar besser als auf mit den eingeschränkten Lösungen eines Herstellers zu arbeiten. Das galt auch schon für das lokale Active Directory und Exchange, welche viel mehr Möglichkeiten für die Delegierung boten, als es heute aus der Cloud schon möglich ist.

Ich habe hier einfach mal ein paar Links zu Produkten aufgeführt, damit Sie die unterschiedlichen Ansätze bewerten können. Eine Empfehlung ist ohne Kenntnis ihrer Anforderungen nicht möglich.

Weitere Links