Warum Benutzerpostfächer keine Team-Postfächer sein dürfen: Risiken beim Teilen von User-Konten in Exchange Online

User Mailbox und Shared Mailbox: Identität, Anmeldung, Lizenzierung und Zugriff sauber trennen

In Exchange Online beschreibt „Mailbox“ zunächst nur den Speicher- und Funktionsumfang für E-Mails, Kalender und Kontakte. Die betriebliche Bedeutung entsteht erst durch die zugehörige Identität in Entra ID sowie durch die Frage, ob und wie diese Identität interaktiv anmelden darf. Genau dort liegt der Kernunterschied zwischen User Mailbox und Shared Mailbox: Beide können für Anwender ähnlich aussehen, sind aber für unterschiedliche Verantwortungs- und Zugriffskonzepte konstruiert.

Identität und Objektmodell: Mailbox ist nicht gleich Benutzer

Eine User Mailbox gehört zu einem regulären Benutzerobjekt, das typischerweise genau eine natürliche Person abbildet. Dieses Konto kann sich interaktiv anmelden, Tokens für Microsoft-365-Dienste erhalten, Geräte registrieren und Richtlinien wie MFA, Conditional Access oder risikobasierte Anmeldung auslösen. Für persönliche Postfächer ist das korrekt. Für Funktionsadressen wird daraus ein Designfehler, sobald mehrere Personen dieselbe Identität nutzen.

Eine Shared Mailbox besitzt ebenfalls ein zugeordnetes Objekt, hat aber eine andere Aufgabe: Sie stellt einen gemeinsamen Kommunikationskanal bereit, ohne daraus ein gemeinsames Login zu machen. Die beteiligten Personen melden sich mit den eigenen Benutzerkonten an und erhalten anschließend delegierte Rechte auf das Postfach. So bleibt die Adresse gemeinsam nutzbar, während Authentifizierung, Richtlinien und Verantwortlichkeit personenbezogen bleiben.

Das ist kein magischer Audit-Beweis für jede einzelne Handlung. Client, Protokoll, Audit-Konfiguration und Workload entscheiden, wie detailliert ein Vorgang später ausgewertet werden kann. Trotzdem ist Delegation das deutlich bessere Grundmodell: Sie liefert wenigstens echte Benutzer-Sign-ins, echte Berechtigungsbeziehungen und eine belastbare Korrelation zwischen Person, Postfach und Aktion. Ein geteiltes Benutzerkonto liefert vor allem eine Ausrede: „Das war das Konto.“ Genau diese Ausrede ist im Betrieb wertlos.

Anmeldung und Authentifizierung: gemeinsames Passwort oder delegierter Zugriff

Die User Mailbox folgt dem Modell „User sign-in“: Der Zugriff erfolgt als genau dieses Konto. Nutzen mehrere Personen dieselben Anmeldedaten, entsteht ein geteilter Sicherheitskontext. Sign-in-Protokolle, Risikoereignisse, Sitzungskontrollen und viele Audit-Spuren zeigen dann das Konto, aber nicht zuverlässig die handelnde Person. Für eine persönliche Identität ist das Modell stark. Für eine geteilte Funktionsadresse ist es eine Fehlkonstruktion.

Bei einer Shared Mailbox authentifiziert sich jede Person mit dem eigenen Konto. Exchange erlaubt den Zugriff anschließend über Berechtigungen wie FullAccess, SendAs oder SendOnBehalf. Moderne Authentifizierung arbeitet damit nicht über ein gemeinsames Passwort, sondern über personenbezogene Tokens. Conditional Access, MFA, Gerätezustand und Risikosignale greifen auf die reale Person, nicht auf eine künstliche Sammelidentität.

Prüfen Sie bei jeder Shared Mailbox den Sign-in-Status des zugehörigen Kontos. Eine Shared Mailbox ist nicht für direkte Anmeldung vorgesehen; der Sign-in sollte blockiert bleiben. Das gilt besonders nach der Umwandlung einer früheren User Mailbox. Bleibt ein altes Kennwort aktiv, ist die Migration nur halb erledigt: Das Postfach heißt dann zwar „shared“, die alte Fehlkonstruktion lebt aber weiter.

