| Previous | Next |
| ERROR_DS_DUP_LINK_ID | ERROR_DS_NAME_ERROR_NOT_FOUND |
ERROR_DS_NAME_ERROR_RESOLVING
ERROR_DS_NAME_ERROR_RESOLVING belongs to the Active Directory name-translation path. It is the generic failure case for converting an object identifier between forms such as a distinguished name, UPN, NT4 account name, canonical name, SID, or service principal name. The input can be syntactically valid; the failure means that processing the conversion did not reach a more specific result such as NOT_FOUND, NO_MAPPING, or TRUST_REFERRAL.
Why the request context matters
DsCrackNames accepts a binding handle, flags, an offered format, a desired format, and an array of names. A successful function call can still contain a per-name conversion failure in the returned DS_NAME_RESULT_ITEM.status. Record all of those inputs before retrying. In particular, a bind to a global catalog has forest scope, whereas a non-GC bind has the scope available to that domain controller.
Useful checks
- Log the exact input string together with
formatOffered,formatDesired, and everyDS_NAME_RESULT_ITEM. - Identify the DC or global catalog used for the bind, its forest, and the security context of the caller.
- Retry the same conversion with one unambiguous identifier, such as the object DN or GUID, to separate name interpretation from directory availability.
- Do not rewrite the input as an LDAP filter until the offered name format is known; a UPN, a DN, and an NT4 account name have different semantics.
This condition is broader than a malformed DN. DN syntax should be checked separately against the LDAP DN rules, while a resolving failure needs the API call context and the target directory scope.
RFC 4514: LDAP string representation of distinguished names
Looking for a different code? Search another status or error code.