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

User Mailbox vs. Shared Mailbox in Exchange Online: Identität, Anmeldung, Lizenzierung und Zugriffskonzepte

In Exchange Online beschreibt „Mailbox“ zunächst nur den Speicher- und Funktionsumfang für E-Mails, Kalender und Kontakte. Die betriebliche Bedeutung entsteht jedoch erst durch die zugrunde liegende Identität in Microsoft Entra ID (Azure AD) sowie durch die Frage, ob und wie diese Identität interaktiv anmelden darf. Genau hier liegt der Kernunterschied zwischen User Mailbox (Benutzerpostfach) und Shared Mailbox (Freigegebenes Postfach): Beide können ähnlich wirken, sind aber für unterschiedliche Authentifizierungs- und Zugriffsmodelle konzipiert.

Identität und Objektmodell: Mailbox ist nicht gleich Benutzer

Eine User Mailbox ist an ein reguläres Benutzerobjekt gebunden, das typischerweise für genau eine natürliche Person steht. Dieses Benutzerobjekt ist grundsätzlich interaktiv anmeldbar, kann Tokens für verschiedene Dienste erhalten und trägt damit die üblichen Identitäts- und Sicherheitsanforderungen (Passwort, MFA, Conditional Access, Risikoauswertung).

Eine Shared Mailbox ist ebenfalls an ein Benutzerobjekt in Entra ID gekoppelt, jedoch mit anderer Semantik: Sie ist für Delegationszugriffe gedacht und nicht dafür, dass mehrere Personen sich direkt mit dieser Identität anmelden. In der Praxis wird sie deshalb über Berechtigungen (z. B. Full Access, Send As, Send on Behalf) in Clients wie Outlook oder über Exchange-APIs eingebunden. Dadurch bleiben Handlungen einzelnen Personen besser zuordenbar, obwohl ein gemeinsamer Kommunikationskanal genutzt wird. Wichtig in der Praxis: Je nach Client und Konfiguration sind nicht alle Aktionen in jedem Fall eindeutig einer Person zuzuordnen (z. B. bei bestimmten Ordnerzugriffen). Für belastbare Nachvollziehbarkeit müssen Mailbox Auditing und die relevanten Audit-Workloads im Tenant aktiv sein und die Auswertung sollte immer mit Sign-in- und Berechtigungsdaten korreliert werden.

Anmeldung und Authentifizierung: interaktive Sign-ins vs. Delegation

Die User Mailbox folgt dem Standardmodell „User sign-in“: Der Zugriff erfolgt über eine interaktive Anmeldung als genau dieses Konto. Damit entsteht technisch ein geteilter Sicherheitskontext, sobald mehrere Personen dieselben Anmeldedaten verwenden. Audit- und Sign-in-Protokolle zeigen dann nur noch die Identität des geteilten Kontos, nicht die handelnde Person.

Shared Mailboxes sind auf Delegation ausgelegt: Eine Person authentifiziert sich mit der eigenen Identität, und der Client greift anschließend aufgrund delegierter Rechte auf das Postfach zu. Moderne Authentifizierung (OAuth 2.0) arbeitet damit nicht „mit einem gemeinsamen Passwort“, sondern mit personenbezogenen Tokens und klarer Richtlinienanwendung pro Benutzer (Conditional Access, MFA, Gerätezustand). Der Zugriff auf das freigegebene Postfach wird durch Exchange-Berechtigungen autorisiert, nicht durch „gemeinsames Anmelden“. Hinweis: Eine Shared Mailbox kann technisch weiterhin für interaktive Anmeldungen genutzt werden, solange das zugrunde liegende Benutzerobjekt nicht gesperrt ist und eine passende Lizenz/Anmeldung möglich ist – fachlich ist das jedoch genau der Fehlgebrauch, den man vermeiden sollte.