• Interaktive Anmeldung bei User Mailboxes: Die Person arbeitet als Kontoinhaber. Bei geteilter Nutzung verschwindet die echte Person hinter der Sammelidentität.
• Delegierter Zugriff bei Shared Mailboxes: Die Person meldet sich selbst an; Exchange gewährt Zugriff über Postfachrechte und Senderechte.
• Automapping in Outlook: Vollzugriff kann freigegebene Postfächer automatisch ins Outlook-Profil einbinden. Bei vielen oder großen Shared Mailboxes wird daraus schnell ein Performance- und Supportthema.
• Programmgesteuerter Zugriff: Anwendungen, Scanner, Skripte und Drittportale sollten nicht über ein geteiltes Benutzerkennwort laufen. Prüfen Sie App-Registrierungen, Graph-Berechtigungen, SMTP-Relay, Connectoren oder sauber abgegrenzte Service-Identitäten.

Lizenzierung in Exchange Online: „lizenzfrei“ ist kein Freifahrtschein

Eine User Mailbox benötigt eine Exchange-Online-fähige Lizenz für das Benutzerkonto. Die Lizenz aktiviert die entsprechenden Service-Pläne am Benutzerobjekt. Wird eine Funktionsadresse als Benutzerpostfach betrieben, zahlen Sie also nicht nur für die falsche Konstruktion, sondern stabilisieren sie organisatorisch auch noch: Das Konto erscheint wie ein normaler Benutzer, obwohl es keine normale Benutzeridentität ist.

Eine Shared Mailbox kann ohne eigene Exchange-Online-Lizenz betrieben werden, solange die Microsoft-Grenzen und Feature-Voraussetzungen eingehalten werden. Die wichtigste harte Grenze ist die Postfachgröße: Ohne Lizenz ist eine Shared Mailbox auf 50 GB begrenzt. Für 100 GB, Archivpostfächer, auto-expanding archive, Litigation Hold oder bestimmte Compliance-Szenarien kann eine passende Exchange-Online- oder Microsoft-365-Lizenz erforderlich sein.

Der häufigste Denkfehler lautet: „Shared Mailbox ist lizenzfrei, also brauchen wir keine Lizenzen.“ Das ist falsch. Die zugreifenden Personen benötigen weiterhin geeignete Lizenzen. Nur das Shared-Mailbox-Objekt selbst kommt unter bestimmten Bedingungen ohne eigene Lizenz aus. Prüfen Sie deshalb vor einem Lizenzentzug nicht nur den Mailbox-Typ, sondern auch Größe, Archivstatus, Holds, Aufbewahrungsvorgaben und die tatsächlich genutzten Zusatzfunktionen.

Zugriffsrechte und Delegationsmodelle: Rechte sauber trennen, statt Passwörter zu verteilen

Exchange trennt Lesen und Verwalten von der Absenderrolle. FullAccess erlaubt das Öffnen und Bearbeiten des Postfachs, aber keinen Versand. Für Versand benötigen Benutzer zusätzlich SendAs oder SendOnBehalf. Diese Trennung ist entscheidend: Sie steuert nicht nur Zugriff auf Inhalte, sondern auch Außenwirkung, Haftung und spätere Rekonstruktion.

SendAs lässt eine Nachricht so erscheinen, als komme sie direkt von der Funktionsadresse. Das ist für zentrale Adressen wie support@ oder rechnung@ oft fachlich gewollt. SendOnBehalf macht dagegen sichtbar, dass eine Person im Auftrag der Adresse sendet. Für interne Rollen, Stellvertretung und sensiblere Prozesse kann das die ehrlichere Variante sein. Entscheiden Sie diese Frage nicht nach Bequemlichkeit, sondern nach Außenwirkung und Nachvollziehbarkeit.

• Lesen und Bearbeiten: Vergeben Sie FullAccess nur an Personen oder Gruppen, die Inhalte tatsächlich bearbeiten müssen.
• Versand als Funktion: Nutzen Sie SendAs, wenn die Funktionsadresse als einheitlicher Absender auftreten soll.
• Transparenter Versand: Nutzen Sie SendOnBehalf, wenn Empfänger erkennen sollen, welche Person im Auftrag handelt.
• Gruppenbasierte Steuerung: Binden Sie Rechte bevorzugt an mailaktivierte Sicherheitsgruppen, damit Joiner-, Mover- und Leaver-Prozesse nicht an Einzelberechtigungen scheitern.

