Forum Discussion

justdoit1530's avatar
justdoit1530
Copper Contributor
Oct 23, 2023

RPC Endpoint Mapper Client Authentication uses NTLM

Introduction

The main goal is to secure existent windows 10 clients. As there a few hardening recommendations from for example CIS and Microsoft concerning secure OS configuration i discovered a potential misleading dependency regarding NTLM and RPC.

 

How it happened

On windows 10 clients in the computermanagement (local admin group) the therein contained domain-members were only shown with their SID. Long story short, the actual name of the ADuser was not displayed anymore.

 

Solution

In the end it turned out that the following configuration based on a hardening configuration of CIS was the root cause:

 

"18.8.37.1 Ensure 'Enable RPC Endpoint Mapper Client Authentication' is set to 'Enabled' (MS only)"

More information here

 

Basically there should not be a problem when enabling the RPC Endpoint Mapper Client Authentication.

 

But if you configured 

"Restrict NTLM: Outgoing NTLM traffic to remote servers" to "Deny all"

More information here

 

then the enabled RPC Endpoint Mapper Client Authentication will not work anymore because it does rely on NTLM.

 

Conclusion

A risk assessment must now be carried out here. 

 

Even Microsoft says that "It's encouraged to move away from NTLM to better secure your environment. If faced with a choice between restricting NTLM and using EnableAuthEpResolution, the recommended approach is that you restrict NTLM in your environment."

More information here

 

--> To sum up, even CIS recommends to enable the RPC Endpoint Mapper Client Authentication, but they do not make any statement in their benchmarks with regard to the denying of outgoing NTLM traffic to remote servers.

 

Question

  • Which configuration will have a more severe risk and what should be the recommendation here regarding to achieve an overall secure configuration?

 

  • Chris-W360's avatar
    Chris-W360
    Copper Contributor

    justdoit1530 

    I just ran into your thread here today trying to do an overview of the RPC Endpoint Mapper (again).  
    A few years back, I had this issue with a case with MS PG. I also found the same as you did and I was able to get them to update their documentation to show this info. 

    RPC Interface Restriction for Windows Server | Microsoft Learn

    if you look at the Blue Important section, it will list what we both are seeing. 

    I'm just happy that I was able to get MS to document it and not make it some mystery. 

     

    We are about 99% complete in eradicating NTLM from our environments. Some apps still struggle to either use kerberos or move to something else like SAML/Oath. 

  • thesquirrel1130's avatar
    thesquirrel1130
    Copper Contributor
    We are finally killing NTLM! Our issue was "Enable RPC endpoint mapper client authentication" (Enabled) and "Restrict unauthenticated RPC clients" (Enabled - Authenticated). To protect the RPC ports we have implemented, for several years, IPSEC in the windows firewall to require it on TCP 135 incoming. We will soon be requiring it on the dynamic ports which will also be limited to a known range of 150 ports. This protects those ports from Nessus scans (if you don't put the Nessus scanner's IP in a full allow rule). This way we can still protect RPC by having IPSEC authentication and blocking all outbound NTLM. NTLM is still allowed inbound for our RDP gateway until we get our remote clients to use the built-in KDC proxy on the gateway.

Resources