Jaa

Remote Desktop Client & credentials saved in UPN format

  • Artikkeli

Another potential head-scratcher from a recent case…

Consider the situation where you have a client machine running Remote Desktop Client connecting to an RDS server Remote1 in domain Alpha, you authenticate using UPN format credentials (e.g. mytestuser@alpha.local) and elect to save the credentials into your vault.

If the machine you are connecting from is not in domain Alpha, but is in another domain (Beta) then the first connection will be successful, but attempts to use the saved credentials on subsequent connections will fail with “the specified user does not exist”).

 

The reason for this is that the initial connection attempt where the credentials are entered will get a negative result from a DC for domain Beta (expected, as it cannot resolve the UPN to a user account), but then allows a fallback to NTLM authentication to establish the connection (i.e. the credentials are passed to the RDS server to resolve against a DC in domain Alpha).

When pulling the credentials from the vault, however, we assume that they were validated at storage time and so when the “user not found” error is returned from the local DC, it does not attempt to fall back to NTLM.

 

The workaround for the issue is to store the credentials for the connection in DOMAIN\USERNAME format instead (e.g. ALPHA\MYTESTUSER) – then the credentials are explicitly for another domain and so are passed through as an NTLM authentication request to the RDS server.

(Note that the client will need to have the effective group policy setting “Allow Saved Credentials with NTLM-only Server Authentication” populated with TERMSRV/Remote1 or a matching wildcard string (e.g. TERMSRV/* ) to be able to used credentials stored in this format.)

 

The problem will not present if any of the following are true:
- the client machine is not in a domain
- there is no DC available for Kerberos requests in domain Beta
- the client is logged on with a local user account (instead of a user account in domain Beta)

Note that we are talking about saved credentials, not cached credentials – they are completely different beasts.

Comments

  • Anonymous
    September 02, 2014
    Thanks. This helped a lot.
  • Anonymous
    September 19, 2014
    i want to add two little things.
    But first let me give you a HUGE thank you. I was searching eternities for a solution. first in German, then in english.
    Now, i had the Problem that i tried to connect from a Domain Client to a Workgroup Server over the Internet.


    I can add following points to your fix:
    @ (testuser@testdomain.net) DOES NOT WORK. It HAS to be DomainUsername. (you can connect manually with this, but the saved credentials won't work this way...)

    If the Server is in a workgroup you have to use the Workgroup instead of the Domain (kinda obvious, but i wasn't 100% sure).