Quantcast
Channel: Andy Milford, Author at PureRDS
Viewing all 49 articles
Browse latest View live

Remote Desktop Protocol v8 (RDP 8) – Why You Need It!

$
0
0

Three Letters: UDP, UDP, UDP

I have spoken at multiple conferences (most recently BriForum Denver 2015 and Techmentor Las Vegas 2016) on the subject of RDP 8 and the numerous ways it improves the Remote Desktop user experience, even over less than reliable networks. Amazingly, I have discovered that very few server administrators who have a RDS farm know about these improvements, as they still run RDS on Windows Server 2008 (which only supports up to Version 7 of the Remote Desktop Protocol).

The lynchpin of the RDP 8 improvements involve the dual use of UDP as a transport protocol alongside TCP. Prior to RDP 8, all client/server Remote Desktop Services connection data was transported over TCP only. While TCP guarantees delivery, it suffers hugely in the face of less-reliable networks with high latency and/or higher packet loss rates (e.g. greater than 1% loss on average). I could go deep in the technical weeds on this subject, but I am not going to – if you’d like to learn more about the inherent problems with rapid delivery of data via TCP over less-reliable networks, search on terms like “queueing delay” and “TCP congestion avoidance algorithms – e.g. Reno, Vegas, New Reno, etc.”

UDP overcomes virtually all of those issues, as reliable delivery of UDP packets are not guaranteed – it is up to the application to handle missing packets via re-transmission and on the fly error correction (specifically, Forward Error Correction techniques).

RDP 8 Vastly Improves Data Throughput, Even Over Less Reliable Networks, Greatly Enhancing User Experience

If you’d like to read more from Microsoft’s own RDS engineering team on the specific improvements in data throughput over different types of networks, please review their blog article here.

From a practical standpoint, here’s what you as a RDS admin need to do to take advantage of RDP 8 and later versions to boost Remote Desktop Connection user experience:

  • Upgrade your RDS servers to Windows Server 2012 or Windows Server 2016. RDP 8 and later versions are only supported on Server 2012 or greater operating systems.
  • Verify that your RD clients support RDP 8 or later. For the Windows Remote Desktop Connection Client, this means that the client operating system should be Windows 8 or Windows 10. Windows 7 SP 1 WILL support RDP 8, but only if you apply the RDP 8 update accordingly. If you use thin clients, you will need to contact the vendor to verify that RDP 8 is supported natively, or can be supported with a firmware update. The latest Microsoft Remote Desktop clients for Android and iOS also support RDP 8+
  • If you use the Microsoft Remote Desktop Gateway to allow access to/from Remote Desktop Session Hosts in your RDS farm, you will need to make sure that role is installed on a Windows 2012 or Windows 2016 server. The RD Gateway role that ships with Windows Server 2008 will not forward UDP traffic. Conversely, if you DO NOT use the RD Gateway, you will need to configure the corporate firewall so it will pass UDP traffic alongside TCP traffic over port 3389.

 

Note – There is a Price Associated With Better Data Throughput Using UDP Transport With RDP 8

As us computer science and engineering types know implicitly – there is seldom such as thing as a free lunch. Because UDP boosts effective throughput, it will also increase the amount of bandwidth RDP traffic consumes over time. It’s definitely something to keep an eye on over low-bandwidth or saturated network links.

Andy Milford is the CEO and Founder of RDPSoft, and is a Microsoft MVP in the Enterprise Mobility / Remote Desktop Services area. Prior to starting RDPSoft, Andy was the CEO and Founder of Dorian Software, a log management company acquired by Ipswitch in late 2009. He loves creating easy-to-use yet powerful software solutions for SMBs and emerging enterprise companies.

The post Remote Desktop Protocol v8 (RDP 8) – Why You Need It! appeared first on PureRDS.


RDP 8 and Challenging Networks – Limitations

$
0
0

I’ve written a lot on the performance improvements gained by implementing RDP 8 on my RDPSoft corporate blog over the past 2 years. If you migrate to Windows Server 2012, or soon, Windows Server 2016, and set up RDP to use TCP and UDP as its transport protocols, you will solve a significant number of connection issues you had to contend while running RDP 7 on Windows Server 2008.

RDP 8 and Later – Network Quality Thresholds and Limitations

However, it should be noted that RDP 8 is NOT a panacea for ALL types of networks. Here are my general rules of thumb when it comes to the question of “is RDP good enough?”

1.) If the upper limit of latency between your remote desktop clients and servers is typically less than 300ms
AND
2.) If the average packet loss rate between your remote desktop client and servers is at or less than 2%

then RDP 8 on a pure Remote Desktop Services implementation will probably work just fine. And yes, if there’s less latency but slightly more packet loss, RDP 8 may still be able to adapt decently. However, if your remote desktop connections are consistently outside the above thresholds based on your remote worker environments, you will need to consider other protocol technologies leveraged by Citrix. For more on those technologies (e.g Framehawk and ThinWire), please read this wonderful performance “bake off” test conducted by my fellow Microsoft MVP Marius Sandbu that he published on his blog.

Given the near ubiquity of decent quality broadband Internet connections in most major metropolitan areas, you can see why RDP 8 will work just fine for the majority of use cases. And this is why I maintain that for an increasing number of businesses, switching to “Pure RDS” over Citrix can save considerable sums of money in licensing, while not significantly impacting user experience (if implemented correctly). So if you are judging Remote Desktop Services by the connection quality you saw when running session hosts on Windows Server 2008, you need to quickly stand up a copy of Windows Server 2012 or Windows Server 2016 (Technical Preview) and fully test RDP 8. You will be amazed at the difference.

And even if you still have some “edge case problem child clients” – the smart CIOs and CTOs out there can save money by shrinking the size of their Citrix farm to only maintain licensing for the 5% or 10% of the workforce that has poor network connectivity, and deploying Citrix clients selectively to only the worker devices that truly need them.

Andy Milford is the CEO and Founder of RDPSoft, and is a Microsoft MVP in the Enterprise Mobility / Remote Desktop Services area. Prior to starting RDPSoft, Andy was the CEO and Founder of Dorian Software, a log management company acquired by Ipswitch in late 2009. He loves creating easy-to-use yet powerful software solutions for SMBs and emerging enterprise companies.

The post RDP 8 and Challenging Networks – Limitations appeared first on PureRDS.

Single Server RDS Deployment With Licensing (Workgroup Friendly)

$
0
0

One major complaint I hear frequently around standing up a Windows Server 2012 Remote Desktop Services solution is the fact that all of the guides and documentation are centered around a full RDS deployment. E.g. Deploying the Session Hosts, plus Licensing, plus the Connection Broker, plus Web Access, plus the Gateway, and making sure you do this all from within a full Windows domain environment.

Here’s an alternative, single server way to deploy Remote Desktop Services on Server 2012, even in a workgroup. I call it “Micro RDS.”

For instance, let’s say you just want to install a multi-user capable Remote Desktop Services Session Host in Windows Azure. Moreover, let’s say you don’t want to join the session host to a domain with all the additional costs and complexities that adds. You don’t have to. Fundamentally, all you need to do is add 4 Windows features, and then do some very minor configuration of RDS licensing. That’s it.

We’ve built all of these steps into two separate streamlined PowerShell scripts which you can download below. The first script will install all necessary roles and features, after which you will need to reboot your Windows Server 2012 virtual machine. The second script will run behind, do some licensing configuration, and then auto-launch the licensing manager tool so you can enter in your licensing CALs or SALs supplied by the Microsoft licensing clearinghouse.

Base level RDS roles and features required for a single server RDS deployment

To have this deployment work properly, you need to add the following roles:

  1. The Remote Desktop Session Host Role
  2. The Remote Desktop Licensing Role

Also, you should add the following features so you can do some licensing configuration after you’ve installed the above roles:

  1. The Remote Desktop Licensing Tools
  2. The Remote Desktop Licensing Diagnoser Tools

 

Necessary configuration of the licensing mode and licensing server

In our single server RDS deployment, you must tell the Remote Desktop Session Host server where to look for its licensing. In this case, it will query itself, because the Licensing Role will also be running on this system. What you as an administrator must do is:

  1. Set the licensing mode (e.g. per-user or per-device)
  2. Tell the session host server to query itself for licensing
  3. Install the CALs/SALs from the clearinghouse

Once the above is done, you will have a functioning single-server RDS deployment you can use on-premise or via Azure or Amazon for your remote computing needs. NOTE: If this single session host will be running in a workgroup, you MUST use per device licensing!

Scripts needed to deploy this RDS single server configuration

In both cases, before running the scripts in PowerShell, you will need to set the Execution Policy appropriately, and then navigate to the directory where your downloaded scripts have been stored. For instance, from a PowerShell prompt, type:

Set-ExecutionPolicy Bypass

Script 1: MicroRDS-SingleServerDeployment-Step1.ps1 (Click to Download)

Run this script first to add the necessary roles and features to your server. Then reboot.

Script 2: MicroRDS-SingleServerDeployment-Step2.ps2 (Click to Download)

Run this script second to set the licensing mode and inform this session host that it needs to query itself for licensing. The script will prompt you for a number that corresponds with the licensing model you will use. AGAIN: If this single session host will be running in a workgroup, you MUST use per device licensing!

Lastly, when the RDS Licensing Manager starts, activate licensing and then enter in the key corresponding to the per-user or per-device CALs/SALs received from the Microsoft licensing clearinghouse. Since the first PowerShell script installed the RDS Licensing Diagnoser tool in addition to the RDS Licensing Manager, you can use the Diagnoser as a final check to make sure licensing has been configured properly.

NOTE: Without a connection broker in your deployment, you will not be able to use the Remote Desktop Services Manager built into Server Manager in Windows Server 2012. To counteract this problem, download the free Remote Desktop Commander Lite tool produced by RDPSoft.

Andy Milford is the CEO and Founder of RDPSoft, and is a Microsoft MVP in the Enterprise Mobility / Remote Desktop Services area. Prior to starting RDPSoft, Andy was the CEO and Founder of Dorian Software, a log management company acquired by Ipswitch in late 2009. He loves creating easy-to-use yet powerful software solutions for SMBs and emerging enterprise companies.

The post Single Server RDS Deployment With Licensing (Workgroup Friendly) appeared first on PureRDS.

Windows Server 2012 Shadowing – Delegating Rights To Non-Admins

$
0
0

UPDATE: This script is now included in the free Remote Desktop Commander Lite utility. Click here for more details.

Ahh, nothing like the upheaval of how Windows Server 2012 shadowing works to put more grey in every RDS administrator’s hair. Read this article on my corporate blog if you want to know all the sordid details, including how RDS shadowing was completely dropped in Windows Server 2012, only to be added back in Windows Server 2012 R2.