• Interaktive Anmeldung (User Mailbox): Authentifizierung als Kontoinhaber, z. B. über https://outlook.office.com oder Outlook mit OAuth; die handelnde Person ist im Audit nur das Konto.
• Delegierter Zugriff (Shared Mailbox): Authentifizierung als eigene Person, Autorisierung über Exchange-Rechte wie FullAccess, SendAs oder SendOnBehalf.
• Automapping und Client-Verhalten: Outlook kann freigegebene Postfächer bei FullAccess automatisch einbinden; steuerbar u. a. über Add-MailboxPermission -AutoMapping $false. Hinweis: Änderungen am Automapping wirken nicht immer sofort in bestehenden Outlook-Profilen; häufig ist ein Profil-Refresh/Neuanlage oder das Entfernen/Neu-Hinzufügen der Berechtigung erforderlich.
• Programmgesteuerter Zugriff: Anwendungen sollten für Postfachzugriff bevorzugt App-Identitäten mit Application Permissions nutzen (z. B. Microsoft Graph) statt ein „Service-User“-Kennwort zu teilen; dies betrifft beide Postfachtypen, ist aber organisatorisch klarer von Shared Mailboxes abgrenzbar.

Lizenzierung in Exchange Online: wann eine Lizenz zwingend ist

Eine User Mailbox setzt eine Exchange Online-fähige Lizenz für das Benutzerkonto voraus. Ohne Lizenz lässt sich kein reguläres Benutzerpostfach bereitstellen oder betreiben. Die Lizenz hängt dabei nicht „am Postfach“, sondern am Benutzerobjekt, das die Service-Pläne aktiviert.

Shared Mailboxes können ohne Exchange Online-Lizenz betrieben werden, solange bestimmte Grenzen eingehalten werden. In der Praxis ist vor allem die Postfachgröße relevant: Überschreitet eine Shared Mailbox die lizenzfreien Kapazitätsgrenzen, wird eine Lizenz erforderlich, um das Wachstum zu ermöglichen. Außerdem können einzelne Zusatzfunktionen (z. B. Archivpostfach, Litigation Hold/Retention, eDiscovery- und Audit-Features) eine passende Lizenzierung erfordern – je nach Feature, Tenant-Konfiguration und den zugewiesenen Microsoft-365-/Purview-Plänen. Wichtig: „Lizenzfrei“ bedeutet nicht „ohne jede Einschränkung“; prüfen Sie vor dem Entzug einer Lizenz insbesondere Postfachgröße, Archivstatus und gesetzte Holds.

Zugriffsrechte und Delegationsmodelle: Berechtigungen statt Passwortweitergabe

Exchange trennt bei Shared Mailboxes sauber zwischen Lesen/Verwalten (Full Access) und Senden (Send As / Send on Behalf). Diese Trennung ist nicht kosmetisch, sondern steuert Datenzugriff und Außenwirkung getrennt. In gut gepflegten Umgebungen werden Rechte zudem über Gruppen vergeben, um Personwechsel ohne Rechtewildwuchs abzubilden.

Für den Betrieb bedeutet das: Eine Shared Mailbox benötigt in der Regel keine Anmeldeinformationen, sondern ein präzises Berechtigungsset. Das reduziert die Angriffsfläche, weil kein gemeinsam bekanntes Passwort existiert, und erhöht die Nachvollziehbarkeit, weil Zugriff und Versand an individuelle Identitäten gekoppelt bleiben.

• Mailbox-Berechtigungen (Lesen/Verwalten): Zuweisung über Add-MailboxPermission -Identity "team@domain.tld" -User "Gruppe-TeamMailbox" -AccessRights FullAccess.
• Sende-Berechtigungen (externe Absenderidentität): Zuweisung über Add-RecipientPermission -Identity "team@domain.tld" -Trustee "Gruppe-TeamMailbox" -AccessRights SendAs oder alternativ Set-Mailbox -Identity "team@domain.tld" -GrantSendOnBehalfTo "Gruppe-TeamMailbox".
• Gruppenbasierte Steuerung: Statt Einzelzuweisungen eine mailaktivierte Sicherheitsgruppe nutzen, z. B. New-DistributionGroup -Type Security, und die Mitgliedschaft über Join/Leave-Prozesse pflegen.
• Governance über Zugriffspfade: Zugriffe auf das Postfach über Outlook/OWA und delegierte Tokens; direkte Passwörter entfallen, wodurch Conditional Access auf die Personenidentität wirkt.

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

