Vista Issue: Vista to Vista Terminal Service Logon Failing

[Alex Simons (AZURE)]

First published on CloudBlogs on Jun, 07 2007

Some of my colleagues recently had a real puzzler of an issue.  When they are that good I want to share it out with everyone so that they don’t have to take the time themselves.

The symptoms were when attempting to connect via terminal services from one Vista computer to another Vista computer the connection would fail with an error:

"No authority could be located for authentication. For assistance, contact your system administrator or technical support."

The system administrators were the ones calling us (technical support), and rightfully so.  This did not look like it should be happening at all.  Some of the additional details on this issue and when it may occur are:

·         Both Vista computers must be members of Active Directory domains.

·         The user who is logging on is a member of a domain which has had at least one authoritative restore done to the Users container (well, specifically the KrbTgT object which resides there).

·         This will occur if you specify the name of the Vista computer you want to log on to remotely (mstsc /v:<computername>)-but not if you use the IP address.

Why is this happening?  Well, you may have heard of a little something we’re working on called Windows Server 2008, also known as Longhorn.  Longhorn has a new feature (discussed in a prior blog post) called Read Only Domain Controllers (RODCs).    RODCs have a read-only copy of the domain naming context that they are domain controllers for.  Think of how global catalogs host read only copies, but for the domain and with a few differences.

One of the design considerations for having RODCs is figuring out how client computers will know an RODC from a regular DC.    Maybe you have a change to be done that can only be handled by a full DC-like a user account creation, or a password change.

Vista clients have code in some places to help determine if they are communicating with an RODC or a full DC.

Why this little explanation?  Because it turns out that the Vista client was thinking that the domain controller that was providing authentication for the terminal service session was an RODC one.  So it would look for a non-RODC one and not succeed since it was using the same test to look.

The test used was a look at the version number of the KrbTgT object in the Active Directory.  RODCs, by nature, will have a different KrbTgT account with its own password that will change more frequently (or at all) compared a regular domain controllers KrbTgT version number.  Vista was assuming that, since the KrbTgT version was large, that the domain controller being used was an RODC.

Of course, the customers who originally called us about this did not have Longhorn RODCs in their environment.

How do you determine the version number of your KrbTgT object?  Repadmin.exe is your friend on this.  Run the command below and it’s as plain as day (be sure to substitute your own domain controller name for tspringdc1, and your own domain name for the remainder of the distinguished name below):

repadmin /showobjmeta tspringdc1 “CN=krbtgt,CN=Users,DC=tspringtest,DC=com”

…and the result:

35 entries.

Loc.USN      Originating DC                                                  Org.USN  Org.Time/Date     Ver Attribute

=======    =============== =========               =============                   ============

12320       Default-First-Site-NameTSPRINGDC1     12320 2005-05-27 12:40:46 100001 objectClass

12320       Default-First-Site-NameTSPRINGDC1     12320 2005-05-27 12:40:46 100001 cn

12325       Default-First-Site-NameTSPRINGDC1     12325 2005-05-27 12:40:46 100002 description

12320       Default-First-Site-NameTSPRINGDC1     12320 2005-05-27 12:40:46 100001 instanceType

12320       Default-First-Site-NameTSPRINGDC1     12320 2005-05-27 12:40:46 100001 whenCreated

12321       Default-First-Site-NameTSPRINGDC1     12321 2005-05-27 12:40:46 100001 displayName

12320       Default-First-Site-NameTSPRINGDC1     12320 2005-05-27 12:40:46 100001 showInAdvancedViewOnly

37122       Default-First-Site-NameTSPRINGDC1     37122 2006-11-09 19:00:42 100003 nTSecurityDescriptor

12320       Default-First-Site-NameTSPRINGDC1     12320 2005-05-27 12:40:46 100001 name

12322       Default-First-Site-NameTSPRINGDC1     12322 2005-05-27 12:40:46 100003 userAccountControl

12321       Default-First-Site-NameTSPRINGDC1     12321 2005-05-27 12:40:46 100001 codePage

12321       Default-First-Site-NameTSPRINGDC1     12321 2005-05-27 12:40:46 100001 countryCode

