User Login (OpenLdap)

Audience: Low-code Engineers

Skill Prerequisites: Actions, Tokens, Connectors, Users

Signs a user in with their account on an LDAP server, such as OpenLDAP. The action finds the user in the directory and checks their password. If it's valid, it creates or updates a matching user account on the site and signs the user in.

On success, the [User:*] tokens, such as [User:UserID] or [User:FirstName], refer to the signed-in user in the actions that follow.

For a step-by-step setup guide, see OpenLDAP.

note

This action is part of the OpenLDAP add-on (PlantAnApp.OpenLdap). The add-on is 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, the add-on isn't installed.

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

Typical Use Cases

• Let users sign in with the username and password they already use for other company systems
• Create site accounts automatically the first time a directory user signs in
• Copy the user's name, email and other attributes from the directory to their site profile

Don't use it to

• Sign in users with a site account. Use User Login instead.
• Sign in users from Microsoft Active Directory with group to role mapping. Use User Login (MS Active Directory) instead.
• Give roles based on directory groups. This action doesn't map groups to roles. Use Grant User Role after it.
• Sync all directory users in advance. The action only creates or updates the user who signs in.

Related Actions

Action Name	Description
User Login	Signs in a user with a site username and password.
User Login (MS Active Directory)	Signs in a user with an Active Directory account, with group to role mapping.
Add Connector	Creates a connector, such as the OpenLDAP connector.
Test Connector	Checks that the service account can connect to the LDAP server.
Grant User Role	Adds roles to the user after sign-in.
Update User Profile	Saves more profile properties after sign-in.

Input Parameter Reference

Parameter	Description	Supports Tokens	Default	Required
Service Connector	The OpenLDAP Connection connector. See The connector. When using an expression, the value must be the connector ID.	Yes	none	Yes
Base DN	Where to search for the user, for example ou=people,dc=example,dc=com, or the root dc=example,dc=com. The search includes everything below it.	Yes	empty string	Yes
User Discriminator	The LDAP attribute that holds the username, for example uid, cn or sAMAccountName.	Yes	uid	Yes
Platform User Prefix	Text added in front of the LDAP username to make the site username, for example OL- turns jsmith into OL-jsmith. Keep a prefix. See Security.	Yes	OL-	No
Username	The LDAP username, which is the value of the User Discriminator attribute. Pick a field, or switch to an expression and use a token.	Yes	empty string	Yes
Password	The user's LDAP password. Pick a field, or switch to an expression and use a token.	Yes	empty string	Yes
Additional User Attribute Mapping	Pairs of an LDAP attribute name and a site profile property name, for example mail and email. See Profile values.	Yes	empty	No
Output Token Name	The name of the token to save the LDAP user details in, for example LdapUser.	No	empty string	No
On Error	Actions to run when the sign-in fails. The [<Output Token Name>:Exception] token holds the full error and [<Output Token Name>:ExceptionMessage] the message. See Errors.	No	empty	No

Output Parameters Reference

Token	Description
[<Output Token Name>:$json]	The LDAP user details as JSON, including all attributes the directory returned and the mapped attributes.
[<Output Token Name>:IsNewUser]	True if the site account was created during this sign-in, otherwise False.
[User:*]	After the action, these tokens refer to the signed-in user.

The connector

Create a connector of type OpenLDAP Connection with:

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.

Test Connector checks that the service account can sign in to the server.

How the sign-in works

1. The action connects to the LDAP server and signs in with the service account.
2. It searches Base DN for entries where User Discriminator equals Username. Exactly one entry must match.
3. It signs in to the LDAP server as that entry, with the user's password. If the password is wrong, the sign-in fails.
4. It looks for a site account called Platform User Prefix plus the username, for example OL-jsmith.
5. If there's no such account, it creates one. The account is authorized and gets a random password, which nobody knows, so the user can only sign in through this action.
6. It updates the profile. See Profile values.
7. It signs the user in with a persistent login cookie.

Profile values

On every sign-in, the action first resets the basic profile values:

• First name and last name are set to the username.
• Display name is set to first name and last name, separated by a space.
• Email is cleared.

Then it applies Additional User Attribute Mapping. These profile property names are special:

Profile property name	Sets
firstname	The first name
lastname	The last name
email or mail	The email
displayname	The display name

Any other name is saved as a profile property with that name. These special names are compared without regard to case. LDAP attribute names must match the case the server returns. If the LDAP entry doesn't have the attribute, the value is empty.

Always map at least mail to email, and the name attributes, for example givenName to firstname and sn to lastname. Otherwise the user's email is cleared and their name is replaced with the username every time they sign in.

Errors

If anything goes wrong, end users see Login failed! Invalid username or password (status LOGIN_FAILURE). Administrators see a technical message. The detailed reason, such as User not found. or Multiple matches found. Could not login., is in the log and in the [<Output Token Name>:Exception] token.

The On Error actions run first. If none of them ends the flow, for example with a redirect, the error is raised after they finish.

Security

• The connection isn't encrypted. The action uses a plain LDAP connection with basic authentication and doesn't use 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, such as a private network between the web server and the LDAP server.
• Keep the prefix. The site account is looked up by the prefixed username. If Platform User Prefix is empty, an LDAP user whose username matches a local site account signs in as that local account. The lookup also treats a number as a user ID and falls back to matching an email, so an LDAP username such as 1 could sign in as the account with that ID. The same can happen if a local account was created with the prefix, for example OL-admin.
• Site account status isn't checked. Once the LDAP server accepts the password, the user is signed in, even if the site account was unauthorized or locked on the site. To block a user, disable them on the LDAP server or move them out of Base DN.
• Check for an empty password. Some LDAP servers accept a sign-in with a DN and an empty password as an anonymous sign-in. Make sure the password field is required on your form, and that your server rejects anonymous binds.
• Use HTTPS on the login page, because the password is sent from the browser.

Considerations

• Usernames are used in the search as they are. Characters such as *, ( or ) in Username change the LDAP search. If more than one entry matches, the sign-in fails.
• Email as username. If the site is set to use the email as the username, the account is created with the email as its username. Later sign-ins look for the prefixed username, don't find it, and fail. Don't use this action on such sites.
• Attribute names. User Discriminator and the LDAP attribute names in the mapping must match the names the server returns, including case. Otherwise the sign-in fails.
• Multi-value attributes aren't supported in the mapping. Map attributes with a single value.
• No role mapping. Unlike the Active Directory action, this action doesn't add or remove roles.
• Not in Automation. Workflows and scheduled jobs run without a web request, so there's no browser to sign in.

Examples

tip

To understand how to use the below examples, please see Running Examples.

1. Sign in LDAP users and copy their profile

This action signs in users from ou=people,dc=example,dc=com with the values of the Username and Password fields. It copies the email, first name and last name from the directory. Replace the connector ID with your own.

{
    "Title": "User Login (OpenLdap)",
    "ActionType": "PlantAnApp.OpenLdap.UserLogin",
    "Description": "Sign in with the company LDAP account",
    "Parameters": {
        "ServiceCredentials": {
            "Entry": "00000000-0000-0000-0000-000000000000"
        },
        "BaseDN": "ou=people,dc=example,dc=com",
        "UserAttributeDiscriminator": "uid",
        "PlatformUserPrefix": "OL-",
        "Username": "[Username]",
        "Password": "[Password]",
        "UserAttributeMapping": [
            {
                "name": "mail",
                "value": "email"
            },
            {
                "name": "givenName",
                "value": "firstname"
            },
            {
                "name": "sn",
                "value": "lastname"
            }
        ],
        "OutputTokenName": "LdapUser"
    }
}

Revised 09/28/2026