Beide Postfachtypen hängen am Entra-ID-Benutzerobjekt, unterscheiden sich aber in der Art, wie Lebenszyklusprozesse wirken. Bei User Mailboxes ist das Benutzerobjekt das zentrale Subjekt: Deaktivierung, Kennwortwechsel, MFA-Registrierung, Sperrung durch Identity Protection oder Conditional Access betreffen unmittelbar den Zugang. Wird ein Benutzerkonto als Funktionskonto missbraucht, kollidieren diese Mechanismen regelmäßig mit organisatorischen Erwartungen an „Dauerverfügbarkeit“.

Shared Mailboxes passen besser zu standardisierten Identitätskontrollen, weil das Postfach nicht „als Konto“ betrieben werden muss. Änderungen im Team werden über Gruppenmitgliedschaften und Delegationsrechte abgebildet; Sicherheitsrichtlinien greifen auf der persönlichen Identität. Das reduziert Seiteneffekte, etwa wenn ein Mitarbeiter ausscheidet: Es wird nur dessen Zugang entfernt, ohne dass ein Teamkanal durch Kontosperren, Passwortrotationen oder MFA-Resets unplanmäßig ausfällt.

Warum geteilte Benutzerkonten scheitern: Sicherheitslücken, fehlende Nachvollziehbarkeit, MFA-Umgehung, Offboarding- und Compliance-Probleme

Geteilte Benutzerkonten sind in Microsoft 365 meist als „Pragmatismus“ getarnt: Ein Konto wie info@ oder buchhaltung@ wird lizenziert, mit Passwort versehen und von mehreren Personen parallel in Outlook, mobil oder per Web genutzt. Technisch funktioniert das oft kurzfristig, organisatorisch und sicherheitlich erzeugt es jedoch eine Konstellation, die zentrale Schutzmechanismen von Entra ID (Azure AD) und Exchange Online aushebelt und die Verantwortlichkeit verwischt.

Der Kernfehler liegt im Identitätsmodell: Eine User Mailbox ist an eine eindeutige digitale Identität gekoppelt, inklusive Anmeldefähigkeit, Authentifizierung, Conditional Access und Audit-Trails. Wird diese Identität geteilt, werden nicht nur Postfachinhalte gemeinsam genutzt, sondern auch sämtliche Sicherheits- und Governance-Eigenschaften des Kontos. Damit kippt die Trennung zwischen „wer handelt“ und „welche Funktion wird bedient“.

Sicherheitslücken durch Passwortteilung und unscharfe Zugriffsgrenzen

Ein geteiltes Benutzerkonto zwingt fast immer zur Passwortweitergabe. Das widerspricht dem Grundprinzip personenbezogener Authentifizierung und erschwert die Durchsetzung von Passwort- und Sitzungsrichtlinien. Sobald mehrere Clients und Standorte dasselbe Konto verwenden, werden Risikoerkennung, Anomalie-Detektion und Reaktionsmaßnahmen (z. B. Sign-in Risk, Session Controls, Token-Widerruf) unpräziser, weil legitime und illegitime Nutzung kaum noch zu trennen ist.

Hinzu kommt, dass viele Schutzkonzepte auf der Annahme beruhen, dass ein Konto einer Person zugeordnet ist: Gerätekonformität (Intune), Named Locations, bedingter Zugriff pro Rolle oder Benutzergruppe. In geteilten Konten werden diese Kontrollen entweder so weit aufgeweicht, dass „alle irgendwie reinkommen“, oder sie erzeugen dauerhafte Störungen, weil sich unterschiedliche Arbeitsweisen, Geräte und Netze gegenseitig blockieren. Beides ist sicherheitlich problematisch.