Abhängigkeiten zu Entra ID: Lebenszyklus, Richtlinien und Zustandswechsel

Bei User Mailboxes ist das Benutzerobjekt das zentrale Subjekt: Deaktivierung, Kennwortwechsel, MFA-Registrierung, Sperrung durch Risikoerkennung, Gerätekonformität oder Conditional Access betreffen unmittelbar den Zugang. Wird ein Benutzerkonto als Funktionskonto missbraucht, kollidieren diese Mechanismen mit der Erwartung, dass die Adresse immer erreichbar bleibt. Genau daraus entstehen die typischen Ausnahmen: MFA lockern, Standorte erlauben, Geräteanforderungen senken, alte Clients weiter dulden.

Shared Mailboxes passen besser zu einem sauberen Lebenszyklusmodell. Das Postfach bleibt als Kommunikationskanal bestehen, während Zugriffe über Gruppenmitgliedschaften und delegierte Rechte gesteuert werden. Verlässt eine Person das Unternehmen, entfernen Sie deren Mitgliedschaft, widerrufen Sitzungen und prüfen relevante Geräte. Sie müssen nicht das Kennwort eines Teamkontos ändern und anschließend hoffen, dass es nicht wieder in einem Chat landet.

Warum geteilte Benutzerkonten scheitern: Sicherheitsbruch, Audit-Loch, MFA-Umgehung und Compliance-Schaden

Geteilte Benutzerkonten werden fast immer mit Pragmatismus begründet: „Das braucht die Buchhaltung“, „der Scanner kann das nur so“, „die Adresse muss für alle funktionieren“. Diese Begründungen erklären den Druck im Alltag, rechtfertigen aber nicht die Konstruktion. Ein Konto wie info@ oder buchhaltung@ als lizenziertes Benutzerkonto mit gemeinsamem Kennwort zu betreiben, ist kein moderner Microsoft-365-Betrieb, sondern eine technische Altlast mit Ansage.

Der Kernfehler liegt im Identitätsmodell. Microsoft 365 baut Schutz, Protokollierung und Richtlinien auf eindeutigen Identitäten auf. Sobald mehrere Personen dieselbe Identität nutzen, brechen diese Annahmen. Dann wird nicht nur ein Postfach geteilt, sondern auch der komplette Sicherheitskontext: Passwort, MFA-Verhalten, Sitzungen, Tokens, Gerätebezug, Audit-Spuren und Risikoauswertung.

Sicherheitslücken durch Passwortteilung und unscharfe Zugriffsgrenzen

Ein geteiltes Benutzerkonto erzwingt fast immer Passwortweitergabe. Das Kennwort landet in Passwortmanagern mit Gruppenfreigabe, in Onboarding-Dokumenten, in Chats, auf Notizzetteln oder in Browserprofilen. Jede Kopie erweitert den tatsächlichen Berechtigungskreis. Spätestens nach einer Personaländerung weiß niemand mehr belastbar, wer das Geheimnis kennt oder auf welchem Gerät noch eine gültige Sitzung existiert.

Conditional Access verliert an Schärfe, wenn ein Konto von unterschiedlichen Personen, Geräten, Standorten und Arbeitsweisen genutzt wird. Entweder blockieren die Regeln legitime Nutzung, oder Verantwortliche bauen Ausnahmen ein. Diese Ausnahmen treffen häufig ausgerechnet Konten mit hoher Außenwirkung: öffentliche Kontaktadressen, Rechnungspostfächer, Bewerbungsadressen oder Supportkanäle. Ein Angreifer findet dort nicht nur Zugang, sondern oft auch sensible Kommunikation und laufende Geschäftsprozesse.

• Unkontrollierte Geheimnisverbreitung: Jedes geteilte Kennwort wird früher oder später kopiert, gespeichert oder weitergereicht. Danach ist Zugriffsentzug nur noch Theorie.
• Verwässerte Richtlinien: MFA, Gerätekonformität und Standortbedingungen werden häufig abgeschwächt, damit das Fehlmodell arbeitsfähig bleibt.
• Legacy-Druck: Scanner, alte Clients oder Drittanwendungen dienen als Vorwand, unsichere Anmeldewege länger zu dulden.
• Falsches Sicherheitsgefühl: Das Konto hat vielleicht ein starkes Passwort und MFA, aber keine belastbare Personenzuordnung.

