r/sysadmin 10h ago

Enabling "Restrict Unauthenticated RPC clients" (Authenticated) on Exchange Server — any real-world breakage?

We're working through a CIS Benchmark remediation and one of the findings is:

>

We're planning to set this to **"Authenticated"** (not "Authenticated without exceptions" — we're aware that level is much riskier and more likely to break things) on our **Exchange Server SE** environment.

Before we push this via GPO, I'd like to hear from anyone who has actually applied this in a production Exchange SE (or 2019) environment:

* Did it break **Outlook Anywhere / RPC over HTTP** for any legacy clients?
* Any issues with **MAPI/RPC** connections from older Outlook versions?
* Any impact on **DAG replication** or **Active Manager**?
* Did it cause problems with **Exchange Management Shell / EAC** functionality?
* Any unexpected issues with **AD communication** (since Exchange talks to DCs heavily over RPC)?
* Did you apply it to Domain Controllers as well, or keep DCs and Exchange servers on separate rollout schedules?
* Since Exchange SE is fairly new, has anyone tested this specifically against SE's RPC dependencies, or is it safe to assume behavior is the same as 2019?

Our environment: Exchange Server SE, mostly modern Outlook clients on MAPI/HTTP, not fully certain if any legacy RPC/TCP clients remain in the environment.

Any war stories, gotchas, or "wish I'd known this before enabling it" experiences would be really helpful before we roll this out.

Thanks in advance.

2 Upvotes

3 comments sorted by

u/accumentum 10h ago

The practical distinction here is level 1 (“Authenticated”) versus level 2 (“Authenticated without exceptions”); I would stage level 1 first rather than jump to the latter. Modern MAPI/HTTP and authenticated RPC/HTTP clients should generally be fine, but old line-of-business agents, monitoring, or backup integrations are where anonymous RPC dependencies tend to surface. Roll it to one non-DC Exchange server, test Outlook, EMS/EAC, DAG failover, and backup jobs, and watch the RPC and Exchange event logs before expanding. I’d keep domain controllers on a separate rollout and export the existing GPO so rollback is a one-step change.

u/blud_13 9h ago

Do NOT put it on the DCs. Microsoft says it flat out, this policy should never be applied to a domain controller, which answers your second to last bullet before you get to the Exchange part. Its at https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-remoteprocedurecall

For Exchange SE, Authenticated is the level people survive. Value is RestrictRemoteClients under HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Rpc, and note that key is Rpc not RPC, which has burned people hand-writing reg drops instead of using the ADMX.

What bites is whatever is still doing anonymous RPC that nobody wrote down. Old backup agents, monitoring, print, the copier that scans to a share, an LOB app somebody installed in 2016. Outlook Anywhere and MAPI/HTTP both authenticate so current clients are fine.

Roll it to one boring member server, sit on it a week, then ONE Exchange node and watch DAG replication before the rest. Reverting can mean touching each box by hand, so don't push it wide on a Friday.

Can go deeper on the rollout order if it helps.

u/Kuipyr Jack of All Trades 5h ago

I'll add that the next on the list is probably "Enable RPC Endpoint Mapper Client Authentication" which requires NTLM. Don't enable that one.