Most medium to larger shops running Microsoft Remote Desktop Services want the ability to delegate shadowing permissions to help desk technicians with out granting those folks full admin rights. There are two ways (I know of, at least) to do this:

  1. You can manipulate a WMI object programmatically on each Remote Desktop Session host with a PowerShell script
  2. For even more granular adjustments, you can load an old copy of the Remote Desktop Session Host Configuration Tool (tsconfig.msc) on a Windows Server 2008 system joined to the same domain, and then connect to a Windows Server 2012 R2 system running the Remote Desktop Services role.

 

Approach 1 – Using PowerShell To Delegate Windows Server 2012 Shadowing Rights To Non-Admins

Here’s the script I’ve written to perform this adjustment on Windows Server 2012 R2 Session Hosts. I’ve seen some examples on other blogs that reference how to do this for a specific domain group on a single session host, but I’ve expanded that concept so you can now pass a comma-delimited list of computer names (each one being a Server 2012 Session Host), and the script will walk the WMI object on each computer name and set the permissions for either a user account or group account that you supply when the script runs.

Server 2012 R2 Shadow Permissions Script Code

AddShadowingPerms.ps1 – Click to Download

param(
[string]$RDServers
)
$RDSArray = $RDServers -split ','
$AccountToAdd = Read-Host("Please enter the user name or group name who needs permission to shadow users" + "`r`n" + "(Format:  DOMAIN\User or DOMAIN\Group)")
foreach ($RDS in $RDSArray)
{
    $TempRDS = $RDS.replace("`"","")
    if($TempRDS)
    {
        
        $WMIHandles = Get-WmiObject -Class "Win32_TSPermissionsSetting" -Namespace "root\CIMV2\terminalservices" -ComputerName $TempRDS -Authentication PacketPrivacy -Impersonation Impersonate
        foreach($WMIHandle in $WMIHandles)
        {
            if($WMIHandle.TerminalName -eq "RDP-Tcp")
            {
                $retVal = $WMIHandle.AddAccount($AccountToAdd, 2)
                $opstatus = "succeeded"
                if($retVal.ReturnValue -eq 0)
                {
                    $opstatus = "succeeded"
                }
                else
                {
                    $opstatus = "failed"
                }
                Write-Host("The operation to grant shadowing permissions to " + $AccountToAdd + " on " + $TempRDS + " " + $opstatus + "`r`n")
            }
        }
        
    }
}

Approach 2 – Using TSConfig.msc To Granularly Delegate Windows Server 2012 Shadowing Rights To Non-Admins

The one downside of using the above script is that it grants the account in question FULL rights across all operations on the Remote Desktop Session Host server. This use (or group) can effectively logon, logoff, connect, disconnect, send messages, shadow users, query session information on the server, and set/configure RDP information on that server.

However, if we load TSConfig.msc on a Windows Server 2008 system, and then connect to a Windows Server 2012 R2 RDSH box, we can use a scalpel instead of a butter knife to delegate shadowing and other rights to help desk users. In fact, we can ONLY give a user or group the right to shadow a session, with no other powers. Here’s a series of screenshots that show how to do this:

1.)  Open up TSConfig.msc on a Windows 2008 server, and connect to your Windows Server 2012 R2 RDSH box.

1.) Open up TSConfig.msc on a Windows 2008 server, and connect to your Windows Server 2012 R2 RDSH box.

2.)  Enter in the name of your Windows Server 2012 R2 box, and click 'OK' to connect to it.

2.) Enter in the name of your Windows Server 2012 R2 box, and click ‘OK’ to connect to it.

3.)  Find the RDP-Tcp entry, right mouse click to show Properties, and then click Properties to bring up all configuration options.

3.) Find the RDP-Tcp entry, right mouse click to show Properties, and then click Properties to bring up all configuration options.

4.)  Click on the Security tab to view the DACL (Discretionary Access Control List) for RDP-Tcp.  Click the Advanced button.

4.) Click on the Security tab to view the DACL (Discretionary Access Control List) for RDP-Tcp. Click the Advanced button.

5.)  Add the user/group you want to add granular permissions for.  Click 'Edit' to view the detailed permissions you can grant in the DACL.  For shadowing, only the 'Remote Control' permission is required.

5.) Add the user/group you want to add granular permissions for. Click ‘Edit’ to change the granular permission set in the DACL. For shadowing, only the ‘Remote Control’ permission is required.

Finally, whether or not you run the PowerShell script or TSConfig.msc to adjust permissions, you may need to restart the Remote Desktop Session Hosts afterwards so that these new permissions will take effect.

Andy Milford is the CEO and Founder of RDPSoft, and is a Microsoft MVP in the Enterprise Mobility / Remote Desktop Services area. Prior to starting RDPSoft, Andy was the CEO and Founder of Dorian Software, a log management company acquired by Ipswitch in late 2009. He loves creating easy-to-use yet powerful software solutions for SMBs and emerging enterprise companies.

The post Windows Server 2012 Shadowing – Delegating Rights To Non-Admins appeared first on PureRDS.

Remote Desktop Session Hosts and Drain Mode Script

$
0
0

UPDATE: This script is now included in the free Remote Desktop Commander Lite utility. Click here for more details.

Remote Desktop Services admins often have a frequent need to take their Remote Desktop Session Host servers in/out of “Drain Mode.” Drain mode, for the uninitiated, places the RDSH server in a state where it will no longer accept new connections, but will allow existing sessions to continue working until they sign off. In a full Windows Server 2012 RDS deployment, Server Manager gives you a menu option that will let you turn drain mode on/off.

Recently, a question was posted on the Remote Desktop Services Technet Forum regarding enabling/disabling drain mode for a Windows Server 2012 session host WITHOUT a full RDS deployment in place. Fortunately, this is possible with a a bit of clever Powershell code.

Placing RDS Servers in Drain Mode – PowerShell Script example

Here’s the script I’ve written that will take Remote Desktop Session Hosts in and out of drain mode. For downloaded scripts that you trust, you may need to invoke Set-ExecutionPolicy Bypass before PowerShell will run them. FYI – We add a digital signature to all our scripts you can inspect first to make sure they’ve not been tampered with.

RDS Drain Mode PowerShell Script Code

DrainMode.ps1 – Click to Download

Parameter list:

RDServers is a comma-delimited list of all Remote Desktop Session Hosts you wish to enable/disable new connections on. E.g. “RDSH01″,”RDSH02” .. To run against a single server, simply omit the commas (e.g. “RDSH01”)

DrainLevel sets the drain mode. Set to 1 to turn it on, Set to 0 to it off.

