RDP secure RPC verification: confirm the policy source

What Is RDP Secure RPC Verification?

RDP secure RPC verification starts with a distinction: a policy protecting the Remote Desktop Services administration interface answers a different question from the encryption used by a remote desktop connection. An audit finding can identify collected policy values worth investigating. Closing it requires evidence for the same server, with the source and applicability of each setting recorded.

The practical deliverable is a host review: which computer receives the RPC policy, where its native RDP encryption level comes from, and what remains unknown about an actual connection. Keep those conclusions separate. A domain-wide collection can contain two reassuring values without showing that either protects the server under review.

For the broader authentication and credential-delegation decisions, see our guide separating NLA, the RDP security layer, and Restricted Admin mode. This procedure focuses on the administrative RPC policy and the provenance of the encryption setting.

How It Works: Administration, Policy and Connection Evidence

Microsoft's RemoteDesktopServices Policy CSP reference describes RequireSecureRPCCommunication as protecting the RPC interface used to administer and configure RDS. Enabled requires authenticated, encrypted requests; Disabled permits unsecured clients that do not respond to the security request; Not Configured permits unsecured communication. Its ADMX mapping names fEncryptRPCTraffic under SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services.

The same reference states that ClientConnectionEncryptionLevel applies to native RDP encryption, not SSL encryption. Its friendly name is Set client connection encryption level. Both policies are under Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security.

Use three evidence categories in the review. This is a proposed review method, not a Microsoft compliance framework:

Detection: Verify the Same RDS Host

Choose an identified Windows target and record its hostname, OS, intended policy scope, reviewer and collection time. Repeat the review for other scopes rather than treating one server as representative of every RDS deployment. The commands below are documentation-based examples; no Windows endpoint or real domain was tested for this article.

Run each command separately on the target with an account permitted to read the relevant configuration. Preserve errors and missing output. A failed read is an evidence gap, not an unsafe value or a successful check.

Step 1: Establish Computer Policy Applicability

Microsoft's gpresult reference documents computer-scope RSoP and summary, verbose and HTML output. Start with:

gpresult /scope computer /r

Expect computer policy information and applied GPOs. A summary supplies context; it does not resolve the provenance of every individual setting. Collect detailed information when comparing candidate policies:

gpresult /scope computer /z

Attach the relevant setting detail to the review. Identify which GPO supplies the RPC policy and which supplies the encryption-level policy. The two settings may legitimately come from different GPOs, provided both are demonstrably applicable to this same host. If the report cannot settle the winning source, leave that part of the review unresolved.

Our four-check GPO guide on policy values, recipient computers and actual protection uses the same target-side distinction for LLMNR, WSUS, LSA protection and policy-share access. Those controls remain separate from this RPC review.

Step 2: Read the Administrative RPC Policy Value

This command instantiates Microsoft's documented reg query syntax with the CSP's registry mapping:

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v fEncryptRPCTraffic

Keep the key, value type, data and error text exactly as returned. For a review targeting an enabled policy, reconcile the target value with the policy report and the collected GPO declaration. The etc-collector predicate accepts a collected value of at least 1; a surprising value above 1 should remain visible for review rather than being normalized to an assumed Boolean.

An absent value is not the same observation as an explicit disabled policy. Determine whether the policy was configured and applicable before deciding what to change. Do not substitute a desktop connection's encryption evidence for the administrative policy evidence.

Step 3: Read Encryption Configuration and Its Source

Read the policy value separately:

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v MinEncryptionLevel

Then query the target's terminal settings. The following example combines the documented Get-CimInstance syntax with the namespace and class in Microsoft's Win32_TSGeneralSetting reference:

Get-CimInstance -Namespace root/CIMV2/TerminalServices -ClassName Win32_TSGeneralSetting

Without a remote computer or CIM session parameter, the cmdlet reads local WMI. Retain the returned objects and identify the relevant TerminalName; do not silently use the first instance. Inspect MinEncryptionLevel, PolicySourceMinEncryptionLevel, SecurityLayer and PolicySourceSecurityLayer.

The class documents encryption levels 1 Low, 2 Client Compatible, 3 High and 4 FIPS Compliant. Its policy-source fields use 0 for server configuration, 1 for Group Policy and 2 for default. These fields describe provenance, not a specific winning GPO. Its SecurityLayer property uses 1 for native RDP, 2 for Negotiate and 3 for SSL; do not confuse that property scale with a registry or setter scale. The class also documents packet privacy for connections to its namespace. Preserve a provider or access error without weakening security to obtain output.

