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.
| Area | Classification |
|---|---|
| Core mail | Shared operation is possible, but sender, delegation, lists, logs and restore need hardening. |
| LDAP | Separation per organization is possible; each organization can use its own directory source. |
| Admin | Shared with limitations; global metadata and logs remain operator-level areas. |
| Web/GAL | Shared with limitations; Webmail and GAL need verification through unique user, domain and organization mapping. |
| Calendar | Shared with limitations; own calendars work, foreign access did not return event details but needs cleaner error behavior. |
| Public folders | Shared with limitations; root separation is plausible, while concrete permission models remain production-relevant. |
| Shared mailboxes / distribution lists | Shared with limitations; cross-tenant recipients, delegation and Send-As must be controlled explicitly. |
| MDM / ActiveSync | ActiveSync works in principle as a shared service; full device-lifecycle isolation between organizations still needs validation. |
| Webmail + grommunio-auth | Shared operation is possible when full email address, claims, domain and organization map unambiguously. |
| Keycloak/Auth | A shared realm is possible but not automatic tenant isolation; separate realms, IdPs or entry points are preferred for independent customers. |
| Rspamd | Shared service; separate policy, history, Bayes and controller planes or dedicated instances are recommended for MSP customers. |
| Archive | Domain model exists, but automatic grommunio organization isolation was not proven; dedicated instances are recommended for MSP customers. |
| Meet | Shared Jitsi/Prosody service; isolation comes from auth, room, guest, lobby and moderator policy, not automatically from organizations. |
| Chat | Shared workspace/backend without automatic organization tenancy; plan team, domain or group isolation deliberately. |
| Files | User, group and share model; automatic organization assignment was not proven, so explicit isolation or a dedicated instance is needed. |
| Office | Shared WOPI/Office service is possible; the security boundary is mainly Files and WOPI tokens. |
- Classification
- Shared operation is possible, but sender, delegation, lists, logs and restore need hardening.
- Classification
- Separation per organization is possible; each organization can use its own directory source.
- Classification
- Shared with limitations; global metadata and logs remain operator-level areas.
- Classification
- Shared with limitations; Webmail and GAL need verification through unique user, domain and organization mapping.
- Classification
- Shared with limitations; own calendars work, foreign access did not return event details but needs cleaner error behavior.
- Classification
- Shared with limitations; root separation is plausible, while concrete permission models remain production-relevant.
- Classification
- Shared with limitations; cross-tenant recipients, delegation and Send-As must be controlled explicitly.
- Classification
- ActiveSync works in principle as a shared service; full device-lifecycle isolation between organizations still needs validation.
- Classification
- Shared operation is possible when full email address, claims, domain and organization map unambiguously.
- Classification
- A shared realm is possible but not automatic tenant isolation; separate realms, IdPs or entry points are preferred for independent customers.
- Classification
- Shared service; separate policy, history, Bayes and controller planes or dedicated instances are recommended for MSP customers.
- Classification
- Domain model exists, but automatic grommunio organization isolation was not proven; dedicated instances are recommended for MSP customers.
- Classification
- Shared Jitsi/Prosody service; isolation comes from auth, room, guest, lobby and moderator policy, not automatically from organizations.
- Classification
- Shared workspace/backend without automatic organization tenancy; plan team, domain or group isolation deliberately.
- Classification
- User, group and share model; automatic organization assignment was not proven, so explicit isolation or a dedicated instance is needed.
- Classification
- Shared WOPI/Office service is possible; the security boundary is mainly Files and WOPI tokens.
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.
| Area | Classification |
|---|---|
| Organizations | Multiple organizations can be managed in parallel. |
| Domains | Domains can be assigned to organizations and constrain user context. |
| Users | Identical user names in different organizations did not cause false assignment. |
| Scoped admins | Organization and domain admins see operational areas in a restricted way, but global metadata is not fully hidden. |
- Classification
- Multiple organizations can be managed in parallel.
- Classification
- Domains can be assigned to organizations and constrain user context.
- Classification
- Identical user names in different organizations did not cause false assignment.
- Classification
- Organization and domain admins see operational areas in a restricted way, but global metadata is not fully hidden.
Multiple LDAP Sources per Organization
The strongest positive finding is per-organization LDAP configuration. Organization A can synchronize against directory A, while organization B synchronizes against directory B. The relevant admin commands use the syntax available on the tested 2026.06.1 system and the organization option.
grommunio-admin ldap info -o <organization>grommunio-admin ldap search -o <organization> <search-term>grommunio-admin ldap dump -o <organization>grommunio-admin ldap downsync -o <organization>grommunio-admin ldap check -o <organization>grommunio-admin ldap reload -o <organization>
Organization A and organization B were checked against their own directory sources. Searches, dumps, downsyncs, checks and reloads stayed tied to the selected organization. Negative searches for objects from the other directory did not enumerate foreign objects through the grommunio LDAP path.
One practical configuration trap: imported users initially had privilegeBits=0. This is not a multitenancy defect, but it matters operationally. After LDAP import, Web, IMAP, SMTP and DAV privileges must be checked and set deliberately.
Mail, GAL, Calendar and MDM
| Component | What can be concluded |
|---|---|
| Mail and store | Users, mailboxes and standard mail flow follow organization and domain assignment. |
| GAL and contacts | Address book and GAL views were checked per tenant; foreign users were not visible as normal GAL results. |
| Calendar | Own calendar access worked. Known foreign event URLs did not return event content; Free/Busy did not expose summary, location, organizer or time data, only recipient/status metadata. Direct foreign-access error behavior should still be cleaner. |
| MDM / ActiveSync | Connectivity, provision, FolderSync and mail, calendar and contacts sync work in principle. Admin API boundaries were tenant-scoped; full device-lifecycle isolation across multiple organizations is not yet finally validated. |
- What can be concluded
- Users, mailboxes and standard mail flow follow organization and domain assignment.
- What can be concluded
- Address book and GAL views were checked per tenant; foreign users were not visible as normal GAL results.
- What can be concluded
- Own calendar access worked. Known foreign event URLs did not return event content; Free/Busy did not expose summary, location, organizer or time data, only recipient/status metadata. Direct foreign-access error behavior should still be cleaner.
- What can be concluded
- Connectivity, provision, FolderSync and mail, calendar and contacts sync work in principle. Admin API boundaries were tenant-scoped; full device-lifecycle isolation across multiple organizations is not yet finally validated.
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.
| Check | Classification |
|---|---|
| Shared Webmail URL | Possible when redirect, client, callback and cookies are aligned with the shared entry point. |
| Identical localparts | `preferred_username` and `email` must contain the full address; the tested path did not rely on the localpart alone. |
| User mapping | Mapping follows full address, domain and the grommunio user object, not the localpart alone. |
| Wrong or incomplete identity | Localpart-only login and nonexistent tenant addresses were not accepted. |
| Shared realm | A shared realm is not automatic tenant isolation; identity, claims, domain and organization mapping, roles, groups and client configuration are decisive. |
| Separate customer realms | The tested setup used exactly one realm, one client and one adapter configuration. Automatic dynamic multi-realm selection was not proven; separate customers need separate realms, IdPs, auth instances, entry points or a broker model. |
- Classification
- Possible when redirect, client, callback and cookies are aligned with the shared entry point.
- Classification
- `preferred_username` and `email` must contain the full address; the tested path did not rely on the localpart alone.
- Classification
- Mapping follows full address, domain and the grommunio user object, not the localpart alone.
- Classification
- Localpart-only login and nonexistent tenant addresses were not accepted.
- Classification
- A shared realm is not automatic tenant isolation; identity, claims, domain and organization mapping, roles, groups and client configuration are decisive.
- Classification
- The tested setup used exactly one realm, one client and one adapter configuration. Automatic dynamic multi-realm selection was not proven; separate customers need separate realms, IdPs, auth instances, entry points or a broker model.
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.
| Boundary | Operational meaning |
|---|---|
| /system/domains and /system/orgs | Global metadata can remain visible to scoped admins. |
| /system/logs | Logs are a shared control area, not a private customer area. |
| Distribution lists | Cross-tenant recipients require organizational and technical validation. |
| Delegation and Send-As | Foreign principals must not be assignable without control. |
- Operational meaning
- Global metadata can remain visible to scoped admins.
- Operational meaning
- Logs are a shared control area, not a private customer area.
- Operational meaning
- Cross-tenant recipients require organizational and technical validation.
- Operational meaning
- Foreign principals must not be assignable without control.
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.regexpsmtpd_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
| Operating model | Classification |
|---|---|
| One organization with multiple domains | Well suited. |
| Multiple organizational units under one common operator | Suitable if global metadata, logs and central policies are accepted and documented. |
| Independent MSP or hosting customers on one shared control plane | Not recommended unchanged. Additional isolation, hardening, validation or separate instances are required depending on component. |
- Classification
- Well suited.
- Classification
- Suitable if global metadata, logs and central policies are accepted and documented.
- Classification
- Not recommended unchanged. Additional isolation, hardening, validation or separate instances are required depending on component.
Limits to Clarify Before Production
| Topic | Why it matters |
|---|---|
| Global metadata | Tenants may see more structural information than desired for independent customers. |
| Global logs | Logs need an operator and access model. |
| Cross-tenant DL and delegation | Recipients, delegation and Send-As need tenant-safe validation. |
| Noisy neighbor and quotas | Tenant-wide storage and load limits were not fully proven. |
| Tenant restore | A full restore of only one tenant was not shown. |
- Why it matters
- Tenants may see more structural information than desired for independent customers.
- Why it matters
- Logs need an operator and access model.
- Why it matters
- Recipients, delegation and Send-As need tenant-safe validation.
- Why it matters
- Tenant-wide storage and load limits were not fully proven.
- Why it matters
- A full restore of only one tenant was not shown.
grommunio 2026 Step by Step
The articles build on each other chronologically. Start with the appliance and then add mail security, central login, video meetings, chat, files, archiving, device management and multitenancy.
Part 1: Install grommunio 2026
Part 2: grommunio Antispam with Rspamd
Part 3: grommunio Auth with Keycloak and MFA
Part 6: grommunio Files and Office
Part 8: grommunio Mobile Device Management
Part 9: Classify grommunio multitenancy (this article)
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.