param(
[string]$RDServers, [int]$DrainLevel
)
$RDSArray = $RDServers -split ','
foreach ($RDS in $RDSArray)
{
    $TempRDS = $RDS.replace("`"","")
    if($TempRDS)
    {
        if($DrainLevel -eq 1)
        {
            Write-Host ("Turning On Drain Mode For System " + $TempRDS)
        }
        else
        {
            Write-Host ("Turning Off Drain Mode For System " + $TempRDS)
        }   
        $WMIHandle = Get-WmiObject -Class "Win32_TerminalServiceSetting" -Namespace "root\CIMV2\terminalservices" -ComputerName $TempRDS -Authentication PacketPrivacy -Impersonation Impersonate
        $WMIHandle.SessionBrokerDrainMode=$DrainLevel
        $WMIHandle.put() > $null
    }
}
Andy Milford is the CEO and Founder of RDPSoft, and is a Microsoft MVP in the Enterprise Mobility / Remote Desktop Services area. Prior to starting RDPSoft, Andy was the CEO and Founder of Dorian Software, a log management company acquired by Ipswitch in late 2009. He loves creating easy-to-use yet powerful software solutions for SMBs and emerging enterprise companies.

The post Remote Desktop Session Hosts and Drain Mode Script appeared first on PureRDS.

Free TSAdmin Replacement Available

$
0
0

One of the biggest criticisms of Remote Desktop Services on Windows Server 2012 has been its general lack of manageability. The first thing RDS admins notice is the disappearance of TSAdmin. Now, in order to manage RDS on Windows Server 2012, you must use the RDSM (Remote Desktop Services Manager) component embedded inside Server Manager. However, the RDSM component will not work in workgroup deployments of RDS, and it also requires specific roles (e.g. the Connection Broker) to be deployed in order to work properly. Even then, the UI can be clunky to work with and in larger collections, does not scale well.

For RDS admins coming from a Windows Server 2008 RDS deployment who used to use TSAdmin and TSConfig, the differences around management techniques could not be any starker, and in general frustrates them to no end. Look no further than the Remote Desktop Services Forums on Microsoft’s TechNet site if you don’t believe me.

Remote Desktop Commander Lite, from RDPSoft, is a free TSAdmin replacement for all RDS deployments

Free TSAdmin Replacement - Remote Desktop Commander Lite

Full disclosure: I am the CEO of RDPSoft.

Given all of the turmoil around RDS management options in Windows Server 2012, I have decided to make Remote Desktop Commander Lite free for all users, whether they use it for commercial, personal, or non-profit use. By doing so, this solves a lot of problems for admins dealing with the limitations inbuilt to RDSM in Server Manager. For instance:

  • You can manage Remote Desktop Session Hosts deployed to workgroups
  • You can manage different OS levels of RDS farms (e.g. Server 2008, Server 2012, and even legacy Server 2003 RDS deployments
  • You can manage Windows 7, Windows 8, and Windows 10 workstations allowing remote connections through RDP
  • Our tool is fully extensible with parameterized PowerShell scripts and cmdlets, meaning, you can pass farm RDSH members, individual computer names, user(s), process names, etc directly to PowerShell for specific management tasks you conduct frequently
  • You can perform intelligent shadowing operations – e.g. our tool will look at the remote OS level of a session host and will automatically use MSTSC or an in-built Terminal Services Client to start the shadowing process.
  • You can do a lot of additional tasks not available in RDSM, such as looking up bandwidth statistics by session, reviewing session latency and error rates on RDP 8 connections, viewing the OS level of the client, etc.

For complete information, including feature lists, screenshots, a demonstration video, and a download link, please visit the Remote Desktop Commander Lite product page at RDPSoft. I sincerely hope it makes your life a lot easier.

Andy Milford is the CEO and Founder of RDPSoft, and is a Microsoft MVP in the Enterprise Mobility / Remote Desktop Services area. Prior to starting RDPSoft, Andy was the CEO and Founder of Dorian Software, a log management company acquired by Ipswitch in late 2009. He loves creating easy-to-use yet powerful software solutions for SMBs and emerging enterprise companies.

The post Free TSAdmin Replacement Available appeared first on PureRDS.

Remote Desktop Manager Free Edition

$
0
0

Being able to quickly connect and manage the machines and devices under his or her responsibility is essential to the duties of any network admin. In more complex networks, there may be multiple domains, tens or hundreds of routers/switches/appliances that are routinely telnet/SSHed into, plus hundreds of Windows and *Nix systems that must be logged into on a regular basis.

Network admins who maintain Citrix XenApp or Microsoft RDS session host servers deal with this scenario daily. Even Windows administrators who do not have full Remote Desktop Services deployments still use Remote Desktop Services for simple administration of their servers – not everyone is a PowerShell wizard. Managing all of these credentials and connection preferences can get very tricky. Yes, some of us still have a folder full of RDP files, but fortunately, there is a much easier way to maintain all of this information.

Solve your RDS/Citrix connection management woes with Remote Desktop Manager Free Edition

Devolution's free tool, Remote Desktop Manager Free Edition, makes managing all of your remote desktop connections and credentials super easy.

Devolution’s free tool, Remote Desktop Manager Free Edition, makes managing all of your remote desktop connections and credentials super easy.

The wonderful folks at Devolutions, whom I’ve had the pleasure of meeting and getting to know at several industry tradeshows like BriForum, offer a free version of their incredible tool, Remote Desktop Manager. For the admin who is struggling to organize, manage, and remember all of the credentials and settings associated with his Windows RDP logins AND the rest of his devices on his network, it is indispensable.

Here are the two features I find most valuable in the Free Edition of Remote Desktop Manager:

  • The ability to save credentials and then connect to more than a dozen types of systems and devices/remotely, beyond regular Microsoft RDP connections. This includes Apple Remote Desktop, Chrome Remote Desktop, Citrix (ICA/HDX), Dameware, FTP/SFTP, LogMeIn, Telnet, SSH, and so much more.
  • The ability to shell out to other management tools like Event Viewer, the Services MMC applet, Computer Management, Ping, Traceroute, and the ability see if a device is online (using both a Ping and a port check).

 

Now you can launch RDPSoft's free Remote Desktop Commander Lite directly from Remote Desktop Manager for advanced management of RDS/Citrix session hosts.

Now you can launch RDPSoft’s free Remote Desktop Commander Lite directly from Remote Desktop Manager for advanced management of RDS/Citrix session hosts.

Over the past few months, Devolutions even added a hook to Remote Desktop Manager so that you can launch RDPSoft’s free Remote Desktop Commander Lite tool to manage all of the sessions, processes, and other items on RDS and Citrix XenApp session host servers. When installed on the same system, these two tools are a great “one two” punch for any network admin, but especially for the Citrix and RDS admins. Grab both of them today, and free up more of your valuable time by leveraging their rich features.

Andy Milford is the CEO and Founder of RDPSoft, and is a Microsoft MVP in the Enterprise Mobility / Remote Desktop Services area. Prior to starting RDPSoft, Andy was the CEO and Founder of Dorian Software, a log management company acquired by Ipswitch in late 2009. He loves creating easy-to-use yet powerful software solutions for SMBs and emerging enterprise companies.

The post Remote Desktop Manager Free Edition appeared first on PureRDS.

Auditing Remote Desktop Services Logon Failures (Part 1)

$
0
0

Today we’re going to tackle one of the most frustrating tasks of a Microsoft Remote Desktop Services administrator – tracking failed logons. Many administrators who have migrated their RDS collections from Windows Server 2008 to Windows Server 2012 are shocked to find that auditing RDS logons has changed considerably between the two operating systems.

Auditing Remote Desktop Services Logon Failures on Windows Server 2008 – RDP Security Layer or Bust

Windows Server 2008 can be configured to record detailed information about failed logon attempts with a Logon Type of 10, corresponding to a Terminal Server/Remote Desktop Services session.  This is recorded as Event ID 4625 in the Security Event Log.  Here’s an example of this event, taken from a system undergoing brute force attack attempts via RDP.  You can see that the attacker has used a username of user2, the attack is originating from 118.x.x.x, the logon type is 10 (RDP), and the Logon Process used is User32.

Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 12/23/2016 4:25:40 PM
Event ID: 4625
Task Category: Logon
Level: Information
Keywords: Audit Failure
User: N/A
Computer: HONEYPOT
Description:
An account failed to log on.
Subject:
Security ID: SYSTEM
Account Name: HONEYPOT$
Account Domain: WORKGROUP
Logon ID: 0x3e7
Logon Type: 10
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: user2
Account Domain: HONEYPOT
Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xc000006d
Sub Status: 0xc0000064
Process Information:
Caller Process ID: 0x87c
Caller Process Name: C:\Windows\System32\winlogon.exe
Network Information:
Workstation Name: HONEYPOT
Source Network Address: 118.x.x.x
Source Port: 4375
Detailed Authentication Information:
Logon Process: User32
Authentication Package: Negotiate
Transited Services: –
Package Name (NTLM only): –
Key Length: 0

However, this level of detail in Event ID 4625 will ONLY be generated if you set the RDP Security Layer to RDP via Group Policy or via the properties of RDP-Tcp in the TSConfig.msc administrative console.  If the Security Layer is set to any other level, all pertinent details of the logon failure will not be recorded, nor will you even be able to tell that the logon attempt came over RDP.

Let’s look at a similar event from a server without the Security Layer set to RDP.  As you will see, it is completely useless.  The only think you know is that the attacker tried to logon with a username of Administrator.  Beyond that, you have no idea it came from RDP, as the Logon Type is set to 3 (generic network logon), and there is no Source Network Address recorded.

Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 12/23/2016 6:37:41 PM
Event ID: 4625
Task Category: Logon
Level: Information
Keywords: Audit Failure
User: N/A
Computer: HONEYPOT
Description:
An account failed to log on.
Subject:
Security ID: NULL SID
Account Name: –
Account Domain: –
Logon ID: 0x0
Logon Type: 3
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: ADMINISTRATOR
Account Domain:
Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xc000006d
Sub Status: 0xc0000064
Process Information:
Caller Process ID: 0x0
Caller Process Name: –
Network Information:
Workstation Name:
Source Network Address: –
Source Port: –
Detailed Authentication Information:
Logon Process: NtLmSsp
Authentication Package: NTLM
Transited Services: –
Package Name (NTLM only): –
Key Length: 0

OK, so the answer, if you have a Server 2008 RDS farm, is to configure GPOs to always use RDP as the Security Layer, right?  Not so fast.  Doing so has numerous implications, and the irony is that switching over to the RDP Security Layer actually weakens your security profile, as opposed to using a TLS/SSL Security Layer with Network Level Authentication.  It makes your session hosts more vulnerable to denial-of-service attacks, AND it prevents providing SSO (Single Sign-on) in your environment.  So, you can either use a weaker security layer, and actually be able to determine where RDP hack attempts are coming from, or use a more secure configuration with TLS/SSL and NLA, and have no clue who is attacking you.  A fantastic choice, right?

Enabling RDP as Security Layer To Get Auditable Insight On Logon Failures - A True Faustian Bargain

Enabling RDP as Security Layer To Get Auditable Insight On Logon Failures – A True Faustian Bargain

Auditing Remote Desktop Services Logon Failures on Windows Server 2012 – More Gotchas, Plus Correlation is Key.

In Windows Server 2012, you can still enable RDP as a Security Layer if you want to see complete information in the Event ID 4625 Security Log events (see above).  However, in Windows Server 2012, Network Level Authentication is enabled by default, which will prevent this level of detail from being recorded, even if the Security Layer is set to RDP.  In order to make full auditing information available, you must set the Security Layer to RDP in the Group Policy Object, and you must also EXPLICITLY DISABLE Network Level Authentication in the same GPO area at the same time.  And just like in Windows Server 2008, you weaken your security posture by doing so.

However, in Windows Server 2012, there is a workaround.  You can still use TLS/SSL with NLA for authentication, AND figure out the source of the hack attempts by looking at a little known channel event log buried deep inside the Microsoft Event Viewer.  That log is: RemoteDesktopServices-RDPCoreTS/Operational

Event IDs 140 and 131 in the RemoteDesktopServices-RDPCoreTS channel log hold the keys to correlating RDS logon failures by originating IP.

Event IDs 140 and 131 in the RemoteDesktopServices-RDPCoreTS channel log hold the keys to correlating RDS logon failures by originating IP.

In Windows Server 2012, if an attacker attempts to logon but fails to do so AND uses a username that DOES NOT EXIST on the targeted RDS host or domain that the host is a member of, Event ID 140 is logged, showing you the source IP of the attacker. For example:

Log Name: Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational
Source: Microsoft-Windows-RemoteDesktopServices-RdpCoreTS
Date: 1/2/2017 7:11:29 PM
Event ID: 140
Task Category: RemoteFX module
Level: Warning
Keywords:
User: NETWORK SERVICE
Computer: HONEYPOT
Description:
A connection from the client computer with an IP address of 172.x.x.x failed because the user name or password is not correct.

Note I said username that DOES NOT EXIST. If the attacker is using a username that DOES EXIST on the session host or the domain, Event ID 140 will NOT BE LOGGED. Personally, I think this is a poor implementation of auditing by Microsoft, and I’m not sure why Event ID 140 works that way. Ideally, Event ID 140 should be logged for ALL logon failures, not just logon failures with unknown usernames. After all, the event description itself for Event ID 140 says “failed because the user name OR password is not correct.”

Fortunately for us, the RemoteFX subsystem in Windows Server 2012 and Windows Server 2016 DOES log every RDP connection attempt and the source IP. So even if the attacker is using a username which exists on the target machine, you can still correlate the timestamps of Event ID 4625 (Network Type 3) in the Security Log with the timestamps of Event ID 131 in RemoteDesktopServices-RDPCoreTS/Operational channel event log. Event ID 131 looks like this:

Log Name: Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational
Source: Microsoft-Windows-RemoteDesktopServices-RdpCoreTS
Date: 1/2/2017 7:24:31 PM
Event ID: 131
Task Category: RemoteFX module
Level: Information
Keywords:
User: NETWORK SERVICE
Computer: HONEYPOT
Description:
The server accepted a new TCP connection from client 174.x.x.x:30022.

It has been my experience that Event ID 131 is logged a few seconds before the corresponding Event ID 4625 Logon Failure event in the Security Log. So, if you take the timestamp of an Event ID 4625 logon failure event (with Logon Type 3) in the Security Log, and there is a corresponding Event ID 131 and/or Event ID 140 event logged in the RdpCoreTS log a few seconds prior to the 4625 logon failure, chances are the logon failure is associated with the IP address referenced in the 131 and/or 140 events.

Auditing Remote Desktop Services Logon Failures on Windows Server 2016 – Return of the IP

Auditing Terminal Server logon failures in Windows Server 2016 works exactly the same way as in Windows Server 2012, with one important difference. Yes, Event IDs 131 and 140 are logged in the RemoteDesktopServices-RdpCoreTS log. Yes, Event ID 140 is only logged when the logon failure occurs with an unknown username. Yes, Event ID 4625 is logged in the Security Log with a generic Logon Type of 3 (Network), provided NLA is still enabled and the Security Layer has not been downgraded to RDP.

However, here’s the one big difference. In Windows 2016, the Security Log logon failure event (Event ID 4625) DOES log the IP address of the client/attacker. Mind you, it’s still shown as Logon Type 3, but now, you can directly correlate the IP address shown in Event ID 4625 with either Event ID 131 or Event ID 140 in the RdpCoreTS log to verify that this logon failure was in fact a failed Terminal Services logon.

Here’s an example of Event ID 4625 on Windows Server 2016 with the attacker IP address present (e.g. 5.x.x.x). As you can see, it is now being recorded correctly.

Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 1/4/2017 2:49:09 PM
Event ID: 4625
Task Category: Logon
Level: Information
Keywords: Audit Failure
User: N/A
Computer: HONEYPOT
Description:
An account failed to log on.
Subject:
Security ID: NULL SID
Account Name: –
Account Domain: –
Logon ID: 0x0
Logon Type: 3
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: TESTING1
Account Domain:
Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xC000006D
Sub Status: 0xC0000064
Process Information:
Caller Process ID: 0x0
Caller Process Name: –
Network Information:
Workstation Name:
Source Network Address: 5.x.x.x
Source Port: 0
Detailed Authentication Information:
Logon Process: NtLmSsp
Authentication Package: NTLM
Transited Services: –
Package Name (NTLM only): –
Key Length: 0

Auditing Remote Desktop Services Logon Failures – Conclusions

We’ve covered quite a bit of ground in this rather lengthy blog article. Here are the key takeaways:

1.) You can appropriately audit RDS logon failures on Windows Server 2008 RDS farms, but only if you choose RDP for the Security Layer, and disable NLA. This however has a host of nasty consequences, such as making your systems more vulnerable to denial of service attacks, and breaking single sign on.

2.) In Server 2012, you can track down and correlate generic network logon failure events (Event ID 4625 with Logon Type 3) in the Security Log to remote desktop logon attempts by using Event IDs 131 and 140 in the RdpCoreTS channel log mentioned above. This correlation can be done via timestamp similarities only.

