Nextcloud SSO and identity integration guide

Nextcloud SSO and identity integration: what it involves and why it is harder than it looks

If you already run a directory or identity provider, the core requirement is simple to state: Nextcloud must authenticate users against that source, honor group membership, and remove access when someone leaves. The difficulty is that a Nextcloud identity integration is not one setting. It is a set of decisions that must be made together. Authentication can run through the LDAP or Active Directory backend, through OpenID Connect, or through SAML. Authorization depends on which groups exist in Nextcloud and how those groups drive share permissions and storage quotas. Provisioning and deprovisioning determine when accounts appear and disappear. Two-factor authentication determines what a password alone can no longer do. Designing these as separate projects tends to produce a system that works on the first login and fails on the first offboarding.

The most common failure is access that survives a directory change. A user disabled in Active Directory may still have a local Nextcloud account, which the LDAP or SSO backend never touched. App passwords created for WebDAV clients, mobile apps or sync tools are separate credentials that can keep working after the main password is reset or the account is disabled, depending on how your configuration handles them. Desktop and mobile clients hold sessions and refresh tokens, and background sync may continue to run until those sessions are revoked or expire. Shares created by a departing user also need an owner plan, because files shared through that account stay exposed until someone reassigns them. Each of these paths must be found, tested and closed on purpose.

Before choosing a protocol, confirm with your identity team which source is authoritative for users and groups, whether it can supply a stable unique identifier, and how disabled accounts are represented. Ask whether group membership is nested, whether groups will be used for quotas and shares, and whether you need to map directory groups to Nextcloud groups by name or by attribute. Check what your identity provider can send for OpenID Connect or SAML claims, and whether it can enforce its own multi-factor policy. Decide whether local administrator accounts will exist as a break-glass path and how they will be protected. These answers shape the build more than the choice of protocol does.

A sound test plan covers the full lifecycle, not only login. Test a new hire receiving the right groups, a group change propagating to shares and quotas, a password reset, a lost device, and a leaver whose access must end across the web interface, desktop and mobile clients, WebDAV and any API tokens. Record how long each path takes to stop working and what remains open in the meantime. For an illustrative case, a team might find that a disabled directory account still syncs from a laptop until the client session is revoked. Such a finding should lead to a documented offboarding runbook, not a one-time fix. Ask any partner to show these test results in writing before go-live.

Cost and effort follow the number of identity paths you must govern, the complexity of your group model, and how many client types you support. Ask for the quote to list the identity source and protocol in scope, the group and quota mapping rules, the provisioning and deprovisioning tests, the two-factor method, the offboarding runbook and the client revocation procedure, along with who performs each item and what you must supply, such as directory service accounts and test users. Confirm with your identity provider and your Nextcloud version which features are available in your environment before committing to a design.

Which Nextcloud components and settings carry identity

Identity in Nextcloud is not held in one place. A small set of components decides who can sign in, which groups they belong to, and how clients authenticate, so each one needs an explicit decision before rollout.

LDAP and Active Directory user backend

The LDAP app lets directory users appear in Nextcloud and sign in with their directory credentials. It is the usual choice when Active Directory or another LDAP directory is the source of truth for people. Confirm which attributes are used for login, which base DNs and filters limit the users who can sign in, and how disabled or removed accounts are treated. Test with a service account that has read-only access.

OpenID Connect and SAML backends

Nextcloud documents OpenID Connect and SAML as user authentication backends, so sign-in can be delegated to an external identity provider. This suits organizations that already run a central identity platform for web apps. Confirm which protocol your identity provider supports well, how claims map to Nextcloud user IDs and display names, and whether local fallback accounts are kept for administrator recovery. Check the exact app and version against the Nextcloud documentation for your release.

Group membership for shares and quotas

Groups from the directory or identity provider often drive sharing permissions, storage quotas and app access. Groups that are mapped inconsistently cause users to see the wrong shares or hit unexpected storage limits. Decide which group names are synchronized, which are created locally, and who may create groups. Confirm how nested groups are flattened and how group changes apply to existing shares and quota settings.

Two-factor authentication framework

Nextcloud's two-factor authentication framework adds second factors on top of the primary login, whether that login comes from a local password, LDAP or an external provider. Decide which methods are offered, whether enrollment is required for all users or specific groups, and how lost devices are recovered by administrators. Confirm that the chosen second factor works with desktop and mobile clients, and that the identity provider does not already enforce its own second factor in a way that conflicts with it.

App passwords for sync clients

