This is the first in hopefully what will become a series of blog posts that less focus on monitoring explicitly with ConnectWise Automate, but more on security monitoring that all MSPs can use in conjunction with their own RMM. I’ve been writing Powershell for monitoring for many years now, but the inspiration to present it like this came from the excellent posts that Kelvin Tegelaar puts out on https://www.cyberdrain.com/. If you haven’t seen his site it is well worth having a look at.

Remote Desktop Users – the most unfortunately named group in Windows?

Do you have any clients with Remote Desktop Servers?  Most MSPs do. Put yourself in the position of one of your engineers. You’ve been asked to create a new user for one of your supported clients, and they need to use the Remote Desktop. You create the user, then you need to add them to the group that controls Remote Desktop. What was their group called again? Hell if I remember… You go to the Member Of tab in Active Directory, click Add and search for Remote Desktop. You find a group called Remote Desktop Users. That sounds right! You add the user to it.

Congratulations! You may have just granted that user RDP rights to all Domain Controllers

Remote Desktop Users is a local group that is present on all Windows machines by default (as far as I am aware). Unless you are on a Domain Controller. A Domain Controller doesn’t have local groups. Its groups belong to the Domain. That user is now a member of that group. I’m sure you can see why this is bad. Unfortunately, it’s a pretty easy mistake to make.

Monitoring the membership of groups with Powershell

The above is one example, but this script can be used to monitor the membership of a number of key groups like Domain Admin, Enterprise Admin etc. This script has been purposely written to work in Powershell 2, so you can even audit as far back as those pesky 2008 servers your client refuses to budget for until January 13th 2020 when it will suddenly become a “Priority”. I digress 😀

$IgnoreTheseGroups = @("Administrator", "SBS Remote Operators", "Domain Admins")
$GroupName = "Remote Desktop Users"
$Result = @(); $Group = [ADSI]"WinNT://$env:COMPUTERNAME/$GroupName,group"; $Members = @($group.psbase.Invoke("Members"))
$Members | foreach-object { $Result += $_.GetType().InvokeMember("Name", 'GetProperty', $null, $_, $null)}
$FinalResult = $Result | Where-Object {$IgnoreTheseGroups -notcontains $_}
If ($FinalResult)
{Write-Output (($FinalResult) -join ",")}
else
{Write-Output "No Accounts Found"}

Input this in to your RMM, and check for the good condition of “No Accounts Found”. Pay attention to the $IgnoreTheseGroups variable on line one; this defines entries that can be present when checking the group. If you are lucky enough to have sent all of your Small Business Servers to a permanent slumber, you can remove SBS Remote Operators. Guess where else this can be used? Administrators group. Use the script to ensure only approved accounts are in the Administrators group in all machines.

You don’t need to limit this to just servers. It’s a good way of highlighting machines where users or admins have inadvertently given remote access to people.

Other security lessons

The scenario I highlighted above shows how important it is to have defined standards in your MSP. If you have one clients RDS users controlled by a group called TerminalServerUsers and another with RemoteDesktopUsersLogon then this will end up being confusing for your staff and they will likely just guess at the correct group. Stick to one standard naming convention and your risk is reduced. Your process to generate new users should also be controlled. Engineers should not just be allowed to “wing” the creation of a user. It also shows why periodically auditing a users group memberships are also important.

I hope you find this helpful. If you do run this and find people in groups they shouldn’t be, let me know!

ConnectWise Automate users – until ConnectWise drag themselves in to the 21st century, you will find a version ready for import at https://www.gavsto.com/remote-monitor-series-security-finding-members-of-local-groups-that-shouldnt-be-there-like-remote-desktop-users/