3.) In Server 2016, you can track down and correlate generic network logon failure events in the same way as Windows Server 2012, but now you can correlate them via timestamps and IP addresses.

4.) Microsoft REALLY needs to fix Event ID 140 so that it is logged in the RdpCoreTS channel log EVERY TIME a failed RDS logon happens, not only when the username is unknown.

In Part 2 of this blog series, I’ll look at how RDS logon failures work when a Remote Desktop Gateway has been deployed in the environment, and I’ll also design some PowerShell scripts to help correlate the information from different logs.  Until then, happy and safe remoting!

Andy Milford is the CEO and Founder of RDPSoft, and is a Microsoft MVP in the Enterprise Mobility / Remote Desktop Services area. Prior to starting RDPSoft, Andy was the CEO and Founder of Dorian Software, a log management company acquired by Ipswitch in late 2009. He loves creating easy-to-use yet powerful software solutions for SMBs and emerging enterprise companies.

The post Auditing Remote Desktop Services Logon Failures (Part 1) appeared first on PureRDS.


Adjust RDP Permissions With Brand New Free Tool – RDSConfig

$
0
0

RDPSoft’s New Free Tool, RDSConfig.exe, Allows You To Adjust RDP Permissions Granularly

Greetings again, everyone. Last year I wrote a blog article about how it was tricky to adjust RDP security permissions on Windows Server 2012 and Windows Server 2016 session hosts to allow non-Administrators to shadow Remote Desktop Users. Back in Windows Server 2008, Microsoft provided an MMC snap-in called TSConfig.msc, also known as the Remote Desktop Session Host Configuration tool. This tool would allow you to adjust a whole host of properties regarding session host behavior and rules for user sessions, including who could connect to and who could administer different aspects of Remote Desktop Services on that host.

TSConfig.msc, as well as TSAdmin.msc (for active user and process management), were removed from the RDS management tools starting in Windows Server 2012. The RDSM (Remote Desktop Services Manager) available within the Server Manager console in Windows Server 2012, allows you to do *some* of the administrative functions that you used to do in TSAdmin.msc and TSConfig.msc respectively, but not all of them. Even in Windows Server 2016, RDSM has not reached feature parity with the old set of tools.

TSConfig.msc went bye bye in Windows Server 2012, and with it, the option to granularly adjust RDP permissions.

TSConfig.msc went bye bye in Windows Server 2012, and with it, the option to granularly adjust RDP permissions.

This is problematic, because while you can adjust certain aspects of RDS configuration both from within the RDSM and directly in Group Policy, there are some things you still cannot get to. Like RDP permissions for instance. In that blog article above, I published a script that would simply grant a user or group full control to perform ALL administrative actions on a Remote Desktop Session Host server via WMI. While effective, this was a pretty crude way to go about it.

RDSConfig

RDSConfig makes adjusting RDP permissions on session hosts super easy.

Therefore, I’ve spent several weeks this year designing a free tool I’m calling RDSConfig (the RDS Configuration Tool) that allows you to adjust RDP permissions on a very granular basis. You can add/remove accounts to the Remote Desktop Protocol ACL (Access Control List), adjust their permissions granularly (just like the old TSConfig.msc tool), but you can also do some cool new things, like quickly add users with permission presets (e.g. Guest, Standard, or Full Control/Admin), or completely reset the RDP Access Control List back to the “out of the box” defaults.

Grant RDS Account Permissions

You can adjust account policies using common presets…

Grant RDS Account Permissions Granular

… or you can adjust each individual permission granularly

It is my hope to add support for adjusting *auditing policies* as well in the near future for RDS users, but after some initial research, there seem to be a few bugs in the API related to audit policy administration. However, I think I’ve found a workaround, so I hope to add that feature set soon. I’ll also be adding features to adjust many of the more common, group policy adjustable settings, such as the licensing server the session host should use, idle/disconnect times, color depth, and much more. This will make RDS deployments in non-domain or non-collection based environments easier, because you can bypass the RDSM and/or Group Policy manager as needed.

Download the RDSConfig Beta Now!

RDSConfig is now in beta – click here to download it now. This tool requires v4 of the .NET Framework, and its installer will attempt to download/install the framework if you don’t already have it. Feel free to make any feature suggestions in the comments below. You can also submit any bug reports at the RDPSoft corporate site here.

Also, if you haven’t already downloaded and installed Remote Desktop Commander Lite, please visit this page to learn more about this other free tool and grab a copy. Remote Desktop Commander Lite effectively replaces most of the old functionality of TSAdmin.msc, works in all RDS environments (domain, workgroup, collection based, non collection based), and also has many additional features, such as displaying RDP connection quality and latency. We will be bundling RDSConfig with Remote Desktop Commander Lite soon.

Andy Milford is the CEO and Founder of RDPSoft, and is a Microsoft MVP in the Enterprise Mobility / Remote Desktop Services area. Prior to starting RDPSoft, Andy was the CEO and Founder of Dorian Software, a log management company acquired by Ipswitch in late 2009. He loves creating easy-to-use yet powerful software solutions for SMBs and emerging enterprise companies.

The post Adjust RDP Permissions With Brand New Free Tool – RDSConfig appeared first on PureRDS.

Remote Desktop Services Logon Failure Correlation with New Tool

$
0
0

Our new Tool, the RDPSoft RDS Log Viewer, tracks and correlates each remote desktop services logon failure and successful logon.

In an earlier post about how to track a remote desktop services logon failure, I documented just how difficult it was to determine the user account of a logon failure and then correlate it with the source IP of the attacker. Moreover, there are subtle differences in how to do such RDP logon failure correlation between Windows Server 2012 and Windows Server 2016.

I’m very pleased today to announce a beta version of my latest free tool, the RDPSoft RDS Log Viewer. The RDS Log Viewer does the heavy lifting for you – regardless of what your RDP Security Layer is set to. It displays the traditional “security log only” RDS logon failures when the Security Layer is set to RDP, but more importantly it automatically correlates logon failures when the Security Layer is TLS/SSL with Network Level Authentication (NLA). In the beta, it also shows you all successful RDS authentications as well. To accomplish this, its correlation engine grabs events from a small handful of event logs on the target session host.

Correlate Remote Desktop Services Logon Failure

The RDS Log Viewer automatically correlates RDS Logon Failures regardless of the Security Layer of your session hosts.

Additional initial features include the ability to both export the results to comma-delimited text, and geolocate the IP address of the attacker.

As I mentioned, this is just the first release of this tool. We will be expanding the capabilities of the RDS Log Viewer to bring in many more types of data, whether recorded on session hosts, RD gateways, or connection brokers. We will also be building some of this technology into our full commercial tool, the Remote Desktop Commander Suite, and we will eventually integrate it into the Remote Desktop Commander Lite free tool as well.

The best part? You can download it for free today here. Just like the RDSConfig tool for adjusting RDP permissions, and the Remote Desktop Commander Lite utility for session management, it’s another community contribution as part of my Microsoft MVP award. Please send me your feedback here.

Andy Milford is the CEO and Founder of RDPSoft, and is a Microsoft MVP in the Enterprise Mobility / Remote Desktop Services area. Prior to starting RDPSoft, Andy was the CEO and Founder of Dorian Software, a log management company acquired by Ipswitch in late 2009. He loves creating easy-to-use yet powerful software solutions for SMBs and emerging enterprise companies.

The post Remote Desktop Services Logon Failure Correlation with New Tool appeared first on PureRDS.

Remote Desktop Gateway Login Failure Auditing

$
0
0

Hello again everyone! I’m releasing a book on how to secure your Remote Desktop Services infrastructure this year, and I’ll be posting some excerpts/topics from the book here on my PureRDS.org blog prior to its release. Please sign up here if you’d like to be notified when my book is released.

Recapping RDP Login Failure Correlation on RDS Session Hosts

In my first article on auditing remote desktop services login failures, I talked about how different authentication methods (e.g. NLA versus no-NLA) and operating system levels (Server 2008, Server 2012 R2, Server 2016) affect the ability to successfully audit RDP brute force attacks on RDS session hosts that are directly connected to the Internet. Because it’s so tedious to do this sort of log parsing manually, I elected to write and release a free tool called the RDS Log Viewer that would do this sort of correlation for you automatically. I updated that tool last year to do some Remote Desktop Gateway login failure tracking too. Later, I leveraged those RDP login and login failure correlation techniques to add some amazing IP geolocation tracking, interactive maps, and automated RDP login reporting to our commercial Remote Desktop Commander Tool.

