Fix ERROR_DS_NAME_ERROR_NO_MAPPING 0X00002118

You're staring at ERROR_DS_NAME_ERROR_NO_MAPPING (0X00002118) and it's probably not the first time you've seen it in the past few hours. I get it — Active Directory name translation errors are maddening because the error message itself is vague. Let's fix this quickly.

What actually causes 0X00002118?

This error shows up when a client or application sends a name (like a user principal name, a NetBIOS name, or a DNS hostname) to a domain controller asking for it in a different format — but the DC found the name and still couldn't convert it. The name exists in some form, but not in the form you're asking for.

Common triggers:

You're trying to map a user's sAMAccountName to a userPrincipalName and UPN isn't set.
A service like SQL Server or Exchange is trying to resolve an SPN but the SPN is missing or duplicated.
Cross-domain or cross-forest authentication where trusts aren't working.
A script or tool passes a name in one format (like DOMAIN\User) but the target system expects something else.

I'll walk you through the most likely fix first, then cover the edge cases.

Fix #1: Check and fix SPNs

SPN issues are the #1 cause of this error in my experience. Here's how to check:

Open Command Prompt as Administrator on a domain-joined machine or directly on a Domain Controller.
Run this command to list all SPNs for a specific computer account (replace SERVER01 with your server name):

setspn -L SERVER01

Look at the output. If you see any SPN listed more than once, that's a duplicate. If you see the SPN you need (like HTTP/SERVER01.contoso.com) missing entirely, that's also a problem.

To remove a duplicate SPN:

setspn -D HTTP/SERVER01.contoso.com SERVER01

To add a missing SPN:

setspn -A HTTP/SERVER01.contoso.com SERVER01

After you make changes, wait a minute or two for replication, then retry your operation. You should see the error disappear.

What to expect after this fix: If SPNs were the issue, the application or command that failed will now succeed. If you still get the error, move on to the next step.

Fix #2: Verify DNS resolution

Sometimes the DC can't resolve the name you're passing because DNS records are stale or missing.

On the client machine, run ipconfig /flushdns then nslookup [hostname-of-target]. Replace [hostname-of-target] with the exact name you're using.
Make sure the returned IP matches what you expect.
If it doesn't, check your DNS server. Clear the cache on the DNS server side too: run dnscmd /clearcache on the DNS server.

What to expect: If DNS was the issue, the lookup will return the correct IP after flushing and clearing cache. The error should stop.

Fix #3: Check trust relationships (cross-domain only)

If you're trying to translate a name from one domain to another (like from contoso.com to fabrikam.com), and you're getting 0X00002118, the trust is likely broken or not configured correctly.

Open Active Directory Domains and Trusts on a Domain Controller in the source domain.
Right-click the target domain and select Properties.
Click the Trusts tab. You should see the trust listed. If not, it doesn't exist — create it.
If the trust exists, click Validate. Enter credentials for the target domain and see if validation passes.

If validation fails, reset the trust. You'll need to do this from both sides:

netdom trust TrustingDomain /domain:TrustedDomain /reset

What to expect: If the trust was the problem, validation will succeed after resetting. The name mapping should now work across domains.

Fix #4: Check the name format you're sending

This one's simpler but often overlooked. The function or tool you're using might be sending the name in the wrong format. For example, if you're using DsCrackNames in PowerShell or C#, the NameFormat parameter matters.

If you're calling the function manually, try these formats in order:

DS_CANONICAL_NAME
DS_USER_PRINCIPAL_NAME
DS_SAM_ACCOUNT_NAME
DS_NT4_ACCOUNT_NAME

One of them will work if the name exists at all.

Real-world scenario: A developer I worked with was calling DsCrackNames with DS_CANONICAL_NAME format, but the user account only had a sAMAccountName and no UPN or canonical name. Switching to DS_SAM_ACCOUNT_NAME fixed it immediately.

Why this error happens in the first place

Active Directory stores names in multiple formats: sAMAccountName, userPrincipalName, distinguishedName, and so on. When you ask for a translation from one format to another, the DC looks up the object and then tries to extract the target format. If that attribute is empty or missing, it throws 0X00002118. It's not that the object doesn't exist — it's that the object doesn't have what you asked for.

This is different from ERROR_DS_NAME_ERROR_RESOLVING (0X0000211B), which means the name itself couldn't be found at all.

Less common variations

Variation A: Group Managed Service Accounts (gMSAs)

If you're trying to map a gMSA name to a service, and the gMSA's msDS-GroupManagedServiceAccount attribute isn't populated correctly, you'll get this error. Check that the gMSA is installed on the target server using Install-ADServiceAccount.

Variation B: Read-only Domain Controllers (RODCs)

If you're hitting a RODC that doesn't have the object cached, name translation might fail. Direct your query to a writable DC instead, or ensure the object is cached on the RODC.

Variation C: Mixed-format UPNs

Some environments use UPNs that don't match the domain DNS name (like user@company.local while the domain is company.com). This can confuse translation functions. Standardize UPNs to match the domain's external DNS name if possible.

How to prevent this from coming back

Standardize SPNs — Use Group Policy or scripts to deploy SPNs consistently for all services. Audit them monthly with setspn -X to catch duplicates.
Keep DNS clean — Set shorter TTLs on DC records (like 300 seconds) and enable scavenging to remove stale records.
Monitor trust health — Run nltest /domain_trusts weekly from Domain Controllers and validate all trusts.
Document name formats — If you're writing scripts that use DsCrackNames, log the input and output format for each call so you can debug quickly.

That's the whole playbook. Start with SPNs, then DNS, then trusts, then format. In 9 out of 10 cases, the first fix gets you there.