grommunio Multitenancy 2026: organizations, domains and multiple LDAP sources

Overview

grommunio 2026.06.1 has a real organization and domain model. In practice, multiple organizations can be operated with their own domains, users and LDAP sources. This article classifies where that separation is solid, where additional hardening is required and which operating models it supports.

The conclusion is intentionally neither “not multitenant” nor “fully multitenant”. grommunio can represent multiple organizational units under one common operator. For independent MSP or hosting customers on an unchanged shared control plane, however, there are boundaries that must be handled architecturally.

Tested Baseline

The baseline was a fresh grommunio appliance 2026.06.1. It was reused after the previous Meet lab, backed up before multitenancy changes and then configured with three organizations: tenant A with directory A, tenant B with directory B and tenant C with local users.

The external directories were only the directory baseline. The relevant proof was inside grommunio itself: organization A uses directory A, organization B uses directory B, local users in organization C remain separate, and search, import and downsync actions do not accidentally cross into another organization.

Multitenancy at a Glance

grommunio organization and domain multitenancy does not automatically apply to every connected collaboration service. Some components have their own identity, data, policy and administration models. This overview is therefore the main decision aid for architecture and operations.

Organizations, Domains and Users

The central tenant structure is built from organizations and domains. Domains are assigned to an organization, so users belong to a clear administrative unit. Identical names in different organizations are manageable as long as assignment uses organization, domain and unique objects.

Mail, GAL, Calendar and MDM

Webmail and SSO with Multiple Organizations

The shared Webmail entry point was also checked with grommunio-auth and Keycloak. The important question is not only whether Keycloak can authenticate multiple users, but whether grommunio Web returns to the correct mailbox, domain and organization after the redirect.

In a shared Webmail model, the mapping is reliable only when the full email address is used as the unique identity. The tested flow used the same grommunio Web instance, the same Webmail URL, the same grommunio-auth, the same Keycloak realm and the same OIDC client for users from different organizations. The OIDC claims preferred_username and email contained the full address, and grommunio Web opened the matching mailbox for the respective domain.

Users with the same name in different domains are distinguishable this way: alice@example-a.test and alice@example-b.test can share the localpart alice as long as the full address remains the identity. grommunio can then map unambiguously from user to domain to organization.

Admin Boundaries and Visible Metadata

Scoped admins can be constrained for operational tasks. At the same time, global control-plane areas are not fully tenant-blind: system endpoints for domains and organizations still expose global metadata, and system logs remain a shared operational area.

Hardening SMTP Sender Authorization

For independent tenants, the default sender check is not enough. The test hardened Postfix with smtpd_sender_login_maps and reject_authenticated_sender_login_mismatch so that an authenticated user cannot freely send as a foreign address.

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

For production, the map has to be complete: primary addresses, aliases, shared-mailbox Send-As, functional mailboxes and deliberate delegation workflows all belong in a clean operating model. Without that maintenance, hardening can either allow too much or block legitimate workflows.

Connected Collaboration Services

Archive, Meet, Chat, Files and Office are not derived blindly from the core model, but classified as separate services. Rspamd is a shared service and needs separate policies, history, Bayes and controller planes or a dedicated instance for independent MSP customers. Archive has a domain model, but automatic grommunio organization isolation was not proven. Meet/Jitsi, Chat and Files have their own room, workspace, user, group and share models; for independent customers, explicit boundaries or dedicated instances are the conservative architecture. Office can run as a shared service as long as Files and WOPI tokens enforce the actual security boundary.

Suitable Operating Models

Limits to Clarify Before Production

Outlook to Part 10

Multitenancy answers which data and administrative paths are logically separated. Part 10 then looks at technical availability: homeserver, share-nothing approaches, database, storage, load balancing, sessions, failover, fencing, service separation, backup and disaster recovery.