12321       Default-First-Site-NameTSPRINGDC1     12321 2005-05-27 12:40:46 100001 homeDirectory

12321       Default-First-Site-NameTSPRINGDC1     12321 2005-05-27 12:40:46 100001 homeDrive

12323       Default-First-Site-NameTSPRINGDC1     12323 2005-05-27 12:40:46 100001 dBCSPwd

12321       Default-First-Site-NameTSPRINGDC1     12321 2005-05-27 12:40:46 100001 scriptPath

12321       Default-First-Site-NameTSPRINGDC1     12321 2005-05-27 12:40:46 100001 logonHours

12321       Default-First-Site-NameTSPRINGDC1     12321 2005-05-27 12:40:46 100001 userWorkstations

12323       Default-First-Site-NameTSPRINGDC1     12323 2005-05-27 12:40:46 100002 unicodePwd

12323       Default-First-Site-NameTSPRINGDC1     12323 2005-05-27 12:40:46 100002 ntPwdHistory

12323       Default-First-Site-NameTSPRINGDC1     12323 2005-05-27 12:40:46 100002 pwdLastSet

12321       Default-First-Site-NameTSPRINGDC1     12321 2005-05-27 12:40:46 100001 primaryGroupID

12324       Default-First-Site-NameTSPRINGDC1     12324 2005-05-27 12:40:46 100001 supplementalCredentials

12321       Default-First-Site-NameTSPRINGDC1     12321 2005-05-27 12:40:46 100001 userParameters

12321       Default-First-Site-NameTSPRINGDC1     12321 2005-05-27 12:40:46 100001 profilePath

12320       Default-First-Site-NameTSPRINGDC1     12320 2005-05-27 12:40:46 100001 objectSid

12424       Default-First-Site-NameTSPRINGDC1     12424 2005-05-27 12:56:07 100001 adminCount

12321       Default-First-Site-NameTSPRINGDC1     12321 2005-05-27 12:40:46 100001 comment

12321       Default-First-Site-NameTSPRINGDC1     12321 2005-05-27 12:40:46 100001 accountExpires

12323       Default-First-Site-NameTSPRINGDC1     12323 2005-05-27 12:40:46 100002 lmPwdHistory

12320       Default-First-Site-NameTSPRINGDC1     12320 2005-05-27 12:40:46 100001 sAMAccountName

12320       Default-First-Site-NameTSPRINGDC1     12320 2005-05-27 12:40:46 100001 sAMAccountType

12401       Default-First-Site-NameTSPRINGDC1     12401 2005-05-27 12:41:41 100001 servicePrincipalName

12320       Default-First-Site-NameTSPRINGDC1     12320 2005-05-27 12:40:46 100001 objectCategory

12320       Default-First-Site-NameTSPRINGDC1     12320 2005-05-27 12:40:46 100001 isCriticalSystemObject

The above version numbers show that I’ve marked that object authoritative once since we know that we increment the version numbers by 100,000 when we mark an object authoritative.

Now, how do you workaround this?  Here’s how:

First, you can use IP address in your MSTSC only.  This will circumvent that access check, but may provide less security since it will not be using Kerberos for the authentication in that instance.

Second, you can alter the RDP connection to behave more like the prior version of our terminal services client.  Here’s how to do that.

1.       Go to StartàRunàMSTSC.

2.       Type in the name of the “server” Vista computer you would like to connect to and then Save the RDP.

3.       Open the RDP file you just save with Notepad.

4.       Alter the line that says “authentication level:i:2” so that the 2 is a 0 like this “authentication level:i:0” (Without the quotes.   This prevents the new TS client version from checking for Server Authentication).

5.       Add “enablecredsspsupport:i:0” (without the quotes) to the end of the file.  (This bypasses entering user credentials prior to creating the connection. The host pc will still prompt for credentials as normal).

6.       Save the file.

7.       Whenever you want to connect to that Vista computer from Vista use that RDP file to connect.

I want to give homage to my colleague engineers who actually worked this issue (credit where credit is due):

Brian “Loner” Singleton

Paul “The Hut” Hutmacher

Ned “Gomer” Pyle

Thanks guys!  As always, please post if you have comments or questions, or email me via the blog.  Take care everyone till next time!