“I Don’t Worry About RDP Hacking Attempts Any More, Because I Placed My RDS Deployment Behind a Remote Desktop Gateway.”

However, its becoming increasingly important to start auditing login failures through your Remote Desktop Gateway servers as well. For a while, there was a perception among admins running a Remote Desktop Services deployment that as long as you had your Remote Desktop session hosts placed behind a Remote Desktop Gateway, you were relatively impervious to brute force hack attacks. Now, in 2019, that idea cannot be farther from the truth.

As recently as late last year, brute force hacking tools and Python scripts, all easily downloadable from public GitHub repositories, have been updated to include modules that now attempt to brute force RDP gateway servers in addition to the session hosts themselves. At its core, the Remote Desktop Gateway is designed to receive authentication attempts over HTTPS – all it takes is a single, specially formed request to the gateway over 443 to make a login attempt. If you’d like to know more of the gory details about how this works – sign up here to be notified when my book is released.

So how do you know if your Remote Desktop Gateway servers are getting peppered with Brute Force attacks? It’s as simple as scanning for Event ID 4625 in the event log. Since Windows Server 2008, authentication failures to the Remote Desktop Gateway are recorded just like any other login failure, with the external IP address of the attacker logged in the event. Here’s an example:

Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 2/6/2019 7:24:46 AM
Event ID: 4625
Task Category: Logon
Level: Information
Keywords: Audit Failure
User: N/A
Computer: rdgw.mydomain123.com
Description:
An account failed to log on.

Subject:
Security ID: NULL SID
Account Name: –
Account Domain: –
Logon ID: 0x0

Logon Type: 3

Account For Which Logon Failed:
Security ID: NULL SID
Account Name: hax0r
Account Domain:

Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xc000006d
Sub Status: 0xc0000064

Process Information:
Caller Process ID: 0x0
Caller Process Name: –

Network Information:
Workstation Name:
Source Network Address: XXX.XXX.XXX.XX
Source Port: 6690

Detailed Authentication Information:
Logon Process: NtLmSsp
Authentication Package: NTLM
Transited Services: –
Package Name (NTLM only): –
Key Length: 0

As you can see, the username the attacker is using to bruteforce is in the Account Name subfield of the “Account For Which Logon Failed” section. Like most login attempts over the network (Login Type 3), the primary username will be displayed as NULL, but unlike direct RDP logins to terminal servers on certain Windows OS levels, we can actually get both the username and the IP address from a single 4625 event.

Note that if you have multiple services that users authenticate against over the Internet on the same VM/server as your RD Gateway Server, there may be authentication failures that originate from those services interspersed with the RD Gateway login failures. Unfortunately, since network login attempts can be treated the same way across the board by the Windows auditing subsystem, there may not be a way to attribute those login failures to one particular service over the other. Therefore, consider having only the RD Gateway service on a specific VM/server exposed to the Internet via specific firewall rules, so you know that all recorded login failures (Event ID 4625, Login Type 3) with a non-internal IP address logged are attributable to that service.

Andy Milford is the CEO and Founder of RDPSoft, and is a Microsoft MVP in the Enterprise Mobility / Remote Desktop Services area. Prior to starting RDPSoft, Andy was the CEO and Founder of Dorian Software, a log management company acquired by Ipswitch in late 2009. He loves creating easy-to-use yet powerful software solutions for SMBs and emerging enterprise companies.

The post Remote Desktop Gateway Login Failure Auditing appeared first on PureRDS.

My RDS Honeypot in Azure – Usernames Susceptible to RDP Brute Force Attacks

$
0
0

By now, word is out among admins that if you stand up a Virtual Machine in Azure or AWS and open up port 3389 to allow RDP access for administrative or app/desktop hosting purposes, you will receive relentless RDP brute force attacks.  Hell, even if you change your endpoint / inbound port mappings in Azure to something other than 3389, the hackers are still probably going to find you!  Public cloud providers like Microsoft and Amazon are just too juicy of a target for attackers to not scan every single port they can with NMAP, leveraging banner grabbing techniques with custom tweaked Python scripts on Kali Linux, etc, etc.

Changing RDP Port in Azure

Remapping your RDP port in Azure still doesn’t keep the bad guys out

As part of my work on an upcoming book about Remote Desktop Security, I’ve set up a few honeypots in Azure to track hacking attempts and research hacking behaviors.  Today’s blog post will highlight some of what I’ve learned about brute force attacks when system usernames are not known to the hacker.  This presumes that you have at least made sure that Network Level Authentication (NLA) is enforced on your server with exposed RDP on the Internet.  If you have DISABLED NLA on your server, then you’re in for a world of hurt.  Not only is your server subject to DOS and DDOS attacks via RDP authentication attempts, but hackers can leverage RDP login screen banner scraping to deduce many of the usernames already present on your server.  I discuss this more in my book but, suffice it to say, disabling NLA on a server with exposed RDP on the Internet is a really, really bad idea.

The Bad Idea Bears Hate NLA

The Bad Idea Bears Always Want You To Disable NLA On Your Servers

What usernames did the bad guys try to brute force on my RDP server?

Here’s a cross-section of some of the most-attempted brute force attack usernames.  I was able to aggregate these by using the login failure collection feature of our commercial Remote Desktop Commander Suite tool.

ADMINISTRATOR 76780
ADMIN 4067
USER 2775
TEST 2139
USER1 1349
TEST1 1273
AZUREUSER 994
MICHAEL 376
ADMINISTRATÖR 360
DANIEL 355
SCANNER 343
CRMADMIN 333
JOHN 327
DAVID 305
SYSADMIN 287
ADMIN1 286
SPADMIN 284
SERVER 273
SCAN 270
JAMES 270
SP_ADMIN 256
MARK 256
SP_FARM 254
BRIAN 251
MIKE 245
ALEX 237
KEVIN 235

I only included the top 25 or so usernames in terms of frequency.  At the top of the list is ADMINISTRATOR, which is no surprise.  Unlike other usernames, the Builtin Administrator account on Windows cannot be locked out, so hackers are free to wail upon that username without mercy. Admittedly this is Security 101, but:

TIP 1 – Rename the Builtin Administrator Account On Your Servers.

Preferably, rename it to something like jmer92331X, that is not your first name, your last name, or anything remotely approaching it!  Because, as you can see from the other login failures, the next most frequently targeted usernames during brute force attacks are some of the most common first names in the Western world.

TIP 2 – Whenever Possible: Do Not Use Simple First Names as Remote Desktop Services Usernames, Don’t Use the Same Naming Convention as Your Organizational Email Addresses, and Decorate Your Usernames With Prefixes/Suffixes.

Hackers employing brute force attack strategies will certainly try common first names, as we can see in the frequency sample collected from my RDP honeypot server above.  Likewise, if they have been able to determine your organization name through various server fingerprinting techniques (more on this in an upcoming blog post), they can then use any number of websites online to look up specific employees AND your default naming conventions to guess usernames on your RDP server.  If you are synchronizing credentials across multiple services like Office 365 and Remote Desktop access, then employing some type of multifactor/two factor authentication mechanism for better security becomes essential.

If your RemoteApp/RDS environment is not integrated with your organization’s primary Active Directory, consider decorating usernames with suffixes or prefixes (e.g. jsmith_dept_hr, hr_dept_kjones) to make them harder to guess.

TIP 3 – If Possible, Rename Well Known Service Account Names On RDP Servers, and/or Deny Them From Being Able To Login Over RDP.

Looking at the cross-section of brute forced usernames, you will see well-known service account usernames like SP_ADMIN and SP_FARM.  Consider renaming these accounts or, if you cannot rename them, make sure that they cannot logon via RDP to the server.  You can do this by adjusting group memberships but, a more definitive way, is to load the Local Security Policy editor (secpol.msc), navigate to Local Policy, User Rights Assignment, and then add those accounts to the “Deny Log On Through Remote Desktop Services” user right.

Stay tuned for more from my RDS Honeypot series.  And, please sign up to be notified when my book on Remote Desktop Security is ready.

Andy Milford is the CEO and Founder of RDPSoft, and is a Microsoft MVP in the Enterprise Mobility / Remote Desktop Services area. Prior to starting RDPSoft, Andy was the CEO and Founder of Dorian Software, a log management company acquired by Ipswitch in late 2009. He loves creating easy-to-use yet powerful software solutions for SMBs and emerging enterprise companies.

The post My RDS Honeypot in Azure – Usernames Susceptible to RDP Brute Force Attacks appeared first on PureRDS.

Brute Force RDP Hacking Is a Lot More Sophisticated Than You Think

$
0
0

In my last article, I showed you some of the most frequently targeted usernames for brute force RDP attacks on one of my RDP honeypot servers in Azure. Not surprisingly, hackers loved to target the built-in Administrator account, followed by common first names, and then common, built-in service accounts.

The purpose of this article will be to show you how SOPHISTICATED brute force hacking attempts against RDP have gotten in recent years. I’ll share real samples from the login failure tables that my Remote Desktop Commander Suite software maintains to prove my point.

Account Lockout Policies – No Longer a Panacea… and Often a Liability!

Back in the late 90s, when I was a young whippersnapper of a college network admin (this was in the wild west days of Windows NT 4.0), defining and setting account lockout policies at the domain level was a commonly accepted best practice. Nowadays, with the proliferation of single sign-on authentication and unified account directories like Azure Active Directory, defining aggressive account lockout policies as a prophylactic security measure no longer makes sense in many circumstances.

In fact, in a Remote Desktop Services environment, aggressively defining account lockout policies can have several serious consequences, and is largely ineffective.

Let’s examine why:

  1. It sets the stage for an eventual DDOS (Distributed Denial-Of-Service) attack that can lockout wide swaths of your user base, creating a huge headache for your admins and service desk help techs if/when that occurs.
  2. It also increases workload for your admins in general, as a certain percentage of your user base (gotta love the ID10T users) will always fat finger their passwords and lock themselves out. If your RDS environment is linked to your domain, an RDP-originated lockout can effectively prevent them from accessing any other services. Yikes!
  3. Modern RDP brute force attacks, as I will now demonstrate to you, skirt around all but the most draconian of account lockout policies, rendering them hopelessly ineffective.

What About Intrusion Detection Systems? Will They Help?

