Fix ERROR_DS_NAME_TYPE_UNKNOWN (0x0000209F) in AD

Quick answer: This error means the DC can't map a security principal name to a recognized type—usually because the target domain's DNS is wrong or the service principal name (SPN) is missing on the object you're querying. Fix the DNS referral first; if that doesn't work, check the SPN.

I walked into a client's server room last month—small law firm, two domains in a cross-forest trust—and their HR app was spitting out this exact 0x0000209F error every time it tried to pull user attributes from the resource forest. The log said "name type unknown," which is Microsoft's way of saying, "I can't figure out what kind of object this is." Usually happens when you hit a DC with a name like CONTOSO\jsmith and the DC can't resolve the domain portion properly. The root cause in 90% of cases is DNS: the querying DC doesn't know how to route to the target domain. The other 10% is a missing or malformed SPN on a service account or computer object.

Step-by-Step Fix

1. Check DNS resolution from the source DC. Open Command Prompt as admin. Run nslookup targetdomain.local. If it returns a time-out or wrong IP, your DNS forwarding or conditional forwarder is busted. Add a conditional forwarder for the target domain pointing to its DNS servers. Had a client last month whose entire print queue died because of this—their IT guy had accidentally deleted the forwarder during a cleanup.
2. Validate the service principal name (SPN). On the DC that owns the object you're querying, run setspn -L objectname. If the SPN is missing for the service type (e.g., HOST/machine.domain.com), the DC can't match the name to a type. Re-add it with setspn -A service/name objectname.
3. Test the trust relationship. Run nltest /dsgetdc:targetdomain.local from the source DC. If it fails, the trust might be broken. Re-establish it using Active Directory Domains and Trusts. Don't skip this—half the time "name type unknown" is just a trust that's been silently rotting.
4. Check for duplicate or stale DNS records. Use dnscmd /EnumRecords zonename on the target domain. Delete any A or CNAME records that point to decommissioned DCs. Stale records confuse the name resolution process.
5. Flush the Kerberos ticket cache. On the source DC, run klist purge then klist -li 0x3e7 purge. Corrupted tickets can cause the DC to misinterpret name types.

Alternative Fixes If the Main Steps Don't Work

1. Update the gcSPN attribute. If using a global catalog server, the gcSPN must include the GC service principal name. Run setspn -A GC/machine.domain.com domain\machine$. Missing this is a sneaky cause that most guides ignore.
2. Repair the trust manually. Remove the outbound trust and re-create it with netdom trust targetdomain.local /add /realm /passwordt:tempPass. I've seen trusts get corrupted after Windows updates.
3. Check for strict name checking. The DC might be rejecting names due to strict name checking policies. In Group Policy, go to Computer Configuration > Administrative Templates > System > Kerberos, and set "Kerberos client support for claims, compound authentication, and Kerberos armoring" to "Enabled" if it's causing issues.

Prevention Tip

Set up a scheduled task that runs dcdiag /test:dns weekly on every DC. DNS drift is the number one cause of cross-forest name resolution failures. Also, document all SPNs for service accounts—use a simple spreadsheet. When you decommission a server, remove its SPNs with setspn -D before you unplug it. That'll save you the headache I had at 2 AM with that law firm.