Skip to main content
Identity Authority
Category: Directory Services

Base DN

Also known as: Base Distinguished Name, Search Base, Base Object
Simply put

A Base DN is the starting point in a directory tree from which a search or operation begins. Think of it as the folder in a filing system where a lookup starts, so the directory knows which branch to look under rather than searching the entire tree. It defines the scope of where entries such as users or groups are found.

Formal definition

In LDAP directory operations, the Base DN (Base Distinguished Name) is the distinguished name of the entry used as the starting point, or base object, for a search or other directory operation. It anchors the search scope, which is typically combined with a scope setting (such as baseObject, singleLevel, or wholeSubtree, depending on the LDAP profile and implementation) and a filter to determine which entries are returned. A Base DN is expressed as a sequence of relative distinguished names (RDNs), for example dc=example,dc=com or ou=People,dc=example,dc=com, reflecting the directory information tree hierarchy. Exact naming conventions, supported attributes, and permitted scopes vary by directory implementation and configuration.

Why it matters

The Base DN determines the portion of the directory information tree that a search or operation can reach, which makes it a foundational control over both correctness and scope. If an application is configured with a Base DN that is too high in the tree, searches may traverse far more of the directory than intended, increasing query cost and potentially exposing entries that were not meant to be visible to that integration. If the Base DN is set too narrow or points at the wrong branch, legitimate users or groups may simply not be found, producing authentication or lookup failures that are often misdiagnosed as credential problems rather than scoping errors.

Because the Base DN is combined with a scope setting and a filter, misunderstanding how these three interact is a common source of misconfiguration. A frequent operational issue is an integration that returns no results because the Base DN and scope exclude the branch where the target entries actually live, or conversely an overly broad Base DN paired with a permissive filter that surfaces more entries than the calling system should ever process. In directory-backed authentication flows, note that locating a user entry via a Base DN is part of identification and lookup; it is distinct from the subsequent authentication step where the directory verifies the presented credential, and these should not be conflated.

The correct Base DN depends heavily on how a given directory's tree is structured, and naming conventions vary by implementation and deployment. Because of this variability, a Base DN that works in one environment cannot be assumed to work in another, and changes to directory structure can silently break integrations that hardcode a specific base. Treating the Base DN as a deliberate scoping decision, rather than a value copied between systems, reduces both failed lookups and unintended exposure.

Who it's relevant to

IAM Engineers and System Administrators
Engineers configuring LDAP-backed applications, authentication connectors, or directory integrations set the Base DN to scope where user and group entries are located. Getting the Base DN, scope, and filter combination right is essential to avoid both failed lookups from an overly narrow or misdirected base and excessive query cost or exposure from an overly broad one.
Directory Services Architects
Those who design the directory information tree structure influence which Base DN values downstream integrations must use. Because naming conventions and tree layout vary by implementation, architects should account for how organizational units and containers map to the Base DNs that applications will depend on, since structural changes can break integrations that reference a fixed base.
Security and Compliance Reviewers
Reviewers examining directory integrations should verify that Base DN and scope settings limit searches to the branches an application legitimately needs. An overly broad Base DN can allow an integration to enumerate entries beyond its intended purpose, which is relevant when assessing least-privilege access to directory data.
Support and Troubleshooting Staff
Personnel diagnosing directory lookup failures need to recognize that a misconfigured Base DN or scope is a common cause of users or groups not being found. Distinguishing a scoping error from a genuine credential or authentication failure helps route issues to the correct resolution rather than treating every lookup failure as an authentication problem.

Inside Base DN

Distinguished Name (DN) syntax
The Base DN is expressed using standard LDAP DN syntax, typically as a sequence of relative distinguished name (RDN) components such as domain components (dc), organizational units (ou), and organizations (o), read from the most specific entry up to the directory root.
Search base for LDAP operations
The Base DN identifies the entry in the directory information tree (DIT) at which a search or bind operation begins. It anchors the subtree that subsequent operations traverse, depending on the search scope requested.
Domain component representation
In many deployments the Base DN maps a DNS-style namespace to directory naming, for example rendering example.com as dc=example,dc=com, though this mapping is a convention rather than a universal requirement.
Search scope interaction
The Base DN works together with the search scope (typically base, one-level, or subtree) to determine which entries are considered. The Base DN itself only sets the starting point; scope governs how far below it the search extends.
Organizational subtree anchoring
A Base DN often points to an organizational unit (for example ou=People or ou=Users) to constrain lookups and binds to the relevant portion of the tree, depending on how the directory is structured.

Common questions

Answers to the questions practitioners most commonly ask about Base DN.

