How to Configure LDAP Authentication in ownCloud Infinite Scale

What does LDAP authentication mean in Infinite Scale?

ownCloud Infinite Scale (oCIS) authenticates browser and client sessions through OpenID Connect (OIDC). LDAP can provide the directory users and credentials behind the built-in oCIS identity provider, or it can sit behind an external OIDC provider such as Keycloak. The right configuration depends on whether you need a small deployment with a simple login flow or a production identity platform with broader controls.

That distinction is useful because oCIS is not ownCloud Server Classic. Classic tutorials that configure LDAP through the web admin page or occ ldap:* do not configure oCIS. In oCIS, settings are deployment environment variables or service configuration, and multiple services may need a consistent view of the same directory.

ownCloud’s versioned IDP service documentation says the built-in provider can use an external LDAP backend. Its security guidance recommends an external OIDC provider for larger or production installations. This guide uses the oCIS 8.2 documentation; check the matching documentation for your installed release before applying variables, since defaults and deployment examples can change.

Which authentication design should you choose?

If you already run Keycloak or another OIDC provider, connecting it to the directory is usually the cleaner production route. If this is a small deployment and the built-in provider’s limits are acceptable, configure the IDP’s LDAP backend and test it before opening access to users.

What should you gather before editing oCIS?

• The exact oCIS version and deployment method, such as Docker Compose, Kubernetes, or a supervised binary process.
• The LDAP server’s DNS name, TLS certificate chain, and LDAPS endpoint. Prefer ldaps:// with certificate validation; do not disable validation to hide a trust problem.
• A least-privilege bind account and its full distinguished name (DN). The account should be able to search the user and group branches oCIS needs, without unnecessary write permissions.
• The user search base DN, search scope, login attribute, object class, email and display-name attributes, and a stable unique user ID attribute. Confirm these against actual directory entries.
• The group base DN and membership attribute if users’ LDAP groups should appear in oCIS.
• A backup of the current oCIS configuration and a tested administrator sign-in that does not depend on the LDAP change.

Stable identity mapping deserves particular care. A display name or email can change; a unique ID should remain attached to the same person. If oCIS sees a different identifier after the change, an existing person may appear as a new account instead of inheriting the expected identity and access.

How do you connect the built-in IDP to an external LDAP server?

For a small deployment using oCIS’s built-in IDP, set the IDP-scoped LDAP variables in the environment or service configuration used by your deployment. The values below are examples only. Replace the host, DNs, certificate path, and schema names with values from your directory.

IDP_LDAP_URI=ldaps://ldap.example.net:636
IDP_LDAP_TLS_CACERT=/etc/ocis/certs/directory-ca.pem
IDP_LDAP_BIND_DN=uid=ocis-reader,ou=service,dc=example,dc=net
IDP_LDAP_BIND_PASSWORD=<load-from-your-secret-store>
IDP_LDAP_BASE_DN=ou=people,dc=example,dc=net
IDP_LDAP_SCOPE=sub
IDP_LDAP_LOGIN_ATTRIBUTE=uid
IDP_LDAP_EMAIL_ATTRIBUTE=mail
IDP_LDAP_NAME_ATTRIBUTE=displayName
IDP_LDAP_UUID_ATTRIBUTE=entryUUID
IDP_LDAP_UUID_ATTRIBUTE_TYPE=text
IDP_LDAP_OBJECTCLASS=inetOrgPerson

The IDP reference documents these settings, including the URI, CA certificate, bind DN and password, user base DN, scope, login attribute, UUID attribute, and object class. The example assumes the directory provides a textual entryUUID; Active Directory and other schemas may require different mappings. Do not copy entryUUID just because it appears here.

Store the bind password as a deployment secret or in the secret mechanism recommended for your platform. Avoid committing it to a public Compose file, repository, or ticket. Keep the CA certificate readable by the oCIS process, and retain certificate verification. The IDP’s INSECURE setting disables LDAP TLS certificate validation and is explicitly not intended for production.

Also match account-disable behavior to your directory. The IDP documentation lists IDP_USER_ENABLED_ATTRIBUTE; its default is an ownCloud-specific attribute name. If your directory uses a different enabled/disabled flag, map that actual attribute. Review the users service’s USERS_LDAP_DISABLE_USER_MECHANISM as well. Depending on the directory, the documented choices are attribute-based handling, group-based handling, or none; choose deliberately so a disabled account is not treated as active because of a schema mismatch.

Do user and group lookups need LDAP settings too?

Often, yes. Successful password verification and user discovery are related but separate jobs. The IDP authenticates the login; the oCIS users and Graph services provide user and group information to the platform. If you use an external directory as oCIS’s identity source, configure the users and Graph LDAP backends to read the same directory and map the same users consistently.

