Restrictions for Unauthenticated RPC Clients: The group policy that punches your domain in the face

Restrictions for Unauthenticated RPC Clients: The group policy that punches your domain in the face

  • Comments 8
  • Likes

Hi folks, Ned here again. Around six years ago we released Service Pack 1 for Windows Server 2003. Like Windows XP SP2, it was a security-focused update. It was the first major server update since the Trustworthy Computing initiative began so there were things like a bootstrapping firewall, Data Execution Protection, and the Security Configuration Wizard.

Amongst all this, the RPC developers added these new configurable group policy settings:

Computer Configuration \ <policies> \ Administrative Templates \ System \ Remote Procedure Call

Restrictions for unauthenticated RPC clients
RPC endpoint mapper client authentication

Which map to the DWORD registry settings:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Rpc


These two settings add an additional authentication "callback capability" to RPC connections. Ordinarily, no authentication is required to make the initial connection to the endpoint mapper (EPM). The EPM is the network service that tells a client what TCP/UDP ports to use in further communications. In Windows, those further communications to the actual application are what typically get authenticated and encrypted. For example, DFSR is an RPC application that uses RPC_C_AUTHN_LEVEL_PKT_PRIVACY with Kerberos required, with Mutual Auth required, and with Impersonation blocked. The EPM connection not requiring authentication is not critical, as there is no application data transmitted: EPM is like a phone book or perhaps more appropriately, a switchboard with an operator.

That quest for Trustworthy Computing added these extra security policies. In doing so, it introduced a very dangerous scenario for domain-based computing: one of the possible policy settings requires all applications that initiate the RPC conversation send along this authentication data or be able to understand a callback request to authenticate.

The problem is most applications have no idea how to satisfy the setting's requirements.

The Argument

One of the options for Restrictions for unauthenticated RPC clients is "Authenticated without Exceptions".


When enabled, RPC applications are required to authenticate to RPC service on the destination computer. If your application doesn't know how to do this, it is no longer allowed to connect at all.

Which brings us to…

The Brawl

Having configured this policy in your domain on your DCs, members, and clients, you will now see the following issues no matter your credentials or admin rights:

Group policy fails to apply with errors:


The processing of Group Policy failed. Windows could not resolve the computer name. This could be caused by one of more of the following:
a) Name Resolution failure on the current domain controller.
b) Active Directory Replication Latency (an account created on another domain controller has not replicated to the current domain controller).
Computer Policy update has completed successfully.
To diagnose the failure, review the event log or invoke gpmc.msc to access information about Group Policy results

The System Event log returns errors 1053 and 1055 for group policy:

The processing of Group Policy failed. Windows could not resolve the user name. This could be caused by one of more of the following:
a) Name Resolution failure on the current domain controller.
b) Active Directory Replication Latency (an account created on another domain controller has not replicated to the current domain controller).

The Group Policy Operational event log will show error 7320:

Error: retrieved account information. Error code 0x5.
Error: Failed to register for connectivity notification. Error code 0x32.

Active Directory Replication fails with errors:

Repadmin.exe returns:

DsBindWithCred to RPC <servername> failed with status 5 (0x5)

DSSites.msc returns:


Directory Service event log returns:

Warning 1655:
Active Directory Domain Services attempted to communicate with the following global catalog and the attempts were unsuccessful.
Global catalog:
The operation in progress might be unable to continue. Active Directory Domain Services will use the domain controller locator to try to find an available global catalog server.
Additional Data
Error value:
5 Access is denied.

Error 1126:

Active Directory Domain Services was unable to establish a connection with the global catalog.
Additional Data
Error value:
1355 The specified domain either does not exist or could not be contacted.
Internal ID:

Warning 2092:

This server is the owner of the following FSMO role, but does not consider it valid. For the partition which contains the FSMO, this server has not replicated successfully with any of its partners since this server has been restarted. Replication errors are preventing validation of this role. Operations which require contacting a FSMO operation master will fail until this condition is corrected.

Domain join fails with error:

Changing the primary domain DNS name of this computer to "" failed.
The name will remain "<something>".
The error was:
Access is denied


After failed join above, rebooting computer and attempting a domain logon fails with error:

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


Remotely connecting to WMI returns error:

Win32: Access is denied.


Remotely connecting to Routing and Remote Access returns error:

You do not have sufficient permissions to complete the operation


Remotely connecting to Disk Management returns error:

You do not have access rights to logical disk manager