Is the Base DN the same thing as the bind DN used to authenticate to the directory?
No. These serve distinct purposes and conflating them is a common source of misconfiguration. The Base DN is the entry in the directory information tree from which a search operation begins, defining the scope of where the directory server looks for matching entries. The bind DN, by contrast, is the distinguished name of the principal used to establish an authenticated LDAP session. A bind operation authenticates a connection; a search operation, scoped by its Base DN, retrieves entries. In many deployments the account represented by the bind DN and the entries located under the Base DN reside in entirely different parts of the tree, so treating them as interchangeable can break both connectivity and search results.
Does setting a Base DN by itself restrict what entries a client is allowed to see or access?
Not on its own. The Base DN narrows the starting point and, combined with the search scope, the portion of the tree a search traverses, but it is not an access control mechanism. What a bound principal is permitted to read or modify is governed by the directory's access control instructions or equivalent authorization rules, which are evaluated independently of the search base. A Base DN scoped narrowly still returns only what the bound identity is authorized to see, and a broad Base DN does not grant additional access it would otherwise lack. Treating the Base DN as an authorization boundary rather than a search-scope setting can lead to a false sense of confinement.
How do I choose an appropriate Base DN for user authentication searches?
Typically you set the Base DN to the lowest common ancestor that contains all the user entries you need to locate, for example an organizational unit that holds accounts rather than the directory root. Setting it too high can pull in unintended branches and increase search cost, while setting it too narrow may exclude legitimate users spread across multiple containers. In deployments where users live under several parallel branches, you may need either a Base DN high enough to cover all of them with a subtree scope or, depending on the client, multiple configured search bases. The correct value depends on your directory's tree layout, which varies by vendor and deployment.
What is the relationship between the Base DN and the search scope setting?
The Base DN and search scope work together to determine which entries a search evaluates. The Base DN establishes the starting entry, and the scope determines how far the search extends from it, commonly base (the entry itself only), one level (immediate children), or subtree (the entry and all descendants). A given Base DN produces very different result sets depending on the scope: a subtree search from a high Base DN can traverse the entire branch, whereas a one-level search examines only direct children. Configuring both correctly is necessary for searches to return the intended entries efficiently.
How should the Base DN be handled when integrating SCIM or other provisioning against an LDAP directory?
When provisioning writes or reads entries in an LDAP-backed directory, the Base DN typically defines where new entries are created and where existing ones are located for updates or deprovisioning. This is a lifecycle management concern distinct from runtime authentication searches, so the container used for provisioning may differ from the one used for authentication lookups depending on how your directory tree separates managed accounts. You should confirm that the configured Base DN aligns with the container where the provisioning connector has the necessary write permissions, since a correct Base DN does not by itself confer authorization to create or modify entries.
What symptoms suggest a misconfigured Base DN, and how do I troubleshoot it?
A common symptom is authentication or lookup failures where the directory server accepts the connection but searches return no matching entries, indicating the search may be starting in the wrong branch or the scope is too restrictive. To troubleshoot, verify the bind succeeds independently, then run a search against the configured Base DN and scope with a known entry's filter to confirm the entry falls within that scope. Check whether target entries actually reside under the configured Base DN, and confirm the scope matches your tree depth. Because directory layouts and server behavior vary by vendor and deployment, validating against the actual tree structure rather than assumptions is usually the fastest path to resolution.

Common misconceptions

The Base DN authenticates users or grants access.
The Base DN is a directory naming and search-scoping construct that identifies where in the tree to look for entries. It does not verify identity or determine permissions; authentication (for example an LDAP bind) and authorization are separate steps that occur after or alongside the search that the Base DN scopes.
A Base DN always corresponds directly to a DNS domain name.
The dc=example,dc=com style is a common convention, but a Base DN can be built from other RDN components such as o or ou and need not mirror a DNS namespace. The exact structure depends on the directory's design and deployment.
Setting a Base DN alone limits which entries a search returns.
The Base DN only sets the starting point of a search. The breadth of results also depends on the configured search scope and any filters; a subtree scope from a broad Base DN can still traverse large portions of the tree.

Best practices

Scope the Base DN as narrowly as practical, pointing it at the specific organizational unit or subtree that holds the relevant entries rather than the directory root, to reduce unnecessary traversal.
Pair the Base DN with an appropriate search scope (base, one-level, or subtree) and precise search filters so lookups return only the intended entries.
Confirm the exact DN structure against the target directory's actual DIT rather than assuming a DNS-to-dc mapping, since naming conventions vary by deployment.
Keep the Base DN configuration consistent across integrated services and document it, so changes to directory structure do not silently break binds or searches.
Validate that the account performing searches has read access to the subtree beneath the configured Base DN, since access rights are enforced independently of the naming path.
Review Base DN settings when directory reorganizations occur, because moving or renaming organizational units can invalidate a previously working Base DN.
Promotional banner graphic asking if you are ready for PCI DSS 4.0 with a call-to-action to get the guide