Loading ...

Category: Terminal Server

A Medical Office’s Journey to the Cloud

Today we tell the story of a medical office’s journey to the cloud. This particular client was facing their server operating system reaching end of support (a HIPAA violation) in the near future. They had begun by looking at their electronic medical records software company’s online offering, which didn’t have all the functionality of their on-premises software and was very expensive (this is typical).


They next decided to look into moving their current on-premises software into the cloud and we were asked to help with the testing. We determined that it would be best to move the file portion of the server to SharePoint / OneDrive to increase their mobility and flexibility. We also determined that it would be best to move them away from on premises Active Directory into Azure Active Directory / Intune to allow authentication and security policies. Finally we began testing the on-premises software hosted on a server in Azure with a VPN connection to their office.


The SharePoint / OneDrive and Azure Active Directory portions went through with little issues. The server, however, was not as we had hoped. The Azure VPN connection was expensive due to it always being on and no way of turning it off outside of business hours. The performance of the SQL database that the on-premises software used was basically unusable. The other option would be to create virtual desktops on Azure for this purpose but the cost and functionality was not what the customer was hoping for.


This has lead them back to searching for an online EMR software that will meet all their requirements. This will be tough because most companies are good at some things, but not all things and compromises usually have to be made. Our hope is that this story is a lesson to other companies. The cloud may sound like the newest and best way to work, but the costs and functionality are often worse than expected.

If your company is going to use full disk encryption or has compliance requirements that you need consulting for, then contact us for assistance.

FBI Cyber Defense Best Practices

A recent briefing from the FBI’s Internet Internet Crime Complaint Center (IC3) detailed current best practices and industry standards for cyber defense. Here is a summation:

Cyber Defense Best Practices

  • Backups – Regularly back up data and verify its integrity. Backups are critical in ransomware; if you are infected, backups may be the only way to recover your critical data.
  • Training – Employees should be made aware of the threat of ransomware, how it is delivered, and trained on information security principles and techniques.
  • Patching – All endpoints should be patched as vulnerabilities are discovered. This can be made easier through a centralized patch management system.
  • Antivirus – Ensure anti-virus and anti-malware solutions are set to automatically update and that regular scans are conducted. Centrally managed is even better.
  • File Permissions – If a user only needs to read specific files, they should not have write-access to those files, directories, or shares. Configure access controls with least privilege in mind.
  • Macros – Disable macro scripts from Office files transmitted via email.
  • Program Execution Restrictions – Implement software restriction policies or other controls to prevent the execution of programs in common ransomware locations, such as temporary folders supporting popular internet browsers, and compression/decompression programs.
  • Remote Desktop Protocol – Employ best practices for use of RDP, including use of VPN, auditing your network for systems using RDP, closing unused RDP ports, applying two-factor authentication wherever possible, and logging RDP login attempts.
  • Software Whitelisting – Implement application whitelisting. Only allow systems to execute programs known and permitted by security policy. This one takes careful planning.
  • Virtualization – Use virtualized environments to execute operating system environments or specific programs. No physical access to servers makes hacking harder.
  • Network Segmentation – Implement physical and logical separation of networks and data for different organizational units. Keep guest traffic out of your business network.
  • No Saved Passwords – Require users to type information or enter a password when their system communicates with a website. Better yet use a password management tool.

If your company is going to use full disk encryption or has compliance requirements that you need consulting for, then contact us for assistance.

VPN for the Win

Remote User VPN - Grants Pass, OR

In reviewing compliance documentation, we found it necessary to talk about Virtual Private Network (VPN) technology for both privacy and secure remote access. A VPN is a connection to a private network over the internet through an encrypted tunnel – think smuggling information across a secret passageway between two places.

Why use VPN?

Privacy: There has been a huge buzz lately about using VPN technology to help mask you browsing habits from the likes of the NSA or Google. VPN services offer connections that regularly change your external IP address so that a profile (marketing or otherwise) is harder to build. It also makes hacking of your information harder when these services providers offer anti-virus and anti-spam filtering as part of the VPN service.

What are the trade-offs? These VPN service providers will now be the sole owner of your browsing habits – they can sell targeted profiles to marketing companies – so read those terms of service. There will also be a performance hit to your internet speed, so if you are working from a slow network already this may not be an option. Then there is the added cost of an extra $5 to $15 per month for these services on top of your internet bill each month.