Expected output here means named configuration properties to inspect, not a fabricated passing transcript. Compare the returned level and source with the policy report, retaining disagreements for investigation.

Step 4: State What Is Known About the Connection

The reviewed class describes terminal configuration and policy sources. It is not a transcript of a particular TLS handshake. Record the mechanism indicated by configuration separately from any evidence about a real connection.

Before collecting additional evidence, decide what can be observed without changing the service. Use existing, authorized connection evidence where available; associate it with the intended server, client and time. State whether it actually establishes native RDP or TLS for that exchange. This article does not prescribe an undocumented event ID, cipher assertion or universal capture recipe.

If session-specific evidence is unavailable, record connection negotiation not demonstrated. Do not restart RDS, change its security layer or create an experimental connection merely to make an incomplete read look conclusive. Plan additional validation as a separate approved operational task.

Remediation: Decide, Apply and Recheck by Host

Resolve the Evidence Before Changing Policy

Use the following questions as explicit decision points:

1. Do both values come from GPOs effectively applicable to this same RDS server? Attach the source evidence for each, even if the GPOs differ.
2. Which mechanism protects the connection, native RDP or TLS, and which evidence can be collected without modifying the service? Mark any unobserved negotiation as unknown.
3. What conclusion should be retained if the historical identifier or catalogue label differs from the current code? Preserve the identifier for traceability and describe the implemented check separately.

A useful review can finish with an unresolved evidence task. Avoid closing it as protected merely because the collector stops reporting a finding. Conversely, a policy collection gap alone does not establish that the server is exposed.

Apply the Administrative RPC Setting to the Intended Scope

Where the review establishes that secure administrative RPC is required and not configured as intended, use Require secure RPC communication = Enabled in the policy path documented above. Identify the GPO owner, affected computers and management clients before rollout. Plan compatibility validation and recovery access for the pilot scope.

After the change has reached the target, repeat the gpresult and fEncryptRPCTraffic reads shown in Detection. Attach before/after evidence and record any administrative-client failure. A changed policy declaration without target evidence leaves the applicability question open.

Handle the Native Encryption Setting According to Applicability

Where native RDP remains relevant, select the intended level through Set client connection encryption level, documenting the client compatibility decision. Treat the collector's >=3 test as its implementation threshold, not a universal compliance requirement. Where SSL/TLS protects the connection, keep native-policy applicability and connection protection as separate decisions.

Repeat the MinEncryptionLevel and CIM reads after a policy change. Record whether configuration or provenance changed, whether the source matches the intended management channel, and which connection question still needs evidence. Do not change the encryption level solely to suppress the finding without understanding its applicability.

Retain a Reviewable Decision Record

For each host, preserve the original finding and collection time; applicable GPO names and identifiers; raw registry output; terminal instance and policy-source fields; connection evidence or its absence; and the owner, rationale and follow-up for the decision. Keep exceptions tied to an identified scope and review date. Distinguish configuration remediation from completion of connection validation.

How EtcSec Detects This

The only catalogue check attached here is ANSSI_R79_RDP_NOT_HARDENED. In the etc-collector implementation reviewed at commit bcd03c540bfccdeecf70f36bb80fd58bbe0bef1d, Detect() evaluates collected GPO RegistrySettings:

The provider reads machine GPO files from SYSVOL; the Registry.pol parser maps the two Terminal Services DWORD values to the fields used by this check. The detector aggregates them across collected GPOs. It does not establish the effective policy for an individual RDS host, require both values in the same applicable scope, or inspect negotiated sessions. Count 1 describes the finding, not a measured number of exposed servers.

ANSSI_R79 is a historical identifier. The code explicitly disclaims measuring R79 while leaving the identifier unchanged; the reviewed blog catalogue still displays an older client-oriented label. Keep that discrepancy in the review record. Do not turn the tag into an ANSSI compliance verdict.

The finding's explanatory text mentions downgrade and MITM scenarios, but its predicate observes neither a network attack nor session negotiation. This finding does not confirm MITM, compromise or an unencrypted desktop session. Use it to open the host verification task, then retain the evidence and decision for each distinct protection question.