Skip to content

LDAP and Active Directory

Directory authentication, lookup and password reset. Works against Active Directory or any LDAP server.

CategoryIdentity
AuthenticationBind account
ReachesYour directory server, on your network
Needs an agentYes, on managed hosting
Demo modeNo

identity.authenticate, identity.lookupUser, identity.resetPassword

Which lights up:

  • Password resets from the kiosk, both self-verified by card and staff-verified at the desk.
  • Directory lookups.
  • Authentication against the directory where you want it.

Active Directory and other LDAP servers are internal by definition.

Self-hosted on that network: reaches it directly.

Managed hosting: needs a connector agent inside your network.

The connector uses a service account to search, then binds as the user to verify their credentials. So the service account only needs to read, except for password reset, which needs the right to change other users’ passwords.

Create a dedicated account. Do not use a domain administrator.

For Active Directory, the minimum is:

RightFor
Read on the user OUSearch and lookup
Reset password on the user OUOnly if you want kiosk password resets

Delegate the reset right on the specific OU containing students, not at the domain root. The Delegation of Control wizard does this properly in about a minute, and it is the difference between a credential that can reset a student’s password and one that can reset the principal’s.

Password reset over plain LDAP sends the new password unencrypted. Active Directory refuses password changes over an unencrypted connection anyway, which is the correct behaviour.

Use ldaps:// on port 636. If your domain controller’s certificate is from your internal CA, the server running Plugboard or the agent needs to trust that CA.

Admin, Connectors, LDAP / Active Directory, Configure.

FieldDefaultValue
urlThe LDAP URL, for example ldaps://dc.school.edu:636
baseDNSearch base, for example ou=Users,dc=school,dc=edu
userAttruidThe login attribute. Use sAMAccountName for Active Directory
bindDNThe service account DN used to search

userAttr catches people out. The default uid is right for OpenLDAP and wrong for Active Directory, where you almost always want sAMAccountName, or userPrincipalName if your users sign in with their email address.

FieldValue
bindPasswordThe service account password

Save and test. Success reports “LDAP bind OK” with a latency.

  1. Bind as the service account.
  2. Search under baseDN for (<userAttr>=<username>).
  3. If found, bind as that user’s DN with the password they gave.
  4. Success means the credentials are valid.

Plugboard never sees a hash and never stores the password. The directory does the verifying.

Two paths, both landing here.

Self-verified. The person taps their own card, the card resolves to them, and they are taken straight to a “set a new password” screen. Fastest, and it needs no staff time.

Staff-verified. The person requests a reset, an ICT staff member confirms who they are at the desk and approves it, and then the person sets a new password.

Either way the actual change happens through this connector, against your directory, subject to your password policy. A password your directory rejects as too weak is rejected here too, with the directory’s own message.

See the service desk kiosk.

SymptomCause
Bind failed on testWrong bind DN or password. The DN is a full distinguished name, not a username
Connection refused or a timeoutWrong port, firewall, or a managed deployment with no agent
Certificate errors on ldaps://The host does not trust your internal CA. Install the CA certificate on that machine
Test passes, users not foundbaseDN is too specific, or userAttr is wrong. Try sAMAccountName for AD
Authentication always failsuserAttr mismatch, so the search finds nobody to bind as
Password reset fails with insufficient rightsThe bind account lacks the reset-password delegation
Password reset fails over ldap://Active Directory refuses password changes on an unencrypted connection. Use ldaps://
Reset rejected as too weakYour directory’s password policy said no. That message is passed through

For managing licences, locking accounts and delegating mailboxes, see directory management, which is a separate connector serving a different purpose.