Microsoft 365 Default Rechte

Jeder Administrator weiß, dass ein Domain Benutzer umfangreiche Lese-Rechte im lokalen Active Directory hat, bis zu 10 Computer in die Domäne aufnehmen kann und Daten umfangreich exportieren kann. Auf dieser Seite beschreibe ich die "Default Berechtigungen" eines "normalen" Office 365 Benutzern oder auch "Gast"-Benutzer in einem Office 365 Tenant.

Wussten sie, dass jeder AzureAD-Benutzer eine Liste aller Benutzer, Gruppen, Geräte, Lizenzen und mehr einfach so generieren kann? Die Admin-Portals sind zwar per Default nicht erreichbar aber per PowerShell ist es ganz einfach. Ein Blick hinter die Default Rechte im AzureAD

Administrative Rollen: On-Premises

Wer im Active Directory, AzureAD, Office365, Microsoft 365 u.a. Dienste etwas sehen oder verwalten will, benötigt die erforderlichen Berechtigungen. Die Windows Administratoren kennen aus ihrem lokalen Active Directory umfangreiche "Standard Rollen", die als Sicherheitsgruppe ausgeführt sind.

Auch ADSync, Exchange, Skype for Business etc addieren neue Sicherheitsgruppen, die mit Rechten versehen werden. So können Administratoren einfach die gewünschten Admin-Konten in die Gruppen aufnehmen und ersparen sich die Vergabe individueller Berechtigungen. Allerdings sind die Rollen-Gruppen vordefiniert und wenn Sie eigene abweichende Rollen benötigen, dann müssen Sie doch wieder selbst ran.

Rollen in Microsoft 365 und AzureAD

Auch in der Cloud gibt es vordefinierte Rollen. Sie finden Sie im Microsoft 365 Admin Center und im Azure Portal

• Microsoft 365 AdminCenter - Rollen
  https://admin.microsoft.com/#/rbac/directory
• Azure Admin Portal - Administrative Rollen
  https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RolesAndAdministrators

Am 22. Jan 2021 habe ich allein in meinem Tenant folgende 63 RoleGroups gefunden:

Application administrator, Application developer, Attack payload author, Attack simulation administrator, Authentication administrator, Azure DevOps administrator, Azure Information Protection administrator, B2C IEF Keyset administrator, B2C IEF Policy administrator, Billing administrator, Cloud application administrator, Cloud device administrator, Compliance administrator, Compliance data administrator, Conditional Access administrator, Customer LockBox access approver, Desktop Analytics administrator, Directory readers, Directory writers, Dynamics 365 administrator, Exchange administrator, External ID user flow administrator, External ID user flow attribute administrator, External Identity Provider administrator, Global administrator, Global reader, Groups administrator, Guest inviter, Helpdesk administrator, Hybrid identity administrator, Insights administrator, Insights business leader, Intune administrator, Kaizala administrator, License administrator, Message center privacy reader, Message center reader, Network administrator, Office apps administrator, Password administrator, Power BI administrator, Power platform administrator, Printer administrator, Printer technician, Privileged authentication administrator, Privileged role administrator, Reports reader, Search administrator, Search editor, Security administrator, Security operator, Security reader, Service support administrator, SharePoint administrator, Skype for Business administrator, Teams Communications Administrator, Teams Communications Support Engineer, Teams Communications Support Specialist, Teams Devices Administrator, Teams Service Administrator, UpdateClientCert, Usage summary reports reader, User administrator
Quelle: https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RolesAndAdministrators

Im Microsoft 365 Portal werden wird eine Teilmenge davon angezeigt.

• About admin roles
  https://docs.microsoft.com/en-us/microsoft-365/admin/add-users/about-admin-roles?WT.mc_id=365AdminCSH&view=o365-worldwide
• Overview of role-based access control in Azure Active Directory
  https://docs.microsoft.com/de-de/azure/active-directory/roles/custom-overview

Message Center öffnet die Tür

Normale Anwender sind in der Regel in keiner dieser Role Groups und ein Gegenstück u "Domain User" oder "Domain Guest" aus dem lokalen Active Directory gibt es anscheinend nicht. Aber es gibt durchaus Standardrechte, wie ich bei der Arbeit um das Message Center festgestellt habe. Ich wollte, dass bestimme Personen aus einer Firma auch das Microsoft 365 MessageCenter unter https://admin.microsoft.com/#/MessageCenter öffnen können. Sehr schnell ist meine Wahl auf eine genau passende RoleGroup im AzureAD gefallen:

