Fix ERROR_DS_NON_BASE_SEARCH (0X00002120) Fast

What's happening here

You're seeing ERROR_DS_NON_BASE_SEARCH (0X00002120) when running an LDAP query against Active Directory. The message says "The requested search operation is only supported for base searches." That's Windows telling you you've set the LDAP search scope to OneLevel or Subtree, but the Directory System Agent (DSA) on the other end only allows Base scoped queries for that specific object.

I see this most often when someone's trying to query a cross-reference object, an application partition, or a read-only domain controller (RODC) that doesn't support subtree searches on certain attributes. The fix is straightforward — you just need to match the scope the server expects.

Quick fix: Change the LDAP search scope (30 seconds)

If you're writing code or using a tool like LDP.exe or PowerShell, change the search scope from Subtree or OneLevel to Base. Here's what that looks like:

# PowerShell example — fix scope to Base
$searcher = New-Object DirectoryServices.DirectorySearcher([ADSI]"LDAP://CN=MyObject,DC=domain,DC=com")
$searcher.SearchScope = "Base"  # This is the fix
$searcher.Filter = "(objectClass=*)"
$result = $searcher.FindOne()

Why this works: The error fires when the server receives a search request with a scope that's broader than what the object's partition allows. Setting SearchScope to Base tells Windows to only look at that exact object, not crawl children. Most tools default to Subtree, which triggers the error on constrained objects.

Test it quickly with LDP.exe (built into Windows Server):

1. Open LDP.exe, connect to your domain controller, bind as a domain admin.
2. Go to Browse > Search.
3. Enter the distinguished name (DN) of the object you're targeting.
4. Set Scope to Base.
5. Click Run. If it succeeds, your code's scope was wrong.

If the query still fails on Base scope, you've got a different problem — likely a permissions or object nonexistence issue. Move to the next fix.

Moderate fix: Check ADSI Edit and the object's partition properties (5 minutes)

The error doesn't always mean your code is wrong. Sometimes the object itself — or its naming context — is misconfigured. This happens with application partitions (CN=NTDS Quotas, CN=Schema, or custom partitions).

Open ADSI Edit (install it via Server Manager if not present). Connect to the naming context that contains the object you're querying.

1. Right-click the target object, choose Properties.
2. Look for the attribute nTSecurityDescriptor — not directly relevant here, but check the object's objectClass.
3. If it's a crossRef object, or something like dnsZone, these often only support base searches by design. That's expected behavior, not a bug.
4. Navigate up to the parent container (the partition root). Right-click > Properties. Check nCName and trustParent attributes. If the partition is marked as systemOnly or has weird replication settings, that can restrict search scopes.

What I'd actually check: the msDS-EnabledFeature attribute on the partition object. If it's a read-only partition (RODC), the server might reject subtree searches because it can't process referrals. The real fix here is to target a writable domain controller by using -Server flag in your query:

# Force a writable DC
$obj = [ADSI]"LDAP://WRITABLEDC.domain.com/CN=MyObject,DC=domain,DC=com"

If you're still stuck, the object might be in a partial attribute set — read-only replicas only return certain attributes on base searches. Try querying the same DN against a full replica.

Advanced fix: Modify the object's allowed search scope via schema (15+ minutes)

This is the nuclear option, and I don't recommend it unless you're maintaining a custom schema extension or an app that genuinely needs subtree searches on a normally base-only object. Messing with this can break directory replication.

The error originates from the searchFlags attribute on the attributeSchema object. Specifically, bit 7 (value 128) in searchFlags controls whether the attribute can be used in subtree searches. If it's set to 128, the attribute is "secure-only" for base searches. You'd need to clear that bit.

Here's the process — only do this if you absolutely must:

1. Open ADSI Edit. Connect to the Schema naming context.
2. Find the attribute that's causing the error. How? Look at the error's stack trace or use a network monitor to see which attribute is referenced in the LDAP filter. Common culprits: msDS-UserAccountControlComputed, tokenGroups, tokenGroupsGlobalAndUniversal.
3. Right-click the attribute > Properties. Find searchFlags.
4. If the value is 128 (bit 7 set), you need to change it to 0. But you can't just edit it directly — the schema is protected. You'll need to use LDAP to modify it.

# PowerShell to clear bit 7 on an attribute schema
$attr = [ADSI]"LDAP://CN=ms-DS-User-Account-Control-Computed,CN=Schema,CN=Configuration,DC=domain,DC=com"
$currentFlags = $attr.searchFlags.Value
$newFlags = $currentFlags -band (-bnot 128)  # Clear bit 7
$attr.Put("searchFlags", $newFlags)
$attr.SetInfo()

After changing it, you must restart the NTDS service on all domain controllers for the change to take effect (net stop NTDS && net start NTDS).

But honestly? I've only needed this once in ten years. Usually a scope mismatch or a writable DC issue. Don't do this unless you're sure — it can cause authentication or replication failures.

Why this error shows up in real life

I've seen it mostly with:

• Third-party apps (like backup software or identity management tools) that query CN=NTDS Quotas with a subtree scope.
• Custom scripts hitting an RODC that doesn't support subtree on tokenGroups attributes.
• Developers using DirectorySearcher with default SearchScope.Subtree against a dnsZone container. That container only accepts base searches.

The fix is almost always simpler than you think. Start with the scope, then check the DC, then — and only then — touch the schema.