LDAP

CYPEX authenticates users against an LDAP directory as an alternative to local (integrated) accounts — the same mechanism that backs Microsoft Active Directory, OpenLDAP, and any other LDAP v3 server. Before a connection is configured, the page simply confirms that no LDAP authentication is set up yet:

No LDAP authentication configured

Click CREATE to start the connection form.

Fill out the connection settings to establish a connection between CYPEX and your directory:

LDAP Configuration — connection settings

URL, Bind dn, Bind password, Base dn, and Search Attribute, filled with example values pointing at a local test directory.

The configuration requires:

• URL — e.g. ldap://ldap:10389 (or ldaps:// for TLS; client certs are read from /certificates if present).
• Bind DN — the distinguished name CYPEX binds as to run the user search, e.g. cn=admin,dc=cybertec,dc=at.
• Bind Password.
• Base DN — the search root, e.g. ou=people,dc=cybertec,dc=at.
• Search Attribute — the attribute matched against the login identifier, e.g. uid. The backend builds the search filter as (<searchAttribute>={{username}}).

To use LDAP to authenticate users and assign rights, there are three modes, exposed as tabs below the connection settings:

One PostgreSQL role for every LDAP user. If the bind succeeds, the user is assigned this role, chosen from the same role dropdown used everywhere else in CYPEX:

Default Role

Every LDAP user that authenticates successfully is assigned the same PostgreSQL role (here: app_user).

The Role Attribute field names the LDAP entry attribute that holds the CYPEX role name directly — e.g. if a user’s cypex_role attribute is set to cypex_admin in the directory, that user is assigned the PostgreSQL role cypex_admin. This is the default tab when the configuration is first created (see the connection screenshot above, where Role Attribute is cypex_role).

Warning

The attribute must resolve to a single string value — the backend reads it as a scalar (user[roleAttribute]) and does not support multiple roles from one attribute. This matters for Active Directory in particular: don’t point Role Attribute at memberOf expecting group-based mapping — it’s multi-valued and won’t behave as a single role name. Use a single-valued custom attribute (e.g. an extensionAttribute), or use Map LDAP role to postgres role below instead.

If the bind succeeds, the user gets the Postgres role mapped from their LDAP role value via cypex.t_ldap_role (a simple ldap_role → postgres_role table, one row per mapping). LDAP Role is free text on the LDAP side; Postgres Role is a dropdown of CYPEX roles:

Map LDAP role to postgres role

Mapping the LDAP group 'Application Designer' to the CYPEX role smi_org_admin. Add more rows with the + icon.

This is the mode that works cleanly with Active Directory’s multi-valued memberOf: pair it with Role Attribute set to memberOf and add one mapping row per AD group DN you want recognized — each login only needs one of the user’s group values to hit a row.

Info

Mapping also affects organization access. A user’s organizations are derived from their PostgreSQL role’s mappings (see Roles & Capabilities), so the role an LDAP user resolves to — whichever mode is active — decides both their capabilities and which organizations’ data they can see. Mapping to an admin role also makes the user a CYPEX admin.

The same mapping and authentication process applies to the API, not just the frontend login form.

LDAP in CYPEX is protocol-generic — there is no AD-specific code path, only the generic LDAP v3 client above. Pointing it at Active Directory typically means:

All three authentication paths can be configured at once, and each user resolves to exactly one PostgreSQL role regardless of which path they came in through:

• Local (integrated) accounts and LDAP share the same login form fields. Login looks up the identifier as a local user first (cypex_api_internal.t_user_integrated); if no local user matches, it falls back to an LDAP bind attempt with the same identifier and password. A local account with a matching username always wins — it is checked first, and LDAP is never attempted for an identifier that already has a local account.
• OIDC SSO is fully separate, additive via its own per-organization sign-in button (see the OIDC setup guide) — it never shares the username/password fields with local or LDAP auth.
• There is no precedence conflict between LDAP and OIDC: an organization can have LDAP configured platform-wide and one or more OIDC providers enabled at the same time. A given human user typically only uses one path, but nothing in the platform prevents both being live simultaneously.

• OIDC setup guide — the other federated login path, and the JWT/RLS trace both paths ultimately feed.
• SSO (architecture) — how OIDC coexists with local auth; the same local-auth-first precedence applies to LDAP.
• Roles & Capabilities — how a PostgreSQL role drives both capabilities and organization access.
• Users — local fallback users.
• User management — the broader user-concept overview (Case A/B/C) this page’s LDAP mode is “Case C”.