Fix ERROR_DS_INSUFF_ACCESS_RIGHTS (0x00002098) in Active Directory

You don't have delegated permissions for the specific object or container

This is the most common cause I see in the field. You're logged in as a domain admin, or you think you are, but the error still pops up. Here's the thing: being a domain admin doesn't automatically give you control over every object in Active Directory, especially if someone's applied custom delegations or blocked inheritance on a specific OU.

This usually happens when you're trying to modify user accounts, computer objects, or groups inside a restricted OU. The error shows up right after you click "Apply" or "OK" in Active Directory Users and Computers (ADUC).

1. Open Active Directory Users and Computers (dsa.msc).
2. Right-click the OU or container where the object lives and pick Delegate Control. This launches the Delegation of Control Wizard.
3. Click Next and then click Add to add your user account or the group you're a member of.
4. In the Tasks to Delegate screen, pick Create, delete, and manage user accounts or whichever specific task you need.
5. Click Next and then Finish.

After you finish the wizard, wait about 5 to 10 minutes for replication to spread the change. Then try the operation again. If the error's gone, you're all set.

If delegation doesn't do it, check if inheritance is blocked on the OU. Right-click the OU, pick Properties, go to the Security tab (if it's visible — you might need to turn on Advanced Features in the View menu first). Click Advanced. If the Enable inheritance button is grayed out or missing, inheritance is already on. If it says Disable inheritance, that means it's currently enabled. But if you see a message like "Permissions are not inherited from the parent," that's your problem. Click Enable inheritance, then Apply.

The authenticated user group lacks read rights on the partition container

This one sneaks up on you. It's common when you're using ADSI Edit or a script to read or modify objects in a specific naming context (like the Configuration partition or a custom application partition).

You'll see the 0x00002098 error when, say, you run an LDAP query against CN=Configuration,DC=domain,DC=com and your account has rights on the domain partition but not on the Configuration partition. This also happens with DNS-integrated zones stored in AD.

1. Open ADSI Edit (adsiedit.msc).
2. Right-click ADSI Edit in the left pane and pick Connect to.
3. In the Connection Settings dialog, under Select a well-known Naming Context, pick the partition you're having trouble with. For example, Configuration or Schema. Click OK.
4. In the left pane, expand the partition, right-click the top-level object (like CN=Configuration,DC=domain,DC=com), and pick Properties.
5. Go to the Security tab.
6. Click Advanced.
7. In the Permissions tab, click Add.
8. Click Select a principal, type Authenticated Users, and click OK.
9. Under Permissions, check the box for Read (and if you need write access, check Write All Properties).
10. In the Applies to dropdown, pick This object and all descendant objects.
11. Click OK three times to close all dialogs.

After applying this, the change replicates. Give it a few minutes, then retry your operation. This fix is often the one that works for DNS managers and third-party tools that query the Configuration partition.

The service account for a Windows service or scheduled task doesn't have enough rights

This one's a pain because you don't see the error right away — it logs in the event viewer or the service just fails silently. But when you dig into the logs, you see 0x00002098.

I've seen this most often with the Active Directory Web Services (ADWS) service, but also with backup agents, monitoring tools, and scripts running as SYSTEM or NETWORK SERVICE. Those accounts often lack permissions on specific AD objects.

1. Open Services (services.msc).
2. Find the service that's throwing the error. Look in the Log On tab of the service's properties to see which account it uses.
3. Write down that account name (e.g., NT AUTHORITY\NETWORK SERVICE or a domain user like DOMAIN\svc_backup).
4. Open Active Directory Users and Computers (if it's a domain account) or use Local Users and Groups (for local accounts like NETWORK SERVICE).
5. If it's a domain account, find it in the Users container or the OU where you keep service accounts.
6. Right-click the account, pick Properties, and go to the Security tab. If you don't see it, turn on Advanced Features in the View menu first.
7. Click Advanced, then Add.
8. Click Select a principal, type the account name (or object SID for NETWORK SERVICE), and click OK.
9. For NETWORK SERVICE, you can't add it directly via the picker. Instead, type NT AUTHORITY\NETWORK SERVICE and click Check Names. It'll resolve.
10. Grant Read and maybe Write permissions, depending on what the service needs to do. For ADWS, it needs Read on the Configuration and Domain partitions.
11. Click OK three times.

Then restart the service. If you're still getting the error, check the Effective Access tab in the Advanced Security Settings dialog. There you can input the service account and see exactly which permissions are missing.