Desktop and mobile sync clients and WebDAV tools often cannot complete an interactive browser login, so Nextcloud issues app passwords as separate credentials. Each app password can be revoked without changing the user's main password. Decide whether users may create them freely, whether they expire, and how they are revoked when a laptop is lost or an employee leaves. Confirm how your identity provider policy interacts with client sign-in before rollout.

How to build Nextcloud SSO in the right sequence

This sequence turns a directory or identity provider into a working Nextcloud login, with groups, quotas, sharing rules, provisioning and two-factor authentication applied in an order that lets each step be tested before the next one depends on it. The result is a production cutover that keeps a fallback admin path open.

Confirm the identity source and service account
Before any Nextcloud configuration, confirm which system is authoritative for user accounts: an LDAP or Active Directory domain, or an OpenID Connect or SAML identity provider. Ask the directory team for a read-only service account, the base distinguished names for users and groups, and whether accounts for contractors or shared mailboxes live in the same tree. Document who approves the account and how its password rotates. This step is done when the directory team has provided the service account details in writing and someone has confirmed that the account can read users and groups from a directory client outside Nextcloud.
Decide the authoritative username attribute
Choose the directory attribute that will become the Nextcloud user ID and keep it stable for the life of the deployment. Common candidates are a unique account name or an immutable identifier from the identity provider, and the choice should not depend on an email address or a display name that people change. Check how existing shares, calendars and client accounts will map to the chosen identifier, because changing it later affects every user. This step is done when the attribute name, its uniqueness and its behavior on renames have been written down and signed off by the identity owner.
Configure the chosen backend on a staging instance
Install the authentication backend that matches the decision, such as Nextcloud's LDAP integration app or the OpenID Connect or SAML user backend, on a staging instance that is not used by real users. Enter the server address, encryption settings, service account, search base and attribute mappings, and confirm which directory objects are loaded. Use the vendor documentation for the exact settings of your Nextcloud version. This step is done when the staging configuration test reports a successful bind and when a directory user returns from a search in the Nextcloud admin interface.
Test login with a pilot group
Select a small pilot group of users who represent different roles, including at least one administrator, one user who belongs to nested or secondary groups and one external or guest account if those exist. Ask each pilot user to sign in through the web interface and a desktop or mobile client, and record failures such as expired passwords, locked accounts or missing attributes. Keep the pilot on staging or on a restricted production group, depending on your risk appetite. This step is done when every pilot account logs in successfully on both the web and a client, and the account details in the user profile show the expected display name, email address and user ID.
Map groups to quota and sharing rules
Translate directory groups into Nextcloud groups that drive storage quotas, sharing permissions and access to apps. Keep the mapping table short, with one owner for each group and a written reason for each quota tier, and avoid mapping every departmental group unless there is a policy need for it. Verify the sharing settings that depend on group membership, such as whether users can share outside the organization, and test them with pilot accounts. This step is done when a test account placed in a mapped group shows the expected group membership and quota in its user profile, and a share attempt behaves according to the policy written for that group.
Enable provisioning and deprovisioning rules
Define how accounts appear and disappear in Nextcloud. Decide whether users are created on first login or synchronized in advance, which directory states disable a Nextcloud account, and what happens to files, shares and calendars owned by a departed user. Confirm the process for reassigning ownership before a deletion occurs, and test a disabled directory account on staging to see whether Nextcloud blocks new sessions and existing client tokens. This step is done when a test account disabled in the directory can no longer sign in to Nextcloud, and the team has a documented owner for the file-transfer step.
Enforce two-factor authentication for chosen groups
Enable two-factor authentication for the groups that need it first, typically administrators and users with access to sensitive shares, and confirm which second-factor methods the organization will accept. Check how the second factor interacts with SSO, because a federated login may already include strong authentication at the identity provider, and avoid prompting users twice without a reason. Confirm the enrollment path for users who lose a device, and make sure the recovery process does not bypass the controls it is meant to protect. This step is done when a test account in an enforced group is prompted for the second factor after sign-in and cannot access the protected group's features until enrollment is complete.
Cut over with a fallback admin account
Before switching production users to the new login path, create or retain a local administrator account that does not depend on the directory, store its credentials in the organization's approved secret store, and test that it can sign in. Schedule the cutover with a rollback plan that states who can switch the login backend back and how users will be informed. After cutover, check a sample of production logins, group memberships and client sessions, and watch the server logs for bind or token errors. This step is done when the fallback administrator has signed in successfully, the rollback owner has confirmed the procedure in writing, and the first production logins show the expected user profiles.

