Kurzüberblick

grommunio 2026.06.1 bringt ein reales Organizations- und Domain-Modell mit. In der Praxis lassen sich mehrere Organisationen mit eigenen Domains, eigenen Benutzern und eigenen LDAP-Quellen betreiben. Dieser Beitrag ordnet ein, wo diese Trennung belastbar ist, wo zusätzliche Härtung nötig wird und für welche Betriebsmodelle das ausreicht.

Das Ergebnis ist bewusst weder ein pauschales „nicht mandantenfähig“ noch ein pauschales „voll mandantenfähig“. grommunio kann mehrere organisatorische Einheiten unter einem gemeinsamen Betreiber sinnvoll abbilden. Für unabhängige MSP- oder Hosting-Kunden auf einer unveränderten gemeinsamen Control Plane bleiben jedoch Grenzen, die architektonisch berücksichtigt werden müssen.

Getestete Grundlage

Geprüft wurde eine frische grommunio Appliance 2026.06.1. Die Appliance wurde nach dem vorherigen Meet-Lab als technische Basis weiterverwendet, vor den Multitenancy-Änderungen gesichert und anschließend mit drei Organisationen aufgebaut: Tenant A mit Directory A, Tenant B mit Directory B und Tenant C mit lokalen Benutzern.

Die beiden externen Directories waren nur die Directory-Basis. Entscheidend war danach der Nachweis in grommunio selbst: Organization A verwendet Directory A, Organization B verwendet Directory B, lokale Benutzer in Organization C bleiben getrennt, und Such-, Import- und Downsync-Aktionen greifen nicht versehentlich in die fremde Organisation.

Multitenancy auf einen Blick

Die Organization- und Domain-Multitenancy von grommunio gilt nicht automatisch für jeden angebundenen Collaboration-Dienst. Einige Komponenten besitzen eigene Identity-, Daten-, Policy- und Administrationsmodelle. Die folgende Übersicht ist deshalb die wichtigste Entscheidungshilfe für Architektur und Betrieb.

Core Mail
Einordnung
Gemeinsam möglich, aber mit Härtung für Sender, Delegation, Listen, Logs und Restore.
LDAP
Einordnung
Getrennt pro Organization möglich; jede Organization kann eine eigene Directory-Quelle verwenden.
Admin
Einordnung
Gemeinsam mit Einschränkungen; globale Metadaten und Logs bleiben Betreiberbereiche.
Web/GAL
Einordnung
Gemeinsam mit Einschränkungen; Webmail und GAL müssen über eindeutige Benutzer-, Domain- und Organization-Zuordnung geprüft werden.
Calendar
Einordnung
Gemeinsam mit Einschränkungen; eigene Kalender funktionieren, Fremdzugriffe liefern keine Eventdetails, brauchen aber saubereres Fehlerverhalten.
Public Folders
Einordnung
Gemeinsam mit Einschränkungen; Root-Trennung ist plausibel, konkrete Berechtigungsmodelle bleiben produktionsrelevant.
Shared Mailboxes / Distribution Lists
Einordnung
Gemeinsam mit Einschränkungen; Cross-Tenant-Empfänger, Delegation und Send-As müssen ausdrücklich kontrolliert werden.
MDM / ActiveSync
Einordnung
ActiveSync funktioniert grundsätzlich als gemeinsamer Dienst; vollständige Device-Lifecycle-Isolation zwischen Organizations bleibt zu validieren.
Webmail + grommunio-auth
Einordnung
Gemeinsam möglich, wenn vollständige Mailadresse, Claims, Domain und Organization eindeutig zusammenpassen.
Keycloak/Auth
Einordnung
Gemeinsamer Realm ist möglich, aber keine automatische Tenant-Isolation; für unabhängige Kunden getrennte Realms, IdPs oder Entry-Points bevorzugen.
Rspamd
Einordnung
Shared Service; für MSP-Kunden getrennte Policy-, History-, Bayes- und Controller-Ebene oder dedizierte Instanz empfehlen.
Archive
Einordnung
Domainmodell vorhanden, aber keine automatische grommunio-Organization-Isolation nachgewiesen; für MSP dediziert empfehlen.
Meet
Einordnung
Shared Jitsi/Prosody-Dienst; Isolation kommt aus Auth, Raum-, Guest-, Lobby- und Moderator-Policy, nicht automatisch aus Organizations.
Chat
Einordnung
Gemeinsamer Workspace/Backend ohne automatische Organization-Tenancy; Team-, Domain- oder Gruppen-Isolation bewusst planen.
Files
Einordnung
User-, Gruppen- und Share-Modell; keine automatische Organization-Zuordnung nachgewiesen, daher explizite Isolation oder dedizierte Instanz.
Office
Einordnung
Gemeinsamer WOPI/Office-Dienst möglich; die Sicherheitsgrenze liegt vor allem bei Files und WOPI-Tokens.