Fehlende Nachvollziehbarkeit: Audit ohne Verantwortlichen ist zu wenig

Bei einem geteilten Benutzerkonto kollabiert die Zurechenbarkeit. Exchange-Aktionen wie Lesen, Löschen, Verschieben, Regeländerungen, Export oder Versand hängen an derselben Sammelidentität. Selbst wenn Audit-Logs vorhanden sind, bleibt die zentrale Frage offen: Welche Person hat gehandelt? Für Incident Response ist das fatal. Sie können dann Zeitpunkte, IP-Adressen und Clients diskutieren, aber die Verantwortung bleibt unscharf.

Eine Shared Mailbox löst nicht jedes forensische Detailproblem, setzt aber an der richtigen Stelle an. Personen melden sich mit eigenen Konten an, Berechtigungen sind nachvollziehbar vergeben, und Aktionen lassen sich besser mit Sign-in-Events, Delegationsrechten und Mailbox-Audit-Daten korrelieren. Damit entsteht kein perfektes Protokollmärchen, aber ein wesentlich belastbarerer Untersuchungsansatz als bei einem Passwort, das „das Team“ kennt.

MFA-Umgehung und Authentifizierungs-Workarounds

Multi-Faktor-Authentifizierung ist personenbezogen gedacht. Ein zweiter Faktor gehört einer Person, einem kontrollierten Gerät oder einem klar zugeordneten Hardwaretoken. Bei einem geteilten Benutzerkonto entsteht deshalb sofort ein Konflikt: Entweder alle greifen auf denselben zweiten Faktor zu, oder das Konto bekommt Ausnahmen. Beides ist ein Armutszeugnis für die Architektur, nicht ein technischer Sonderfall.

Die typischen Workarounds sind bekannt: Authenticator-App auf einem Teamgerät, SMS an eine Sammelnummer, FIDO2-Schlüssel im Schrank, weitergeleitete MFA-Prompts oder Conditional-Access-Ausnahmen für bestimmte Standorte. Solche Lösungen mögen den Tagesbetrieb retten, aber sie verschieben das Risiko in genau die Konten, über die häufig Kundenkommunikation, Rechnungen, Bewerbungen oder Supportdaten laufen.

• Gemeinsamer Zweitfaktor: Ein geteilter Schlüssel oder ein gemeinsam genutztes Authenticator-Gerät verhindert echte Personenzuordnung.
• Notfall-Ausnahmen: Ausnahmen werden selten sauber zurückgebaut und entwickeln sich zu dauerhaften Sicherheitslöchern.
• Dauerhafte Sessions: Viele parallele Clients erschweren Token-Widerruf, Reauthentifizierung und Sitzungskontrolle.
• OAuth-Unschärfe: Drittanwendungen können Zustimmungen oder Tokens an eine Sammelidentität binden, die später niemand mehr verantwortet.

Offboarding-Blocker: Zugriffsentzug darf kein Betriebsrisiko sein

Sauberes Offboarding verlangt eindeutige Schritte: Benutzerkonto sperren, Tokens widerrufen, Geräte abmelden, Gruppenmitgliedschaften entfernen, Berechtigungen entziehen und Daten geordnet übergeben. Bei geteilten Benutzerkonten wird daraus ein Widerspruch. Sperren Sie das Konto, trifft es alle. Ändern Sie nur das Passwort, bleiben alte Sitzungen, gespeicherte Zugangsdaten und unbekannte Kopien ein Problem. Geben Sie das neue Passwort weiter, beginnt der Fehler von vorn.

Besonders gefährlich wird es, wenn das Funktionskonto im Laufe der Jahre zusätzliche Rollen bekommen hat: Besitzer eines Teams, Zugriff auf SharePoint-Bibliotheken, Anmeldung an Drittportalen, SMTP-Konto für Scanner, API-Zugriff für eine Fachanwendung oder Notfallkonto für eine Abteilung. Dann ist die Shared-Mailbox-Migration nicht nur ein Exchange-Thema, sondern eine Bereinigung von Schattenarchitektur. Genau deshalb muss der Ton hier deutlich sein: Verantwortliche, die solche Konstruktionen dulden, verschieben Betriebsschulden in die Zukunft.

