Interactive user logon over external trust fails or encounters delays

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".