Organizations, Domains und Benutzer

Die zentrale Mandantenstruktur entsteht über Organizations und Domains. Domains werden einer Organization zugeordnet, Benutzer gehören damit zu einer klaren administrativen Einheit. Identische Namen in verschiedenen Organisationen sind technisch handhabbar, solange die Zuordnung über Organization, Domain und eindeutige Objekte erfolgt.

Organizations
Einordnung
Mehrere Organisationen können parallel verwaltet werden.
Domains
Einordnung
Domains lassen sich Organisationen zuordnen und begrenzen Benutzerkontext.
Benutzer
Einordnung
Gleichnamige Benutzer in unterschiedlichen Organisationen verursachten keine falsche Zuordnung.
Scoped Admins
Einordnung
Organisation-/Domain-Admins sehen operative Bereiche eingeschränkt, globale Metadaten bleiben aber nicht vollständig verborgen.

Mehrere LDAP-Quellen pro Organisation

Der wichtigste positive Befund ist die per-Organization-LDAP-Konfiguration. Organization A kann gegen Directory A synchronisieren, Organization B gegen Directory B. Die relevanten Admin-Kommandos werden mit der tatsächlich vorhandenen Syntax und der Option für die jeweilige Organisation ausgeführt.

bash
grommunio-admin ldap info -o <organization>
grommunio-admin ldap search -o <organization> <suchbegriff>
grommunio-admin ldap dump -o <organization>
grommunio-admin ldap downsync -o <organization>
grommunio-admin ldap check -o <organization>
grommunio-admin ldap reload -o <organization>

Im Test wurden Organization A und Organization B jeweils gegen ihre eigene Directory-Quelle geprüft. Suchen, Dumps, Downsyncs, Checks und Reloads blieben auf die gewählte Organization bezogen. Negativtests mit Suchbegriffen aus der fremden Directory-Quelle lieferten keine fremden Objekte über den grommunio-LDAP-Pfad.

Ein praktischer Stolperstein: importierte Benutzer wurden zunächst mit privilegeBits=0 angelegt. Das ist kein Multitenancy-Fehler, aber eine Betriebsfalle. Nach dem LDAP-Import müssen Web-, IMAP-, SMTP- und DAV-Rechte bewusst geprüft und passend gesetzt werden.

Mail, GAL, Kalender und MDM

Mail und Store
Was sich daraus ableiten lässt
Benutzer, Mailboxen und Standard-Mailflow folgen der Organisations- und Domain-Zuordnung.
GAL und Kontakte
Was sich daraus ableiten lässt
Adressbuch- und GAL-Sichten wurden tenantbezogen geprüft; fremde Benutzer wurden nicht als normale GAL-Ergebnisse sichtbar.
Kalender
Was sich daraus ableiten lässt
Eigene Kalenderzugriffe funktionierten. Bekannte fremde Event-URLs lieferten keine Eventinhalte; Free/Busy zeigte keine Termin-, Ort-, Organisator- oder Zeitdaten, sondern nur Empfänger-/Status-Metadaten. Das direkte Fremdzugriffs-Fehlerverhalten sollte dennoch sauberer werden.
MDM / ActiveSync
Was sich daraus ableiten lässt
Connectivity, Provision, FolderSync sowie Mail-, Kalender- und Kontakte-Sync funktionieren grundsätzlich. Admin-API-Grenzen waren tenantbezogen; eine vollständige Device-Lifecycle-Isolation zwischen mehreren Organizations ist noch nicht abschließend validiert.