Compliance und Governance: Sammelidentitäten zerstören Verantwortlichkeit

Regulatorische Vorgaben und interne Policies setzen Verantwortlichkeit voraus: Wer hat personenbezogene Daten verarbeitet? Wer hat Informationen exportiert? Wer hat eine Nachricht gelöscht, weitergeleitet oder an externe Empfänger gesendet? Geteilte Konten unterlaufen diese Fragen. Sie erzeugen keine bessere Zusammenarbeit, sondern eine Grauzone im Berechtigungs- und Nachweismodell.

Auch DLP-Richtlinien, Sensitivity Labels und risikobasierte Kontrollen wirken im Zusammenspiel aus Identität, Rolle, Kontext und Datenklassifizierung. Wird über ein geteiltes Konto gearbeitet, verschiebt sich dieser Kontext. Regeln greifen entweder zu streng und werden „aus Betriebsgründen“ entschärft, oder sie greifen zu weich und lassen Datenabflüsse passieren. Das Ergebnis ist nicht nur unsauber, sondern strukturell inkonsistent.

• Unklare Verantwortlichkeit: Exporte, Weiterleitungen und Löschaktionen hängen an einer Sammelidentität, nicht an einer Person.
• Schwacher Need-to-know-Nachweis: Der tatsächliche Zugriffskreis ist größer als dokumentiert und schwer rekonstruierbar.
• Problematische Aufbewahrung: Retention und Holds können technisch gesetzt sein, ohne dass Verantwortlichkeiten und Zugriff sauber geklärt sind.
• Schlechtere Incident Response: Die Untersuchung verliert Zeit, weil Identität, Gerät, Person und Zweck nicht sauber zusammenfallen.

Entscheidung und Migration in der Praxis: Fehlkonstruktion beseitigen, ohne neue Schattenlösungen zu schaffen

Entscheidungskriterien: Shared Mailbox, User Mailbox, Gruppe oder Service-Identität?

Die richtige Lösung ergibt sich nicht aus der E-Mail-Adresse, sondern aus dem Zweck. Geht es um eine gemeinsame Kommunikationsadresse, ist eine Shared Mailbox meist naheliegend. Geht es um reine Verteilung ohne gemeinsames Archiv, reicht oft eine Verteilergruppe. Geht es um Zusammenarbeit mit Gruppenpostfach, Kalender, Dateien und Team-Kontext, kann eine Microsoft 365 Group sinnvoller sein. Muss ein technisches System authentifizieren, brauchen Sie ein sauberes App- oder Service-Modell – nicht das Passwort einer Funktionsadresse.

Shared Mailbox korrekt einrichten: klare Adresse, klarer Owner, klare Rechte

Beginnen Sie nicht mit PowerShell, sondern mit dem Betriebsmodell. Eine Shared Mailbox braucht einen dokumentierten Zweck, einen fachlichen Owner, eine klare Namenskonvention und definierte Rechte. Sonst ersetzen Sie nur eine schlechte Konstruktion durch eine etwas modernere Unordnung. Legen Sie fest, wer Inhalte bearbeiten darf, wer senden darf, wer Regeln und Weiterleitungen verantwortet und wie Zugriffe regelmäßig geprüft werden.

Auch die Adresslogik verdient Sorgfalt. Eine primäre SMTP-Adresse wie info@domain.tld sollte eindeutig sein; Aliase wie kontakt@domain.tld oder office@domain.tld brauchen fachlichen Sinn und sollten nicht unkontrolliert wachsen. Jede zusätzliche Adresse vergrößert die Angriffs- und Zuständigkeitsfläche. Prüfen Sie deshalb, welche Adresse nach außen kommuniziert wird und welche Aliase historischer Ballast sind.

• Zweck dokumentieren: Beschreiben Sie, wofür die Adresse genutzt wird und welche Daten typischerweise im Postfach landen.
• Owner benennen: Ordnen Sie fachliche Verantwortung einer Rolle oder Personengruppe zu, nicht nur der IT.
• Zugriffsgruppen definieren: Trennen Sie Lese-/Bearbeitungsrechte von Senderechten und pflegen Sie Mitgliedschaften über Gruppen.
• Sign-in blockieren: Eine Shared Mailbox darf nicht als direktes Benutzerlogin weiterleben.
• Regeln prüfen: Kontrollieren Sie Inbox-Regeln, Weiterleitungen und automatische Antworten, bevor das Postfach produktiv wird.

