Fix ERROR_DS_UNAVAILABLE_CRIT_EXTENSION (0X0000202C)

You're hitting this error and it's stopping your app from connecting to Active Directory. Let's fix it now.

The error code 0X0000202C (ERROR_DS_UNAVAILABLE_CRIT_EXTENSION) pops up when a client sends an LDAP request marked as “critical” and the domain controller doesn’t support that extension. I see this most often when someone tries to use an LDAP tool or a newer app against an older DC, like a Windows Server 2008 R2 DC that doesn’t have the LDAP_SERVER_EXTENDED_DN_OID extension. The DC basically says “I don’t do that, and you said it’s critical, so I’m refusing the whole request.”

The fast fix: stop the client from requiring that extension

This is the easiest path and works in 90% of cases. You won’t touch the server at all.

1. Find the application or script making the LDAP request. It could be a PowerShell script, a .NET app, or an LDAP browser like Softerra or Apache Directory Studio.
2. Look for where it constructs the LDAP connection or search request. In PowerShell, that’s often New-Object DirectorySearcher or Get-ADUser. In .NET, it’s usually DirectoryEntry or LdapConnection.
3. Check if the code explicitly sets a SearchScope, PageSize, or ReferralChasing that triggers a critical extension. The most common culprit is setting PageSize to a non-zero value without the server supporting paged results.
4. If you’re using DirectorySearcher in .NET, remove or set PageSize to 0. Like this:

   DirectorySearcher searcher = new DirectorySearcher();
   searcher.PageSize = 0;  // This disables paging, which avoids the critical extension

5. If you’re using PowerShell with Get-ADUser or similar, try adding -ResultPageSize 0:

   Get-ADUser -Filter * -ResultPageSize 0

6. After making the change, rerun the query. You should see it succeed. If not, move to the next section.

Expected outcome: The LDAP request completes without the error. You’ll get your data back.

Why this works

LDAP extensions let clients ask for extra features—like paged results, extended DNs, or sort controls. When a client marks an extension as critical (by setting the critical flag to TRUE in the LDAP control), the server must either support it or reject the entire operation. The error 0X0000202C is the server’s polite way of saying “I can’t do that.” By disabling the extension on the client side, you remove the requirement. The server then processes the request using default behavior, which usually works fine.

The alternate fix: update the domain controller

If you can’t change the client (maybe it’s a vendor app you can’t modify), you need a DC that supports the extension. Here’s the plan:

1. Check what OS your DCs run. Run this on each DC:

   Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsHardwareAbstractionLayer

2. If you’re on Windows Server 2008 R2 or older, you’re missing many LDAP extensions that newer clients assume exist. The real fix is to upgrade to at least Windows Server 2012 R2, ideally 2016 or 2019.
3. If upgrading isn’t an option (I’ve been there), install the latest LDAP-related hotfixes from Microsoft. For Server 2008 R2, KB 975893 added support for several extensions. You can find it in the Microsoft Update Catalog.
4. After updating, reboot the DC. Then test the client again.

Expected outcome: The DC now advertises the extension in its root DSE, and the client’s critical request succeeds.

Less common variations

Third-party LDAP servers

This isn’t just a Microsoft issue. I’ve seen 0X0000202C when connecting to OpenLDAP or 389 Directory Server with a client that demands LDAP_SERVER_SORT_OID. The fix is the same—check the server’s supported extensions by querying the root DSE:

ldapsearch -x -b "" -s base "(objectClass=*)" supportedExtension

Compare that list with what your client requests. If they don’t match, you either update the server or disable the extension on the client.

Group Policy or security software blocking LDAP controls

Rare, but I’ve seen it. Some security tools intercept LDAP traffic and block certain controls, thinking they’re exploits. If your client works fine on one network but fails on another, check for:

• Network firewalls with deep packet inspection for LDAP
• Endpoint security software like CrowdStrike or Symantec that filters LDAP
• Microsoft’s own LdapEnforceChannelBinding setting (though that usually gives a different error)

Temporarily disable the security tool (in a test environment!) to confirm. If it’s the culprit, add an exception for your app.

Prevention for the future

This error usually comes back when you introduce a new tool or update an existing one. Here’s how to stay ahead:

• Keep DCs current. I know it’s not always possible, but Windows Server 2016 and later support almost all LDAP extensions commonly requested. Server 2022 is even better.
• Test LDAP clients against a lab DC first. Before rolling out a new app, fire up a quick LDAP query with the critical extensions your app uses. If it fails, you find out before it hits production.
• Document which extensions your apps rely on. For each app that talks to AD, note if it uses paged results, extended DNs, or sort controls. This makes troubleshooting faster.
• Use Wireshark to capture the LDAP bind request. When you do, you can see the supportedExtension attribute in the server’s response. Compare that to the controls the client sends. That mismatch is your smoking gun.

One last thing: if you’re building your own LDAP client, never mark an extension as critical unless you absolutely have to. Most servers handle missing features gracefully when you don’t force the issue. That’s the difference between getting an error and getting your data.