• Unkontrollierte Verbreitung von Geheimnissen: Passwörter werden typischerweise in Chats, Dokumenten oder Passwortlisten geteilt; jede Kopie erhöht das Risiko von Abfluss und erschwert den Nachweis, wer Zugriff hatte.
• Brüchige Schutzlogik in Conditional Access: Richtlinien für ein Funktionskonto werden häufig „ausnahmsweise“ gelockert, etwa um heterogene Geräte zuzulassen; damit sinkt das Sicherheitsniveau für genau das Konto, das oft extern adressiert ist.
• Angriffsfläche durch Legacy-Clients und Protokolle: Sobald ein Teamkonto „überall funktionieren muss“, steigt der Druck, veraltete Zugriffswege zu tolerieren; konsequente Sperren für Altprotokolle und unsichere Authentifizierungsflüsse werden dadurch unterlaufen.

Fehlende Nachvollziehbarkeit: Audit, Verantwortlichkeit und Incident Response

Bei einem geteilten Benutzerkonto kollabiert die Zurechenbarkeit. Exchange-Aktionen (Lesen, Löschen, Verschieben, Regeln), Zugriffe auf SharePoint/Teams, sowie Sign-in-Events in Entra ID werden auf dieselbe Identität protokolliert. Selbst wenn technisch „etwas“ geloggt wird, bleibt die zentrale Frage offen: Welche Person hat konkret gehandelt? Diese Lücke wirkt sich direkt auf Incident Response und interne Ermittlungen aus, weil Hypothesen nicht belastbar verifiziert werden können.

Auch im operativen Alltag entstehen Reibungsverluste: Unklare Zuständigkeiten bei Kundenkommunikation, Doppelbearbeitung oder unbemerkte Löschvorgänge. In Postfächern mit hohem Durchsatz führt das zu Fehlentscheidungen, weil Kontext fehlt und Änderungen nicht einer Person zugeordnet werden können. Shared Mailboxes reduzieren dieses Problem über Delegation und „Send As/Send on behalf“, ohne Identitäten zu vermischen – vorausgesetzt, Berechtigungen werden sauber vergeben und Audit-Daten werden korrekt ausgewertet.

MFA-Umgehung und Authentifizierungs-Workarounds

Mehrpersonen-Nutzung kollidiert fast zwangsläufig mit Multi-Faktor-Authentifizierung. Ein Benutzerkonto kann zwar MFA nutzen, praktisch scheitert es jedoch daran, dass ein zweiter Faktor einer Person gehört (Authenticator-App, FIDO2-Key, SMS/Telefon). In der Folge entstehen typische Workarounds: ein gemeinsam genutzter Zweitfaktor, Weiterleitung von MFA-Prompts, „Notfall“-Ausnahmen in Conditional Access oder der Betrieb ohne starke Authentifizierung. Jeder dieser Wege schwächt die Sicherheitsarchitektur an einer Stelle, die häufig extern exponiert ist (öffentliche Mailadresse, Kontaktformulare, Rechnungsverkehr).

Besonders kritisch wird es, wenn Anmeldungen für Automationen oder Drittanwendungen „einfach über das Teamkonto“ umgesetzt werden. Damit werden langlebige Anmeldesitzungen oder unklare OAuth-Consent-Situationen begünstigt. Identitätsbasierte Steuerung wird so durch eine Mischung aus geteilten Geheimnissen und nicht sauber zuordenbaren Tokens ersetzt. App-Kennwörter sind in vielen Tenants bereits deaktiviert bzw. werden zunehmend unattraktiv, weil sie MFA umgehen und nur für Legacy-Flows gedacht sind.

• Gemeinsam genutzter Zweitfaktor: Ein geteilter FIDO2-Key oder eine gemeinsam installierte Authenticator-Instanz schafft einen Single Point of Failure und verhindert belastbare Personenzuordnung.
• Ausnahmen in Richtlinien: Wenn Conditional Access für das Konto entschärft wird (z. B. weniger strikte Device- oder Standortbedingungen), sinkt die Hürde für Account Takeover.
• Dauerhafte Sessions und Token-Risiken: Bei vielen parallelen Clients ist eine konsequente Sitzungskontrolle schwieriger; Token-Widerruf und Reauth-Trigger verlieren praktische Wirksamkeit, wenn die Nutzung nicht mehr personengebunden ist.

