Operator authentication via LDAP

The LDAP plugin lets ACCELERO operators log in by validating their credentials against an external LDAP server (for example, OpenLDAP or Active Directory), instead of relying exclusively on the passwords stored locally in ACCELERO. Authentication is done by LDAP bind: ACCELERO connects to the directory and tries to authenticate the user with the credentials provided at login.

Availability

This integration is provided as a plugin (ldap) and must be installed and enabled by the IONGRADE technical team. Contact support to check compatibility with your ACCELERO version.

Compatibility

Current plugin version: 0.0.1 — compatible with ACCELERO 2.16.0 or higher (according to manifest.json).

Plugin at an early stage

This is version 0.0.1 of the plugin. The package only brings the LDAP connection and authentication mechanism (three library classes: LdapConfiguration, LdapFacade and LdapUser). It does not include a configuration screen, routes, menu items, migrations, or the link to the login screen: no part of ACCELERO calls this mechanism in version 0.0.1. For operator login to start using LDAP, the IONGRADE technical team needs to integrate the mechanism into the environment's login flow. Confirm with support what is available in your installation.

---

What the plugin does

Feature	What happens in ACCELERO
Operator authentication via LDAP	The mechanism connects to the LDAP server and tries a bind with the username and password it receives. If the bind succeeds, authentication is accepted
User query in the directory	The plugin can query the directory (search by uid) using an administrative account, returning the attributes of the user registered in LDAP

Main benefit

Centralizes operator authentication in the corporate directory (LDAP/Active Directory), avoiding isolated passwords in ACCELERO and taking advantage of the organization's existing password policies.

Scope: operators, not people

LDAP authentication applies to operators (users who access the ACCELERO system). It does not handle the people registry or physical access control — only login to the software.

---

Configuration

The parameters used by the authentication mechanism (LdapConfiguration class) are:

Parameter	Description
Server (server)	Address of the LDAP server to which ACCELERO connects
Administrator user (adminUser)	Administrative account (root) used to query the directory (cn field of the admin account)
Administrator password (adminPassword)	Password of the administrative account
Domain components (dc)	List of domain components (dc) that form the directory base. Ex.: ["empresa", "com"] results in the base dc=empresa,dc=com

No configuration screen

In version 0.0.1 there is no screen in ACCELERO to enter these parameters, and the plugin does not read them from any saved configuration either: whoever integrates the mechanism into the login needs to create the LdapConfiguration with the directory values. That is why there is no menu path for the LDAP configuration.

PHP LDAP extension

The mechanism uses PHP's ldap_* functions. The ACCELERO server needs the PHP LDAP extension installed; without it, the connection does not happen.

---

How authentication works

The mechanism (LdapFacade class) operates on top of the standard LDAP functions, using LDAP version 3.

Connection

The mechanism connects to the address configured in Server and pins the protocol to version 3 (LDAP_OPT_PROTOCOL_VERSION = 3).

Authentication bind (operator login)

When authenticating, the plugin builds the user DN in the format:

cn=<user>,ou=users,<domain base>

where <domain base> is derived from the configured dc components (e.g., dc=empresa,dc=com). It then performs a bind with that DN and the provided password:

• Successful bind → authentication accepted.
• Refused bind → authentication denied.

Expected directory structure

The current version builds the user DN with the fixed organizational unit ou=users. The LDAP directory must expose the users under that OU for the bind to work in the expected format.

User query (directory search)

To query a user's data, the plugin performs an administrative bind (using the Administrator user and the Administrator password) and then runs a search:

• Search base: ou=users,<domain base>
• Filter: (uid=<user>)
• Result: the first record found is returned as a directory user, with its DN and the attributes filled in (each attribute receives the first available value).

If the administrative bind fails, the search returns no result, or an error occurs, the event is recorded in the error log and no user is returned.

---

Use cases

Enable LDAP authentication for the operators

1. Request that IONGRADE install the ldap plugin and integrate the mechanism into the environment's login.
2. Provide the technical team with the directory data: the server address, the administrator account and password, and the domain components (dc).
3. Make sure the operators are registered in LDAP under the ou=users OU, with the cn/uid matching the login user.
4. Validate the login of a test operator before releasing it for everyone.

Correspondence between the operator and the directory

The mechanism does not look up the ACCELERO operator registry: it only receives the username text and the password, and uses that same text in both operations:

Operation	How the username text is used
Authentication (bind)	As cn, in the DN cn=<user>,ou=users,<domain base>
Data query	As uid, in the filter (uid=<user>) under ou=users,<domain base>

In practice, the directory record must have cn and uid equal to the username the operator types. Version 0.0.1 brings no rule that associates the result with a local operator (by e-mail, employee ID, or another attribute): that association is up to whoever integrates the mechanism into the login.

---

Best practices

• Dedicated administrative account: use a service account with read-only permission on the directory for the queries, instead of a broad administrative account.
• Secure communication: prefer LDAP over TLS (LDAPS) between the ACCELERO server and the directory, so as not to transmit credentials in plain text. Confirm TLS support with the technical team.
• Test operator: keep a test operator in the directory to validate the integration after changes to LDAP.
• Directory structure: keep the operators under the ou=users OU expected by the plugin.

---

Troubleshooting

The operator cannot log in via LDAP

Possible causes:

• The user DN does not match the expected format (cn=<user>,ou=users,<dc>).
• The user is not under the ou=users OU in the directory.
• Incorrect password or account locked in LDAP.
• LDAP server inaccessible from the ACCELERO server.

Solution:

1. Confirm the server address and the network connectivity (LDAP/LDAPS port) between ACCELERO and the directory.
2. Check whether the user exists under ou=users and whether the cn/uid matches the login user.
3. Test the credentials directly in the directory.

User query returns no data

Possible causes:

• The administrative bind failed (incorrect administrator user/password).
• The (uid=<user>) filter does not find the record.
• The search base (ou=users,<dc>) is incorrect.

Solution:

1. Check the configured Administrator user and Administrator password.
2. Confirm the domain components (dc) — the base must reflect the actual structure of the directory.
3. Consult the ACCELERO error log, where the LDAP error messages are recorded.

---

Integration with other modules

Operators

LDAP authentication acts on the login of Operators — users who access the ACCELERO system. Check how operators are registered and how their permissions are defined.

Other authentication integrations

If the organization uses Microsoft Entra ID (Azure AD), also consider the Azure OAuth integration as an alternative for operator authentication.

---

Next Steps

• Operators — Understand operator registration and permissions
• Azure OAuth — Alternative for operator authentication via Microsoft Entra ID
• Plugins — Learn more about the ACCELERO plugin system