For the users service, review USERS_DRIVER=ldap and its service-scoped settings, such as USERS_LDAP_URI, USERS_LDAP_CACERT, USERS_LDAP_BIND_DN, USERS_LDAP_BIND_PASSWORD, USERS_LDAP_USER_BASE_DN, USERS_LDAP_USER_SCHEMA_ID, and USERS_LDAP_USER_SCHEMA_USERNAME. Set mail, display-name, scope, and group variables when your deployment needs them. The exact schema names must match the directory rather than a generic example.

The Graph service has its own LDAP settings. For an existing directory that oCIS should read without managing, set GRAPH_LDAP_SERVER_WRITE_ENABLED=false and configure the Graph LDAP connection and schema. ownCloud documents this as the read-only pattern for connecting to an existing LDAP server. Leave writes disabled unless you have deliberately prepared a compatible LDAP schema and want oCIS to create or change directory objects.

Use the service-specific variable prefixes or the documented global OCIS_LDAP_* variables carefully. Global variables can affect several services at once. For a first integration, explicit per-service settings make it easier to see which service is failing and prevent an unintended write or schema assumption. The users service reference and Graph service reference list the release-specific names and defaults.

How do you apply the settings safely?

1. Save a copy of the current environment file, service unit, or Compose configuration. Record how to revert it.
2. Add the LDAP variables to the actual oCIS service definition. Do not replace the rest of an existing Compose environment block with this example; merge the settings into the deployment you already run.
3. Check that the certificate file exists inside the container or host namespace where the oCIS service reads it. A host path is not automatically visible inside a container.
4. Validate the bind account and search base against LDAP before restarting oCIS. Use the same server hostname, base DN, and login attribute configured for the service.
5. Restart oCIS using your deployment’s normal process so the services receive the new environment. In a multi-service or multi-node deployment, confirm the relevant services on every instance use the intended configuration.
6. Test with one permitted LDAP account and one account that should not sign in. Keep an existing administrator session open until the new login path has been verified.

For a direct directory check, ldapsearch can test the bind and user filter without putting the password on the command line:

ldapsearch -H ldaps://ldap.example.net:636 \
  -D 'uid=ocis-reader,ou=service,dc=example,dc=net' -W \
  -b 'ou=people,dc=example,dc=net' '(uid=alice)' dn uid entryUUID mail

Use the login attribute and base DN you intend to configure. A successful query confirms network, TLS, bind, and search behavior for that query; it does not prove that every oCIS service uses the same mapping.

How do you know the configuration is working?

Judge the result by more than whether a login page appears. Sign in through the normal oCIS Web flow with a test directory user, open a file, and confirm the expected username and profile details. If groups drive shares or space access, verify one known group membership as well. Then test a wrong password and an LDAP account that is disabled or outside the allowed user search. Those accounts should not gain access.

Review the oCIS service logs for LDAP connection, TLS, bind, and user lookup errors. A valid LDAP bind followed by a failed oCIS login often points to a search filter, base DN, user identifier, or OIDC-to-user mapping mismatch. In a production pilot, verify an existing user’s files, shares, and group-based access before migrating a larger group. A successful authentication check alone does not verify that existing account identity and authorization were preserved.

What should you change when login still fails?

• TLS or connection errors: Confirm that the oCIS host resolves and reaches the LDAP server, that the port and scheme match, and that the CA file contains the issuing certificate chain. Keep verification enabled.
• Bind succeeds but no user is found: Test the exact user base DN, scope, object class, login attribute, and filter. A correct bind DN does not imply that the search is looking in the correct branch.
• LDAP accepts the password but oCIS cannot resolve the account: Compare the IDP login identifier and the users-service username or stable ID mapping. Keep a stable identifier and do not switch from username to email casually.
• Login works but group-based access is wrong: Check the users and Graph group base DN, group object class, member attribute, and whether the Graph backend is configured read-only or write-enabled as intended.
• You need MFA, centralized sessions, or broader identity controls: Move LDAP authentication to an external OIDC provider and configure oCIS to trust that issuer. The built-in IDP is intentionally limited; ownCloud recommends an external provider for larger installations and notes that the built-in provider does not offer the full capabilities of an external identity service.

Do not enable PROXY_ENABLE_BASIC_AUTH as a shortcut for a production browser login. The proxy documentation lists Basic Auth as a supported request scheme but says to use it only for development, not production. For standard oCIS sign-in, use the built-in OIDC provider only where its limitations fit, or connect an external OIDC identity provider backed by LDAP.

What is outside this setup?

LDAP authentication does not automatically make every LDAP administrative function available in oCIS. User and group provisioning, group synchronization, write access, password changes, disabled-account rules, and mapping existing users require their own compatible service settings and LDAP schema. For external OIDC auto-provisioning, ownCloud also requires a stable user claim and a write-enabled Graph backend when the chosen flow creates accounts. Review the proxy documentation before enabling that behavior.

Make one change at a time, test with a small account set, and confirm both authentication and identity mapping before broad rollout. If the oCIS release, LDAP schema, or identity provider differs from the assumptions in the example, follow that exact release’s configuration reference rather than reusing the sample unchanged.