Offboarding-Blocker: Entzug von Zugriff wird zum Betriebsrisiko

Offboarding verlangt eindeutige Schritte: Konto sperren, Tokens widerrufen, Geräte abmelden, Berechtigungen entziehen, Postfachdaten regelkonform übergeben. Bei geteilten Benutzerkonten ist dieser Prozess kaum möglich, ohne den Betrieb zu unterbrechen. Ein Passwortwechsel sperrt alle Beteiligten aus, und es bleibt unklar, ob ehemalige Mitarbeitende das neue Passwort erneut erhalten. Gleichzeitig werden bestehende Sitzungen auf Geräten oder in Browsern durch Passwortwechsel nicht in jedem Fall sofort beendet, was in der Praxis zu unerwarteten Restzugriffen führen kann.

Außerdem wachsen geteilte Konten häufig in Rollen hinein: Sie besitzen Zugriffe auf Teams, SharePoint-Bibliotheken oder Drittportale, weil es „praktisch“ war, alles an einer Identität festzumachen. Damit wird Offboarding zu einem Such- und Bereinigungsprojekt, das selten vollständig gelingt. Delegationsmodelle mit Shared Mailboxes und berechtigungsbasiertem Zugriff pro Person vermeiden diese Kaskade.

Compliance- und Governance-Probleme: Policy-Umgehung, Datenzugriff und Aufbewahrung

Regulatorische Anforderungen und interne Policies setzen oft personenbezogene Verantwortlichkeit voraus: wer Daten verarbeitet, wer sie exportiert, wer Informationen löscht oder weiterleitet. Geteilte Konten unterlaufen diese Prinzipien. Selbst wenn Purview-Audit und Mailbox Auditing aktiv sind, wird die Auswertung erschwert, weil Aktionen nicht sicher einer Person zugeordnet werden können. Das gilt insbesondere bei sensiblen Bereichen wie HR, Finanzen oder rechtlicher Korrespondenz.

Auch Data Loss Prevention und Sensitivity Labels entfalten ihre Wirkung in Kombination aus Identität, Kontext und Richtlinie. Werden Nachrichten über ein geteiltes Konto versendet oder verarbeitet, verschiebt sich der Kontext: Policies, die an Benutzergruppen, Rollen oder Risikosignale geknüpft sind, greifen entweder zu hart (und werden aus „Betriebsgründen“ entschärft) oder zu weich (und lassen Abflüsse passieren). Im Ergebnis wird Governance nicht nur schwerer, sondern strukturell inkonsistent.

• Unklare Verantwortlichkeit in Audits: Exporte, Weiterleitungen und Löschaktionen sind einer Sammelidentität zugeordnet; die Beweisführung wird schwächer, auch bei aktiviertem Unified Audit Log.
• Policy-Konflikte bei Aufbewahrung: Retention und Litigation Hold lassen sich zwar technisch setzen, organisatorisch fehlt jedoch die klare Zuordnung, wer für Inhalte und Zugriffe verantwortlich ist.
• Risiko unautorisierter Datenverarbeitung: Wenn mehrere Personen mit derselben Identität arbeiten, kann der tatsächliche Berechtigungskreis nicht mehr sauber gegen Need-to-know abgegrenzt werden.

Entscheidung und Migration in der Praxis: Shared Mailboxes korrekt einrichten, User-Mailboxen umwandeln, Delegation sauber modellieren

Entscheidungskriterien: Wann Shared Mailbox, wann User-Mailbox?