Remotely connecting to Component Services (DCOM) returns error:

Either the machine does not exist or you don't have permission to access this machine


Running DFSR Health Reports returns errors:

Domain Controller is unreachable
Cannot access the local WMI repository
Cannot connect to reporting DCOM server


DFSR does not replicate nor start initial sync, with errors:

DFSR Event log error 1202:

The DFS Replication service failed to contact domain controller to access configuration information. Replication is stopped. The service will try again during the next configuration polling cycle, which will occur in 60 minutes. This event can be caused by TCP/IP connectivity, firewall, Active Directory Domain Services, or DNS issues.

error: 160 (one or more arguments are not correct)

DFSRMIG does not allow configuration of SYSVOL migration and returns error:

"Unable to connect to the Primary DC's AD. Please make sure that the PDC is reachable and retry the command later"

FRS does not replicate and returns event log warning 13562:

Could not bind to a Domain Controller. Will try again at next polling cycle.

Remotely connecting to Windows Firewall with Advanced Security returns error:

You do not have the correct permissions to open the Windows Firewall with Advanced Security Console.
Error code: 0x5


Remotely connecting to Share and Storage Management returns error:

Connection to the Virtual Disk Service failed. A VDS (Virtual Disk Service) error occurred while performing the requested operation.


Remotely connecting to Storage Explorer returns error:

Access is denied.


Remotely connecting to Windows Server Backup returns error:

The Windows Server Backup engine is not accessible on the computer that you want to manage backups on. Make sure you are a member of the Administrators or Backup Operators group on that computer.

Remotely connecting to DHCP Management returns error:

Access is Denied

RPC Endpoint connections seen through network capture shows errors:

