Category Archives: All Posts

Windows Server 2008r2 and SQL Server 2008r2 End-of-Life End-of-Support coming soon

Windows Server 2008r2 and SQL Server 2008r2 will be END OF SUPPORT soon. This means no more security updates. SQL Server 2008/R2 supports ends July 2019 and Windows Server 2008R2 support ends January 2020.

Contact us to migrate from Windows Server 2008r2 to 2016 at no charge!

Methods to Secure Windows Remote Desktop RDP

How To Secure Windows Remote Desktop

In September 2018 the FBI issued a public service announcement regarding risks and hacking attempts again the RDP protocol.  See the announcement here which includes some suggestions (with additional considerations below)

Considerations For Securing your Windows Server / RDP Terminal Server

Here is a list of various actions to consider to help secure your remote server environment:

After applying any of the actions above, make sure to test whether they are working properly.  You can open multiple RDP sessions using different user names initiated from one PC which can be useful for testing.


The information provided in this document/post is intended to provide general information only and is not a complete listing of available considerations.  The content is provided AS IS without any express or implied warranties of any kind with respect to the accuracy, correctness, reliability, or fitness for a particular purpose.  You should be discussing all security policies and related procedures, configurations, monitoring and other server management functions with your IT staff or consultants.  Riptide Hosting does not provide managed services and is not a substitute for you maintaining your own IT staff/consultants. 

RD Session Host Security settings in Windows Server 2016

RD Session Host Security settings in Windows Server 2016 (SSL, High encryption, etc.)

Gpedit.msc, computer configuration, administrative templates, windows components, remote desktop services, remote desktop session host, security, see various options.

  • “Require use of specific security layer for remote (RDP) connections” – Changing Security Layer to SSL is the recommendation listed in Windows 2016,
  • “Client Connection Encryption Level to High” – enabled/Yes
  • “Require Secure RPC communication” – enabled/Yes
  • “Require user authentication for remote connections by using NLA” – enabled/Yes

Enable Group Policies to automatically logoff disconnected sessions or idle sessions after X minutes/hours

Enable Group Policies to automatically logoff disconnected sessions or idle sessions after X minutes/hours

Not only does this reduce server resources (ram/cpu) that are used up by disconnected sessions and affecting the overall performance of the remote desktop server, automatically logging off disconnected and idle sessions may help lessen risk if vulnerabilities in Windows are found that allow a user on one active session to access another active session.  See this post on how to enable policies to automatically logoff disconnected and idle sessions (highly recommended to do, and something we do by default now on new servers):

RD Gateway Role in RDS

RD Gateway Role in RDS

Using the Remote Desktop Gateway Role (RDGW) provides additional security by forcing RDP traffic over https/port 443 (requires SSL certificate) instead of port 3389.

General steps to install the RDGW role on Windows Server 2016: (we have a more detailed post on this too)

  • Install RDGW role which will also install IIS
  • In RD Gateway Manager, create CAP and RAP policies for who can login to the gateway and what resources they can access.
  • For initial testing/deployment, you can create a self-signed certification and change the certificate name to IP address in the name field. Using a self-signed certificate will require you to install the certificate on each client device. Using a SSL cert issued by a certificate authority is preferred and can only be issued in the domain name, not IP address).
  • Confirm that all items in the RD Gateway Manager have green checkmarks.
  • From the RD Connection Client on your local PC, go to more options, advanced tab, enter gateway settings before connecting.
  • Turn off port 3389 to the outside on the Windows Firewall on the server to force traffic to use port 443.

Test deployment

Windows Server Lockout Policies

Lockout Policies (based on username attempts, not IP addresses):

To lock out an account for a period of time after a number of incorrect login attempts (to create delay with recurring failed logins), you can set up Account Lockout Policies in Windows.  It does NOT apply to the Administrator account (so you may want to disable the Administrator account and create a different account with administrator rights – see previous suggestion).  Lockout policies can be useful to prevent brute-force password guessing attacks but can cause your accounts to be locked out without you being able to access the server (so plan accordingly).

Local Security Policy (secpol.msc) -> Security Policies -> Account Policies -> Account Lockout Policy, set values for the three options, OR

Gpedit.msc -> Local Computer Policy -> Computer Configuration -> Windows Settings -> Security Policies -> Account Policies -> Account Lockout Policy, set values for the three options

