Office 365 Admin Konzept

Für den sicheren Betrieb "OnPremise" ist es ratsam ein Adminkonzept zu entwerfen, um die verschiedenen Zuständigkeiten und Berechtigungen zu definieren. Mit der Neuanlage eines Office 365 Tenant wird es auch immer einen ersten Benutzer geben, der z.B. admin@<tenantname>.onmicrosoft.com benannt ist und auch nicht gelöscht werden kann. Mmit diesem Admin sollten Sie nicht täglich arbeiten, sondern sich je nach Größe und Delegierung weitere Konten anlegen und Berechtigungen delegieren.

Konten in Office 365

Zuerst stellt sich da natürlich die Frage, welche Konten für einen Administrator denn geeignet sind. Mit Office 365 könnte ich mir hier schon drei Konten vorstellen.

Kontentyp Anmeldung Beschreibung

CloudOnly Benutzer mit Adminrechten

Cloud Kennwort

Der erste Admin ist solch eine Konto mit einem "<tenantname>.onmicrosoft.com"-UPN, der komplett Autark vom lokalen AD oder DirSync ist. Wer dieses Konto nutzt, hat ein eigenes Kennwort und ist unabhängig von ADFS. Es ist aus meiner Sicht das optimale Konto für "Globale Administratoren".

ADSync Admin Konto

  • ADFS
  • AD-Kennwortsync
  • Cloud Kennwort

Viele Firmen nutzen heute für die Verwaltung ihres lokalen Active Directory auch schon ein zweites Konto. (Siehe auch Adminkonzept). Damit stellt sich die Frage, ob dieses AD-Konto ebenfalls in die Cloud repliziert wird und z.B. per ADFS die Authentifizierung erfolgt oder ob dieses Konto gerade nicht repliziert wird (Datenschutz). Wenn so ein Konto in die Cloud repliziert wird, dann bietet es sich natürlich an, diesem auch die Berechtigungen in Office 365 zuzuweisen. Für den Administrator ist die Anmeldung und Nutzung mit ADFS oder KennwortSync einfacher. Allerdings sollten Sie nicht alle Admin-Konten so umstellen, da bei einem Ausfall von ADFS oder einer Fehlkonfiguration von DirSync diese eventuell unbrauchbar geworden sind.

ADSync User Konto

  • ADFS
  • AD-Kennwortsync
  • Cloud Kennwort

Auch "normale Benutzerkonten" könnten unabhängig von Berechtigungen im lokalen AD auch in der Cloud mit administrativen Rechten versehen werden. Solch ein Einsatz ist aber eher ungewöhnlich.

Schutz durch MFA

Administrative Konten sind besonders "schützenswert. Office 365 bietet hierzu die Möglichkeit, den Zugriff über eine "Multi Faktor Authentifizierung" zusätzlich abzusichern. Dazu kommt eine entsprechenden App auf dem Smartphone, eine SMS, Mail oder Telefonanruf zum Einsatz. MFA kann sowohl für "Cloud Only"-Konten als auch für ADSync-Konten eingerichtet werden. Allerdings ist es deutlich einfacher diesen Schutz für ein Admin Konto in der Cloud einzurichten.

Eine Absicherung eines per ADFS authentifizierten Kontos betrifft alle Office 365 Dienste. Dies ist besonders stören, wenn das Admin-Konto per ADSync verwaltet wird und der Anwender auch auf Daten (z.B. SharePoint) mit dem gleichen Konto zugreift. Hier kann MFA stören, so dass der Anwender vielleicht sogar darauf verzichtet.

Ich plädiere dafür, dass die "Globalen Admin Konten" Immer per MFA  geschützt werden und als "CloudOnly" Konto angelegt werden. Sie sollten nie den Zugriff auf Daten benötigen.

Administrative Rechte unter Office 365

Nach all den Ausführungen über Konten und Typen wenden wir uns nun der Fragestellung zu, welche Berechtigungen in Office 365 überhaupt delegiert werden können. Der schnellste Weg ist der Blick in das Admin Center. Wenn Sie hier einen Benutzer editieren, dann werden ihnen die verschiedenen Rollen angezeigt:

Diese Liste ist der Stand vom Mai 2016 und kann von Microsoft geändert werden

Ausgehend von den "Benutzerrollen", die eigentlich "Admin-Rollen" heißen müssten, können Sie Berechtigungen auf die drei Hauptprodukte von Office 365 ableiten:

Office 365 admin role

Role in Exchange Online

Role in SharePoint Online

Role in Skype for Business

Global Admin

Exchange Online Admin
Company admin

SharePoint Online Admin

Skype for Business Admin

Billing Administrator

 

 

 

Password Administrator

Help Desk Admin

 

Skype for Business Online Admin

Service Administrator

 

 

 

User management Administrator

 

 

