LDAP testing: bind, search, assert.

VirtuProbe implements LDAP from scratch — BER encoding, RFC 4511 — with no third-party LDAP library involved. That means you send the exact bind, the exact filter, the exact DN you typed, and you assert on the numeric result code the directory returns. It's the tool for debugging an auth integration, checking a directory's contents, or proving a bind fails when it should.

01The operations

Each step runs one LDAP operation, configured directly:

• BIND — authenticate with a DN and password (or bind anonymously).
• SEARCH — the workhorse: base DN, scope, filter, attributes, limits.
• COMPARE — test whether an attribute on an entry holds a given value.
• DELETE — remove an entry by DN.
• UNBIND — close the session cleanly.

Connect on port 389, or 636 with LDAPS for TLS from the first byte.

02Search that behaves like search

The SEARCH operation exposes what the protocol actually offers, not a simplified subset:

• Base DN and Scope — BASE (the entry itself), ONE (its immediate children), or SUB (the whole subtree).
• Filter — full RFC 4515: equality (cn=John), presence (cn=*), substring (cn=J*), >= / <=, and boolean (&…), (|…), (!…).
• Attributes — a specific list, or blank for all.
• Size & time limits — cap the result set and the wait.

# LDAP probe: authenticate, then look up a user

BIND     cn=admin,dc=example,dc=com   (password)     expect 0
SEARCH   base    dc=example,dc=com
         scope   SUB
         filter  (&(objectClass=person)(uid={{user}}))
         attrs   cn, mail, memberOf                   expect 0

03Assert on the result code

Every LDAP operation returns a numeric result code, and you set the one you expect. A mismatch fails the step — which is exactly how you test the negative cases, not just the happy path:

• 0 — success.
• 49 — invalid credentials (the bind you want to fail).
• 32 — no such object (the entry isn't there).
• 6 — compareTrue (a COMPARE that matched).

Pull values out with two extractors: LDAP_SUCCESS (true when the operations completed with no failed assertion) and LDAP_EXCHANGE_RESULT_CODE, whose expression is the operation to read — e.g. BIND cn=admin — returning that operation's code as a string for a later step to branch on.

04Put it in a chain

LDAP is a first-class chain step (and callable from scripts), and {{variables}} resolve in the host, DN, password, filter, attribute and value. Two flows fall out naturally:

• Auth verification. The tail end of a signup / email-verification chain — confirm the freshly-created account binds, or that the directory now returns it.
• Directory-driven testing. Search for a set of accounts, extract the results, and ITERATE another protocol step over them.