What drives identity integration effort and how to keep it down

This table lists the factors that most often expand a Nextcloud identity project and the practical steps that keep each one contained. Read each row as a lever: the left column names the driver, the middle column explains why it adds work, and the right column shows what to change before the build starts. The main takeaway is that directory cleanup and a short list of sign-in methods usually save more effort than any single technical setting.

Driver	Why it adds effort	How to keep it down
Directory complexity	Nested groups, several domains or forests, and inconsistent attributes such as mail or display name make group mapping for shares and quotas harder to reason about and test.	Clean group naming and nesting before connecting, agree which attribute is the Nextcloud user ID, and confirm which domains or forests must log in.
Number of identity sources	Each LDAP directory, OpenID Connect provider or SAML identity provider adds its own mapping, failure modes and sign-in path to test and support.	Limit sources to the system of record for users, and treat any second source as a documented exception with a named owner.
Number of client types	Desktop sync clients, mobile apps, WebDAV tools and browsers each handle app passwords, token refresh and two-factor prompts differently, multiplying test cases.	Standardize on one supported client list, publish the sign-in method for each, and retire unsupported clients before rollout.
Sharing and quota policy complexity	Group-based share permissions, per-group quotas and exceptions for external users require mapping rules that must match directory group membership exactly.	Keep the policy model small, map quotas to a few stable groups, and write down which group controls each share permission.
Compliance evidence needs	Assessors often ask for proof of access approvals, deprovisioning timing, two-factor enforcement and log retention, each of which must be generated and kept.	Confirm the control list with the assessor early, decide which logs and reports Nextcloud and the directory must produce, and test them once in staging.
Number of environments	Development, staging and production each need their own directory bindings, OIDC or SAML client registrations and test accounts, which can drift apart.	Keep identity configuration in version-controlled settings, use the same group structure in every environment, and test sign-in in each before promotion.
Provisioning and deprovisioning scope	Users who leave the directory must lose access, shares and sessions, and orphaned shares or external links create cleanup work after each departure.	Define the offboarding path in the directory first, confirm how Nextcloud handles disabled users, and review share ownership rules with the business owners.

How SSO changes between single node, clustered and air-gapped Nextcloud

On a single Nextcloud server, identity integration is usually the simplest to reason about. One web tier handles every request, so session state lives in one place and the identity provider only needs to be reachable from that server and from user browsers. LDAP or Active Directory binds, OpenID Connect redirects and SAML assertion handling all terminate on the same host, which makes troubleshooting a matter of checking one reverse proxy, one set of logs and one clock.

Points to plan for:

Hostname and redirect URIs: the public name used by the reverse proxy must match what is registered with the identity provider, including the callback path for the chosen backend.
Directory bind account: create a read-only service account with a narrow search base, and record who owns its password and when it expires.
Time synchronization: token validation and Kerberos-style checks fail when clocks drift, so confirm NTP on the server and the IdP.
Local fallback login: decide whether an administrator account outside SSO is kept, stored and tested.
Log visibility: confirm that failed logins from the identity backend reach your central logging.

Confirm the exact configuration keys, supported backend apps and their versions against the Nextcloud documentation for your release before you commit to a design.

How group mapping controls shares and quotas in Nextcloud

Group mapping decides who can share what, and how much storage each person gets, so it should be designed before any user is synced. In a Nextcloud deployment that uses LDAP or Active Directory, the LDAP app reads directory groups and presents them to Nextcloud as local groups. Those local groups are then the objects that sharing rules, share permissions and per-group quotas attach to. A user's directory group memberships therefore determine what they can do inside Nextcloud, even when the user never touches an admin screen. Confirm in the Nextcloud LDAP documentation which group filter and group search settings your version uses, and test them against a sample of real accounts before you rely on them.

Group membership drives three things. First, share permissions: administrators can restrict who may create link shares, who may create shares with users outside the instance, and who may re-share. Second, sharing restrictions: some settings can limit sharing to members of specific groups, so a finance group and a general staff group can behave differently under the same server. Third, per-group quotas: a user's effective quota is set by the group policy that applies to them, and the outcome depends on how Nextcloud resolves a user who belongs to several groups. Check how your installed version resolves overlapping quotas and sharing settings, because the answer changes the rule you need to write.

The main risk is that directory groups were never designed for file access. Active Directory often contains nested groups, legacy distribution lists, and duplicate groups created for email, printing or a previous system. If Nextcloud imports those groups, a user may inherit a share permission or a larger quota through a group nobody reviewed. Ask the directory owner which groups are authoritative for file access, whether nested membership should be followed, and which groups must be excluded from the Nextcloud import. Decide these questions with the identity team, not after the first complaint about unexpected access.

