Forum Discussion
justdoit1530
Oct 23, 2023Copper Contributor
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-W360Copper Contributor
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.
- thesquirrel1130Copper ContributorWe 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.