Identity federation for a workplace suite with Active Directory or Entra ID

Entra ID does not answer LDAP binds or LDAP searches, so the Nextcloud LDAP app and the Nubus Directory Importer have nothing to query if you point them at a tenant. Both need a directory that accepts a bind account, exposes a searchable tree of users and groups, and returns attributes such as the user principal name and mail address. Entra ID exposes identity through OpenID Connect, OAuth 2.0 and the Microsoft Graph API, which are different interfaces. Before you write any connection settings, decide which pattern applies: a directory the importers can bind to, or a login-only federation in which the workplace suite never reads the directory at all. Confirm which pattern your chosen components support in their current documentation.

Azure AD Domain Services is Microsoft's managed domain service. It synchronizes selected objects from Entra ID into a domain that offers LDAP and domain protocols, so the importers and the Nextcloud LDAP app can work against it. The trade-offs sit in three places. First, synchronization scope: only the users, groups and attributes you include are visible, so the attributes needed for matching must be planned before the first sync. Second, password hash handling: some bind and authentication paths depend on password hash material being synchronized, which affects which accounts can authenticate and how cloud-only users behave. Third, cost: a managed domain is a recurring Microsoft charge, so ask Microsoft for the current price for your region, tier and object count, and include it in the quote your partner prepares. Confirm all current requirements with Microsoft and with your implementation partner before you commit.

The alternative is to broker Entra ID through Keycloak over OIDC. You register the workplace stack as a client in Keycloak, configure Entra ID as an identity provider there, and let the suite log in through Keycloak without any LDAP directory. This avoids a managed domain, but it changes where authorization data comes from. Group membership and roles must arrive as token claims, so test which claims your Entra ID tenant issues and how Keycloak maps them to the attributes each component expects. Our openDesk federation with external IdP guide describes the federation pattern for that suite, and you should confirm with the component owners whether their version accepts the claims you plan to send.

Attribute matching decides whether a person who signs in through Keycloak lands on the same Nextcloud or openDesk account every time, or whether the platform quietly creates a second one. Settle the matching rules before the first directory sync, because duplicates are much harder to clean up after users have shared files, owned projects and been added to chat rooms. Five attributes need a deliberate answer: the login name, the email address, the unique identifier, group membership and the role that grants access to each component. The immutable identifier is the critical one. Use the directory's object GUID for Active Directory or the immutable object ID for Entra ID as the anchor, not the username or email, because people marry, change departments and get renamed, and those values change while the underlying identity does not. Record which attribute the suite treats as the unique key and confirm that the same key is passed through the Keycloak identity provider mapping and the LDAP attribute mapping.

Duplicates and orphans follow predictable patterns. If Nextcloud is matched on the username in one path and on the email address in another, a user who signs in through the OIDC broker and once through the LDAP connection can end up with two accounts with the same display name and different file trees. If a user is renamed in the directory, a username-based match creates a new account and leaves the old one orphaned, still holding shares and ownership. Group membership has the same risk: a group synced under one name in the suite and a second name by an admin creates two permission sets that drift apart. For openDesk, check which attributes the bundled Nubus identity layer expects from the Nubus Directory Importer and whether role mapping is handled there or in the broker. Confirm this against the openDesk federation documentation rather than assuming the defaults match your schema.

Review Keycloak identity mappers and LDAP attribute mappings as a single change set, with a named owner and a written list of which attribute feeds which field. Before go-live, run a test with a representative sample of accounts that covers renamed users, users with a changed email, a leaver whose account is disabled, a user in two groups and a service account that must not be imported as a person. Check that a second sign-in reuses the first account, that a disabled directory user loses access on the next sync, and that the orphan report is empty. Record the results as evidence for the access control review. The Nextcloud LDAP documentation and openDesk federation guide are the next reads for field-level settings, and your identity team should confirm every attribute name against your actual directory schema.

Start by asking which federation path the partner recommends for your directory and why. Ask whether they would connect openDesk through Keycloak as the broker, or connect Nextcloud directly through its LDAP app, OpenID Connect or SAML backends, and what that choice means for the number of identity hops, login behavior and where group membership is resolved. Ask how they would use the Nubus Directory Importer against your Active Directory forest, which accounts and organizational units it reads, and whether they would run it against a read-only service account. For Entra ID, ask directly how they would reach your tenant. The answer should explain why Azure AD Domain Services is part of the design, how it exposes an LDAP view of users and groups, which synchronization scope it uses, and who owns the Domain Services instance, its licensing and its network path. A partner who cannot describe that path in specific terms has not yet designed it.

Next, ask how attribute matching is tested before go-live. Request the mapping table that links sAMAccountName, userPrincipalName, mail and any employee identifier to the attributes the suite expects, and ask how duplicate or changed values are handled, such as renamed users or accounts that share a mail address. Ask for the test cases they run: a user with a changed surname, a disabled account that still holds an active session, a user moved between organizational units, and a nested group that grants a role. Ask how they confirm that a single user does not appear twice in the suite under two identities. For Keycloak, ask who installs and upgrades it, whether they use the Keycloak Operator with manual approval mode for updates, how they plan around the Keycloak release cadence, and whether schema migration runs automatically at startup or is applied manually. Ask which production database and high availability design they would use, because both supported designs need a synchronously replicated database. Finally, ask what the runbook covers when people leave or change roles. The partner should describe how a disabled account is removed from the suite, how sessions and tokens are revoked, how group changes propagate and how long that takes in your environment, and who approves and records each change. Ask which side of the boundary owns the directory: whether your identity team retains ownership of users and groups in Active Directory or Entra ID, and whether the partner only owns the connector, the Keycloak realm and the suite configuration. Ask what evidence they hand over at acceptance, such as the attribute mapping, test results, configuration as code, access reviews and logs that show authentication events, and confirm that the logs flow to your own monitoring. Ask for a written list of what you are responsible for after handover.