Though later versions of our Remote Desktop Commander Suite build on these key features, it’s worth drilling into these specific capabilities in RDS logins and logon failure tracking (plus some extra stuff we’re sure will interest you) that were introduced starting with v4.5:
Consolidate All RDS Logins and Logon Failures, Regardless Whether Or Not They Occurred On Session Hosts Or Remote Desktop Gateway Servers
Our CEO, Andy Milford, has written at length about the challenges faced when attempting to correlate RDP logon failure data from session hosts at his PureRDS.org blog. Attempting to track successful RDP logins is no picnic either, as multiple log files from multiple different systems – the session host servers and remote desktop gateway servers – must be consulted and the information correlated.
In version 4.5 of the Remote Desktop Commander Suite, the Remote Desktop Reporter Service automatically collects and correlates key events from event log files on Session Host servers and Remote Desktop Gateway servers. The result is a treasure trove of valuable login and logon failure data that it retains in its SQL database, allowing us to deliver the incredible new features described below.
Geolocate RDS Logins and Logon Failures In the User IP Geolocation Dashboard – Find Out Where Your Users Are Working From, and Locate the Source Of Brute Force RDP Hack Attempts
Remote Desktop Services login and logon failure data correlation from session hosts and gateways is a valuable feature in its own right, but the rich visualizations of this data is what sets Remote Desktop Commander Version 4.5+ apart from the competition. The User IP Geolocation Dashboard combines IP geolocation data with interactive worldwide maps and tabular, filterable tables so administrators can zero in on both legitimate RDS users and hackers.
Our dashboard is completely extensible via PowerShell scripts, which are designed to receive selected server names, usernames, and IP addresses as input parameters. This is especially useful for the remediation of inbound hack attempts.
Instantly build reports from the filtered RDP login and logon failure data in the dashboard, or simply export the data to comma-delimited text.
Schedule Daily User Login and Logon Failure Reports
Scheduled reports make it easy to keep track of both where your users are routinely connecting from, as well as the sources of hacking and penetration attempts. Group login and logon failure data by country or by user. With routine review of these reports, you can quickly spot geographic RDP login anomalies that could be suggestive of a compromised user account.
See The Actual IP Address and Geolocation Information for User Sessions In Existing Time Tracking Reports.
By default, the Microsoft Terminal Services client (MSTSC) does not report its actual global IP address when connecting to a terminal server. When connecting through a Remote Desktop Gateway system, no IP address information is transmitted at all. Many admins have requested that we transform the incorrect or missing IP address information with the actual global IP address of the user, whether or not they are connecting through a RD Gateway.
Based on this feedback, we have retrofitted several existing reports, such as the User Sessions – Session Details By User report family, to include the correct global IP of the user based on the correlated log data now collected by our central polling service. Also, when possible, the global IP address is accompanied with the geographic region of the user’s ISP
Massively Reduce Database Storage Requirements With Performance Threshold Database Pruning
As you can see, we’ve mainly talked about logins and logon failures so far, and we’re talking about lots of data that we work with. So, we have to be ready to handle it all. Which brings us to a related feature.
Collecting in-depth performance data on a per-user and per-program basis with our agent service is great, but it’s easy to generate a lot of data in SQL by doing so. Version 4.5+ has a nifty new feature that we call “Performance Threshold Database Pruning.”
Now, in addition to purging out agent-based performance data based on date, you can elect to keep only the agent data associated with times of high load on session host servers. You can define what you consider to be high load both in terms of CPU usage or memory utilization, or a combination of both. Using this new feature can drastically reduce the amount of data stored in SQL over time, in many cases by over 80%.
. . . And What’s The Latest?
Of course, features change and mature, so be sure to find out the latest developments with our Remote Desktop Commander Suite by requesting a web demo with an RDPSoft solutions expert.
Updated: November 2020.
Leave a Reply