Secure Remote Access: This was the original intent of VPN technology and where it really shines. Either from remote workers using coffee shop wifi or remote offices connecting to the main office, VPN tunnels are used to securely access data, servers, and other network resources. This technology is required by all major compliance agencies so that all data transmitted is encrypted during transport. In the past servers would open ports to the internet to allow access, but it was found that this practice allowed hackers the same opportunity to gain access. With VPN tunnels there is another layer of protection from unexpected access. There is also the benefit that no outside provider gets access to your browsing habits.

What are the trade-offs? This will require a router at the main office that is business grade and capable of handling the traffic. It will then require setup of remote workers laptops or remote offices with similar business grade routers.

If your company is concerned about privacy on the internet or secure remote access, then contact us for assistance.

Using External Certificate for RemoteApps in .Local Domain

Recently did some Tier 3 support work for another technology company that was trying to setup a Windows Server 2016 RemoteApps server in Azure that would allow connectivity to remote users for their on-premise software. The process started with creating a VPN tunnel between on-premise and Azure, but that is a discussion for a future set of blog posts. Once this connection  was in place, the company tried to use an external certificate for RemoteApps setup on the server. This would have been fine if the internal domain had not been a “.local”  address scheme. This tutorial assumes that you have already installed Remote Desktop Services on a server and configured it to use the CA provided external certificate.

Change Remote Computer Name

One of the main sticking points that caused issues with security warnings for clients connecting is they would see the warning – “The remote computer could not be authenticated due to problems with its security certificate.” The fix for this has been graciously scripted in PowerShell by someone with the handle “TP” on Technet. The script is called Set-RDPublihedName.ps1 and is used as follows:

Set-RDPublishedName "remote.domain.com"

Proper Active Directory Group

There were then issues with the login process that caused the following error:

Remote Desktop can’t connect to the remote computer “<End Resource Name>” for one of these reasons:

1) Your user account is not authorized to access the RD Gateway “<RD Gateway Server Name>”
2) Your computer is not authorized to access the RD Gateway “<RD Gateway Server Name>”
3) You are using an incompatible authentication method (for example, the RD Gateway might be expecting a smart card but you provided a password)

This was coupled with Security Log messages – “The Network Policy Server was unable to connect to a domain controller in the domain where the account is located. Because of this, authentication and authorization for the RADIUS request could not be performed.” All this turned out to be the RD Gateway was not in the proper Active Directory Group, so added the server to the RAS and IAS Servers group.

Add URL to IIS

There was then an error about not being able to find the computer name, which turned out to be a setting in IIS. Looking under Sites > Default Web Site > RDWeb > Pages click on Application Settings and change the DefaultTSGateway to the URL of the CA external certificate for RemoteApps.

Fixing RS CAP & RAP

Last error that was received was the following:

Remote Desktop can’t connect to the remote computer “computername” for one of these reasons:

1) Your user account is not listed in the RD Gateway’s permission list
2) You might have specified the remote computer in NetBIOS format (for example, computer1), but the RD Gateway is expecting an FQDN or IP address format (for example computer1.fabrikam.com or 157.60.0.1).

This turned out to be related to the RD Client Access Policy (CAP) & Remote Access Policy (RAP) under the RD Gateway Manager tool and DNS. For RD CAP, make sure that Domain Users is listed, and that Client Computer Group membership is blank. FTor RD RAP, make sure that Domain Users is listed, and that it is set to allow connection to Any Network Resource (This allows remote access). For DNS, make sure it contains a Forward Lookup Zone that points to the URL of the CA external certificate for RemoteApps and has an A record for the internal IP address of the RD server.

If your company is currently moving some of your resources to the Azure cloud or wanting to properly setup your RemoteApps server, then contact us for assistance.

Remote Desktop Network Printer Redirection

Found myself setting up a client with a remote desktop connection to a local workstation from a remote site to use their Client Management System (CMS). Even after successfully getting them connected to the local workstation and warning them there would be issues with using their network printer at the remote office, they stated it would be just fine. Found out later indeed they were not able to use the printer successfully due to the inherent issue with network printers across a Remote Desktop Connection. Found this little workaround to provide Remote Desktop network printer redirection in the Microsoft forums:

Remote Desktop network printer redirection workaround

  • Click on the Start button and open Control Panel then open “Devices and Printers”
  • Right click on the network printer that needs to be redirected and choose “Printer Properties”
  • Click on the Ports tab and put a check next to “Enable printer pooling” and next to the “LPT1:” in the list then click the OK button to finish.
    Printer Properties - Ports Tab
  • Click on the Start button and open Remote Desktop Connection then click on the “Local Resources” tab.
    Remote Desktop Connection - Local Resources Tab
  • Click on the “More…” button at the bottom then put a check next to the Ports item then click the OK button.
    Remote Desktop Connection - More Dialog
  • Make sure to go back to the General tab and click on save before clicking on the Connect button.
  • Once connected download and install the needed print driver but do not create the printer itself yet.
  • Inside the Remote Desktop connected computer click on the Start button and open Control Panel then open “Devices and Printer”
  • Click on the Add Printer button at the top then click on the “The printer that I want isn’t listed” link at the bottom of the window that opens.
    Add Printer - Add a Device
  • Click on the radio selection next to “Add a local printer or network printer with manual settings” then click on the next button.
    Add Printer - Find a printer by other options
  • Click on the list “Use an existing port” and choose “TS001:” which usually corresponds to the LPT1: port redirection, but it may take some trial and error going through this list later to figure out which one it is.
  • Search through the list of drivers to pick the one associated with the one being connected then click on the Next button.
  • If requested, choose to “Replace the current driver” and click on the Next button.
  • Change the name as needed and click on the Next button.
  • Choose “Do not share this printer” and click on the Next button.
  • Test the printer by clicking on “Print a test page” then click the Finish button.

If the printer does not print then open the printer properties on the Remote Desktop connected computer and change the port to TS002: on the Ports tab, click Apply then click “Print a test page” on the General tab to test again. Repeat down the list until the correct port is found. If your company is using Remote Desktop Network Printer Redirection or need help getting the network connected printers working properly, then contact us for assistance.

Microsoft Office 2007 EOL Approaches

All good things must come to an end and all software will one day reach End-of-Life (EOL). Microsoft Office 2007 EOL is coming in October 2017 as per the Microsoft Support Lifecycle Site. This will mean that all patching and extended support for the product will end and anything new that goes wrong with the product is ignored by Microsoft. This allows malicious hackers to use these flaws to easily infect systems, encrypt data, exfiltrate data or basically have their way with your systems. Now is the time to consider updating your systems to Office 365 which includes the opportunity to use their fabulous new Exchange Online service along with many other useful cloud based services.

Install Remote Desktop Gateway Role

Here are the basics, as promised earlier, for deploying the Remote Desktop Gateway role on Windows Server 2012 platform. Here are the basic steps to add only this role on a single server:

