OpenLDAP

Audience: Low-code Engineers, System/Security Administrators

Skill Prerequisites: Actions, Tokens, Connectors, Users

The OpenLDAP add-on lets users sign in to your app with their account on an LDAP server, such as OpenLDAP. It adds an OpenLDAP Connection connector type, which holds the server and a service account, and the User Login (OpenLdap) action. The action finds the user in the directory, checks their password, creates or updates a matching site account, and signs the user in.

note

This add-on is the OpenLDAP add-on (PlantAnApp.OpenLdap). It's installed separately and needs the OPENLDAP feature in your license. If it isn't licensed, the action fails with a "not licensed" error. If you don't see the action in the User Management group, or the OpenLDAP Connection connector type, the add-on isn't installed.

Choosing an action

Action	What it does	Use it to
User Login (OpenLdap)	Checks the password against an LDAP server, creates or updates a matching site account, and signs the user in. It doesn't map groups to roles.	Let users sign in with the account they use for other company systems.

To sign in users with a site account, use User Login from the User Management add-on. For Microsoft Active Directory with group to role mapping, use the Active Directory add-on.

For a step-by-step guide with screenshots, see OpenLDAP.

Setting it up

1. Create the connector. Add a connector of type OpenLDAP Connection. See Connectors, or create it with Add Connector.

   Setting	Description
   UserDN	The full DN of a service account that can search the directory and read user attributes, for example uid=service,ou=people,dc=example,dc=com.
   Password	The service account's password. It's stored encrypted.
   LDAP Server	The LDAP server's host name, for example ldap.example.com.
   LDAP Port	The port. The default is 389. It must be a number.

2. Test the connector. Test Connector checks that the service account can connect to the server.

3. Build the login form. Add Username and Password fields and a button. Make the password field required, and use HTTPS on the page.

4. Add the action. Add User Login (OpenLdap) to the button. Pick the connector, set Base DN to where the users are, for example ou=people,dc=example,dc=com, and set User Discriminator to the attribute that holds the username, for example uid. Keep a Platform User Prefix, such as the default OL-.

5. Map the profile values. In Additional User Attribute Mapping, map at least mail to email, and the name attributes, for example givenName to firstname and sn to lastname. See Profile values.

6. Handle errors. Add On Error actions, for example a message or a redirect. End users only see a general login failure. The detailed reason is in the log and in the [<Output Token Name>:Exception] token.

The action isn't available in Automation (workflows and scheduled jobs), because signing in needs a browser to receive the login cookie.

Profile values

The first sign-in creates a site account called Platform User Prefix plus the username, for example OL-jsmith. It's authorized and gets a random password, so the user can only sign in through the action.

On every sign-in, the action resets the basic profile values first. The first and last name are set to the username, and the email is cleared. Then it applies the attribute mapping. So if you don't map mail and the name attributes, the user's email is cleared and their name is replaced with the username each time they sign in.

The profile property names firstname, lastname, email (or mail) and displayname set those basic values. Any other name is saved as a profile property with that name. LDAP attribute names, and User Discriminator, must match the case the server returns.

The action doesn't add or remove roles. Use Grant User Role after it if you need them.

Security

• The connection isn't encrypted. The action uses a plain LDAP connection without SSL or StartTLS. The service account password and the user's password travel over the network as plain text. Only use it on a network you trust.
• Keep the prefix. If Platform User Prefix is empty, an LDAP user whose username matches a local site account signs in as that local account. A numeric username can also match a user ID. See Security.
• Site account status isn't checked. Once the LDAP server accepts the password, the user is signed in, even if the site account is unauthorized or locked. To block a user, disable them on the LDAP server or move them out of Base DN.
• Reject empty passwords. Some LDAP servers treat a sign-in with an empty password as anonymous. Make the password field required, and make sure your server rejects anonymous binds.
• Email as username isn't supported. If the site uses the email as the username, sign-ins after the first one fail. Don't use the add-on on such sites.

For all settings and an example, see User Login (OpenLdap). For all add-ons, see Add-ons.

Revised 10/02/2026