Domain-Qualified Usernames in Proxy Credentials
Distinguish an opaque account name from APIs with separate domain fields, and avoid changing an account identity merely to satisfy URL syntax.
One answer says to remove DOMAIN\. Another says to add it. Both changes can be wrong for your proxy.
There are two questions: which identity the service expects, and how the chosen API represents that identity.
| Interface | What to establish |
|---|---|
| A single account-name field | The exact account syntax the operator accepts |
| A credential API with a domain field | Whether domain and username should be supplied separately |
| Credential components inside a URI | How the intended values must be encoded for that container |
For example, .NET exposes a NetworkCredential constructor with separate username, password and domain arguments. Putting a domain into two fields indiscriminately is not a portable way to configure integrated authentication.
Basic authentication is another case: the server interprets the supplied account text under its own policy. Being on the same network does not prove that a domain prefix is implied. Nor is a domain-qualified name automatically a different authentication protocol.
URL escaping should preserve the intended account rather than change it. A backslash in a source-language string, a backslash in an account name and its percent-encoded representation inside a URI are separate layers.
Get the accepted identity form and scheme from the operator, then use the corresponding credential interface. Randomly alternating between a short name, a domain name and an email-looking name creates poor evidence about the original 407.