Die Entscheidung sollte an fachlichen Verantwortlichkeiten und am erforderlichen Authentifizierungs- und Nachvollziehbarkeitsniveau ausgerichtet werden. Eine Shared Mailbox eignet sich für Rollen- oder Funktionskommunikation, bei der mehrere Personen im Auftrag eines Teams lesen und senden müssen, ohne dass ein eigenes, dauerhaftes Benutzer-Login benötigt wird. Eine User-Mailbox bleibt hingegen die korrekte Wahl, sobald ein Konto eigenständig authentifizieren muss, eine persönliche Identität abbildet oder eigenständige Workloads und Richtlinien (z. B. persönliche OneDrive-/Teams-Nutzung) gebunden werden.

Shared Mailbox korrekt einrichten: Objekt, Adressen, Zugriff

Technisch sollte die Shared Mailbox als eigenständiges Postfachobjekt geführt werden, mit klarer Namenskonvention, dokumentiertem Zweck und definiertem Owner-Kreis. Entscheidend ist die saubere Trennung zwischen Zugriffsrechten auf das Postfach (Lesen/Verwalten) und dem Recht, im Namen der Adresse zu senden. Für den Betrieb ist außerdem relevant, dass die Shared Mailbox nicht als „Anmeldekonto“ missverstanden wird: Zugriff erfolgt über Delegation durch eindeutig identifizierbare Benutzerkonten.

• Shared Mailbox anlegen: New-Mailbox -Shared -Name "Info" -DisplayName "Info" -Alias "info"
• Primäre SMTP und Aliase setzen: Set-Mailbox -Identity "Info" -EmailAddresses @{add="smtp:kontakt@domain.tld"} -PrimarySmtpAddress info@domain.tld
• Vollzugriff delegieren (ohne Auto-Mapping, wenn bewusst gesteuert): Add-MailboxPermission -Identity "Info" -User user@domain.tld -AccessRights FullAccess -AutoMapping $false
• Senden als (Send As): Add-RecipientPermission -Identity "Info" -Trustee user@domain.tld -AccessRights SendAs
• Senden im Auftrag (Send on behalf): Set-Mailbox -Identity "Info" -GrantSendOnBehalfTo @{add="user@domain.tld"}

In Outlook-Clients entstehen häufig Supportfälle durch uneinheitliches Auto-Mapping, insbesondere wenn mehrere Shared Mailboxes mit sehr großen Ordnerstrukturen eingebunden werden. In solchen Fällen ist eine bewusste Steuerung sinnvoll: Auto-Mapping deaktivieren und die Shared Mailbox gezielt als zusätzliches Konto bzw. zusätzliches Postfach hinzufügen. Damit bleiben Performance, Offline-Cache und Benutzererwartungen besser kontrollierbar.

Bestehende User-Mailbox in Shared Mailbox umwandeln: Vorgehen und Stolperfallen

Bei bereits existierenden Funktionsadressen als Benutzerpostfach muss die Migration priorisiert werden, sobald Passwortteilung, MFA-Ausnahmen oder unklare Verantwortlichkeiten im Spiel sind. Die Umwandlung erhält Inhalte (E-Mails, Ordner, Kalender) und schafft die Grundlage für Delegationsmodelle. Dennoch entstehen Abhängigkeiten, wenn das Konto außerhalb von Exchange „zweckentfremdet“ wurde, etwa für Anmeldungen an Drittanwendungen oder als Besitzer von Cloud-Ressourcen.

• Mailbox-Typ umstellen: Set-Mailbox -Identity "info@domain.tld" -Type Shared
• Delegationsrechte neu und namentlich zuweisen: Add-MailboxPermission -Identity "info@domain.tld" -User user@domain.tld -AccessRights FullAccess
Add-RecipientPermission -Identity "info@domain.tld" -Trustee user@domain.tld -AccessRights SendAs
• Direkte Anmeldung technisch unterbinden (Konto blockieren): Update-MgUser -UserId info@domain.tld -AccountEnabled:$false
• Lizenz nach Umstellung prüfen und ggf. entfernen: Get-MgUserLicenseDetail -UserId info@domain.tld
• Postfachgröße gegen Lizenzgrenzen abgleichen (bei Entzug der Lizenz): Get-ExoMailboxStatistics -Identity info@domain.tld | Select TotalItemSize