PowerShell bleibt ein Werkzeug, nicht der Kern des Artikels. Für die Praxis reichen meist wenige Befehle, um Einrichtung und Migration sauber zu kontrollieren. Entscheidend ist nicht, jede Option auswendig zu kennen, sondern falsche Kombinationen zu vermeiden: FullAccess ersetzt kein Senderecht, Auto-Mapping ist bewusst zu steuern, und SMTP-Aliase sollten nicht nebenbei in derselben Hektik wie die Berechtigungen gesetzt werden.

• Shared Mailbox anlegen: New-Mailbox -Shared -Name "Info" -DisplayName "Info" -Alias "info" -PrimarySmtpAddress info@domain.tld
• Alias ergänzen: Set-Mailbox -Identity "info@domain.tld" -EmailAddresses @{add="smtp:kontakt@domain.tld"}
• Vollzugriff vergeben: Add-MailboxPermission -Identity "info@domain.tld" -User "gruppe-info-mailbox@domain.tld" -AccessRights FullAccess -InheritanceType All
• Senderecht vergeben: Add-RecipientPermission -Identity "info@domain.tld" -Trustee "gruppe-info-sendas@domain.tld" -AccessRights SendAs

Outlook, Auto-Mapping und Client-Verhalten: nicht jede Bequemlichkeit ist betrieblich gut

Auto-Mapping ist bequem, solange wenige freigegebene Postfächer mit überschaubarer Größe eingebunden werden. In Umgebungen mit vielen Shared Mailboxes oder großen Ordnerstrukturen kann es zum Supporttreiber werden: Outlook-Profile laden zu viel, die Suche wirkt träge, Offline-Caches wachsen, und Anwender sehen Postfächer, die sie fachlich kaum nutzen. Steuern Sie Auto-Mapping deshalb bewusst und testen Sie Outlook Desktop, Outlook im Web und mobile Clients getrennt.

Soll Auto-Mapping deaktiviert werden, reicht es in bestehenden Umgebungen oft nicht, nur eine neue Berechtigung mit -AutoMapping $false zu setzen. In der Praxis müssen Berechtigungen häufig entfernt und neu gesetzt werden; bestehende Outlook-Profile benötigen manchmal einen Neuaufbau oder eine gezielte Bereinigung. Das ist kein Detail für Perfektionisten, sondern relevant für die Akzeptanz der Migration.

Bestehende User Mailbox umwandeln: nicht nur klicken, sondern Abhängigkeiten freilegen

Bestehende Funktionsadressen als Benutzerpostfach sollten priorisiert bereinigt werden, sobald Passwortteilung, MFA-Ausnahmen oder unklare Verantwortlichkeiten im Spiel sind. Die Umwandlung in eine Shared Mailbox erhält Inhalte wie E-Mails, Ordner und Kalender und schafft die Grundlage für Delegation. Sie beseitigt aber nicht automatisch alle Altlasten. Wenn das Konto für Scanner, Drittportale, Skripte, Teams, SharePoint oder App-Zustimmungen missbraucht wurde, müssen diese Abhängigkeiten getrennt gelöst werden.

Inventarisieren Sie vor der Umstellung, wo das Konto tatsächlich verwendet wird. Prüfen Sie Anmeldeprotokolle, Geräte, OAuth-Zustimmungen, Weiterleitungen, Inbox-Regeln, Transportregeln, mobile Geräte und Fachanwendungen. Gerade alte Multifunktionsgeräte und Branchenanwendungen sind häufig der Grund, warum ein Fehlmodell jahrelang überlebt. Der richtige Schluss ist nicht, die Shared Mailbox weiter direkt anmelden zu lassen, sondern den technischen Versandpfad sauber zu ersetzen.