To unlock an account, (if a legit user is locked out) login under an active account (with administrator properties), go to the locked out user’s properties, and uncheck the box by “account is locked out”.

You can see detailed status of a user account by opening the command prompt and typing “net user [username]”

Limit users who can login via RDP

Limit users who can login via RDP

By default, all users in the “Administrators group” have RDP access rights.  And, of course, all users in the “Remote Desktop Users group” have RDP access rights too.  If you only want some members of the Administrators group to have RDP access, you can adjust this in Local Security Settings as follows: by removing the “administrators group” and then making sure all required remote users are part of the “Remote Desktop Users group”.

Local Security Policy (secpol.msc) -> Security Settings -> Local Policies -> User Rights Assignment -> Allow Logon Through Remote Desktop Services, change settings to remove “Administrators group” (but make sure any users you want to have RDP access are already part of the “Remote Desktop Users Group” especially the one you are currently logged in with).

Change RDP Listening Port

Change RDP Listening Port from default 3389

Changing the RDP listening port to a non-default port may not defeat a determined hacker but it should reduce attacks from automated bots.  **Remember to create new firewall rules to allow the new port number so you don’t accidently lock yourself out.  And remember that end-users will need to add the new port # to the IP address/computer name when logging in, such as 123.456.78.888:5555 where the new listening port is 5555.  If you have MAC users, you should verify if the RD Client for MACs support a port other than 3389.

  • Change port in Registry first – (older link but still should apply)
  • Regedit, then locate and click the following registry subkey: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp\PortNumber On the Edit menu, click Modify, and then click Decimal. Type the new port number, and then click OK. Quit Registry Editor.)
  • Create two new Windows Firewall rules (one for TCP and one for UDP) for the new port number. For example, in a administrative command prompt, type this to create two new inbound rules (tcp & upd) where 35000 is the new port you used in the registry change:

netsh advfirewall firewall add rule name=”Remote Desktop (TCP-In) 35000″ dir=in localport=35000 protocol=tcp action=allow

netsh advfirewall firewall add rule name=”Remote Desktop (UDP-In) 35000″ dir=in localport=35000 protocol=udp action=allow

You can compare these new rules to the existing rules in the firewall.

  • Reboot server
  • Then Login using new port number using :ZZZZ where ZZZZ is new RDP listening port – for example, (and also test that 3389 to confirm it won’t work).
  • Disable previous RDP Firewall rules that allowed port 3389

Windows Server 2016 VPN


Using a VPN with RDP is more secure because it provides two steps to access your network.  You could require clients to connect with a VPN first before being able to RDP to the server.  Unless you are using our Dedicated Server Hosting offering where you can have a hardware vpn device, you will need to install a software VPN on the server.  One option is using the free built-in Windows VPN role service. Other software VPN options available have been Hamachi (acquired by LogMeIn), Zerotier which provides software defined networking capabilities, and other options.



If you are interested in setting up the built-in VPN role on Windows Server 2016 and then limiting RDP access to private IPs after VPN is connected, contact Riptide Hosting for a post we wrote on how to set this up.  PPTP VPN using Windows Authentication is password based so strong/complex passwords are still very important. Other VPN protocols, certificate authentication, may provide stronger security depending on your needs and environment.  You can use the built-in Windows VPN to setup a L2TP VPN with preshared keys too.

General steps to install the (free) built-in VPN role on Windows Server 2016:

  • Add “Remote Access” server role with “DirectAccess and VPN (RAS)” role service.
  • Open the Getting Started Wizard, select “Deploy VPN only”, “Configure and Enable Routing and Remote Access”, Select “Custom Configuration”, Select “VPN access” only. Start Service.  Reboot
  • Go into “Routing and Remote Access” properties, IPv4 tab to add static IP address pool with private IPs
  • Change Network Adapter settings, IPv4, to add secondary IP from private IP range above
  • Adjust User Properties for each user on the Dial-In tab to Allow “Network Access Permission”
  • Setup VPN Connection on each user PC (may need to uncheck “use default gateway on remote network” if having internet issues on the PC)
  • Adjust Server Firewall rules to disable RDP access on port 3389
  • Test deployment (verify you can’t RDP without using VPN first, etc.)
  • Our steps generally follow the steps in these links with a few additional items noted

