| Previous | Next |
| ERROR_DS_NAME_ERROR_DOMAIN_ONLY | ERROR_DS_CONSTRUCTED_ATT_MOD |
ERROR_DS_NAME_ERROR_NO_SYNTACTICAL_MAPPING
ERROR_DS_NAME_ERROR_NO_SYNTACTICAL_MAPPING does not say that the input name is invalid. It says that the caller asked for a conversion that cannot be performed only by parsing the local string. The condition is especially relevant when DsCrackNames is called with DS_NAME_FLAG_SYNTACTICAL_ONLY, which forbids a directory lookup.
The supported local conversion is deliberately narrow
Microsoft documents one purely syntactic conversion: from DS_FQDN_1779_NAME to DS_CANONICAL_NAME or DS_CANONICAL_NAME_EX. For example, a DN can be transformed between those string representations without confirming that the object exists. Mapping a UPN, SID, account name, GUID, or service principal name generally needs directory data and therefore cannot satisfy the local-only constraint.
Choose the right execution model
- Keep
DS_NAME_FLAG_SYNTACTICAL_ONLYonly when the input and requested output are one of the supported local pairs. - For an identity lookup, remove the local-only flag, bind to a DC or global catalog, and inspect the per-name status returned by the API.
- Use
DS_NAME_FLAG_EVAL_AT_DCwhen the caller intentionally wants server evaluation even though a syntactic conversion could be made locally. - Validate escaping, commas, plus signs, and RDN structure under RFC 4514 independently; correcting syntax will not make a directory-dependent mapping local.
This status differs from NO_MAPPING. Here the selected execution mode prohibits the required network lookup; with NO_MAPPING, the directory found the object but could not provide the requested output representation.
Microsoft: DS_NAME_FLAG_SYNTACTICAL_ONLY and DS_NAME_FLAG_EVAL_AT_DC
Microsoft: DS_FQDN_1779_NAME and canonical formats
RFC 4514: parsing an LDAP distinguished name
Looking for a different code? Search another status or error code.