Remote Shared Mailbox

Diese Seite beschreibt die Aspekte von gemeinsam genutzten Postfächern in der Exchange Online und insbesondere die Verwaltung der Berechtigungen. Beachten Sie dazu auch die Seite Disable-RemoteMailbox.

OnPremises-Welt

Gemeinsame Postfächer gibt es schon mit Exchange OnPremises seit vielen Jahren und eignen sich wunderbar für generische Postfächer wie "Info", "Vertrieb", "Support", so dass mehrere Mitarbeiter gemeinsam das Postfach mitlesen und auf eingehende Nachrichten reagieren können. Im Gegensatz zu öffentlichen Ordnern gibt es hier auch Regeln, einen Postausgang, gesendete Objekte und Mitarbeiter können recht schnell auch mit der Adresse der Shared Mailbox senden. Sie können die anderen Benutzer einfach als Besitzer berechtigen und über ein Backlink-Attribute (Automapping) können Sie sogar steuern, ob diese Postfächer bei den Benutzern automatisch mit eingebunden werden.

Add-MailboxPermission `
   -Identity shared1@msxfaq.de `
   -User User1@msxfaq.de `
   -AccessRights FullAccess `
   -AutoMapping:$false

Die Rechte werden dann nicht nur im Postfach sondern auch im lokalen AD hinterlegt.

# Anzeige der User, die Stellvertreter sine
Import-Module ActiveDirectory
Get-ADUser <User> -Properties msExchDelegateListBL

# Liste leeren
Set-ADUser <User> -Clear msExchDelegateListLink

Knifflig ist die Funktion der Offline-Verfügbarkeit mittels OST-Datei. Die Replikation von Shared Mailboxen ist möglich, damit Outlook nicht auf die Antwort des Servers warten muss aber kostet lokal Platz, erhöht das Transfervolumen und die Aktualisierung kann etwas dauert, so dass mehrere Benutzer sich in die Quere kommen.

Shared Mailbox in Exchange Online

Natürlich können Sie eine Shared Mailbox auch in die Cloud migrieren und die Benutzer, die darauf zugreifen auch. Es ist sogar ein "Kreuzbetrieb" möglich, d.h. Benutzer und Shared Mailbox müssen nicht auf der gleichen Umgebung sei. Allerdings muss dann Outlook, Autodiscover und alles stimmen, da der Client sich mit beiden Welten verbinden muss. Ein Zugriff per OWA ist aber meines Wissens nicht mehr möglich, da das Exchange Online OWA sich nicht die Daten einer lokalen Shared Mailbox holen kann und umgekehrt.

Daher ist es immer ratsam, die Shared Mailbox und die darauf zugreifenden Benutzer in einer Gruppe zu migrieren und auf der gleichen Plattform zu betreiben.

Beachten Sie beim Betrieb einer Shared Mailbox in der Cloud die Dienstbeschreibungen zu Exchange Online. Hier möchte ich zwei Grenzen hervorheben:

  • 50 GB Limit
    Eine Shared Mailbox kostet keine Lizenz, wenn Sie weniger als 50 GB Postfachspeicher hat. Wird Sie größer, dann müssen Sie eine Exchange Lizenz zuweisen.
  • Send/Empfangslimit
    Für alle Postfächer gelten ein paar feste Grenzen (Siehe Exchange Online Message Rate Grenzen), die nicht verschoben werden können. Allzu viele Mails pro Zeiteinheit sollten diese Postfächer nicht von extern erreichen
  • Max 25 zugreifende Benutzer
    Beachten Sie, dass bis bis zu 25 parallel zugreifende Benutzer offiziell unterstützt sind.

OnPremises gibt es diese Grenzen so nicht aber in beiden Welten sollten Sie den Absprung nicht verpassen, um solche speziellen Adressen vielleicht zu einem CRM-System oder Ticketsystem zu leiten.

Auch bei den Berechtigungen können Sie nur andere Postfächer oder Mailenabled-SecurityGroups zuweisen. Sie können insbesondere keine Microsoft 365 Groups oder dynamische Gruppen oder reine Verteilergruppen zuweisen. In der Exchange Admin Center sehen Sie diese Gruppen auch nicht in der Auswahl.

Rechte und Automapping

Denken sie daran, dass die Berechtigungen auf einer Mailbox bei einer Migration mittels Remote Move Request mit übertragen werden. Nachdem die Mailbox aber in Exchange Online betrieben oder direkt dort neu angelegt wird, können Sie die Berechtigungen nicht mehr im lokalen Exchange verwalten. Das Commandlet "Add-MailboPermission" funktioniert nicht mit RemoteMailboxen:

