Product · Identity & administration
One identity everywhere.
One place to manage it.
Single sign-on, multifactor authentication, a directory of users and groups, role-based administration and account lifecycle — on open identity standards, for every workload in the platform.
Project status Identity is planned for the core-services phase, as the foundation the other services depend on. Keycloak, Samba AD and LDAP are under evaluation; nothing on this page is available yet.
Why identity comes first
It is the part of the platform every other part depends on.
Ask an administrator what makes a collection of applications feel like one product, and the answer is usually sign-in and accounts. If mail, files and chat each have their own passwords and their own user lists, then every new starter is several tasks, every leaver is a risk that one account is forgotten, and every security policy has to be configured several times and is probably configured differently in each.
Office Unbound puts one identity provider in front of every service. People sign in once, with one password and one MFA method, and the same session takes them into mail, documents, files, chat and meetings. Administrators manage users, groups and roles in one directory, and the platform turns those decisions into access in each service.
It is also the area where the comparison with Microsoft is most demanding. Entra ID is a very large identity platform; the scope here is narrower and is described precisely below.
How identity is intended to work
Accounts come from the console, an existing directory or a provisioning API. One identity provider holds them and signs users in to every service. Changes to a person’s groups flow through to their access.
Intended capabilities
What the identity and administration services are being designed to provide. Each line shows its current status; none is available yet.
- Available Available and verified in a release
- In development Being built now
- Planned In the roadmap, not yet started
- Under evaluation Being assessed; not yet selected
| Capability | What it means | Status |
|---|---|---|
| Centralized user management | Create, edit, suspend and delete users once, for every service. | Planned |
| Groups and organizational structure | Groups, departments and nesting that drive mail lists, folder access and channel membership. | Planned |
| Single sign-on | One sign-in across the platform through OpenID Connect and SAML. | Planned |
| Multifactor authentication | Authenticator-app codes and security keys or passkeys, enforceable by policy. | Planned |
| Directory services | A directory for users, groups and contacts, readable by services that need it. | Planned |
| LDAP integration | LDAP access for applications that cannot use OIDC or SAML, and connection to existing LDAP directories. | Planned |
| Active Directory interoperability | Using an existing Active Directory as a source of users, where validated. | Under evaluation |
| Role-based permissions | Administrative roles with defined scopes instead of a single all-powerful admin. | Planned |
| Administrative delegation | Helpdesk, department and per-customer administrators with limited rights. | Planned |
| User provisioning | Accounts created with services, mailbox and storage assigned from group membership. | Planned |
| User deprovisioning | Disabling access everywhere at once, with defined handling of the user’s data. | Planned |
| Session controls | Session lifetime, idle timeouts and revocation of active sessions. | Planned |
| Authentication policies | Password rules, MFA requirements and sign-in restrictions per group. | Planned |
| Service access assignment | Which users may use which services, set by group or individually. | Planned |
| Organizational policies | Defaults for sharing, guests, retention and security set once for the organization. | Planned |
| Audit logs | Sign-ins, failures and administrative changes recorded for review. | Planned |
| API integration | A management API for provisioning and administration from other systems. | Planned |
Open identity standards
The protocols are the contract. Any application that speaks them can share the platform’s sign-in.
- OpenID Connect
- The modern standard for web and mobile sign-in, built on OAuth 2.0. The intended default for Office Unbound’s own services and for new applications an organization connects.
- SAML 2.0
- The established enterprise standard for single sign-on, still required by many business applications. Supported so that third-party software can use the same sign-in.
- LDAP
- The long-standing directory protocol. Used to read users and groups from an existing directory, and for older applications that can only authenticate against one.
- TOTP and WebAuthn
- Open standards for second factors: time-based codes from an authenticator app, and hardware security keys and passkeys.
Using standard protocols also means that applications outside Office Unbound — a CRM, an accounting system, an internal tool — can be connected to the same sign-in without custom integration, where they support OIDC or SAML.
Technology under evaluation
Established identity software, with Office Unbound’s administration services on top.
-
Keycloak
An open-source identity and access management server with OIDC and SAML, MFA, user federation from LDAP and Active Directory, and identity brokering. The leading candidate for the identity provider.
Under evaluation -
Samba AD
An open-source implementation of an Active Directory-compatible domain controller. A candidate where Windows domain services or AD-style directory behavior are required.
Under evaluation -
LDAP directories
Standard directory servers as an alternative store for users and groups, and the connection point for directories an organization already runs.
Under evaluation
Delegated administration
Not everyone who administers the platform should be able to do everything. The intended model separates roles by what they can change and over which part of the organization — or, for MSPs, over which customer.
| Role | Typical scope |
|---|---|
| Platform operator | Infrastructure, updates and tenants. For MSPs, the provider’s own staff. |
| Organization administrator | All users, groups, domains and policies within one organization. |
| Service administrator | One workload, such as mail or files, without access to identity policy. |
| Helpdesk | Password resets, MFA re-enrollment and account unlocks; no policy changes. |
| Group owner | Membership of the groups and teams they own. |
Joiners, movers and leavers
Provision
An account is created in the console, synchronized from a directory or created through the API. Group membership assigns services, a mailbox, storage and team access.
Enroll
The user sets a password and registers an MFA method on first sign-in, guided by the platform.
Change
Moving departments is a change of groups. Folder access, channel membership and distribution lists follow.
Deprovision
Disabling the account revokes sessions across every service. Mailbox, files and ownership are transferred or retained according to policy, not deleted by accident.
Record
Each step is written to the audit log with who did it and when.
Passwords and MFA when migrating
Migration can move a great deal — users, groups, aliases, mailboxes, files — but not sign-in secrets. Microsoft 365 and Google Workspace do not hand out users’ passwords or MFA secrets through ordinary migration APIs, and they should not. Moving to Office Unbound therefore includes an enrollment step: each person sets a new password, or signs in through a connected directory, and registers MFA again.
The planned migration tooling treats that as part of the project rather than an afterthought: identifying who must enroll, when, and how they will be told, so that cutover day is not also a day of locked-out users. Organizations that keep an on-premises Active Directory may be able to keep existing passwords by connecting it as a source, where that integration is validated.
What we are not claiming
Office Unbound’s identity service is not presented as an equivalent of Microsoft Entra ID. It is designed to provide sign-in, MFA, directory, groups, roles, policy and lifecycle for the Office Unbound platform and the applications an organization connects to it through open standards. Entra features such as device-based Conditional Access, Intune device management, Windows device join and the wider Microsoft identity ecosystem are not in scope. Active Directory interoperability will be claimed only where it has been validated.
Planning how sign-in would work for you?
Tell us about your current directory, MFA and the applications that depend on it. It shapes what is integrated and validated first.