grommunio Multitenancy 2026: Organizations, Domains und mehrere LDAP-Quellen einordnen

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.

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.

Mail, GAL, Kalender und MDM

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.

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.

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.

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

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

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.