[PS] C:\>Add-MailboxPermission -Identity t2tuser1 -User fcarius -AccessRights full
The operation couldn't be performed because object 't2tuser1' couldn't be found on 'DC01.UCLABOR.DE'.
    + CategoryInfo          : NotSpecified: (:) [Add-MailboxPermission], ManagementObjectNotFoundException
    + FullyQualifiedErrorId : [Server=EX01,RequestId=207ac40a-533e-489d-a8cc-4021c161fe67,TimeStamp=27.03.2024 12:45:2
   1] [FailureCategory=Cmdlet-ManagementObjectNotFoundException] 94912D11,Microsoft.Exchange.Management.RecipientTask
  s.AddMailboxPermission
    + PSComputerName        : ex01.uclabor.de

Damit ist auch verständlich, dass ADSync keine Berechtigungen in die Cloud replizieren kann und Sie Postfachrechte auf Exchange Online Postfächer direkt in Exchange Online über das Exchange Online Admin Center oder die Exchange Online PowerShell verwalten müssen. Damit ist aber auch erklärt, warum sie auch das Automapping direkt in der Cloud setzen müssen.

Leider ist mir noch kein Weg bekannt, wie ich nachträglich erkennen kann, welche Berechtigung mit Automapping gesetzt wurde. Anscheinend speichert Exchange Online dies nicht im AzureAD-Objekte aber auch nicht an den Postfachrechten. Ich vermute den Speicherplatz am Objekt im Exchange Online Verzeichnis, welches aber auch mit Get-User nicht einsehbar ist.

Wenn Sie ein Recht per Exchange Admin Portal vergeben, dann ist Automapping immer $true.

Dazu passen dann auch KB-Artikeln, bei denen das Entfernen von "Automapping" nur über das Entfernen der Rechte und Neuzuweisen gehen

Gruppen und Rechte

Der Befehl "Add-MailboxPermission" kennt den Parameter "-User", um die Identität des Benutzers anzugeben. Es gibt zwar keinen Parameter "-Group" aber sie können auch bei "-User" problemlos eine Gruppe mit angeben. Dies ist auch erforderlich, wenn Sie wirklich sehr viele berechtigte Benutzer haben.

Laut Microsoft können aber maximal 500 Einträge in der ACL einer Shared Mailbox angelegt werden. Wer mehr Berechtigungen verwalten will, kann dies über Security Groups machen, wie Microsoft selbst beschreibt:

You can use this cmdlet to add a maximum of 500 permission entries (ACEs) to a mailbox. To grant permissions to more than 500 users, use security groups instead of individual users for the User parameter. Security groups contain many members, but only count as one entry.
Add-MailboxPermission https://learn.microsoft.com/en-us/powershell/module/exchange/add-mailboxpermission?view=exchange-ps#description

Allerdings gebe ich zu bedenken, dass 500 berechtigte Personen schon sehr viel sind. Ich sehe daher einen anderen Grund, warum Sie eine Gruppe anstatt einzelner Benutzer berechtigen wollen: Die Pflege der Berechtigungen über eine Gruppe können Sie delegieren. Mit dem richtigen Setup können "Besitzer" einer Gruppe auch die Mitgliedschaften ändern und als Administrator können Sie damit die Verwaltung der Gruppe delegieren. Ganz problemlos ist dies aber auch nicht. Zuerst können Sie nur "Mailenabled Security Groups" für die Berechtigung verwenden. In Exchange Online fallen Microsoft 365/Office Groups ebenso raus wie Dynamische Gruppen. Dies gilt auch für OnPremises.

Viel störender ist aber die Einschränkung von Gruppen, die über ADSync in der Cloud verwaltet werden. Sobald Sie das Postfach des Besitzers einer Gruppe in die Cloud verschoben haben, kann dieser Anwender die Mitgliedschaften seiner Gruppen nicht mehr Outlook, OWA oder dem Microsoft Portal verwalten, den die Gruppe ist in der Cloud "ReadOnly". Hier müssen Sie sich dann andere Ansätze zur Verwaltung der Mitglieder überlegen.

Gruppen und Automapping

Es gibt noch eine zweite Einschränkung, wenn Sie die Berechtigungen über eine Gruppe vergeben:

However, Autodiscover won't enumerate security groups that are given Full Access permission to the mailbox.
Add-MailboxPermission https://learn.microsoft.com/en-us/powershell/module/exchange/add-mailboxpermission?view=exchange-ps#-automapping

