LDAP & Active Directory

Drovio Server can authenticate users through an LDAP directory or a Microsoft Active Directory. Accounts are created automatically the first time someone signs in, so there is nothing to provision by hand. The field-by-field settings are described in the Configuration reference.

LDAP can run alongside local accounts and alongside SSO. It applies to the Drovio app only, as the web client requires no account.

How a sign-in is processed

Each sign-in performs the classic bind, search, bind sequence:

1. Drovio Server binds to the directory with the service account.
2. It searches for the user under base, using search_filter, where {0} is replaced by the email address typed in the sign-in form.
3. It binds a second time with the user's own distinguished name and the password they supplied. That second bind is the actual authentication.

Three consequences to keep in mind when writing your filter

• The search runs on the whole subtree below base.
• The filter must resolve to exactly one entry. If it matches several entries, the sign-in is refused rather than authenticating with an arbitrary match.
• Users sign in with an email address. The value is trimmed and lowercased, and it has to be syntactically valid: a bare sAMAccountName is rejected before the directory is even contacted.

Only the distinguished name is read back from the directory. No attribute is fetched, and the bind mechanism is simple, so Kerberos and the other SASL mechanisms are not available.

Configure the connection

The settings sit under Users in the administration panel, in the LDAP / Active Directory section.

Field in the panel	Configuration key	Example
Status	enabled	true
URL	url	ldaps://ldap.example.com:636
Service Account DN	service_account_dn	cn=drovio,ou=services,dc=example,dc=com
Service Account Password	service_account_password
Base	base	ou=users,dc=example,dc=com
Search Filter	search_filter	see below
CA Certificate	ca_certificate_path	/etc/drovio-server/ldap-ca.pem

The service account only needs the right to search the subtree under base, nothing more.

OpenLDAPActive Directory, by emailActive Directory, by user principal name

(&(objectClass=inetOrgPerson)(mail={0}))

(&(objectClass=user)(mail={0}))

(&(objectClass=user)(userPrincipalName={0}))

The shipped default is (&(objectClass=*)(mail={0})). It works, but narrowing the object class makes the search cheaper and the single-match requirement easier to satisfy.

Changes take effect on the next sign-in. No restart is needed.

There is no test button

The panel cannot validate the configuration on its own. Save it, have a user sign in, then read the server log. Every failure is logged with the step that failed, which the table in Troubleshooting maps back to the field to check.

Connect over LDAPS

Use ldaps:// on port 636. Plain ldap:// sends credentials unencrypted, and the server warns about it in the log once per lifetime.

StartTLS is not supported. The two modes are cleartext on ldap:// and implicit TLS on ldaps://.

ca_certificate_path points at the certificate to trust. It accepts PEM or DER, and a PEM bundle holding a whole chain. You can point it at a certificate authority or directly at the directory's own certificate, which is what makes a self-signed certificate work.

The file replaces the system trust store, it does not extend it

When ca_certificate_path is set, the LDAP connection trusts only what that file contains. A directory certificate issued by a well-known public authority stops validating unless its chain is in the file too. Leave the setting empty to use the Java trust store instead.

The certificate must also match the host in url, and the setting is only read for ldaps:// URLs. Setting it next to an ldap:// URL does nothing.

Automatic account provisioning

On the first successful sign-in, Drovio Server creates the account:

Account field	Value
Email	The address typed in the form
Username	The local part of that address, so jane.doe@example.com becomes jane.doe

No directory attribute is mapped, unlike SAML and OIDC which have their own email_attribute and username_attribute settings. Users can change their username afterwards, and later sign-ins leave that change alone.

No password is ever stored for an LDAP account, and no verification email is sent. Password changes, resets and password policy stay entirely with your directory: the administration panel offers no credential editing for these accounts.

Check your license pool before opening LDAP to a large directory

Provisioning follows users.license_allocation like any other account. If no seat is free, the account is still created, just without a license. The end user is alerted over the Drovio app and the server log records:

Could not automatically allocate a license: no more free license left...

Restrict access to a group or an organizational unit

There is no dedicated setting and none is needed. Both existing fields do the job:

• By subtree. Point base at the branch that holds the authorized users, for instance OU=Drovio Users,DC=example,DC=com. Anything outside it is invisible to the search.

• By group membership. Add a clause to the filter:

  (&(objectClass=user)(mail={0})(memberOf=CN=Drovio,OU=Groups,DC=example,DC=com))
  

  On Active Directory, use the memberOf:1.2.840.113556.1.4.1941:= matching rule instead of memberOf to include nested groups.

The check runs at every sign-in. Removing someone from the group locks them out immediately. Keep in mind that the filter still has to match exactly one entry.

Combine with other sign-in methods

Combination	Behavior
LDAP and local accounts	The directory is tried first. If it rejects the credentials, the same email and password are then tried against the local account
LDAP and SAML	Supported, they run on separate paths
LDAP and OIDC	Supported, they run on separate paths

To force directory-only authentication, disable users.auth.local.

Revoke access

Removing or disabling the account in the directory stops the sign-in at the very next attempt. What it does not do is remove anything on the Drovio side: there is no reconciliation job. The user record and its license seat both remain, if users.license_allocation is disabled or new_user mode is set.

To free the seat, delete the user from the Users tab of the administration panel, or enable users.remove_inactive to have unused accounts periodically cleaned up.

Operational limits

A few behaviors are fixed and worth knowing when you size or firewall the deployment:

Behavior	Value
Connections per sign-in	Two, one for the service account and one for the user. They are not pooled
Connect timeout	30 seconds
Read timeout	60 seconds
Referrals	Ignored

Referrals being ignored matters in a multi-domain Active Directory forest: users whose account lives in a different domain than the one in url are not found. Point Drovio Server at a Global Catalog instead, on ldaps:// port 3269, or run one server per domain. The Global Catalog exposes only a partial set of attributes, which is enough here since only the distinguished name is used.