- Thread Author
-
- #1
I'm seeing some very odd remote desktop problems at work. The server is 2008 Server R2 64-bit. Unfortunately, I do not have administrative privileges. I have to escalate to another group in order to analyze logs. I have done this, but my team may meanwhile sit idle for days. All clients are Windows 7 Enterprise Service Pack 1 64-bit. I have full admin privileges on all clients. The clients that cannot connect are on a domain, and the clients that can connect are not on a domain. The server is on a totally different domain, and we are logging in with local user accounts.
Some of the clients can connect to the server using remote desktop. Other clients cannot connect using precisely the same credentials. This rules out a username/password error. However, it is some sort of username/password problem because repeated attempts will lock out the account. The remote desktop failure message is "invalid credentials." If I remove the system from the domain, the problem goes away! It seems like being on the domain is causing the credentials passed to the server to be invalid, even though we're typing the same username and password that work on other clients. We're specifying exactly the same username and password, and we're specifying a local user account by prefixing the username with the remote desktop server hostname: servername\firstname.lastname
They are on the same subnet, and I can literally move the network cable from one system that works to one that doesn't, and the system still cannot connect to the server. This, in my opinion, rules out network problems. I don't see anything noteworthy in event viewer on the client side.
I used Wireshark to compare the network transmissions between failing hosts and succeeding hosts. I cannot analyze the payload, of course, because the session is encrypted. I do, however, notice that the systems that cannot connect are the first to send a packet with the FIN flag. This tells me that the clients are the ones initiating the dismantling of the TCP session. This is consistent with all of the other evidence pointing towards a client-specific problem.
I began checking into security policy settings, but I can't for the life of me find any differences. I checked the certificate being used by the server and imported it into the trusted certificates store. I know I'm trying to connect to the server using the same hostname that appears on the certificate. Does anyone have any suggestions? I'm a UNIX admin and I'm a little stumped. Are there any tools or scripts that can dump security policy settings for easy comparison? Any debuggers that will allow me to analyze the remote desktop session on the client side? If anyone can point me to some documentation that may provide some education, I'll be happy to read it. Any advice would be greatly appreciated.
Some of the clients can connect to the server using remote desktop. Other clients cannot connect using precisely the same credentials. This rules out a username/password error. However, it is some sort of username/password problem because repeated attempts will lock out the account. The remote desktop failure message is "invalid credentials." If I remove the system from the domain, the problem goes away! It seems like being on the domain is causing the credentials passed to the server to be invalid, even though we're typing the same username and password that work on other clients. We're specifying exactly the same username and password, and we're specifying a local user account by prefixing the username with the remote desktop server hostname: servername\firstname.lastname
They are on the same subnet, and I can literally move the network cable from one system that works to one that doesn't, and the system still cannot connect to the server. This, in my opinion, rules out network problems. I don't see anything noteworthy in event viewer on the client side.
I used Wireshark to compare the network transmissions between failing hosts and succeeding hosts. I cannot analyze the payload, of course, because the session is encrypted. I do, however, notice that the systems that cannot connect are the first to send a packet with the FIN flag. This tells me that the clients are the ones initiating the dismantling of the TCP session. This is consistent with all of the other evidence pointing towards a client-specific problem.
I began checking into security policy settings, but I can't for the life of me find any differences. I checked the certificate being used by the server and imported it into the trusted certificates store. I know I'm trying to connect to the server using the same hostname that appears on the certificate. Does anyone have any suggestions? I'm a UNIX admin and I'm a little stumped. Are there any tools or scripts that can dump security policy settings for easy comparison? Any debuggers that will allow me to analyze the remote desktop session on the client side? If anyone can point me to some documentation that may provide some education, I'll be happy to read it. Any advice would be greatly appreciated.