It’s truly an arms race right now between black hat hackers and IDS vendors, in terms of attack techniques versus IDS countermeasures and detection algorithms. I’m sure there are some IDS vendors out there that have developed better detection algorithms for RDP brute force attacks, but the most sophisticated modern brute force attacks are designed to blend in with normal background login failures from users. By that very nature it makes it harder for an IDS system to detect. That’s why month after month we read about one company after another getting PWNED by ransomware and/or their sensitive data getting exfiltrated, where the initial attack vector was RDP.

How are hackers / nation state actors / cybercriminals getting around account lockout policies? They do several things:

  • They leverage botnets or similar to make RDP login attempts originate from many different machines. When you look at these login trials and geolocate their origin, you see bunches of different IP addresses from across the world.
  • They rotate through username password combinations, trying the same username a few times over an extended period of time (30 minutes, 1 hour, 3 hours). In many cases, different usernames are interleaved with one another. By spreading out the attempts and rotating the usernames, the login failures look more organic and benign to an IDS. Also, the lengthy duration in between those attempts prevents lockout of the account.

In a coming article, and in my upcoming book, I’ll talk more about the tools and Python scripts they use to accomplish these brute force techniques. I’ll also speak on how you can block these sorts of attacks using the Remote Desktop Commander Suite solution I built. For now, I’ll conclude this article with a sample of logon failures I obtained from my RDP Honeypot in Azure.

Time LoggedUsernameAttacker IP
12:00:09 AMCOLUMBIANAxxx.209.0.46
12:00:17 AMSAULxxx.209.0.30
12:00:20 AMLAWxxx.238.46.140
12:00:21 AMAAFDEVxxx.209.0.45
12:00:27 AMNETADMINxxx.238.46.121
12:00:29 AMWSP1xxx.238.46.140
12:00:36 AMSBSADMINxxx.238.46.140
12:00:46 AMVISITORxxx.242.228.45
12:00:51 AMADMINISTRATORxxx.71.243.115
12:00:59 AMADMINISTRATORxxx.43.157.98

Above, you can see exactly what I mentioned. Multiple usernames are being tried, with only ADMINISTRATOR being repeated, and only one IP address was used more than once.

Time LoggedUsernameAttacker IP
12:32:54 PMWALTERxxx.156.177.193
5:38:28 PMWALTERxxx.156.177.192
7:41:56 PMWALTERxxx.156.177.192
7:42:29 PMWALTERxxx.156.177.192
7:53:30 PMWALTERxxx.156.177.192
10:22:44 PMWALTERxxx.156.177.193

Yet looking at the above, if we filter out login attempts for a specific user, we’ll see that the login failures for “WALTER” are all coming from the same two IPs in the same subnet. As you will also notice, “WALTER” only managed 6 login failures in a 12 hour period, none of them too close to one another. Is “WALTER” a real user who is klutzy with his passwords, or part of a huge RDP brute forcing botnet?

When we as humans look at all of the data holistically, we know “WALTER” is part of a larger distributed RDP bruteforce attack. But will your IDS be able to make that judgment call? Till next time…

Andy Milford is the CEO and Founder of RDPSoft, and is a Microsoft MVP in the Enterprise Mobility / Remote Desktop Services area. Prior to starting RDPSoft, Andy was the CEO and Founder of Dorian Software, a log management company acquired by Ipswitch in late 2009. He loves creating easy-to-use yet powerful software solutions for SMBs and emerging enterprise companies.

The post Brute Force RDP Hacking Is a Lot More Sophisticated Than You Think appeared first on PureRDS.

Windows Virtual Desktop Internals – TCP Only, Reverse Connect

$
0
0

Alright, folks – Windows Virtual Desktop is now in Public Preview in Azure, so now is the time to dig in and start playing with it! I’ve had the privilege to be working with it in Private Preview, so I’m starting a blog series covering the “under the hood” internals that make WVD different than traditional Remote Desktop Services.

Classic Remote Desktop Services deployments (let’s hope WVD is better than New Coke), whether run on-premises or in Azure on IaaS virtual machines, typically require the use of separate VMs to host the infrastructure roles, such as Remote Desktop Web Access, Remote Desktop Gateway, and the Remote Desktop Connection Broker. What Microsoft has done with Windows Virtual Desktop is to abstract away these traditional Windows Virtual Desktop roles into “black box” web services that they control and maintain as part of Azure. As a result, all you are responsible for are the session hosts that serve up the apps/desktops into which your employees or customers connect.

BTW – in Classic Remote Desktop Services, these logical groupings of session hosts were called RDS collections. In WVD, they are now called host pools. You can provision, tear down, and re-provision these host pools via a limited wizard in Azure, through ARM templates in Azure, or via specialized PowerShell commands. I’ll touch upon these concepts more in upcoming articles.

That being said, in Classic Remote Desktop Services, if a Remote Desktop Gateway was deployed, a client would connect to the gateway over TCP Port 443, authenticate, and then the Gateway would create a secure session inbound to a session host (after consulting with the Connection Broker) over the traditional RDP port 3389. In Server 2012 and later, the RDS Gateway could also use UDP port 3391 to enable dual transport for much better connection quality over higher latency or less-reliable networks.

In Windows Virtual Desktop, things are different. My colleague and fellow MVP Freek Berson alluded to as much in his recent blog article. The RDS/WVD client still connects to the Azure Windows Virtual Desktop Gateway Service over port 443, but then using “black box magic” via agent software on the target session host:
1.) The Windows Virtual Desktop Gateway and Broker Services contact the session host in the host pool that should receive the new client connection, and
2.) That session host establishes a reverse connection back to the client through the Azure WVD Gateway Service. In this way, the Azure WVD Gateway Service is acting as a reverse proxy of sorts.

Windows Virtual Desktop Reverse Connect Server Side
No more port 3389 folks. Just a connection from the Remote Desktop Service back to the Azure WVD Gateway Service sitting in the middle between the client and the session host.
As you’ll notice, on the client side, we have an outbound 443 connection to the same WVD Gateway Service in Azure.

Arguably, this architecture is somewhat more secure than classic RDS, since the connection comes from the session host back TO the client through the WVD Gateway after authentication and validation by the Azure WVD Infrastructure. Also, in Classic RDS deployments, admins often forget to be appropriately restrictive with their CAPs (Connection Authorization Policies) and RAPs (Resource Authorization Policies) on their RD Gateways, setting up a scenario where just about any Windows host running RDP can be accessed once any domain user was authenticated through the RD Gateway. In WVD, you have to explicitly indicate the users that will be permitted to connect to any given host pool during host pool creation.

One noticeable difference, now, is the lack of UDP traffic between the client and server. This has direct implications on how robust WVD can be over higher latency connections whereby remote workers in one part of the world attempt to connect to WVD resources in a distant Azure region. I have a feeling Microsoft’s answer to this will be “place your host pools in the Azure geographic region most suitable for your clients” and/or “create as many host pools in different regions as required to serve your clients.” However, that adds both architectural complexity and cost, so it is my hope that RDP dual transport featuring UDP will eventually come to WVD. Until then, it may make sense to continue to set up Classic RDS in Azure with the traditional infrastructure role services under YOUR direct control as opposed to deploying WVD, since dual transport with TCP/UDP will still work in those circumstances.

Andy Milford is the CEO and Founder of RDPSoft, and is a Microsoft MVP in the Enterprise Mobility / Remote Desktop Services area. Prior to starting RDPSoft, Andy was the CEO and Founder of Dorian Software, a log management company acquired by Ipswitch in late 2009. He loves creating easy-to-use yet powerful software solutions for SMBs and emerging enterprise companies.

The post Windows Virtual Desktop Internals – TCP Only, Reverse Connect appeared first on PureRDS.

Remote Desktop Kiosk Mode for Windows Server 2012/2016/2019

$
0
0

Several months ago, I spoke to a client who ran an internal application in a Kiosk mode with Remote Desktop Services on Windows Server 2008, and they wanted to start hosting this same application on Windows Server 2016. They had configured their terminal servers to store a cached login so that anyone connecting to those servers was logged in automatically, and a specific line of business application was launched immediately. On Windows Server 2008, they used the Remote Desktop Session Host Configuration utility (tsconfig.msc) to make these changes, but since TSConfig went bye-bye starting in Windows Server 2012, they didn’t know how to replicate the process on Server 2016.

Creating a cached RDP login on Windows Server 2008
It used to be a lot easier to create an automatic, cached Kiosk-style RDP login in Server 2008

The Solution: Registry Tweaks and Powershell WMI Calls

After doing some research, I determined that it was possible to replicate this behavior on Windows Server 2012 and later, but that it required both some registry tweaks and some specific WMI calls via Powershell in a specific order. Here are the steps I took, and I’ve bundled both the batch file and the PowerShell script in a downloadable zip file below.

First, a big disclaimer: You should only use these techniques on internal, non-Internet connected terminal servers to run a Kiosk-style system. As part of this process, you disable NLA (Network Level Authentication) and you cache login credentials on the server. This severely weakens the security of the terminal server. For Internet connected Remote Desktop Servers, use RemoteApp with individual user authentication and NLA enabled to serve up apps to users.

The first step involved is to change a few registry settings to disable NLA, downgrade the SecurityLayer to RDP authentication, and also to permit the Powershell script to place the server into auto-login mode. Here are those three changes, which I placed into a batch file I called “disablenla.bat.”

DisableNLA.bat

REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v fInheritAutoLogon /t REG_DWORD /d 0 /f
REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication /t REG_DWORD /d 0 /f
REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SecurityLayer /t REG_DWORD /d 0 /f

Once you run the batch file above on a target session host, you then run the following Powershell script to set (cache) specific auto-login credentials, as well as set the initial program (and its working directory) which starts immediately after connecting to the terminal server. This script takes 6 parameters:

  1. RDSHostName – the name of the terminal server to make these changes on.
  2. DomainName – the domain portion of the credentials you are caching for auto-login.
  3. Username – the username portion of the credentials you are caching for auto-login.
  4. Password – the password of the credentials you are caching for auto-login.
  5. PathToStartupProgram – the path of the initial program that runs immediately after the user is signed in.
  6. PathToWorkingDirectory – the working directory used by that initial program.

 

CacheLogonAndSetProgram.ps1