Two-Factor / Dual-Factor Authentication

Two-Factor / Dual-Factor Authentication

There are several third-party software products available that enable two-factor authentication.  One third party software option is Duo Security ( which provides two-factor authentication for RDP access (and more) where you have to enter a code during RDP login that you receive on your smartphone first.  Duo has a free personal account for up to 10 users, trials and various other paid levels.

Disable built-in Administrator account

Disable built-in Administrator account (create alternative admin account)

All Windows Servers come with the built-in Administrator account (SID 500) by default and all administrator accounts have RDP access by default (when RDP is enabled overall).  Therefore the Administrator account, if port 3389 is open, is frequently the target of repeated brute-force hack attempts against this account name.  Options include disabling the Administrator account completely and setup a separate account that has administrator rights, or removing RDP access from the Administrator account.  Make sure you have a different account with admin rights available before disabling the Administrator account so you don’t get locked out.  Generally it is better to disable the Administrator account (and replace with a different account with administration rights) rather than just renaming the Administrator account because the SID remains 500 when you rename it and there are some non-Microsoft tools that allow authentication by using SID rather than account name (but renaming is still better than doing nothing….you can rename the  Administrator account in Local Security Policy (Security Settings, Local Policies, Security Options, Accounts: Rename administrator account) or via gpedit.msc).   We noted on a test server with port 3389 open that over 50% of the failed login attempts were using the “administrator” user name, followed by admin, user, test, user1, etc.

Whitelist IPs: Use Windows Firewall to restrict RDP access to specific IPs only

Whitelist IPs: Use Windows Firewall to restrict RDP access to specific IPs only

If you always connect from the same IP address, or IP address range (or the range your ISP uses), you can restrict RDP access to those IPs through the Windows Firewall (Inbound Rules for Remote Desktop which may consist of multiple rules, TCP-in and UDP-in, and Remote Desktop-User Mode and Remote Desktop Services-User Mode).  Go to the scope tab of the inbound firewall rule and add your IP addresses to the Remote IP list for both rules.  This is a great method to secure RDP when always working from the same location but it won’t work if you plan to access your Remote Desktop Server while traveling because you won’t be using the same static IP address.

Always use complex usernames and passwords for user accounts

Utilize complex usernames/passwords

It’s very important to use mix of special characters, numbers, upper & lower case letters, non-words and require longer length.  Don’t use standard usernames such as administrator, user, user1, test, admin, etc.  Avoid creating passwords that include your name, dictionary words or reusing passwords from other accounts.  You may want to increase the default minimum length beyond 6 characters.  Using simple passwords is the easiest way for someone to compromise your server – do NOT use simple passwords that are vulnerable to brute-force and dictionary attacks.

You can enforce strong/complex passwords and policies at Local Security Policy, Security Settings, Account Policies, Password Policy, see policies including “password must meet complexity requirements”  (or this can be done via gpedit.msc, Computer Configuration -> Windows Settings -> Security Settings -> Account Policies -> Password Policy) – the password complexity policy should be enabled by default on Windows Server 2016 but you should verify and adjust policies if needed (such as keeping password complexity enabled but increase the password length policy to a higher number of characters).  After changing policies, you should always test your changes.

Also, please note that the “user much change password at next logon” selection box in user properties does not work with RDP sessions.  A workaround is to have users manually change their password upon logon by pressing control-alt-end and following the change password prompts within a desktop session.

See following links for additional info:

Make sure to keep this policy Disabled, “Store password using reversible encryption”, as described here:

Windows 2016 Remote Desktop Server RDS doesn’t allow change password at next logon

We have seen several users have this issue where they cannot login if the checkbox in user properties for “user much change password at next logon” has been enabled.  Various comments and posts online indicate that changes in the windows authentication process in recent OS versions don’t allow expired users to change their password via RDP once it expires when Network Level Authentication or Credential Security Support Provider (CredSSP) is enabled.  This is only an issue trying to force users to change their password on a RDP session – it works fine from a console session if you are local to the machine.

Try to un-check this box by “user must change password at next logon” if it is currently checked. Remember to always create complex, strong passwords!

Users can manually change their password upon logon by pressing control-alt-end and following the change password prompts).