Webmail und SSO bei mehreren Organizations

Zusätzlich wurde der zentrale Webmail-Zugang mit grommunio-auth und Keycloak geprüft. Entscheidend ist dabei nicht nur, ob Keycloak mehrere Benutzer anmelden kann, sondern ob grommunio Web nach dem Redirect wieder die richtige Mailbox, Domain und Organization öffnet.

Im geteilten Webmail-Modell funktioniert die Zuordnung nur belastbar, wenn die vollständige Mailadresse als eindeutige Identität verwendet wird. Der geprüfte Ablauf nutzte dieselbe grommunio-Web-Instanz, dieselbe Webmail-URL, dasselbe grommunio-auth, denselben Keycloak-Realm und denselben OIDC-Client für Benutzer aus unterschiedlichen Organizations. Die OIDC-Claims preferred_username und email enthielten jeweils die vollständige Adresse, und grommunio Web öffnete die passende Mailbox der jeweiligen Domain.

Gleichnamige Benutzer verschiedener Domains sind dadurch unterscheidbar: alice@example-a.test und alice@example-b.test können denselben Localpart alice besitzen, solange die vollständige Adresse als Identität erhalten bleibt. Danach kann grommunio eindeutig von User zu Domain zu Organization abbilden.

Gemeinsame Webmail-URL
Einordnung
Möglich, wenn Redirect, Client, Callback und Cookies sauber auf den gemeinsamen Einstieg abgestimmt sind.
Identische Localparts
Einordnung
Unkritisch im geprüften Pfad, solange `preferred_username` und `email` die vollständige Adresse enthalten.
Benutzer-Mapping
Einordnung
Die Zuordnung erfolgt über volle Adresse, Domain und grommunio-Benutzerobjekt, nicht über den Localpart allein.
Falsche oder unvollständige Identität
Einordnung
Anmeldungen nur mit Localpart oder nicht vorhandener Tenant-Adresse wurden nicht akzeptiert.
Gemeinsamer Realm
Einordnung
Ein gemeinsamer Realm bedeutet keine automatische Tenant-Isolation; entscheidend sind Identität, Claims, Domain-/Organization-Mapping, Rollen, Gruppen und Client-Konfiguration.
Getrennte Kunden-Realms
Einordnung
Im getesteten Aufbau wurden genau ein Realm, ein Client und eine Adapter-Konfiguration verwendet. Eine automatische dynamische Multi-Realm-Auswahl wurde nicht nachgewiesen; getrennte Kunden benötigen getrennte Realms, IdPs, Auth-Instanzen, Entry-Points oder ein Broker-Modell.

Admin-Grenzen und sichtbare Metadaten

Scoped Admins können für operative Aufgaben sinnvoll begrenzt werden. Gleichzeitig sind globale Control-Plane-Bereiche nicht vollständig tenantblind: Systemendpunkte für Domains und Organizations zeigen weiterhin globale Metadaten, und Systemlogs bleiben als gemeinsamer Betriebsbereich sichtbar.

/system/domains und /system/orgs
Bedeutung für den Betrieb
Globale Metadaten können für scoped Admins sichtbar bleiben.
/system/logs
Bedeutung für den Betrieb
Logs sind ein gemeinsamer Kontrollbereich und nicht als tenantprivater Kundenbereich zu verstehen.
Distribution Lists
Bedeutung für den Betrieb
Cross-Tenant-Empfänger müssen organisatorisch und technisch validiert werden.
Delegation und Send-As
Bedeutung für den Betrieb
Fremde Principals dürfen nicht unkontrolliert eingetragen werden.

SMTP-Sender-Autorisierung härten

Für unabhängige Mandanten reicht die Standardprüfung des Absenders nicht aus. Im Test wurde Postfix zusätzlich mit smtpd_sender_login_maps und reject_authenticated_sender_login_mismatch gehärtet. Damit darf ein authentifizierter Benutzer nicht beliebig als fremde Adresse senden.

