In an LDAP SearchRequest, what do the scope values baseObject, singleLevel and wholeSubtree each match?
answer
- how far down, not what matches
- three values, numbered zero to two
- the base entry itself sometimes counts
- singleLevel means immediate subordinates only
- scope picks candidates, filter tests them
basics
~20 sAn LDAP SearchRequest's scope decides how far below the base DN the server walks: baseObject (0) considers only the base entry itself, singleLevel (1) only its immediate subordinates, and wholeSubtree (2) the base entry plus every descendant.
solid answer
~40 sEvery LDAP search carries a base DN and a `scope`. The base DN says where in the directory tree the walk starts; `scope` says how far down it may go. `baseObject (0)` considers exactly one directory entry, the base entry. `singleLevel (1)` considers the entries immediately subordinate to it and deliberately excludes the base entry itself. `wholeSubtree (2)` considers the base entry and everything beneath it to any depth. Scope is applied before the RFC 4515 filter: the server assembles the candidate entries by scope, then evaluates the filter against each one. So a search with the right filter and the wrong scope returns nothing and looks, to the caller, exactly like nobody matching.
code
asn1 · 17 linesSearchRequest ::= [APPLICATION 3] SEQUENCE {
baseObject LDAPDN,
scope ENUMERATED {
baseObject (0),
singleLevel (1),
wholeSubtree (2),
... },
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3) },
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
typesOnly BOOLEAN,
filter Filter,
attributes AttributeSelection }go deeper
Recall the three names and what each covers: one entry, one level down, everything below. Remember that singleLevel leaves out the entry you started from.
Explain that scope selects candidate entries before the filter is evaluated against any of them, so a wrong scope produces an empty answer and no error at all.
Show that you reach for a narrower base DN before a cleverer filter, and that you can say what a wholeSubtree search over a large naming context costs a directory server.
Frame scope as an interface contract: what a lookup is allowed to traverse shapes both the directory's layout and the cost every consumer of it pays.
## What a search request actually carries An LDAP search is a single `SearchRequest` message, and almost every surprise people hit with directory lookups comes from one of its first two fields. `baseObject` is a **Distinguished Name** naming the directory entry the walk starts from. `scope` is an enumeration saying how far below that entry the server may go. Everything else on the request either narrows what comes back (`filter`, `AttributeSelection`, `typesOnly`) or bounds the work (`sizeLimit`, `timeLimit`, `derefAliases`). The word **base** is doing two jobs here and they are not the same thing: `baseObject` is the name of the field holding the starting DN, and `baseObject (0)` is also one of the three values `scope` can take. A sentence like "search the base" is ambiguous until you say which. ## The three scope values | Scope | Value | Entries the server considers | Typical use | |---|---|---|---| | `baseObject` | 0 | Exactly the entry named by the base DN | Read one entry whose DN you already hold | | `singleLevel` | 1 | The entries immediately subordinate to the base entry, **not** the base entry | List what sits directly under one organizational unit | | `wholeSubtree` | 2 | The base entry **and** every entry below it, to any depth | Find a person anywhere under a naming context | Two asymmetries catch people out. `singleLevel` **excludes** the base entry, while `wholeSubtree` **includes** it. And `singleLevel` goes exactly one level: an entry two levels down is not a candidate, however well it matches the filter. ## Scope is evaluated before the filter A search has two independent gates: 1. **Scope** decides which directory entries are candidates at all. 2. **The RFC 4515 filter** is evaluated against each candidate, and an entry is returned only when the filter evaluates to TRUE for it. An entry outside the scope is never tested. This is why a mis-scoped search fails silently rather than loudly: the server completes normally, returns zero entries, and reports success. Consider a teaching hospital whose clinician directory is one naming context covering three sites, with an organizational unit per site and clinician entries beneath each. A `singleLevel` search from the naming context tests only the three site entries - it never reaches a single clinician - and answers "nobody matched" with a clear conscience. ## Choosing one 1. **You already have the entry's DN and want its attributes.** Use `baseObject` with a filter that always matches, such as a presence filter on `objectClass`. This is the cheapest search a directory can serve. 2. **You want the members of one container.** Use `singleLevel` from that container's DN. It bounds the work to one level no matter how deep the tree gets below it. 3. **You are looking for a person and do not know which site they sit under.** Use `wholeSubtree` from the naming context. This is the right answer and the expensive one, and it is the scope that makes the rest of the request matter. ## What wholeSubtree costs - Every entry under the base DN is a candidate, so the search's cost tracks the size of the subtree rather than the size of the answer. - The server leans on indexes for the attributes the filter asserts; an unindexed assertion over a large subtree degrades into a scan. - It is the scope most likely to meet a limit - the `sizeLimit` and `timeLimit` the client set, or an administrative limit the server enforces - and a search that stops early still returns the entries it already found. - Narrowing the base DN one level is usually a bigger win than tightening the filter, because it removes candidates rather than testing them. ## The other fields on the same request - `derefAliases` says whether the server follows alias entries while searching, with values including `derefInSearching (1)`. - `typesOnly` asks for attribute descriptions without their values - useful for discovering what an entry holds. - `AttributeSelection` names which attributes come back. An empty list or `*` requests the user attributes; the OID `1.1` requests none; `+` requests the operational attributes (RFC 3673), with the caveat that some are still returned only when named explicitly. - `sizeLimit` and `timeLimit` are the client's own ceilings on the search, and zero in either field means the client is asking for no restriction of its own.
- In an LDAP SearchRequest, what does an empty base DN with scope baseObject and a presence filter on objectClass retrieve?The **root DSE** - the server's own capability entry. It advertises `namingContexts`, `supportedControl`, `supportedExtension`, `supportedSASLMechanisms` and `supportedLDAPVersion`, which is how a client learns what the server holds and what it can be asked to do. Most of those are operational attributes, so a client that wants them reliably names them in `AttributeSelection` rather than assuming they arrive by default.
- What does the AttributeSelection field do, and what do the special values mean?It names which attributes the server returns on each matching entry. An empty list or `*` requests the user attributes. The OID `1.1` requests no attributes at all, which is how you ask for just the DNs of the matches. `+` requests the operational attributes (RFC 3673). Narrowing this list is the cheapest way to cut the size of a large answer, because it changes what is sent rather than what is searched.
- What does derefAliases control on an LDAP search?Whether the server follows **alias entries** - entries whose `aliasedObjectName` points at another entry - while running the search. `neverDerefAliases (0)` leaves them as ordinary entries; `derefInSearching (1)` dereferences aliases found beneath the base entry but not the base entry itself; the remaining values dereference when locating the base, or in both places. It changes which entries the walk actually reaches, so it is part of the scope story, not part of the filter.
saying these in an interview costs you the question
- Thinks singleLevel includes the base entry itself
- Says wholeSubtree excludes the base entry
- Confuses an LDAP search scope with an OAuth2 scope string
- Believes the filter decides how deep the search walks
- Treats wholeSubtree from the naming context as always safe