Ich habe die Berechtigung einen Benutzer zugewiesen und ihn auf die URL https://admin.microsoft.com/#/MessageCenter verwiesen. Er konnte das Message Center wie erwartet einsehen. Unerwartet war aber, dass er noch viel mehr Informationen einsehen konnte.

Das ist deutlich mehr, als ich erwartet hätte und auf jeden Fall nicht meine Intention. Bei Microsoft steht in der Anleitung:

Users in this role can monitor notifications and advisory health updates in Message center for their organization on configured services such as Exchange, Intune, and Microsoft Teams. Message Center Readers receive weekly email digests of posts, updates, and can share message center posts in Microsoft 365. In Azure AD, users assigned to this role will only have read-only access on Azure AD services such as users and groups. This role has no access to view, create, or manage support tickets.
Quelle: https://docs.microsoft.com/de-de/azure/active-directory/roles/permissions-reference#compliance-administrator-permissions

Hier wird zumindest auf die "Read"-Rechte auf Benutzer und Gruppen hingewiesen. Aber das beschreibt nur eine kleine Teilmenge.

Natürlich kann auch ein Domain Benutzer über LDAP im lokalen Active Directory sogar noch mehr Informationen über Benutzer und Gruppen auslesen.

Aber ein "Message Center Reader" muss nicht wirklich wissen, welche Cloud-Lizenzen welcher Benutzer hat oder welche globalen Organisationseinstellungen gerade aktiv sind. Da wollte ich dann schon mal wissen, was ein Benutzer denn noch so alles sehen darf.

Auf der Seite O365 Message Center beschreibe ich die Benutzung des Message Center und insbesondere die Funktion, die Informationen als Admin in einen "Planner" zu replizieren. So können auch  berechtigte Personen die Änderungen als Task nicht nur gefahrlos lesen sondern auch als Aufgaben untereinander zuweisen und nachverfolgen.

• O365 Message Center

Default Rechte für Benutzer

Die Antwort auf meine Frage lag nur wenige Mausklicks entfernt. Über die Anzeige der Berechtigungen zum "Message Center Reader" sehen Sie alle weiteren Berechtigungen:

Unter den beiden Einträgen für die "Role permission" kommt eine sehr lange Liste mit den "basic read permissions".

Wenn Sie diese Rolle einem Gast oder Service Principal zuweisen, bekommt das Objekt auch die Rechte, die jeder normale Anwender sowieso auch hat.

Die Liste ist sehr umfangreich und ich gebe hier den Stand vom 22. Jan 2021 eines Standard EU-Tenant wieder:

Ich kann mir aktuell keinen Reim drauf machen, warum normale Anwender oder sogar Gäste solch umfangreiche Berechtigungen haben sollten. Es ist zwar "nur" ein Read-Recht und die meisten Benutzer kommen allein mit diesen Berechtigungen nicht an die beiden Admin-Portale heran. Aber das ist doch kein echter Schutz, denn es kann doch durchaus "erwartet" sein, dass auch ein normales Konto über Rollenzuweisungen ausgewählte Leserechte bekommt.

Zumindest erwarte ich nicht, dass ein Anwender mit "Message Center Reader" über das Portal gleich alle anderen Dinge ganz einfach per Mail einsehen kann.

• Administrator role permissions in Azure Active Directory
  https://docs.microsoft.com/de-de/azure/active-directory/roles/permissions-reference

AzureAD per PowerShell?

Ich habe dann einen "normalen Anwender" genutzt, der nie Administrator war und sicher 100% "Standard" ist. Nach der Installation der Microsoft Online PowerShell konnte ich mich problemlos am Tenant als Benutzer anmelden. Die zur Verfügung stehenden Commandlets entsprachen den Berechtigungen. ich konnte mit...

• Get-MsolAccountSku die Lizenzen und Anzahl ermitteln.
• Get-MsolRole und Get-MsolRoleMember die Adminrollen und zugewiesenen Benutzer auslesen
• Get-MsolDevice -ALL eine Liste aller Geräte und deren grundlegenden Eigenschaften ermitteln
• Get-MsolAdministrativeUnit und Get-MsolAdministrativeUnitMember die AdminOUs einsehen
• Get-MsolCompanyInformation die Firmendaten samt Kontaktnummer des Administrators, Dienstkonto des DirSync-Kontos u.a.auslesen
• Get-MsolContact eine Liste aller Kontakte generieren
• Get-MsolPartnerContract liefert eine Liste der TenantIDs, bei denen mein Tenant als Partner/Admin hinterlegt ist
• Get-MsolDirSyncProvisioningError und Get-MsolHasObjectsWithDirSyncProvisioningErrors zeigen den Status des DirSync an
• Get-MsolCompanyAllowedDataLocation wurde aber mit "No Permission" quittiert.

