Documentation Core Concepts Environments Services Reactions Reaction Examples Variables Mock Accounts Script Library & JWT Attachments LDAP Mode Forwarding & Recording CORS & Auth Basics MCP & REST API Clustering & Clones Administration Debug & Troubleshooting

LDAP Mode AI-generated

An environment set to Traffic Type: LDAP (see Environments) becomes a stub LDAP directory instead of an HTTP server. It speaks real LDAP wire protocol - Bind and Search only - and is set up and matched using the same Services/Reactions model as everything else in MockMotor, reusing mock accounts as directory entries.

Example. A Search with BaseDN ou=Accounts,o=Example and filter (cn=jsmith) is routed to the service whose BaseDN suffix matches, and the filter becomes an account selector. It matches an account with dn: cn=jsmith,ou=Accounts,o=Example, cn: jsmith, mail: jsmith@example.com - every property except dn comes back as a returned attribute.

Accounts as directory entries

A mock account represents one LDAP entry: give it a dn property holding its full distinguished name (e.g. cn=jsmith,ou=Accounts,o=Example), and every other property becomes a regular returned attribute. dn itself is never returned as an attribute - it's communicated structurally, the same way a real directory does it.

Services are BaseDN prefixes

Just as an HTTP service's Base URL is a path prefix, an LDAP service's Bind/Base DN Suffix field (see Services) is a DN suffix. An incoming Search's BaseDN is matched against it the same longest-match way HTTP paths are - case-insensitively on attribute type names, case-sensitively on values.

Bind

A BIND-method reaction answers an LDAP Bind request. MockMotor looks up the one mock account whose dn exactly matches the bind DN and makes it available as account/$account to the reaction's scripts - so, for instance, the reaction's LDAP Result Code field can be scripted to fail the bind for an account flagged as locked. Account Selection is not separately configurable for Bind; it's always this exact-DN lookup.

Search

A SEARCH-method reaction answers an LDAP Search. Account selection is fully automatic, combining two things:

  • The incoming RFC 4515 filter, converted on the fly to the same account-selector script language used everywhere else (an equality filter like (cn=jsmith) becomes account.cn=="jsmith"; AND/OR/NOT, presence and substring filters are all supported).
  • The incoming BaseDN, restricting results to accounts whose dn falls under it.

A reaction's own Selection Script field is not used for Search - there's no legitimate reason to override normal LDAP filter+BaseDN semantics, so the console hides that section entirely for LDAP-mode reactions. A search that matches nothing is answered as a normal, successful, empty result (as a real directory would), not an error - unless the matched reaction's own LDAP Result Code field is set to something else.

Result codes

The reaction's status field (labeled LDAP Result Code for an LDAP-mode reaction, reusing the same field the HTTP status code uses) is the raw numeric LDAP result code - 0 for success, 32 for noSuchObject, and so on through the standard RFC 4511 codes.

What's not implemented

Bind and Search are the only two operations. Add/Modify/Delete/Compare/ModifyDN are not supported, and LDAP scope (OBJECT/CHILDREN/SUBTREE) is decoded and available to scripts as an informational value but doesn't yet automatically restrict results by depth - every search currently behaves subtree-scoped once BaseDN and filter are applied.

See also: Environments Services Mock Accounts