Three Reasons Why You Need to Monitor CAP and RAP Failures On Your Remote Desktop Gateways

The latest version of our Remote Desktop Commander Suite (Version 6) now offers reporting that tracks CAP (Connection Authorization Policies) and RAP (Resource Authorization Policies) failures on your Remote Desktop Gateway servers. Why is it important to track these failures? Here are three very important reasons . . .

CAP and RAP Failures on Your Remote Desktop Gateways May Be Indicative of Hack Attempts

Put simply, Remote Desktop Gateway CAPs control WHO (which users and groups) can access your Remote Desktop Services deployments, and Remote Desktop Gateway RAPs control WHAT (e.g. which computers) they can access in the deployment. If you are seeing either CAP or RAP failures in your event logs, it could be an intruder trying to gain access to your internal network’s systems. This is especially true if you are *not using* a MFA solution on your network to better validate RDS users authenticating through a Terminal Services Gateway.

For instance, if you see a CAP failure (Event ID 201 in the Microsoft-Windows-TerminalServices-Gateway/Operational event log), it could indicate that an attacker has managed to successfully authenticate with one of your Remote Desktop Gateway servers, but the compromised user was not a user approved to access your RDS deployment. Or in other words, a hacker has obtained the correct username/pw combo for a user in your Active Directory, but that user is NOT authorized to use your RDS collections.

In contrast, if you see a RAP failure (Event ID 301 in the Microsoft-Windows-TerminalServices-Gateway/Operational event log), an attacker may be trying to connect to a system BEYOND your RDS deployment and has been blocked from doing so. That is more likely if you’ve already done what I’ve recommended in my book on securing RDS deployments and tightened down your RAPs. A normal user typically uses the default RDP file they obtain from your RDWeb feed. An attacker, on the other hand, could have altered an RDP file to keep your gateway server information, but instead target a non-RDS server by it’s name or IP address.

You Could Have a Configuration Issue On Your Gateways

It’s easy to screw up CAP and RAP policies on a Gateway. For instance, let’s say you’ve setup an RDS deployment with a single connection broker. Then, you decide to add a second connection broker and put the deployment into High Availability mode. Did you remember to visit both of your Remote Desktop Gateway servers and add the new broker to each of their RAPs? If not, users who get load balanced to the new, second broker will have problems connecting via the gateway because they’re not yet authorized to connect via the RAP.

In another scenario I’ve seen in my consulting work, a client migrated their RDS deployment from one datacenter to another, and then had an issue with name resolution because of legacy RDP files still in use. The gateways had RAP entries for the fully qualified domain names of the session hosts, but not for their equivalent NetBIOS short names and IP addresses. As a result, some connections were working and others were not.

Your End Users Could Be Using Misconfigured RDP Files

Your end users will continually cause you pain by doing things like caching copies of the RDP files they’ve downloaded to their desktop. Then, when you push changes and reconfigurations out to RDWeb via the Connection Broker, they’ll bypass RDWeb or RADC in favor of their out of date RDP file already stashed on their desktop. That, in turn, can generate RAP failures and/or connection broker connection request failures. If you’re monitoring CAP/RAP failures and connection broker failures, you can make a list of the “wayward children” who need to get a tap on the shoulder!

The Takeaway – You Need Automated Collection and Reporting of Remote Desktop Gateway CAP and RAP Failures

In busy deployments, the Microsoft-Windows-TerminalServices-Gateway/Operational event log wraps VERY quickly. I’ve seen these logs wrap within an hour, because no one remembers to boost their retention settings via Group Policy. And even if you fix the retention, consolidating things by username or by gateway server to make sense of it all will take some doing, even if you do have a SIEM or other log aggregation solution in place.

Our Remote Desktop Commander Suite solution automates all of this for you.

First, it continually collects CAP, RAP and other informational events from your Remote Desktop Gateways and stores them in its SQL database. Doing so allows you to produce reports like these on demand or on a scheduled basis with powerful filtering capabilities around usernames and server names.

Secondly, it has a Top Level Deployment Status Dashboard where you can continually keep your eye on Remote Desktop Gateway health, current connection count, recent connection failures, plus summon reports like those above with just two mouse clicks. To give you an idea of that dashboard’s power, please watch this video below (remember to expand it to full screen!)

The Remote Desktop Commander Suite can monitor and report on your gateways for only $11.49 per server per month, with volume discounts available. Contact our sales team for more information or to set up a demo.