Note how the client ( attempts to bind to the EPM on a DC ( and gets rejected with status 0x5 (Access is Denied).


Depending on the calling application - in this case, the Group Policy service running on a Win7 client that is trying to refresh policy - it may continue to try binding many times before giving up. Again, the DC responds with the unhelpful error "REASON_NOT_SPECIFIED" and keeps rejecting the GP service.


For comparison, a normal working EPM bind of the GP service looks like this:



Anyone notice the Catch-22 above? If you deployed this setting using domain-based group policy to your DCs, you have no way to undo it!  This is another example of “always test security changes before deploying to production”. Many virtualization products are free, like Hyper-V and Virtual PC – even a single virtualized DC environment would have shown gross problems after you tried to use this policy.

To fix your environment:

1. You must delete or unlink the whole policy that includes this RPC setting:


2. Delete or rename this specific policy's GUID folder from each DCs SYSVOL folders (remember, file replication is not working so it must be done on all individual servers).



3. Manually visit all DCs and delete the RestrictRemoteClients registry setting.


4. Reboot all DCs to get your domain back in operation. Not all at once, of course!

These are only the affected Windows in-box applications and components that I have identified. The full list probably includes 99% of all third party RPC applications ever written.


Some security audit consulting company may ask you to turn this policy on to be compliant with their standards. Make sure you show them this article and make them explain why. You can also point out that our Security Compliance Manager tool does not recommend enabling "Authenticated without Exceptions" even in Specialized Security Limited Functionality networks (and SSLF is far too restrictive for most businesses). This setting is really only useful in an unmanaged, standalone, non-domain joined member computer environment such as a DMZ network where you want to close an RPC connection vector. Probably just web servers with local policy.

You should always get in-depth explanation from any third party security audit's findings and recommendations; many a CritSit case here started with a customer implicitly trusting an auditor's recommendations. That auditor is not going to be there to troubleshoot for you when everything goes to crap. Disconnecting all your DCs from the network makes them more secure. So does disabling all your user accounts. Neither is practical.

If you absolutely must turn on Restrictions for unauthenticated RPC clients, make sure it is set only to "Authenticated", and guarantee RPC endpoint mapper client authentication is also enabled. Then test like your job depends on it - because it does. Your applications may still fail with this setting in its less restrictive mode. Not all group policies are intended for domains.

By the way, if you are a software development company you should be giving the Security Development Lifecycle a frank appraisal. It is a completely free force for good.

Until next time.

Ned "2005? I am feeling old" Pyle

  • Ned, I was wondering if you could take a quick look at KB 3073942? That KB article seems to suggest that the "Enable RPC Endpoint Mapper Client Authentication" setting can cause problems across forest trusts if applied to DCs.

    However, I understood that setting to only affect client behavior - that being: Enabling *support* for acting as an RPC authenticated client, when necessary. Nothing to do with requiring it - that's where "Restrictions for unauthenticated RPC clients" would come into play (i.e. server behavior).

    I am just wondering if KB 3073942 is accidentally recommending the wrong setting be turned off - that the real risk, as noticed in your blog above, is "Restrictions for unauthenticated RPC clients".

    The reason I ask - if the client behavior setting ("Enable RPC Endpoint Mapper Client Authentication") is safe to use, wouldn't it be prudent to enable it (NOT the "Restrictions" one) on all systems? That way they are prepared, should the need arise, to respond to authenticated RPC requests where necessary.

    Perhaps KB 3073942 is indeed written correctly and the cross-trust problem it documents is indeed a problem with enabling the client behavior, but it seems to defy common sense to me. The client setting seems like it would be innocuous, and would have no effect if connecting to an unauthenticated RPC Endpoint Mapper.

  • I forgot to add... "except the Windows NT4 Server Endpoint Mapper Service" at the end of my previous comment.

  • The KB is a bit mysterious to me. The Method 2 section talks about an "AQ", whatever that is. I never experienced the trust issue mentioned in that KB either, and I am pretty sure I tried out that scenario.

    I do like that a KB is now telling people that a setting punches people in the face, though. :D

    I will follow up with the KB author and find out. Thanks EdgeDC!

  • Awesome, thanks Ned! I just want to make sure the information provided is accurate. It would be a shame to demonize a relatively "safe" setting (the client-side portion that enables basic support for it) instead of the real problem, the restrictions. Due to the wording of the 2 settings, it is easy to get them mixed up.

  • Ned - I see that KB 3073942 was updated today... but it seems that all they did was add in the step to remove the "RestrictRemoteClients" registry setting, in addition to "EnableAuthEpResolution". Again, I still think the article is misleading, as the rest of the text still targets "Enable RPC Endpoint Mapper Client Authentication" (i.e. EnableAuthEpResolution", which as I understand it is NOT the source of the problem.

    If you agree that the only real problem (*at all*) is "Restrictions for unauthenticated RPC clients" (i.e. "RestrictRemoteClients"), can you please speak again with the KB author to reflect this?

    Enabling *client-side* support for this feature should not be unnecessarily demonized if it is 100% safe to do. By enabling it, it helps to reduce the impact should the restrictions be put in place anywhere else (since it allows the machine to support the feature).

  • I should add - Method 1 still doesn't even mention the Restrictions setting. It still misleadingly targets the client-side setting (which it shouldn't do, IMO). I believe the entire article should also add the word "restrictions" to better reflect the issue:

    "RPC Endpoint Mapper client authentication restrictions prevent users and groups from being added to trusting forest"

    "When RPC Endpoint Mapper client authentication restrictions are enabled, unauthenticated RPC traffic from the trusted Active Directory forest is not accepted."

  • Ned... I retract some of my former statements above. Yesterday I set up a test lab with two independent 2012 R2 Update 2 DCs (and new forests) and a *1-way* forest trust to check out KB3073942 (adding users from the trusted domain to a Domain Local group on a trusting domain):

    Control test – default configuration - SUCCESS! (naturally)
    Scenario 1 – “Enable RPC Endpoint Mapper Client Authentication” on trusted DC only - SUCCESS
    Scenario 2 – “Enable RPC Endpoint Mapper Client Authentication” on trusting DC only - FAILURE
    Scenario 3 – “Enable RPC Endpoint Mapper Client Authentication” on both DCs - FAILURE
    Scenario 4 – “Enable RPC Endpoint Mapper Client Authentication” on both DCs, but set up a 2-way trust instead of 1-way trust - SUCCESS

    Conclusion: I was wrong. If the "client side” RPC Endpoint Mapper Authentication setting is enabled on the trusting DC in a one-way forest trust scenario, it prevents adding users from the trusted domain to the trusting domain, even though their names can still be resolved. The problem does not occur if the setting is only enabled on the trusted DC, nor does it occur at all if there is a 2-way forest trust in place (instead of a 1-way forest trust).

    Even though the results were very specific, this still was very surprising to me, and very odd behavior based upon my understanding of how the settings are supposed to work. It almost feels like a bug in the product, especially since it goes away with a 2-way trust. My apologies for adding mud to the water! Hopefully the testing I did above filters some of it out again. :)

  • We are equally puzzled and are talking about it. Will follow up with you offline. Thanks for the excellent write up.