Interactive user logon over external trust fails or encounters delays


Symptoms


  1. Interactive logons on Windows Vista or Windows Server 2008 computers by users in trusted domains fail with the on-screen error:

    The security database on the server does not have a computer account for this workstation trust relationship.

  2. RDP logons from Windows Vista or Windows Server 2008 computers by trusted domain user accounts fail with the on-screen error:

    The security database on the server does not have a computer account for this workstation trust relationship.

  3. Network traces of scenario 2 above taken from the Windows Vista or Windows Server 2008 computer show KDC_ERR_S_PRINCIPAL_UNKNOWN in the Kerberos TGS Response:

    1457  15:56:35.4908750  22.9218750        192.168.1.10      192.168.1.99      KerberosV5  KerberosV5:TGS Request {TCP:189, IPv4:184}

    1460  15:56:35.4908750  22.9218750        192.168.1.99      192.168.1.10      KerberosV5  KerberosV5:KRB_ERROR  - KDC_ERR_S_PRINCIPAL_UNKNOWN (7)     {TCP:189, IPv4:184}

  4. Logons from computers running versions of Windows earlier than Windows Vista using trusted domain user accounts will succeed. Examining a network trace of this logon will show the same Kerberos failure. However, NTLM fallback authentication allows the user to logon.

    1750       16:40:29.2526250              21.2656250                          192.168.1.11       192.168.1.78       KerberosV5                KerberosV5:KRB_ERROR  - KDC_ERR_S_PRINCIPAL_UNKNOWN (7)         {UDP:216, IPv4:201}

    ...

    1785       16:40:29.2838750              21.2968750                          192.168.1.78       192.168.1.11       SMB       SMB:C; Session Setup Andx, NTLM AUTHENTICATE MESSAGE, Domain: CONTOSO, User: admin, Workstation: TEST       {SMBOverTCP:223, TCP:220, IPv4:84}

  5. The traces may also show no response from the remote domain controllers when LDAP pings (over UDP port 389) are sent, or when the Kerberos ticket request over port UDP 88 does not see a response. You may also see there is no response to TCP SYN requests on port 88.

In this case, the delay you encounter depends on the port that is blocked:

  • UDP 389: The DC Locator will walk all domain controllers it can find in DNS and ping each one. The delay increases proportionally with the number of domain controllers found. In a sample environment with 23 domain controllers there was a 25 seconds delay.
  • Port 88: The Kerberos client will retry reaching the KDC. For UDP you may see a delay of approximately 60 seconds.

Cause


There are two scenarios where Kerberos authentication fails:

  1. The network ports and IP addresses required for the Kerberos ticket requests are blocked on the firewall since you did not expect Kerberos was being used, and a direct contact from the user workstation to the user domain being made.

  2. Key attributes on the trusted domain object (TDO) do not contain the DNS name of the trusting domain. In this case, Kerberos cannot identify the DNS name of the user domain.

The latter applies when:

  1. A Windows NT 4.0-style trust was created to the trusted domain either because the trusting domain ran Windows NT 4.0 when the trust was created or a third-party tool created a down-level trust between the trusted and trusting domains.

  2. The trusting domain was subsequently upgraded from Windows NT 4.0 to Windows 2000, Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2.

  3. The trust in Step 1 survived the Windows NT 4.0 to Windows 2000 or later upgrade.

  4. The CN, Name and trustPartner attributes on the trusted domains TDO contain the NetBIOS name of the trusting domain.

NTLM authentication fails if the computers performing the interactive logon are running Windows Vista or later versions of Windows.

Winlogon on Windows Vista and Windows Server 2008 computers has been modified so that it no longer performs a fallback to NTLM if Kerberos authentication fails to prevent man-in-the-middle replay attacks.

The Kerberos referral failure is the result of a DNS name missing from the TDO. This typically occurs when external domain trusts are created using third-party tools or if the domain was upgraded from Windows NT 4.0. 

See the More Information section of this article for examples of a TDO missing DNS information.

NOTE

You can still see Windows 7 Clients use NTLM for interactive logon. The scenario is a pair of forests with users in one child domain of forest1 and the computers they use for logon in a child domain in forest2. There is no global NETBIOS name resolution and the users logon using the NT4 Syntax forest1-child\user.

In this case, the search for a DC of "forest1-child" will fail and the client will send the request to the primary DC of the workstation. The name "forest1-child" is in the list of child domains in the remote forest, so it knows it can forward the request to "forest1" through its root DCs. In response, it will be a NTLM logon using the user NETBIOS name. Because of that, the environment variable "USERDNSDOMAIN" will be missing from the user environment.

NTLM authentication will succeed, however any future access to the user DCs by the group policy or profile service will fail, and group policy for the user does not apply. An interim solution is using LMHOSTS to publish select DCs from the user domain on the client. The real solution is using unique UPN suffixes and UPN logons, e.g. the implicit UPN of the user.

We have tested that if the computer DC ("forest2-child") is Windows Server 2012, it apparently returns the DNS name of "forest1-child" to the client, as it immediately requests DNS name resolution for the user domain. When having Windows Server 2012 you will also have the varialbe "USERDNSDOMAIN".

Resolution


If the trust is not enabled for DNS, remove the existing external trust and recreate it using the Windows Domains and Trusts snap-in or the Netdom command-line tool.

If the firewall ports are blocked, open the ports UDP 389 and UDP and TCP port 88 for the domain controllers of the user domain. For information about optimizing the location of domain controllers, see the following article in the Microsoft Knowledge Base:

306602 How to optimize the location of a domain controller or global catalog that resides outside of a client's site

For more information about Windows Server port usage, see the following article in the Microsoft Knowledge Base:

832017 Service overview and network port requirements for the Windows Server system

More Information


Here is an example of a TDO that is missing the DNS name:

Expanding base 'CN=CONTOSO,CN=System,DC=wingtiptoys,DC=com'...
Result <0>: (null)
Matched DNs:
Getting 1 entries:
>> Dn: CN=CONTOSO,CN=System,DC=wingtiptoys,DC=com
3> objectClass: top; leaf; trustedDomain; 
1> cn: CONTOSO
1> distinguishedName: CN=CONTOSO,CN=System,DC=wingtiptoys,DC=com; 
1> instanceType: 0x4 = ( IT_WRITE );
1> whenCreated: 08/31/2005 17:53:08 Central Standard Time Central Daylight Time;
1> whenChanged: 10/30/2009 02:27:43 Central Standard Time Central Daylight Time;
1> uSNCreated: 7305;
1> uSNChanged: 8467655;
1> showInAdvancedViewOnly: TRUE;
1> name: CONTOSO;
1> objectGUID: d66d2700-c599-4d73-a7b8-ab36e4929910;
1> securityIdentifier: <ldp: Binary blob>;
1> trustDirection: 2;
1> trustPartner: CONTOSO;
1> trustPosixOffset: -2147483648;
1> trustType: 1;
1> trustAttributes: 0;
1> flatName: CONTOSO;
1> objectCategory: CN=Trusted-Domain,CN=Schema,CN=Configuration,DC=wingtiptoys,DC=com;
1> isCriticalSystemObject: TRUE;
2> dSCorePropagationData: 08/11/2009 17:57:47 Central Standard Time Central Daylight Time; 0/0/0 64153:219:58292 UNC;