Das Blockieren der Anmeldung verhindert, dass erneut ein „Team-Login“ entsteht. Gleichzeitig bleibt das Objekt für Exchange erreichbar. Wo weiterhin SMTP-Authentifizierung oder App-Zugriffe erforderlich sind, sollte eine technische Neumodellierung erfolgen (z. B. moderne Authentifizierung über App-Registrierung, Connector, oder eine dedizierte, lizenzierte Service-Identität mit strengem Conditional Access). Ein Fortbestehen von Alt-Workflows darf nicht stillschweigend über das reaktivierte Benutzerkonto gelöst werden.

Delegationsmodell sauber modellieren: Rollen, Rechte, Nachvollziehbarkeit

Eine Shared Mailbox benötigt ein nachvollziehbares Betriebsmodell: Wer ist fachlicher Owner, wer darf lesen, wer darf senden, und wer verantwortet Regeln, Weiterleitungen und externe Freigaben? Ohne diese Trennung kippt die Konstruktion in einen informellen „Sammelpunkt“, der bei Personalwechseln oder Sicherheitsvorfällen kaum noch sauber aufzulösen ist. Für Audits und Incident Response ist außerdem relevant, ob im Namen der Shared Mailbox gesendet wird und wie diese Aktionen protokolliert werden.

• Rollen trennen: Owner (fachlich) und Administratoren (technisch) getrennt benennen; Owner steuert Mitgliedschaften, Admins steuern Richtlinien und Ausnahmefälle.
• Minimale Rechte vergeben: FullAccess nur für Bearbeitung im Postfach, SendAs nur, wenn Versand im Namen zwingend nötig ist; ansonsten -GrantSendOnBehalfTo für transparentere Absenderkennung.
• Gruppenbasiert delegieren: Rechte bevorzugt an Mail-aktivierte Sicherheitsgruppen binden, um Joiner/Mover/Leaver-Prozesse zu vereinfachen, statt Einzelberechtigungen zu pflegen.
• Regeln und Weiterleitungen kontrollieren: Inbox-Regeln und Weiterleitungen zentral reviewen; bei Bedarf per Get-InboxRule -Mailbox info@domain.tld dokumentieren und bereinigen.

Migrations-Checkliste: Bereinigung ohne Betriebsunterbrechung

Eine Umstellung gelingt mit paralleler Übergangsphase: Delegation einrichten, Client-Verhalten testen, Versandpfade validieren, danach erst die direkte Anmeldung blockieren und Lizenzierung bereinigen. Besondere Aufmerksamkeit verdienen Systeme, die fest ein Benutzerkonto erwarten (z. B. Multifunktionsgeräte, Legacy-Apps, externe Portale). Diese Abhängigkeiten sollten inventarisiert und ersetzt werden, bevor das Konto gesperrt wird. Andernfalls entstehen Schattenlösungen, die den ursprünglichen Fehlgebrauch reaktivieren.

• Abhängigkeiten inventarisieren: Anmeldungen in Anwendungen, SMTP-Clients, Besitz von Ressourcen; technische Indizien aus Sign-in-Logs und vorhandenen Dokumentationen zusammenführen.
• Parallelbetrieb testen: Zugriff über Delegation in Outlook, OWA und Mobilgeräten prüfen; Senden als info@domain.tld und Antworten auf bestehende Threads validieren.
• Direktanmeldung deaktivieren: Konto sperren (AccountEnabled $false), Passwortrotation und Entfernen von Legacy-Authentifizierungswegen, sofern noch vorhanden.
• Kommunikations- und Prozessanpassung: Dokumentierte Zuständigkeiten, Ticket-/CRM-Zuordnung, Signaturen und Vorlagen aktualisieren; keine personenbezogenen Daten in Funktionssignaturen.
• Offboarding-fähig machen: Zugriffe über Gruppenmitgliedschaften steuern, regelmäßige Review-Termine festlegen, damit bei Personalwechseln kein „verwaistes“ Postfach zurückbleibt.