Microsoft has released a KnowledgeBase article, in which they describe an issue you might encounter in a multi-domain environment, resulting in a loss of the secure channel between the domains and a long time for the secure channel to become reestablished.
In KnowledgeBase article 2860157, Microsoft describes the situation where you have multiple domains in one or more forests that have Windows Server 2012-based Active Directory Domain Controllers and you have at least one direct trust relationship between the domains.
On the Domain Controllers, you set the value for the RestrictRemoteClients registry key to 2 and the value for the EnableAuthEpResolution registry key to 1.
These two registry key settings can be placed in
HKLM\ Software\Policies\Microsoft\Windows NT\RPC
They help secure RPC Endpoint Mapper:
- The RestrictRemoteClients registry key modifies the behavior of all RPC interfaces on the system. By default, the RestrictRemoteClients registry key prevents remote anonymous access to RPC interfaces on the system, with some exceptions. With the setting defined as 2, all remote anonymous calls are rejected by the RPC runtime with no exemptions. When this value is set, a system cannot receive remote anonymous calls using RPC.
- After you enable RestrictRemoteClients with the above value, the RPC Endpoint Mapper interface will not be accessible anonymously. This is a significant security improvement, but it changes the task of resolving an endpoint. Currently, an RPC client that attempts to make a call using a dynamic endpoint will first query the RPC Endpoint Mapper on the server to determine what endpoint it should connect to. This query is performed anonymously, even if the RPC client call itself is performed using RPC security. Anonymous calls to the RPC Endpoint Mapper interface will fail on Windows Servers (since Windows Server 2003 with ServicePack 1) if the RestrictRemoteClients key is set to 1 or higher. This makes it necessary to modify the RPC client runtime to perform an authenticated query to the Endpoint Mapper. If the EnableAuthEpResolution key is set, the RPC client runtime will use NTLM to authenticate to the endpoint mapper. This authenticated query will take place only if the actual RPC client call uses RPC authentication.
These registry settings have been part of the Threats and Countermeasures guides since the Windows XP and Windows Server 2003 era.
In this situation, the secure channel between the Active Directory domains is lost when you perform cross-domain NT LAN Manager (NTLM) authentication. Also, there is a long delay before the secure channel is reestablished. You may also receive unexpected credential prompts and the following Error event:
Log Name: System
Event ID: 5816
Netlogon has failed an authentication request of account username in domain user domain FQDN. The request timed out before it could be sent to domain controller directly trusted domain controller FQDN in domain directly trusted domain name. This is the first failure. If the problem continues, consolidated events will be logged about every event log frequency in minutes. Please see http://support.microsoft.com/kb/2654097 for more information.
This issue occurs because the Netlogon secure channel is a special case for RPC Endpoint Mapper. It can be used to authenticate RPC Endpoint Mapper itself. In some cases, the Netlogon secure channel is not honored, and this causes a deadlock that takes time to resolve.
A supported hotfix is available from Microsoft, that replaces Rpcrt4.dll. You can apply this hotfix on Domain Controllers running Windows Server 2012.
You might need to restart the computer after you apply this hotfix. This hotfix does not replace a previously released hotfix.
I suggest that you apply this hotfix to all Windows Server 2012-based Active Directory Domain Controllers in your environment.
Related KnowledgeBase articles
2860157 Lost secure channel takes a long time to be reestablished when RPC Endpoint Mapper is secured on Windows Server 2012 Domain Controllers
2654097 New event log entries that track NTLM authentication delays and failures in Windows Server 2008 R2 are available