Install Remote Desktop Gateway Role on Windows Server 2012

  1. Once logged in a administrator, open Server Manager and select “Add servers roles and features”
  2. If you have not already check the box next to “Skip this page by default” then click “Next >”
  3. It is important to select role based installation here before clicking “Next >”. This article only explains how to install RD Gateway, not a full deployment.
  4. Select your server that will host the RD Gateway rolethen click “Next >”
  5. Select Remote Desktop Services role
  6. Skip feature selection as you don’t need anything here
  7. On the Remote Desktop Services role click “Next >”
  8. On the Add Roles and Features Wizard click “Add Features”
  9. Make sure Remote Desktop Gateway role is selected and click “Next >”
  10. On the Network Policy and Access Services (NPS) click “Next >”
  11. Make sure Network Policy Server role is selected and click “Next >”
  12. Make sure leave the defaults for the Web Server Role (IIS) role is selected and click “Next >”
  13. Checked the “Restart the destination server automatically if required” check-box then click “Install”
  14. You may notice that Server Manager states there are no RD Connection Broker servers in the server pool. This is as designed since this is not a complete Remote Desktop Session host environment as we want to have only RD Gateway
  15. In Server Manager go to Tools > Terminal Services > Remote Desktip Gateway Manager and you will see that Remote Desktop Gateway server is not configured. One of the most important things to keep things simple for the user is the RD Gateway certificate (the SSL certificate needs to be installed on BOTH the server and on the client workstation for this will not work). It is highly recommended to get an external SSL Certificate for this process – a great provider is StartSSL as they are free for a basic secure certificate.
  16. Click on “View or modify certificate properties” then click on “Import Certificate…”
  17. Navigate the file downloaded from your certificate provider and import it.
  18. On the right hand side click on the “Create New Authentication Policies Wizard”
  19. In the wizard select “Create RD CAP and a RD RAP (recommended)” then click “Next >”
  20. Name the Remote Desktop Client Access Policy policy then click “Next >”
  21. Leave the default of Password authentication then select an Active Directory User Group (I usually create a specific one for this purpose and add the needed members to it) then click “Next >”
  22. Device redirection and session time out are left at their defaults, so click “Next >”
  23. Name the Remote Desktop Remote Access Policy policy then click “Next >”
  24. Select an Active Directory Computer Group (I usually create a specific one for this purpose and add the needed endpoints to it) then click “Next >”
  25. Leave the default port as 3389 then click “Next >”
  26. Finish the wizard and you will receive successful message the RD RAP and RD CAP policies have been created.
  27. The server is now configured. Go to the client workstation and import the SSL certificate from your provider.
  28. Open the RDP client, click on the “Show Options”, click on the “Advanced” tab then “Settings…”
  29. Specify the RD gateway server here. (The RD Gateway address here and the server name on the certificate needs to be the same.) Then select “Use my RD Gateway credentials for the remote computer” and then click “OK”
  30. On the General tab, specify local computer name of the workstation or server inside the network and full username including local domain then click “Next >”

RDP Gateway NULL SID errors

Recently converted a client’s Windows Standard 2012 R2 terminal server into a Remote Desktop Protocol (RDP) Gateway server so that remote users could connect to their workstations inside the corporate network. (The details of how to do this properly will follow soon in another post.) Once the setup was completed it was time to test the connectivity as follows:

Testing RDP Connectivity

  1. Log into a remote workstation
  2. Open Microsoft Terminal Services Client (MSTSC)
  3. Type in the Computer name and User name into the General tab:
    Remote Desktop Connection - General Tab
  4. Click on the Advanced tab and then on the Settings… button.
    Remote Desktop Connection - Advanced Settings
  5. Choose Use these RD Gateway server settings then type in the external URL of the RDP Gateway
  6. Choose Bypass RD Gateway server for local addresses
  7. Choose Use my RD Gateway credentials for the remote computer then click OK
  8. Should then be able to click Connect to tunnel into that workstation

Issues with NULL SID as follows:

  • Getting errors during login process about inability to connect, noticed that it allowed for credentials at RDP Gateway but then failed when trying to login to local worksations.
  • Attempted to connect from machines without the KB2592687 and KB2830477 installed, but same errors occured.
  • Checked the event logs for the local workstation and found Event ID #4625 NULL SID errors. Which should have pointed to issues with authentication.
  • Tested NTLMv2 login issues via changing the following registry entry:

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa] – LMCompatibilityLevel set above 3

  • Did the same thing via Group Policy using the following setting:

    Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options – “Network security: LAN Manager authentication level” set to Send NTLMv2 response only

  • Finally narrowed it down to NTP settings on the router not being set and mismatch of time.

UmbreCrypt RansomWare Hits Terminal Server

This one scares me to read about. A new variant of ransomware called UmbreCrypt RansomWare is out there that is getting into business networks via hacking of terminal servers. This is even more reason to use the best practice of connecting to a Virtual Private Network (VPN) before connecting to your company terminal server. Please take the time to read this article from BleepingComputer.com to find out the frightening details. Feel free to call or email us to discuss how to proactively protect your business computer network with managed antivirus and offsite backups. Schedule a full network security audit to determine just how vulnerable your systems are and to determine what can be done to mitigate the risks.

Archives

Categories

Plant a Seed @ 541-761-9549
233 Rogue River Hwy #873 Grants Pass, OR 97527
Mon-Fri: 9:00am-5:00pm
support@farmhousenetworking.com
© 2016-2023- Farmhouse Networking. All rights reserved
Terms and Conditions Privacy Policy

Evaluation Signup

[contact-form-7 id="452" title="Free Network Evaluation"]