param(
[string]$RDSHostName, [string]$Domainname, [string]$Username, [string]$Password, [string]$PathToStartupProgram, [string]$PathToWorkingDirectory
)

    $WMIHandles = Get-WmiObject -Class "Win32_TSEnvironmentSetting" -Namespace "root\CIMV2\terminalservices" -ComputerName $RDSHostName -Authentication PacketPrivacy -Impersonation Impersonate

    foreach($WMIHandle in $WMIHandles)
    {
        if($WMIHandle.TerminalName -eq "RDP-Tcp")
        {
            $retVal = $WMIHandle.InitialProgram($PathToStartupProgram,$PathToWorkingDirectory)
            $opstatus = "succeeded"
            if($retVal.ReturnValue -eq 0)
            {
                $opstatus = "succeeded"
            }
            else
            {
                $opstatus = "failed"
            }
            Write-Host("The operation to set initial startup program " + $PathToStartupProgram + " on " + $RDSHostname + " " + $opstatus + "`r`n")
        }
    }

    $WMIHandles = Get-WmiObject -Class "Win32_TSLogonSetting" -Namespace "root\CIMV2\terminalservices" -ComputerName $RDSHostName -Authentication PacketPrivacy -Impersonation Impersonate
    foreach($WMIHandle in $WMIHandles)
    {
        if($WMIHandle.TerminalName -eq "RDP-Tcp")
        {

            $retVal = $WMIHandle.SetPromptForPassword(0)
            $opstatus = "succeeded"
            if($retVal.ReturnValue -eq 0)
            {
                $opstatus = "succeeded"
            }
            else
            {
                $opstatus = "failed"
            }
            
            Write-Host("The operation to disable password prompting for " + $Username + " on " + $RDSHostname + " " + $opstatus + "`r`n")


            $retVal = $WMIHandle.ExplicitLogon($Username,$DomainName,$Password)
            $opstatus = "succeeded"
            if($retVal.ReturnValue -eq 0)
            {
                $opstatus = "succeeded"
            }
            else
            {
                $opstatus = "failed"
            }
            Write-Host("The operation to cache logon credentials for " + $Username + " on " + $RDSHostname + " " + $opstatus + "`r`n")
            
            
        }
    }

For your convenience, you can download both the batch file and Powershell script here in a zip file.

Andy Milford is the CEO and Founder of RDPSoft, and is a Microsoft MVP in the Enterprise Mobility / Remote Desktop Services area. Prior to starting RDPSoft, Andy was the CEO and Founder of Dorian Software, a log management company acquired by Ipswitch in late 2009. He loves creating easy-to-use yet powerful software solutions for SMBs and emerging enterprise companies.

The post Remote Desktop Kiosk Mode for Windows Server 2012/2016/2019 appeared first on PureRDS.


Windows Virtual Desktop Shadowing Tips and Tricks

$
0
0

Microsoft is currently running at breakneck speed to get Windows Virtual Desktop out the door and into general availability. One big gap that they have right now within WVD is the management piece, including shadowing. Fortunately, they are partnering with third party vendors – my company RDPSoft included – to bridge this gap as WVD comes to market.

Can I Shadow User Sessions in WVD?

A current challenge with Windows Virtual Desktop is how to provide shadowing, management, and remote assistance to users running on Windows 10 Multi Session hosts in Azure. As you may have read in my previous blog post, the WVD Gateway sets up a reverse proxy with the VMs in the host pool and the inbound WVD clients, so there is no access via port 3389 to these hosts. That’s great for security, but complicates management. Now, you COULD turn on port 3389 for a limited time, using the “Just-in-time” feature of Security Center in Azure, to access a specific host in the host pool directly; but Security Center, even at their Standard Pricing tier, costs $15 per VM per month. Yikes!

The Solution – Publish Your WVD Management Tools as RemoteApps in a Single VM Host Pool

I’m excited to announce that I’ve engineered a much more elegant solution that solves all of these issues AND keeps things secure. I ran a proof of concept setup in my Windows Virtual Desktop environment this week, and it works great. I’ve even attached a small video demonstrating how it works below. Here’s what I did:

  1. I created a single VM host pool in my WVD environment using the host pool provisioning wizard in Azure. Then, I loaded up our RDS Management Software, RDPSoft Remote Desktop Commander, on this single VM. In other words, this single VM will serve as a WVD “Management Application Hub” where all my WVD management tools will live. Do keep in mind the number of admins/help desk users that will be connecting to this VM to run management/remote assistance tools, so you can size it appropriately in terms of vCPUs and Memory.
  2. When I provisioned this WVD management host pool, I connected it to the same VNet in Azure that houses my other WVD host pools and AAD-linked Active Directory VM. Doing so allows the internal traffic necessary to support management, monitoring, and shadowing between my WVD management server running Remote Desktop Commander, and the other VMs in the host pools.
  3. To facilitate management and shadowing with Remote Desktop Commander, I enabled the Remote Registry Service on all Windows 10 Multi Session VMs that I planned to manage. I also turned on the Remote Service Management exception in the Windows Firewall on each host, and verified that the Remote Desktop and Remote Assistance firewall exceptions were already enabled.
  4. I then ran the RDS Management Delegation Wizard in Remote Desktop Commander to delegate specific RDS/WVD management rights (like shadowing) to non-admin accounts in my AAD-linked domain.
  5. Finally, I installed and imported the Windows Virtual Desktop Management Powershell Library (Microsoft.Rdinfra.Rdpowershell.Dll) in order to publish Remote Desktop Commander as a RemoteApp on my single VM WVD Management Hub. Here are the cmdlets I ran:

Powershell Cmdlets I Used to Set Up a Windows Virtual Desktop Shadowing RemoteApp

New-RDSAppGroup MyTenantName MyHostPoolName RemoteDesktopCommander -ResourceType “RemoteApp”

This created a new App Group called RemoteDesktopCommander for all of my RDPSoft WVD Management Tools. Then, I ran:

Get-RDSStartMenuApp MyTenantName MyHostPoolName RemoteDesktopCommander

in order to list all of the installed applications on my virtual machine, so I could find Remote Desktop Commander in the list. Once I wrote down its alias name, I ran:

New-RdsRemoteApp MyTenantName MyHostPoolName RemoteDesktopCommander -Name “Remote Desktop Commander” -AppAlias rdpsoftremotedesktopcommander

…which published Remote Desktop Commander as a RemoteApp in my RDS Management Tools AppGroup. Finally, I ran:

Add-RDSAppGroupUser MyTenantName MyHostPoolName RemoteDesktopCommander -UserPrincipalName helpdeskadminuser@myaadlinkedtenantinazure.onmicrosoft.com

once for each admin and help desk user whom I wanted to have access to Remote Desktop Commander for WVD management and shadowing tasks.

The results? Well, see for yourself in this demo. I launch the WVD client, start the Remote Desktop Commander published RemoteApp, review all of the hosts in the various host pools that I imported from Active Directory, and then start shadowing WVD sessions from within my RemoteApp program using Remote Desktop Commander’s awesome SuperShadow feature, all without opening up a single external port to any of my WVD hosts running Windows 10 Multi Session. Amazing stuff – and the only costs are the monthly infrastructure costs associated with this new VM, plus my Premium Management Features license for Remote Desktop Commander.

Windows Virtual Desktop Shadowing and Management Via RemoteApp
Andy Milford is the CEO and Founder of RDPSoft, and is a Microsoft MVP in the Enterprise Mobility / Remote Desktop Services area. Prior to starting RDPSoft, Andy was the CEO and Founder of Dorian Software, a log management company acquired by Ipswitch in late 2009. He loves creating easy-to-use yet powerful software solutions for SMBs and emerging enterprise companies.

The post Windows Virtual Desktop Shadowing Tips and Tricks appeared first on PureRDS.

Citrix Managed Desktop – Not an Option For SMBs

$
0
0
Citrix Managed Desktop Is Too Damn High

Hey folks – I’ve been watching the announcements from Citrix Synergy around Windows Virtual Desktop this week, and from my perspective, Citrix still does not get (or does not want) the SMB market. Bas just wrote an excellent blog article on Citrix Managed Desktop here – please go read it – but my commentary below will focus on the pricing exclusively. Please note that these are brand new developments, so if pricing / assumptions change, I will update this blog post.

Per Usual, When Citrix “Manages” Anything, It Gets Hella Expensive For You

In order to run Citrix Managed Desktop, you will be shelling out a minimum of $525 per month, every month, even if you have less than 25 users. How so?

Citrix Managed Desktop costs $16 per user per month, with a 25 user minimum. That’s $400 per month right there. On top of that, they make you pre-pay an “Azure Consumption Commitment” of $5 per user per month to be applied to your Azure VM compute costs, which is another $125 per month minimum.

If you don’t already have subscriptions for Microsoft Office 365 / Windows 10 licensing levels that support access to the Windows 10 Multisession OS, you’ll be paying for a Windows RDS CAL on top of that, which will cost another $6 or so per user per month. So, the actual minimum cost could be nearing $700 per month.

Increasingly, It Seems Citrix Just Doesn’t Want Revenue From SMBs or Managed Service Providers

These price points just don’t make sense for Managed Service Providers or most SMBs. As a point of comparison, my company’s Remote Desktop Commander Suite manages and monitors classic RDS deployments and Windows Virtual Desktop deployments for less than $10 per multi user session host VM per month. Given that most user densities are 10 users or more per host, we typically cost less than $1 per named user to layer our solution on top of RDS or Windows Virtual Desktop. That’s 20 times less expensive than Citrix Managed Desktop, and I would argue that Citrix Managed Desktop does not deliver 20 times more value than our offering. Anyway, as in all things software and public cloud, caveat emptor and do your due diligence when calculating total cost of ownership!

Andy Milford is the CEO and Founder of RDPSoft, and is a Microsoft MVP in the Enterprise Mobility / Remote Desktop Services area. Prior to starting RDPSoft, Andy was the CEO and Founder of Dorian Software, a log management company acquired by Ipswitch in late 2009. He loves creating easy-to-use yet powerful software solutions for SMBs and emerging enterprise companies.

The post Citrix Managed Desktop – Not an Option For SMBs appeared first on PureRDS.

Remote Desktop Gateway Security Considerations

$
0
0

Hello everyone! My upcoming book on Remote Desktop security will be released in a few weeks, and I’m posting some excerpts/topics from the book here on my PureRDS.org blog prior to its official launch. Please sign up here if you’d like to be notified when my book is released.

The COVID-19 outbreak has many organizations scrambling to establish or expand their teleworking infrastructure for their employees.  Some companies are simply allowing direct RDP traffic to their servers and workstations over port 3389 – not a good idea as you will see below.  Other companies are more wisely choosing to deploy a Windows Server running the Remote Desktop Gateway service.  That RD Gateway deployment may either be part of a full RDS deployment with Web Access and a Connection Broker, or used as an easy way to route users directly to their individual workstations located within the corporate firewall.  While this is a much better approach than just opening RDP over 3389, there are still security implications of doing so that you need to think about.  Read on below…

Do Not Leave Standalone Remote Desktop Servers Exposed Over the Internet – Place Them Behind a VPN or a Remote Desktop Gateway