Das ist ganz schön viel und zeigt mir, dass diese Informationen nicht nur per Browser über das Webportal erreichbar sind, und auch nicht von einer Rolle wie "Message Center Reader" anhängig sind, um diese Daten zu erhalten. Sie brauchen einfach nur ein gültiges Office 365 Konto.

Das öffnet natürlich die Tür, wenn nur ein Benutzer seine Zugangsdaten "verliert" und damit eine nicht berechtigte Person von überall in der Welt diese Daten auslesen kann. Aus meiner Sicht ist das ein weiterer Grund, über AzureAD P1 nachzudenken und den Zugang zu bestimmten Schnittstellen auf bekannte Endgeräte und Benutzer zu beschränken.

Exchange Online

Nun war ich natürlich neugierig geworden und habe mich mit meinem "normalen Userkonto" auch an die anderen Online-Dienste verbunden.

PS C:\> Connect-ExchangeOnline

PS C:\> get-mailbox

Name                Alias           Database                  ProhibitSendQuota
----                -----           --------                  -----------------
Carius, Frank       fc              EURPR04DG045-db080        99 GB (106,300,44...

PS C:\> Get-MobileDevice | ft Friendlyname,DeviceOS,ismanaged,iscompliant

FriendlyName               DeviceOS         IsManaged IsCompliant
------------               --------         --------- -----------
                           iOS 14.3             False       False
iPhone 11                  iOS 14.4 18D52       False       False
iPhone SE (1st generation) iOS 13.5.1 17F80     False       False

Ich kann mich per Default mit der PowerShell verbinden und sogar Commandlets aufrufen. Allerdings beziehen sie die meisten Commandlets nur auf mein eigenes Konto. Ich sehe also keine Daten zu anderen Postfächern oder anderen Mobilgeräten. Allerdings kann ich eine komplette Liste der Empfänger abrufen

PS C:\> Get-Recipient| group recipienttypedetails -NoElement

Count Name
----- ----
  3171 UserMailbox
   119 MailUniversalSecurityG...
   334 MailUniversalDistribut...
  1174 GroupMailbox
    13 PublicFolder
   121 SharedMailbox
   221 MailUser
    89 RoomMailbox
    23 TeamMailbox
   329 MailContact
    12 SchedulingMailbox
     2 RoomList

Ein "Sicherheitsloch" würde ich das nicht bezeichnen, denn im lokalen Active Directory kann ich das per LDAP auch und über die OutlookAPI kann ich ja auch das Adressbuch auslesen. Allerdings kann ich so auch "unsichtbare" Empfänger ermitteln. Auch die Ausgabe der Daten als "Objekt" macht es natürlich sehr viel einfacher. Die meisten Eigenschaften kann ich nicht schreiben:

PS C:\> set-mailbox fcarius -DisplayName "FC"
Ein Azure Active Directory-Aufruf wurde ausgeführt, um die Synchronisierung eines Objekts zwischen Azure Active
Directory und Exchange Online aufrechtzuerhalten. Dabei ist jedoch ein Fehler aufgetreten. Detaillierte Fehlermeldung:
        Unable to update the specified properties for On-Premises mastered Directory Sync objects or objects currently
undergoing migration.

Auf der anderen Seite gibt es bei Set-CASMailbox schon die ein oder andere Überraschung.

PS C:> get-casmailbox fc

Name                ActiveSyncEnabled OWAEnabled PopEnabled ImapEnabled MapiEnabled SmtpClientAuthenticationDisabled
----                ----------------- ---------- ---------- ----------- ----------- --------------------------------
Carius, Frank       True              True       True       True        True

PS C:\> get-casmailbox fc | fl PopSuppressReadReceipt

PopSuppressReadReceipt : False

PS C:\> set-casmailbox fc -PopSuppressReadReceipt:$true
PS C:\> get-casmailbox fc | fl PopSuppressReadReceipt

PopSuppressReadReceipt : True

PS C:\> set-casmailbox fc -PopSuppressReadReceipt:$false

PopSuppressReadReceipt : False

Das hat mich dann schon etwas überrascht, dass ich wenige, aber nicht alle, CAS-Einstellungen meiner Mailbox so anpassen kann. Auch Auswertungen kann ich als Anwender auf mein eigenes Postfach anstellen.

PS C:\> Get-MailboxFolder -Recurse | ft folderpath

FolderPath
----------
{}
{Archiv}
{Aufgaben}
{Aufgezeichnete Unterhaltungen}
{Entwürfe}
{Gelöschte Elemente}
{Gesendete Elemente}
{Journal}
{Junk-E-Mail}
{Kalender}
{Kontakte}
{Notizen}
{Posteingang}
{Posteingang, _Beispiele}
{Posteingang, _Beispiele, NDR-Archiv}
{Posteingang, _Beispiele, OCS/UM}
{Posteingang, _Beispiele, Phishing/Spam/Virus}

Auch die Funktion "Get-MailboxFolderPermissions" ist möglich aber nicht "Get-MailboxFolderStatistics". Aber ich konnte Rechte in meinem Postfach berichten und aufräumen.

PS C:\> get-mailboxfolder -Recurse | Get-MailboxFolderPermission -User "otheruser@msxfaq.de"

PS C:\>  get-mailboxfolder -Recurse | % {Remove-MailboxFolderPermission -identity $_.identity -User "otheruser@msxfaq.de" -Confirm:$false}

Aber das ist natürlich nicht der Regelfall.

Das eröffnet natürlich diversen 3rd Party Tools, z.B. als Anwender ausführlichere Reports zu generieren.

Tipp: Als Administrator können Sie bei den Benutzern den Zugriff per PowerShell unterbinden. Das geht per Conditional Access (Azure AD P1)

Teams, SharePoint, OneDrive, Graph u.a.

Die weiteren PowerShell-Schnittstellen habe ich noch nicht weiter untersucht.

Zugang per Gast?

In der Beschreibung von Microsoft steht auch, dass die Rechte sogar "Gastbenutzern" offen stehen.

Also habe ich eine weitere PowerShell gestartet und versucht, mich an einem anderen Tenant mit meinem Gastkonto anzumeldeb. Der Anmeldename als Gast in einem anderen Tenant ist ja vom Aufbau her einfach zu ermitteln.

userpart_domainpart#EXT#@tenantdomain.onmicrosoft.com

Ein einfacher "Connect-MsolService" war mit diesem Benutzername aber nicht möglich. Im Zieltenant wurde das auch protokolliert:

Die Cloud hat also schon den Gastbenutzer mit dem übermittelten Benutzernamen erkannt und dem Tenant zugeordnet. Allerdings wurde das Kennwort nicht akzeptiert, obwohl es nachweislich korrekt war.

Insofern kann ich zumindest nicht per PowerShell als Gast so einfach in einem anderen Tenant wildern.
Es kann aber schon sein, dass eine andere Schnittstelle hier kooperativer ist. Das wäre noch einmal nachzustellen, welche Rechte ein Gast im Tenant tatsächlich ausüben kann.

Allerdings möchte ich in dem Zuge noch auf eine weitere Einstellungen zu Gästen und AzureAD hinweisen. Unter der URL "https://portal.azure.com/#blade/Microsoft_AAD_IAM/UsersManagementMenuBlade/UserSettings" können Sie weitere Einschränkungen aktivieren.

Der erste "Learn More"-Links verweist auf:

• Restrict guest access permissions (preview) in Azure Active Directory
  https://docs.microsoft.com/en-us/azure/active-directory/enterprise-users/users-restrict-guest-permissions

Dort steht dann:

Guest users are set to a limited permission level by default in Azure AD, while the default for member users is the full set of default user permissions:
Quelle https://docs.microsoft.com/en-us/azure/active-directory/enterprise-users/users-restrict-guest-permissions

Eine weitere Quelle beschreibt

Guest users have restricted directory permissions. They can manage their own profile, change their own password and retrieve some information about other users, groups and apps, however, they cannot read all directory information. For example, guest users cannot enumerate the list of all users, groups and other directory objects...
Quelle: https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/users-default-permissions

Das ist aber noch keine Aussage, warum meine Anmeldung per PowerShell überhaupt nicht funktioniert hat und ob es vielleicht andere APIs wie z.B. die Graph API gibt, die hier doch einen Zugriff erlaubt.

Weitere Link

• "Global Reader" Admin
• Office 365 Admin Konzept
• O365 Message Center
• Administrator role permissions in Azure Active Directory
  https://docs.microsoft.com/de-de/azure/active-directory/roles/permissions-reference
• What are the default user permissions in Azure Active Directory?
  https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/users-default-permissions
• Restrict guest access permissions (preview) in Azure Active Directory
  https://docs.microsoft.com/en-us/azure/active-directory/enterprise-users/users-restrict-guest-permissions