Revised this question to be more concise, consolidating several revisions.


From a domain-member Windows 7 Client:

  • Domain credentials to a domain controller => success
  • Domain credentials to a member server (by hostname or FQDN) => success
  • Domain credentials to a member server (by IP) => fail
  • Local credentials to a member server (by either) => success

From a non-domain-member Windows 7 Client:

  • Domain credentials to a domain controller => success
  • Domain credentials to a member server => fail
  • Local credentials to a member server => success
  • (Identical behavior from a Mac RDC 2.1 client)

Server Configuration Details:

  • Windows 2008 R2 Datacenter w/ SP1
  • The domain in question is a subdomain of a Windows 2008 domain (forest root).
  • Root has DCs in both Site A and Site B, subdomain only has DCs in Site B.
  • RDP is operating normally on all root member-servers and DCs.
  • No remote desktop settings are defined by GPOs.
  • Network level authentication is enabled; all clients are compatible and the certificate exchange/SSL handshake completes successfully.
  • Not catching any errors in netlogon log.
  • A domain is a security boundary, is your user account a domain admin in both the parent and child domain? Mar 22, 2011 at 4:00
  • The user is a member of the same domain as the target RD Session Host, and is a member of the Domain Admins group.
    – lukiffer
    Mar 22, 2011 at 4:02

2 Answers 2

  1. If you are seeing SID's in local groups then your DNS or AD access is messed up from that server to either sub or parent domain IMO. RDP access could be a red herring and the real issue is proper connectivity to AD. Do you have event log events talking about unable to resolve account, etc? In a healthy server you should never see SID's IMO (unless accounts are deleted).
  2. It's possible a GPO is affecting member servers security policy "allow log on through Remote Desktop Services" or the often forgotten "deny log on through Remote Desktop Services" inside the computer GPO config. You might be left out of the first or added to the second for member servers GPO, then that could be overwritten at the DC container level by the "default domain controllers policy". Run a Group Policy Results on a member server as you and see what shows up for:

computer config > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignments > two settings in quotes above

  • 1. Event Viewer and dcdiag indicate that AD is working properly. I can authenticate for UNC, but not RDP. 2. The two settings are not defined in the GPO. I did however discover an interesting twist. I'll update the question with that.
    – lukiffer
    Mar 22, 2011 at 4:00
  • for the failed attempt, what's the event logs say? security got a specific failure? Do you have IPSec policies in place? On the member boxes are you set for NLA auth only? wondering if either NLA or IPSec could be denying connection based on certificate not matching name you use to access. Is your RDP client set to deny connections that don't auth to server (although that results in a diff error then you said in update 2)? Mar 22, 2011 at 4:49
  • Stangely, I don't see anything in any of the logs (both client and server-side). There aren't any IPSec policies. Both the DCs and member servers require NLA - tried allowing connections without NLA, but the Windows 7 and 2008 R2 clients attempt it by default. The RDP client is configured to warn on a certificate error - I permanently accepted the cert when I first connected.
    – lukiffer
    Mar 22, 2011 at 5:07

I see this has already been mentioned but I have to also say it sounds like a GPO is in the mix denying your access to RDP.

Try to run GPO modeling from the GPMC on each of the member servers as a domain admin and see what GPO's are supposed to be applying. You will be able to look at the report and tell what settings are applied to both the user and the computer. Also, login to the console and look at the local policy settings and see if the GPO login is denied there.

If all of that is inconclusive, try enabling netlogon debugging and see if, when you attempt to login, you get any errors in there.

  • Thanks for the response. GPO modeling on the member server matches the policy in the GC. Nothing is defined except that RDP should be enabled. The interesting twist is that it works fine by hostname, but not by IP, even though they resolve to the same address (see Update 2).
    – lukiffer
    Mar 22, 2011 at 4:22
  • Just to clarify, if you RDP to these machines using either the host name or the fqdn, it will prompt for credentials and log you in to the desktop. If you run "mstsc /v <IP Address>" it will prompt you for credentials but give you the message that the credentials are invalid?
    – BoxerBucks
    Mar 22, 2011 at 4:34
  • Correct, mstsc /v <IP>, enter credentials, and it repeats the prompt with this error: "The credentials that were used to connect to <IP> did not work. Please enter new credentials." : "The logon attempt failed"
    – lukiffer
    Mar 22, 2011 at 4:43
  • Enable netlogon debugging and look at the debug file for the error. Also look in the security logs to see the authentication error. I don't know the significance of using an IP address to simply connect mstsc to a machine as opposed to using the FQDN. I didn't think there was a difference - once the connection is made and you pass the credentials, the machine you are authenticating to takes care of the rest. The fact that you use an ip address or an FQDN shouldn't matter.
    – BoxerBucks
    Mar 22, 2011 at 5:01
  • I also found this thread that references your problem and says there is a hotfix available. Its at the bottom of the page - social.technet.microsoft.com/Forums/en-US/winserverTS/thread/…
    – BoxerBucks
    Mar 22, 2011 at 5:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .