Busy moving a bunch of domains into a tenant, to get better client and operational separation of email accounts. However, how would I setup (without using an enterprise account slot) a “super” Administrator that is part of a tenant group/emails?
on
What you’re describing is contradictory by design, unfortunately. Once a principal is a member of a tenant, it’s isolated to that tenant and its permissions are capped at whatever the tenant is allocated, so it can’t also be a server-wide super-admin. A super-admin is a top-level account (no tenant membership) that manages all tenants from outside.
So you’ve got two workable shapes: keep the super-admin as a top-level account that administers the tenant from outside, or create a normal account inside the tenant and give it a Role with the permissions it needs, which gets you a tenant-scoped administrator (full control of that tenant, but bounded to it).
On the slot question: the admin capability itself is just a role and costs nothing, but any account that has a mailbox is a principal and counts against quota, so there’s no mailbox-bearing account that’s free. The one non-account admin credential is the recovery admin, which is a temporary backdoor rather than something for daily use. Multi-tenancy is an Enterprise feature, for reference.
Yes, as an entreprise feature I now (by suddenly getting a big client) needing to setup/handle the tenancy issues.
Where I previously was a “single account lots of domains” type I now have the need to split my management services domains into a tenant too, where I can have a tenant administrator only for my management services domains, and then inside each tenant I then have their own tenant administrators.
The “super admin” requirement comes now where I’d prefer to have an mailbox account inside my ManagementServices tenant, to also be able to manage the other client-tenants.
The actual problem I’m facing is that my current “defaultDomain” I’d also want inside a tenant, but seems that I need to change to another defaultDomain (like ops-domain) for that purpose like licensing.
So, lets say only the ops-domain is not inside a tenant, I see then the only option (with my normal/business emails inside the managedServices-tenant)
is to create MAILBOXES like adminUSer1@ops-domain and adminUser2@domain? there aren’t method to NOT have those as mailboxes? also to forward those emails to a user1@managedServices-tenant possible? guess not as a “similar”/equivalent email address as it can’t cross tenant boundaries?
The short version is that a super-admin has to live outside any tenant. Once a principal is a member of a tenant it’s isolated to that tenant and its permissions are capped by the tenant’s allocation, so it can’t also be server-wide. So keep your ops/management domain out of any tenant and run the super-admin there, managing the client tenants from outside; inside each tenant you then have tenant-scoped admins.
On the slot and forwarding questions: the admin capability itself is just a role and is free, but any account that owns a mailbox is a principal and counts against quota, so there’s no mailbox-bearing admin account that doesn’t cost a slot (the only non-account admin credential is the temporary recovery admin, which isn’t meant for daily use). And addresses don’t resolve across tenant boundaries, so you can’t forward an ops-domain mailbox into a managed-services tenant mailbox as if they were the same address; that isolation is the point of tenants. Practically, that means adminUser@ops-domain style mailboxes on the untenanted ops domain, used directly, rather than trying to alias or forward them into a tenant. One alternative to forward email across tenants is using a Sieve script on the user’s mailbox.
So to state it clearly: The current design can NOT have “superadmins” WITHOUT principal/mailbox account-slots.
Ie. if I have 5 “superadmins”, currently — as per design, they REQUIRE principal/mailbox account slots outside any tenant.
This opens another concern to contemplate for versions after 1.x.y for future growths and for service providers (and yes, I see Stalw.art as a product with service provider/reseller potential): If I setup several separate Stalwart mail clusters (separate tenants/etc.), I would still need for each of them principal/mailbox slots for the MSP’s SuperAdmins, even if they won’t be using those for any emails/etc. ie. only be administrators, not mailbox users.
Clarification: I need to just have this clearly documented and understood, as it adds account costs (albeit minimal, but still) for MSPs/etc. that might not be as obvious
Your statement is correct. It is not “any account with a mailbox counts”: every account principal counts toward the licensed total, mailbox or not, quota or not. Setting a zero quota or never delivering mail to the address does not exempt it. Roles, tenants, domains and mailing lists are separate object types and are never counted, so the admin capability itself really is free; the identity that holds it is not.
So yes: five super-admins outside any tenant means five account slots, and the same applies per deployment if you run separate clusters for separate clients. The recovery admin remains the only admin credential that does not count, and it is a break-glass mechanism rather than something to build a process on.
Thank you, this basically adds a feature request for version 1.1+ to have no-mailbox admins