Recently, clients get problems when the Broker of our RDP server farm decides that the user should be redirected to another host. We use a broker and DNS round robin, no NLB or gateway.All RDP servers involved are Win2008R2, AD is Win2003.
The problem occurs with all modern clients (i.e., those with server authentication); changing the connectrion security from "negotiate" to "RDP" helps (though that brings back the old user experience of people having to enter their credentials
twice etc.).
The error message the clients get in case of redirection is (translated from German):
Remote desktop connection cannot connect to remote computer.
From the remote computer "myfarm" which you are trying to connect to you are redirected remote computer "somefarmmember.mydomain.local". It cannot be verified if both remote computers belong to the same remote desktop session host server
farm. You must use the farm name, not the computer name, if you want to make a connection to a remote desktop server farm.
Contact a network administrator to obtain support if you use a RDP connection that was prepared by the administrator.
If you want to connect with a specific farm member for administration purposes, use "mstsc /admin" at the command prompt.
In my test farm, I can even enforce this error message by blocking one server ("Do not accept logins until reboot") and let DNS resolve "myfarm" only to the IP of this blocked server (so that the broker will always decide to redirect).
What we see in the logs of the broker is that the redirection seems to take place correctly, but after some simeout the broker notices that the expected login to the redirected host did not occur.
What can be the problem? How can I debug more closely how that failed verification mentioned in the error message takes place? At least I am unable to see anything that seems to be related to the problem in any of my event logs
What might we have done to break things? Two months ago, we wanted to begin our migration from AD2003 to AD2012. A new Win2012 server was added and DNS and AD roles installed without any problems. Later we were unhappy with the new server in general
and demoted and removed it - sucessfully as far as I can tell. While this process must have permanently "modernized" the schema and all, I cannot really assume that this process is the root cause of our porblems (also, the time the error behaviour
stated was not directly related), but some side-effects might be perhaps?
Regards
Hagen
UPDATE
Things are getting weird: As of now some lucky users function, i.e. they go through the following steps:
- Start "mstsc"
- enter the farm name and "connect"
- enter their credentials and "OK"
- accept the warning about the certificate of the first contact rdp host (I let warnings on deliberately to easily see which hosts get tried)
- accept the warning about the certificate of the second rdp host
- huzzah!
Other (unlucky) users get only to point 3 (i.e., they are never even presented the server certificate warning) and get a "failed login" message upon hitting "OK". They can try again and again - only entering a different username/password
(one of the lucky ones) will help.
Originally I had just one lucky user. It seems that one can (temporarily?) turn an unlucky user into a lucky user by doing "mstsc /admin" once to the destination rdp server (and logout again). This procedure was even needed to make Administrator
work! It seems that at any moment I can have at most two lucky accounts - trying to make a third one lucky makes one of the others unlucky ...
A login attempt by an unlucky user leaves the following trace in the corresponding rdp host: In Eventlog "security" there is an Event 4625
>An account failed to log on.
>
>Subject:
> Security ID: NULL SID
> Account Name: -
> Account Domain: -
> Logon ID: 0x0
>Logon Type: 3
>Account For Which Logon Failed:
> Security ID: NULL SID
> Account Name: <unlucky username>
> Account Domain: <domain>
>Failure Information:
> Failure Reason: An error occured during login.
> Status: 0xc000006d
> Sub Status: 0x0
>Process Information:
> Caller Process ID: 0x0
> Caller Process Name: -
>Network Information:
> Workstation Name: <workstation name>
> Source Network Address: -
> Source Port: -
>Detailed Authentication Information:
> Logon Process: NtLmSsp
> Authentication Package: NTLM
> Transited Services: -
> Package Name (NTLM only): -
> Key Length: 0
I find the many gaps (e.g., Source network addess) and all those NULL SIDs disturbing.