• Mailbox-Typ umstellen: Set-Mailbox -Identity "info@domain.tld" -Type Shared
• Postfachgröße prüfen: Get-EXOMailboxStatistics -Identity info@domain.tld | Select-Object TotalItemSize
• Weiterleitungen prüfen: Get-Mailbox -Identity info@domain.tld | Select-Object ForwardingAddress,ForwardingSmtpAddress,DeliverToMailboxAndForward
• Direkte Anmeldung blockieren: Blockieren Sie den Sign-in des zugehörigen Kontos im Microsoft-365-Admincenter oder über Microsoft Graph.

Entziehen Sie die Lizenz nicht reflexartig direkt nach der Umwandlung. Prüfen Sie zuerst, ob die Shared Mailbox unter 50 GB bleibt, ob ein Archivpostfach aktiv ist, ob Litigation Hold, Retention oder eDiscovery-Anforderungen bestehen und ob Zusatzfunktionen an der Lizenz hängen. Lizenzbereinigung ist sinnvoll, aber nicht der Beweis einer erfolgreichen Migration. Der Beweis ist, dass keine Person und kein System mehr das alte Konto direkt nutzt.

Delegationsmodell sauber modellieren: Owner, Gruppen, Regeln und Reviews

Eine Shared Mailbox braucht ein Betriebsmodell, sonst kippt sie in den nächsten informellen Sammelpunkt. Trennen Sie fachliche Owner von technischen Administratoren. Der Owner verantwortet Zweck, Mitgliedschaften und Dateninhalt. Die IT setzt Rechte, Richtlinien, Audit-Anforderungen und technische Grenzen um. Ohne diese Trennung bleibt unklar, wer bei Datenabfluss, falscher Weiterleitung oder veralteten Zugriffsrechten entscheidet.

• Owner festlegen: Benennen Sie eine fachliche Rolle, die Zugriff, Zweck und Dateninhalt verantwortet.
• Rechte trennen: Führen Sie getrennte Gruppen für Lesen/Bearbeiten und Senden, wenn der Berechtigungskreis unterschiedlich ist.
• Regeln reviewen: Prüfen Sie Weiterleitungen, Inbox-Regeln und automatische Antworten regelmäßig, besonders nach Personalwechseln.
• Audit einplanen: Verlassen Sie sich nicht auf Bauchgefühl. Prüfen Sie, welche Audit-Events im Tenant tatsächlich verfügbar und auswertbar sind.
• Rezertifizierung durchführen: Lassen Sie Owner regelmäßig bestätigen, wer noch Zugriff braucht und wer entfernt werden muss.

Migrations-Checkliste: Bereinigung ohne Betriebsunterbrechung

Eine saubere Umstellung arbeitet mit einer kontrollierten Übergangsphase: Delegation einrichten, Client-Verhalten testen, Versandpfade prüfen, technische Abhängigkeiten ersetzen, danach direkte Anmeldung blockieren und Lizenzierung bereinigen. Die Reihenfolge ist wichtig. Sperren Sie zu früh, fällt der Betrieb möglicherweise aus. Warten Sie zu lange, bleibt der alte Fehlgebrauch bestehen und wird beim nächsten Problem wieder zur Ausrede.

Die richtige Zielarchitektur: Personen, Funktionen und Systeme getrennt behandeln

Die saubere Zielarchitektur ist eindeutig: Personen melden sich mit persönlichen Konten an. Funktionsadressen laufen als Shared Mailbox, Verteilergruppe oder passende Gruppenlösung. Technische Systeme erhalten eigene, kontrollierte Zugriffspfade. Diese Trennung ist kein akademisches Ideal, sondern betriebliche Hygiene. Sie verhindert, dass ein Postfach, ein Kennwort und eine Sammelidentität zum gemeinsamen Ausweichkanal für alles werden, was vorher nicht sauber geplant wurde.

Geteilte Benutzerkonten für Funktionsadressen sind keine kleine Unschärfe und kein liebenswerter Admin-Trick aus alten Zeiten. Sie sind eine Fehlkonstruktion, die Verantwortliche bewusst beseitigen sollten. Exchange Online liefert mit Shared Mailboxes, Gruppen, Delegationsrechten, moderner Authentifizierung und Audit-Funktionen die besseren Bausteine. Nutzen Sie sie konsequent, sonst bleibt das Risiko nicht technisch abstrakt, sondern wird beim nächsten Offboarding, Sicherheitsvorfall oder Audit sehr konkret.