Before rollout, define a naming convention for every group that Nextcloud will use. A useful convention states the purpose, the scope and the policy owner in the name, so an administrator can tell at a glance whether a group grants sharing rights, sets a quota or is only informational. Keep a register that maps each Nextcloud group to its directory source, its quota and its sharing settings. Changes to the register should go through the same review as directory changes.

Build a test matrix for sharing rules before any production user is enabled. For each role, list the expected outcome for a set of actions: creating an internal share, creating a link share, sharing with an external address, re-sharing a file received from another user, and checking quota on a new account. Include users in one group, in two overlapping groups, in a nested group and in no group. Run the matrix on a staging instance with copies of the directory structure, record the actual results, and resolve every difference before go-live. Repeat the matrix after each change to group filters, sharing defaults or Nextcloud version, since a major upgrade can change behavior.

Securing the SSO path: secrets, TLS and two-factor enforcement

Nextcloud's identity connections are only as strong as the credentials, certificates and fallback paths behind them. The controls below cover the secrets Nextcloud holds, the trust it places in directories and identity providers, and the login paths that must be enforced or closed.

Bind service account privileges

The LDAP bind account lets Nextcloud search the directory, so it should be a dedicated, read-only account limited to the users and groups Nextcloud needs. Confirm it cannot change directory objects or read unrelated attributes. Set a rotation plan that names an owner, a schedule and the steps to update the password in the Nextcloud LDAP configuration without locking out users.

LDAPS and certificate trust

Nextcloud should connect to LDAP or Active Directory over LDAPS or StartTLS, not plain LDAP, so bind credentials and user attributes are encrypted in transit. Confirm the directory certificate chains to a CA that the Nextcloud host trusts, and that the certificate name matches the configured host. Plan renewal of the directory certificate as an operational task.

IdP metadata and signing trust

For SAML and OpenID Connect, Nextcloud relies on the identity provider's metadata, signing certificates and endpoints. Record where each metadata document comes from, who approves changes to it, and how certificate rollovers are scheduled. Check that the configured issuer and redirect URIs match the production hostname exactly, since mismatches are a common cause of failed logins.

OIDC client secret and SAML key storage

The OpenID Connect client secret and the SAML service provider signing key should not sit in shared documents or in version control. Restrict file permissions on the Nextcloud configuration, keep backups of the configuration encrypted, and record who can read them. Rotate the client secret or key on a set schedule and after any staff change that touched them.

Two-factor enforcement by group

Two-factor authentication can be enforced for specific groups instead of all users, which lets administrators phase the rollout and protect privileged accounts first. Decide which groups must enroll, such as administrators and users with external sharing rights, and test enrollment with a pilot group. Confirm the second factor methods offered meet your policy before enforcing them broadly.

App passwords and client access

Desktop, mobile and WebDAV clients often need app passwords when single sign-on is in use, because they cannot complete a browser login. Decide whether app passwords are permitted, which clients may use them, and how users revoke them when a device is lost. Review active app passwords during offboarding so access ends with the directory account.

Local fallback account control

Local Nextcloud accounts can remain active after directory integration and become a bypass around SSO and two-factor policy. Inventory every local account, disable those not needed, and keep one tightly controlled break-glass administrator with its own enforced second factor. Audit login activity for local accounts on a regular schedule and record each review.

How to remove access when people leave in Nextcloud

Disabling a user in the directory is the first step of a leaver process, but it does not by itself end everything that user can reach in Nextcloud. When the LDAP or Active Directory account is disabled, new password logins through the LDAP user backend should fail, and the account stops appearing in provisioning when the directory is synchronized. Existing client sessions, app passwords and share links can continue to work, and sync clients may keep running until their tokens are revoked or the account is disabled in the backend. Treat the directory change as necessary but incomplete, and plan the Nextcloud side of the leaver process as a separate, logged set of actions.

The checklist should run in a fixed order. First, disable the account at the source, whether that is Active Directory, the identity provider behind OpenID Connect or SAML, or the LDAP directory Nextcloud reads from. Second, confirm that login actually fails: attempt a web login and a sync client login with the leaver's credentials in a test or staging instance first, then verify on production using the account's status in the admin user list. Third, revoke app passwords and active sessions under the user's security settings or through the administrator tools available on your release. Fourth, review files and shares the user owns, and transfer ownership of shared folders and team content to a successor so that shares do not depend on a disabled account. Fifth, record who performed each step, when, and what was verified, so the log can support later access reviews.