bash
smtpd_sender_login_maps = regexp:/etc/postfix/sender_login.regexp
smtpd_sender_restrictions =
  reject_non_fqdn_sender,
  reject_authenticated_sender_login_mismatch,
  permit_sasl_authenticated,
  permit_mynetworks

Für Produktion muss die Map vollständig gepflegt werden: primäre Adressen, Aliase, Shared-Mailbox-Send-As, Funktionspostfächer und bewusst erlaubte Stellvertretungen gehören in ein sauberes Betriebsmodell. Ohne diese Pflege kann die Härtung entweder zu viel erlauben oder legitime Workflows blockieren.

Angebundene Collaboration-Dienste

Archive, Meet, Chat, Files und Office wurden nicht mehr pauschal aus dem Core-Modell abgeleitet, sondern als eigene Dienste bewertet. Rspamd ist ein Shared Service und braucht für unabhängige MSP-Kunden getrennte Policies, History, Bayes und Controller oder eine dedizierte Instanz. Archive besitzt ein Domainmodell, aber keine automatisch nachgewiesene grommunio-Organization-Isolation. Meet/Jitsi, Chat und Files besitzen eigene Raum-, Workspace-, Benutzer-, Gruppen- und Share-Modelle; für unabhängige Kunden sind explizite Grenzen oder dedizierte Instanzen die konservativere Architektur. Office kann als gemeinsamer Dienst betrieben werden, solange Files und WOPI-Tokens die eigentliche Sicherheitsgrenze sauber durchsetzen.

Geeignete Betriebsmodelle

Eine Organisation mit mehreren Domains
Einordnung
Gut geeignet.
Mehrere Organisationseinheiten unter einem gemeinsamen Betreiber
Einordnung
Geeignet, wenn globale Metadaten, Logs und zentrale Richtlinien akzeptiert und dokumentiert sind.
Unabhängige MSP-/Hosting-Kunden auf gemeinsamer Control Plane
Einordnung
Nicht unverändert empfehlen. Zusätzliche Isolation, Härtung, Validierung oder getrennte Instanzen sind je nach Komponente nötig.

Grenzen, die vor Produktion geklärt werden müssen

Globale Metadaten
Warum es wichtig ist
Mandanten sehen unter Umständen mehr Strukturinformationen als für unabhängige Kunden gewünscht.
Globale Logs
Warum es wichtig ist
Logs gehören in ein Betreiber- und Zugriffskonzept.
Cross-Tenant-DL und Delegation
Warum es wichtig ist
Empfänger, Stellvertretungen und Send-As müssen mandantensicher validiert werden.
Noisy Neighbor und Quotas
Warum es wichtig ist
Tenantweite Storage- und Lastgrenzen wurden nicht vollständig bewiesen.
Tenant-Restore
Warum es wichtig ist
Ein vollständiger Restore nur eines Mandanten wurde nicht gezeigt.

grommunio 2026 Schritt für Schritt

Die Beiträge bauen chronologisch aufeinander auf. Starte mit der Appliance und ergänze danach Mail-Security, zentrale Anmeldung, Videokonferenzen, Chat, Dateien, Archiv, Geräteverwaltung und Multitenancy.

Teil 1: grommunio 2026 installieren

Teil 2: grommunio Antispam mit Rspamd

Teil 3: grommunio Auth mit Keycloak und MFA

Teil 4: grommunio Meet

Teil 5: grommunio Chat

Teil 6: grommunio Files und Office

Teil 7: grommunio Archive

Teil 8: grommunio Mobile Device Management

Teil 9: grommunio Multitenancy einordnen (dieser Beitrag)

Ausblick auf Teil 10

Multitenancy beantwortet, welche Daten und Verwaltungswege logisch getrennt sind. Teil 10 betrachtet danach die technische Verfügbarkeit: Homeserver, Share-Nothing-Ansätze, Datenbank, Storage, Load Balancing, Sessions, Failover, Fencing, Service-Trennung sowie Backup und Disaster Recovery.