Support multiple dedicated admin accounts (service accounts without a mailbox/domain)

[csiocc]

Current situation

The Admin API and admin web UI currently provide exactly one admin identity that is not associated with a mailbox: the built-in admin account, created automatically by grommunio-admin passwd. Further administrative privileges can only be granted through roles attached to existing domain or mailbox users.

Problem

For operators and integrators, this leads to:

• Every human operator and every external system sharing the same admin credentials. Audit logs cannot attribute actions to a specific person or integration.
• Rotating the admin password breaking all consumers at once.
• No way to disable a single operator or integration individually.
• The only workaround being to grant admin roles to mailbox users, which ties administrative access to a licensed mailbox and to a person's lifecycle.

Proposed feature

Allow creating multiple dedicated admin accounts (service accounts) that:

• exist independently of any domain or mailbox,
• can be assigned the existing roles/permissions (system, organization, domain),
• can be created, disabled, and deleted via the Admin API and the grommunio-admin CLI,
• appear individually in audit and access logs.

Context / offer to contribute

We (Open Circle AG, a Swiss managed services provider) are integrating grommunio into our service platform, which uses the Admin API from an external Rails application. We would be willing to contribute to the implementation of this feature — happy to discuss design direction first if you have preferences.

Related: this fits naturally with scoped API tokens (see separate feature request); tokens would ideally be issued per service account.

[crpb]

fwiw

From my notes.. (of course this tell a bigger story)
And yeah, it's domain/organization wide but this should probably be ok as they are license-free.

# https://github.com/grommunio/admin-api/issues/33#issuecomment-2467681926
# > This can be achieved by creating a user with `SystemAdminRO` permissions and then generating an access token via `grommunio-admin user login <username> --nopass --token`.
# > I can also add an explicit expiry parameter to the CLI call if needed, otherwise the global default for login tokens applies (`security.jwtExpiresAfter` configuration).
# https://github.com/grommunio/admin-api/issues/33#issuecomment-3442046597
# > You can now use --no-maildir to create a user without a mailbox.
#
# So to create a api-user we just do
# `grommunio-admin user create --no-maildir someapiapp@host.tld`
# `grommunio-admin password someapiapp@host.tld` # this is still needed
# `grommunio-admin user login someapiapp@host.tld --nopass --token`

[csiocc]

Yeah, that works as a workaround for low-stakes read-only access like monitoring, but it's not a real token feature: it's just the web session JWT (7-day default expiry via security.jwtExpiresAfter), the explicit expiry parameter mentioned above was never added, and there's no way to revoke or list issued tokens. Once a token expires, unattended integrations are locked out until someone regenerates it on the host via CLI.