Skype for Business Online Admin

Exchange Administrator

Exchange Online Admin

 

 

SharePoint Administrator

 

SharePoint Online Admin

 

Skype for Business Administrator

 

 

Skype for Business Online Admin

Microsoft hat die aktuellen Rollen auf dem folgenden Link ebenfalls dokumentiert

Hier gibt es dann auch eine noch ausführlichere Tabelle, welche individuellen Aktionen die verschiedenen Administrativen Rollen ausführen dürfen.

Buildin Admin

Ich habe schon vorher geschrieben, dass der "erste Administrator" seine Rechte nicht verlieren kann. Das wird auch im Admin Center entsprechend angezeigt.

Insofern ist es schon hier ratsam, dass dieses Konto nicht "personengebunden" ist.

Mein Tipp: Wenn Sie die weiteren Administratoren angelegt und berechtigt haben, sollten sie das Kennwort für dieses Konto neu setzen und in einem Briefumschlag sicher verwahren. Es ist dann ihr Notnagel im Desasterfall. So könnten zwei Administratoren einfach die Hälfte des Kennworts eingeben, auf einen Zettel schreiben und dem Geschäftsführer aushändigen, der den Kennwortbrief dann im Schließfach verstaut.

Sie können aber auch dieses Admin-Konto mit einem UPN einer Domäne versehen, die für ADFS aktiviert ist. Das sollten Sie nicht tun. Selbst Microsoft weist darauf explizit hin:

Warning It's a Microsoft best practice to always have at least one administrator user ID that's associated with the default domain so that administrative access to the organization isn't lost if SSO is compromised. 
Quelle: https://support.microsoft.com/en-us/kb/2662960

Andere Rechte

Wenn Dienste wie Exchange oder Skype for Business installiert werden, dann richtet Microsoft auch eine ganze Menge anderer RBAC-Rolle und Windows Gruppen ein. Das gibt es so in der Cloud natürlich nicht. Es gibt aber Berechtigungen, die genau genommen nicht zu den Administrativen Berechtigungen gehören aber zugriffe auf Daten erlauben.

Darunter fällt insbesondere bei Exchange das Recht auf andere Postfächer direkt oder per Impersonation zuzugreifen. Wer z.B. Dienstkonton nutzt, die per Impersonate in den Postfächern der Benutzer aktiv sind, sollte diese Konten schon mit der gebotenen Aufmerksamkeit behandeln und zu den besonders schützenswerten Konten zählen.

Konzept

Wenn ich nun die ganzen Informationen zusammenfasse, dann würde mein Admin-Konzept einer Firma mit ADFS und DirSync vielleicht so aussehen:

  • Globale CloudOnly Administratoren
    Es gibt einige "Cloud Only"-Konten, die globaler Administrator sind und dessen Kennwort besonders geschützt ist, z.B. per MultiFaktor Authentifizierung. Die Konten sind Personenbezogen. Nur ein Konto ist ein Notfall Admin, dessen Kennwort sicher in einem Schließfach verwahrt wird.
  • Die "normalen Konten" der Anwender, die per ADSync angelegt werden, werden in der Cloud keine Administrative Rolle erhalten.
  • Delegierte Administratoren
    Wer auch OnPremise entsprechende "Admin-Konten" hat und dieser per ADSync in die Cloud synchronisiert, kann diesen auch in der Cloud entsprechende administrative Rollen übertragen. Wer OnPremise keine Admin-Konten hat und auch keine einführen will, sollte für delegierte Administrationsaufgaben auch hier eigene Konten in der Cloud für die Delegierung anlegen

Ein wichtiger Aspekt bei der Unterscheidung zwischen administrativen Konten und normalen Anwendern ist der, dass normale Aufgaben wie Mails lesen, Internet recherchieren, Dokumentationen schreiben etc. immer mit einem nicht privilegierten Konto ausgeführt werden und eine Person z.B. im Browser an Office 365 angemeldet sein kann aber keine administrativen Rechte hat. Es wäre sonst z.B. denkbar, dass der Browser gekapert wird und Veränderungen vorgenommen werden.

Umgekehrt bedeutet das natürlich, dass ein Administrator zur Nutzung seiner administrativen Berechtigungen einen anderen Browser oder den "Private Mode" aktiv macht. So kann er in einem eigenen Fenster administrative Funktionen nutzen und sollte dabei aber entsprechend vorsichtig sein. Viele meiner Kunden haben einen eigenen "Verwaltungsserver", auf dem alle Tools installiert und aktualisiert werden. Die Administratoren verbinden sich dann einfach per RDP. Das hat nebenbei den Vorteil, dass man auch unterwegs langlaufende oder datenintensive Aufträge nicht über das WAN betreiben muss. Nach einen Verbindungsabbruch kann ich dann einfach wieder aufsetzen.

Weitere Links