Expect the sharing review to take the most judgment. Shares created by the leaver may point to external recipients, public links or groups that the business still needs. Decide in advance who approves ownership transfers and whether public link shares with expiry dates should be left alone or disabled. Check your sharing policy settings so that link shares and external sharing defaults match what the organization approved, since those settings control what a leaver's links can expose after departure. Group membership removal should also be reviewed, because group-based quotas and share permissions follow the group rather than the individual.

Behavior differs between releases and between authentication backends, so the checklist should be verified rather than assumed. Build a test user in a non-production instance on the same Nextcloud major version and identity configuration you run in production. Disable that user at the source, then check whether an existing desktop client session, a mobile session, an app password and a public link each still function. Record the results and repeat the test after any upgrade, because session and token handling can change between releases. Confirm the exact revocation steps with the Nextcloud documentation for your version and with your identity provider's token lifetime settings.

Plan for the cases the checklist does not cover on its own. Shared folders synced to a leaver's laptop may hold local copies of confidential files, so pair the account action with a device retrieval or remote wipe process from your endpoint management tooling. Files in the leaver's personal space may need retention before deletion, which ties into your backup and legal hold rules. Ask your implementation partner to include the leaver test and the offboarding runbook in the written scope, so the procedure is documented, owned and rehearsed before the first real departure.

What to monitor, back up and document after SSO goes live

This table lists the operational controls that keep Nextcloud SSO working after go-live, with what each control covers and what evidence the team should keep. Read it as a handover checklist: each row names the signal to watch, the artifact to protect, or the routine to schedule. The main takeaway is that identity failures often surface late, so the monitoring, backups and documentation need to exist before the first user is onboarded.

Area	What to do	Evidence to keep
Login failures and bind errors	Alert on spikes in failed OpenID Connect, SAML or LDAP bind attempts, and on repeated authentication errors for service accounts	Alert history, triage notes and the directory team's response times
Certificate and secret expiry	Keep one calendar covering IdP signing certificates, SAML metadata, OIDC client secrets, LDAP bind passwords and TLS certificates, with owners and renewal dates	Current calendar, renewal tickets and dated change records
Group sync logs	Review directory group sync runs, skipped users and group-to-share or quota mappings after each change and on a fixed schedule	Sync logs, exception reports and sign-off on mapping changes
Provisioning and deprovisioning	Check that leavers lose access and that group changes in the directory reach Nextcloud within the agreed window	Sample test results and deprovisioning tickets
Configuration and identity mapping backup	Back up the Nextcloud config file, LDAP configuration and attribute mapping settings with each change, stored outside the server	Dated configuration exports and restore test notes
Attribute and group rule documentation	Record each attribute mapping, group rule, quota rule and share default, with the owner and the reason for the rule	Versioned mapping document reviewed against the live settings
Periodic access reviews	Review admin accounts, privileged groups, external identities and two-factor enrollment on a schedule set by the data owner	Signed review records and removed-access actions
Upgrade planning	Check identity backends and each app against the target release, upgrade one major version at a time, back up first, and keep third-party apps disabled until confirmed compatible	Compatibility checklist, pre-upgrade backup record and post-upgrade login test results

Questions buyers ask about Nextcloud SSO and identity integration

Can our own team set up Nextcloud SSO and directory integration without a partner?

Yes, many internal teams can, provided they have someone comfortable with both Nextcloud administration and their identity stack. The work is mostly configuration and testing, but the risk sits in the details: attribute mapping, group filters, how deprovisioning behaves and how two-factor enrollment interacts with SSO. Ask yourself whether your team has built this integration before, has a test environment that mirrors production directory structure, and can own the result after go-live. If any of those answers is no, a fixed-scope engagement can cover the build and knowledge transfer. Confirm your in-house skills against the scope before deciding.

What drives the cost and effort of a Nextcloud identity integration?

The main drivers are directory complexity, number of identity sources, group design and the compliance evidence you need. A single Active Directory forest with clean group membership is far simpler than several forests, nested groups used for share and quota rules, or a separate IdP that brokers logins. Each additional source adds mapping rules, test cases and failure modes. Compliance evidence, such as documented provisioning and deprovisioning records or access reviews, adds documentation and verification work. Ask any provider to break its quote down by source, group logic and evidence deliverables so you can see which items move the total.

What do we need to provide before an identity integration project starts?