Die Anwender, die über eine Gruppe die Berechtigungen auf eine Shared Mailbox bekommen, müssen dieses zusätzliche Postfach manuell in Outlook oder OWA hinzufügen. Das kann dann doch wieder ein ein Grund sein, die bis zu 500 Personen individuell zu berechtigen und Automapping zu steuern.

Durch den Verzicht von Gruppen und damit der Mitgliedschaft von Anmeldekonten reduziert sich übrigens auch die Ticketsize des Anmeldetokens, welches ebenfalls zu Problemen führen kann. Siehe dazu auch Kerberos Ticketsize und Gruppen

Shared Mailbox und Clients

Solange Sie Berechtigungen auf eine Shared Mailbox direkt an die Personen geben und mittels Automapping zuweisen, erscheinen die Postfächer einfach in Outlook. In OWA können sie aber eine Shared Mailbox auch einfach über das Kontextmenü addieren.

Die Outlook-Nutzer müssen ohne Automapping die Postfächer über das Profil zusätzlich einbinden.

Lizenzen

Eine Shared Mailbox oder Remote Shared Mailbox benötigt normalerweise keine Lizenz. Microsoft schreibt dazu:

Licenses: Your shared mailbox can store up to 50GB of data without you assigning a license to it.
Quelle: https://learn.microsoft.com/en-us/microsoft-365/admin/email/about-shared-mailboxes?view=o365-worldwide

Das stimmt soweit aber nur, wie die Mailbox unter 50 GB ist und kein Archiv braucht.  


https://learn.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/exchange-online-limits#storage-limits

Die Fußnote "2" bedeutet dabei (Stand Feb 2024):

To access a shared mailbox, a user must have an Exchange Online license, but the shared mailbox doesn't require a separate license. Without a license, shared mailboxes are limited to 50 GB. To increase the size limit to 100 GB, the shared mailbox must be assigned an Exchange Online Plan 2 license. If Exchange Online Plan 1 license with an Exchange Online Archiving add-on license is assigned, this condition lets you enable auto-expanding archiving for additional archive storage capacity. Similarly, if you want to place a shared mailbox on litigation hold, the shared mailbox must have an Exchange Online Plan 2 license or an Exchange Online Plan 1 license with an Exchange Online Archiving add-on license. If you want to apply advanced features such as Microsoft Defender for Office 365, Microsoft Purview eDiscovery (Premium), or retention policies, the shared mailbox must be licensed for such feature(s).
Quelle: https://learn.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/exchange-online-limits#storage-limits

Das findet sich auch noch mal auf:


About shared mailboxes https://learn.microsoft.com/en-us/microsoft-365/admin/email/about-shared-mailboxes?view=o365-worldwide

In den allermeisten Fällen werden solche Postfächer unter 50 GB bleiben und sind daher nicht weiter zu beachten.

Shared Mailbox Account deaktivieren!

Im Hybrid Mode sollten Sie auch eine Shared Mailbox immer über das lokale AD anlegen. Seit  Exchange 2013 CU21 bzw. Exchange 2016 CU10 gibt es dazu beim "Enable-RemoteMailbox" auch extra den Parameter "-Shared".

Sie können aber auch direkt im Exchange Online Admin Center oder die Exchange Online PowerShell eine "CloudOnly"-Shared Mailbox anlegen. Dann gibt es dazu natürlich kein korrespondierendes Objekt im lokalen AD, was die Sichtbarkeit und Mailrouting für alle OnPremises-Dienste verhindert. Wenn aber alle Postfächer schon in der Cloud sind und auch das Mailrouting erst über Exchange Online erfolgt, dann kann das ein gültiges Setup sein.

Beachten Sie aber, dass eine CloudOnly-Shared Mailbox bei der Anlage über das Exchange Admin Center ein "aktives Konto" ist.

Nun ist es natürlich so, dass die Zugangsdaten zu diesem Konto niemandem bekannt sein sollten aber das verhindert dennoch keine Brute Force Attacke.

Wenn Sie eine Shared Mailbox über das lokale AD anlegen, dass ist ein deaktiviertes Konto. Keine Ahnung, warum Microsoft dies bei CloudOnly Konten anders handhabt.

Ich würde das Konto einer Shared Mailbox immer deaktivieren, um jegliche Versuche eines Zugriffs zu unterbinden.

Bei einem Cloud Only Konto können Sie dies direkt im Azure Portal (https://portal.azure.com) oder im Microsoft Admin Center (https://admin.microsoft.com/Adminportal/Home#/users) deaktivieren. In Verbindung mit ADSync ist das lokalen AD der richtige Ort.

Weitere Links