If you leave any of your Windows servers directly connected to the Internet with the RDP service open, you’re tempting fate. Do not think that changing the default port from 3389 to a non-standard port offers you any protection. It is trivial for modern botnets and banner scraping tools to scan all open ports on a host, and see if any of the ports respond to an RDP connection sequence. Once the port that RDP is running under is determined, the dictionary attacks and unpatched vulnerability probes will begin in earnest. It only takes one user account with a weak password to be compromised, and then they’re inside your system(s) looking for ways to escalate their privileges.

This warning is doubly important if your remote desktop hosts have been deployed to a large public cloud provider like Azure, AWS, or Google Cloud. Attackers, especially APT (Advanced Persistent Threat) actors, know the IP address ranges assigned to these providers and will preferentially target them first, understanding that RDP will be open on many of the systems for convenience of administration or teleworking.

If your users must connect through a VPN first before gaining access to remote desktop resources, this will prevent direct dictionary attacks over RDP, and hackers will need to target the VPN first. The other option is to place a Remote Desktop Gateway in front of your remote desktop servers, which will authenticate incoming connections over port 443 and then route traffic to/from the remote desktop servers you authorize.

It’s a popular misconception that you have to stand up a full Remote Desktop Services deployment – with the other roles like the Connection Broker and Remote Desktop Web Access deployed – in order to leverage the Remote Desktop Gateway service. If you have a small to medium sized deployment, you can stand up one or more servers running the Remote Desktop Gateway service, connect them to the Internet, and then define connection authorization policies (CAPs) and resource authorization policies (RAPs) that control 1.) the users that can connect in and 2.) the session host servers or personal workstations they in turn can access. Then, all you need to do is reference the public domain name of the Remote Desktop Gateway server, and the internal name of the target session host server or workstation in the RDP files that you distribute to your users.

The principal advantage of using a Remote Desktop Gateway server instead of a VPN is performance; RD Gateway servers set up a TCP and UDP channel for communication between the client devices and the internal remote desktop server, which leads to better performance for clients with higher latency or lossy connections into your environment. Another advantage is that unlike some VPN solutions, you can limit access to only terminal servers in the environment via only the RDP protocol.

Lock Down Your Remote Desktop Gateway Servers With CAPs and RAPs

As discussed in Chapter 8, I much prefer using Microsoft’s Remote Desktop Gateway over a standard VPN to provide external access to a Remote Desktop Services deployment. That being said, most organizations forget to tweak the two most important access features on their Remote Desktop Gateway servers after deploying them to tighten up security in the environment.

Those two features are called Client Authorization Policies (CAPs) and Resource Authorization Policies (RAPs). Put briefly, CAPs control who can log in and access the RDS environment through the Remote Desktop Gateway, and RAPs control what systems they can access once they are successfully authenticated.

By default, a Gateway’s CAP and RAP polices are wide open. Specifically, all Domain Users are granted the ability to attempt an RDP connection on ANY computer account in the domain! Definitely not a good security posture. Do not accept these defaults when setting up a new RDS environment – instead, change the CAP to point to only the group in Active Directory that contains users you want to allow to connect to the RDS collection. Likewise, change the RAP to only permit connections to actual RDS servers or user workstations, not every server that can be accessed via port 3389.

You can always create a different CAP/RAP pair (e.g. allowing RDS administrators to connect to RDS servers and another subset of servers on your network), but you should also consider layering in an additional level of security like Multi-factor Authentication for privileged account access.

For more information on how to set up CAPs and RAPs on your gateway servers, please review this great blog article written by my friend and fellow Microsoft MVP, Freek Berson.

Andy Milford is the CEO and Founder of RDPSoft, and is a Microsoft MVP in the Enterprise Mobility / Remote Desktop Services area. Prior to starting RDPSoft, Andy was the CEO and Founder of Dorian Software, a log management company acquired by Ipswitch in late 2009. He loves creating easy-to-use yet powerful software solutions for SMBs and emerging enterprise companies.

The post Remote Desktop Gateway Security Considerations appeared first on PureRDS.

Stretching Your RDS Environment During COVID-19

$
0
0

Greetings my stressed out readers. Quite a few of you are no doubt working long hours right now in an attempt to provide a functioning remote working environment for your company’s employees. I myself am helping many different companies as they deploy our Remote Desktop Commander Suite and other tools to keep an eye on employee attendance, as well as the health and functioning of their Remote Desktop Services deployments.

That being said, unless you have a big budget and/or are already running your Remote Desktop Environment in the cloud where you can immediately scale up your remote working capacity with a few mouse clicks in a portal, you may be currently stuck with the hardware you have. With that in mind, here are some thoughts on how to “stretch your RDS compute” against the incoming deluge of teleworkers.

Kill the Memory Hogging Applications On Your Terminal Servers

In many RDS environments, the enemy of capacity on a terminal server is not the CPU usage but rather the memory utilization. Common culprits are web browsers, collaboration tools like Teams (sorry Microsoft), and Microsoft Office applications. It’s seldom the line of business application that your employees are supposed to be running that is eating up all of the server resources, in most circumstances. As much as possible, prevent use of the memory hogging programs by preventing them from being used (either through NTFS permissions, GPO settings, or application whitelisting technologies like AppLocker). Users should be running Teams, browser sessions, and other collaboration tools on their client devices as much as possible, not on the terminal servers.

Rein in the Browser Tab Jockeys

If you have to permit web browser use, install some plugins that will control the %$*!$ users who insist on opening 10 tabs at a time and then leaving them running. If you use Google Chrome as your browser du jour, deploy The Great Suspender plugin to automatically suspend browser tabs that have not been used for a while, freeing up their CPU and memory resources. If you are using other web browsers, search for similar plugins (they exist) by looking up phrases like “Tab Suspender.”

Overflow Users Back On To Their Internal Workstations

If you’ve deployed a Remote Desktop Gateway server, and you should for security reasons, you can overflow incoming teleworkers back to their internal company workstations. Simply craft an RDP file that has the public IP address or FQDN of the gateway, but that specifies the user’s internal workstation, and then distribute that RDP file to them. Make sure to update the Resource Authorization Policies (RAPs) on your Gateway server to permit connections to user workstations inside the firewall.

Stand Up a Connection Broker, If You Haven’t Already

Many organizations have a haphazard array of VMs running Remote Desktop Services, with different number of users assigned to each VM. This can generate a lot of wasted compute, as one terminal server may have 10 users, and another with 20, yet both VMs are sized with the same number of virtual processors and memory. Instead, introduce a connection broker into the environment, standardize the apps offered on each terminal server, and then add the terminal servers to an RDS collection controlled by the connection broker. The connection broker will then load balance all users across all of the terminal servers in the collection, allowing you to support a higher capacity of concurrent users.

Convert Full Desktop Collections to RemoteApp Collections Instead

If your users primarily only need to access a handful of line of business applications to do their jobs, create a RemoteApp collection on your connection broker, and then place your terminal servers into that RemoteApp collection and publish only the apps they need to use. Because RemoteApp sessions don’t provide access to the full desktop, or generate as many Windows dependency processes as a full desktop session, you can support a higher number of concurrent users per terminal server.

When All Else Fails, Establish and Enforce Shift Working With User Login Hours and Group Policies

Ideally you don’t want to place restrictions on when users can sign in to do work or access network resources. However, in a worst case scenario, you can enforce shift working by users in different departments by using the Logon Hours feature of Active Directory, and combining it with a GPO that force disconnects users after their shift ends. You could then expand upon that further in the GPO controlling your terminal servers so that disconnected users are auto-logged off after a set period of time. For further ideas around this topic, please review this blog article.

Andy Milford is the CEO and Founder of RDPSoft, and is a Microsoft MVP in the Enterprise Mobility / Remote Desktop Services area. Prior to starting RDPSoft, Andy was the CEO and Founder of Dorian Software, a log management company acquired by Ipswitch in late 2009. He loves creating easy-to-use yet powerful software solutions for SMBs and emerging enterprise companies.

The post Stretching Your RDS Environment During COVID-19 appeared first on PureRDS.

Improving Security Auditing on RDS By Deploying Sysmon (Part 1)

$
0
0

Hello everyone! My new book on Remote Desktop Security has now been released, and I’m posting some excerpts/topics from the book here on my PureRDS.org blog.  Please click here if you’d like to purchase the Amazon Kindle edition.

Out of all of the amazing free tools available at Microsoft’s Sysinternals website, Sysmon is simply indispensable as a supplemental event logging engine. It is incredible in terms of being able to detect malware, and/or other unauthorized use of programs. Therefore, it’s critical that you both deploy this tool to your RDS systems and that you collect and monitor the events it generates. If you do this correctly, you may be able to shut down an attempted compromise of your Remote Desktop Services deployment, before it really gets going. You should make this utility standard on any of your production servers, even the ones not public facing, so you can audit administrator activities and watch for internal threats.

Where to Download Sysmon

So, first things first – you will need to download Sysmon from the Sysinternals website here: https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon

The Activities on Your Remote Desktop Servers That Sysmon Can Detect And Log

When installed from the command line, it generates a service and a companion device driver that intercepts and logs all sorts of system events to a special Windows event log. Here’s a list of some examples:

• Detailed information on process creation/program startup
• Network connections that processes make
• When device drivers are loaded
• When one process creates a thread in another process, which is a common code injection technique used by malware
• File and registry key creations

The entire list of what it can monitor is tremendous. That being said, with those logging capabilities, it is extremely important to tailor the sorts of events it monitors. This will increase the “signal to noise” ratio in such a way that only suspicious events get recorded, and normal software operations do not flood the Sysmon log.

How To Tailor What Activity Sysmon Logs With Configuration Files

Fortunately, several individuals have taken it upon themselves to author and publish Sysmon configuration files that have already been tuned to screen for malware – which you can then further tweak to suit your monitoring requirements.

Moti Bani, a Microsoft employee who blogs frequently about security, is one such individual. First, read his blog post entitled “Sysinternal Sysmon Suspicious Activity Guide” located here: https://docs.microsoft.com/en-us/archive/blogs/motiba/sysinternals-sysmon-suspicious-activity-guide

You may then download his well-tailored Sysmon configuration file from his GitHub repository here: https://github.com/MotiBa/Sysmon/

Continue on to Part 2 of this blog series…

Andy Milford is the CEO and Founder of RDPSoft, and is a Microsoft MVP in the Enterprise Mobility / Remote Desktop Services area. Prior to starting RDPSoft, Andy was the CEO and Founder of Dorian Software, a log management company acquired by Ipswitch in late 2009. He loves creating easy-to-use yet powerful software solutions for SMBs and emerging enterprise companies.

The post Improving Security Auditing on RDS By Deploying Sysmon (Part 1) appeared first on PureRDS.

Viewing all 49 articles
Browse latest View live