Plan to provide directory administrator access (read access at minimum for LDAP bind accounts), identity provider administrator access for OpenID Connect or SAML client registration, named group owners who can confirm membership rules, test accounts covering each role, and a change window for cutover. Also provide a non-production Nextcloud instance if you have one. Missing any of these usually delays the project more than the technical build itself. Ask the provider to list these inputs in the written scope so responsibilities are clear on both sides before work starts.

Is LDAP or OpenID Connect cheaper to run long term?

Neither is automatically cheaper, because running cost depends on what you already operate. LDAP through Nextcloud's LDAP integration fits well when Active Directory is already the source of truth and you want users to log in with directory credentials. OpenID Connect or SAML fits better when a central identity provider already handles SSO for many applications, which spreads its operating cost across them. Recurring costs include directory or IdP licensing, certificate and secret rotation, monitoring of bind accounts or client settings, and occasional troubleshooting. Compare the operating model of your existing identity stack rather than the protocol in isolation.

How long does a Nextcloud SSO project usually take?

Duration depends on the number of identity sources, how clean your group structure is, how many applications and clients depend on the login flow, and how long your change approvals take. A single directory with well-defined groups usually moves faster than a multi-source design with custom mapping. Testing with real user cases and staged rollout often takes more calendar time than configuration itself. Ask for a timeline in the written scope that separates discovery, build, test, cutover and handover, and name the dates your side must meet, such as group owner sign-off and change windows.

Does Nextcloud Enterprise support change the scope of an identity integration?

Enterprise support changes the support commitments around the platform, not the design of the integration itself. Nextcloud's pricing page lists Enterprise in Standard, Premium and Ultimate tiers with a 100-user minimum and per-user list prices starting at 71.29 euros, 104.99 euros and 204.75 euros per user per year respectively for 100 or more users, with lower rates from 200 users. Those list prices come from Nextcloud's pricing page and are separate from any implementation fee. Confirm with Nextcloud which tier covers the support hours and response times you need, and ask your provider which integration tasks, if any, the subscription changes.

What should a fixed-scope quote for Nextcloud identity integration include?

A fixed-scope quote should list each identity source, the protocol used for each (LDAP, OpenID Connect or SAML), group mapping rules for shares and quotas, provisioning and deprovisioning behavior, two-factor authentication requirements, test cases, cutover steps, documentation and knowledge transfer. It should also name the inputs you must supply, the acceptance criteria, what is excluded, and which costs are one-time versus recurring. Ask whether compliance evidence is included and in what form. Request the quote in writing before work starts, so changes to scope are handled explicitly rather than absorbed silently.

How do we verify that deprovisioning works after go-live?

Verification should be scripted and repeatable, not a one-off check. Test a leaver case by disabling a test account in the directory or identity provider and confirming that its Nextcloud login stops working and its active sessions end. Also confirm that shares and group memberships behave as your policy expects, and record the results as evidence. Check how your chosen method handles users who were never provisioned locally, and confirm the behavior of any cached sessions or app passwords. Ask the provider to include these tests in the acceptance criteria and to hand over the test scripts.

How DeployOpen scopes, builds and hands over Nextcloud identity work

DeployOpen plans, implements, documents and supports Nextcloud identity integration inside your own infrastructure, whether that means LDAP or Active Directory, OpenID Connect, SAML or two-factor authentication. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts, and ongoing support is available as a retainer.

How we scope

Confirm which identity sources exist (LDAP, Active Directory, OpenID Connect provider or SAML identity provider) and who owns each.
Map directory groups to Nextcloud group, share and quota rules, and agree which attributes drive them.
Define provisioning, deprovisioning and two-factor requirements in the written scope before any configuration begins.

How we build

Configure the chosen authentication backend in a non-production Nextcloud instance first, then test login paths end to end.
Test group mapping with representative accounts, including shares and quota behavior for each group.
Verify deprovisioning by disabling a test account in the directory and confirming access ends in Nextcloud.

How we hand over

Document the configuration, attribute mappings, group rules and the known dependencies on the identity provider.
Provide a runbook for adding groups, rotating identity provider settings and handling locked or disabled accounts.
Walk your administrators through the configuration and the test results so they can operate the integration without us.

How we support

Review identity integration again before each Nextcloud major upgrade, since backends and apps can change behavior.
Support changes to directory structure, group mapping or identity provider settings under a retainer if you choose one.
Confirm with us during scoping which support hours and response commitments apply, as these are set in each agreed scope.

Nextcloud SSO and identity integration